Script command vs. terminal input

theCapitain · 11-25-2018, 07:40 AM

Hello,
probably a really basic question, but there it is: does somebody want to tell me why this simple script doesn't work

Code:

#!/bin/bash

unset PATH  

BACKUP_DEVICE="/dev/sdg1"
MOUNTING_POINT="/root/snapshot"

mount -o rw $BACKUP_DEVICE $MOUNTING_POINT

Giving the following error message:

Code:

./test.sh: line 8: mount: No such file or directory

While the exact same commands pasted on the terminal work perfectly?
I have similar troubles with other commands, not only “mount”, so I think I’m doing something wrong.

Thanks for helping

hazel · 11-25-2018, 08:23 AM

If you unset your PATH, bash does not know where to look for executables. So it concludes that they don't exist.

I find no difference when I unset my PATH in a terminal and then call mount.

lougavulin · 11-25-2018, 08:34 AM

Did you write the script yourself ?
What is/was the purpose to unset PATH ? I'm curious to know how or why you came to do that.

theCapitain · 11-26-2018, 07:25 AM

Hi hazel,
thanks for your hint: actually I've taken the script from the web, but I've made a modification. The original was "slightly" different:

Code:

MOUNT=/bin/mount
...
MOUNT -o rw $BACKUP_DEVICE $MOUNTING_POINT

well, I didn't see a point in doing that chain

@lougavulin: the purpose to unset PATH, based on the source script comments, is to avoid accidental use of $PATH. Do you think it is unnecessary?

pan64 · 11-26-2018, 07:37 AM

unset PATH means you remove that variable. bash usually uses it, so removing it is not a good idea.
MOUNT should be used as any other variable: $MOUNT.

BW-userx · 11-26-2018, 07:38 AM

you're the programmer, I do not know how PATH would get accidentally used, unless the script was written

Code:

mount -o rw $PATH $DESTINATION

source -> destination

nodir · 11-26-2018, 09:01 AM

Quote:

Originally Posted by theCapitain

Hi hazel,
thanks for your hint: actually I've taken the script from the web, but I've made a modification. The original was "slightly" different:

Code:

MOUNT=/bin/mount
...
MOUNT -o rw $BACKUP_DEVICE $MOUNTING_POINT

well, I didn't see a point in doing that chain

@lougavulin: the purpose to unset PATH, based on the source script comments, is to avoid accidental use of $PATH. Do you think it is unnecessary?

1) "Variables hold data. Functions hold code. Don't put code inside variables! " from here:
http://mywiki.wooledge.org/BashFAQ/050
(i for one am not that sure in this case, just saying)
2) don't user upper case variables
3) quote *every* substitution
4) #bash IRC bot "Google is NOT a preferred source for learning bash, because almost all the "tutorials" and scripts out there are JUNK." (the reasoning for that harsh comment should be clear from that very short example you found via google).

scasey · 11-26-2018, 09:05 AM

Quote:

Originally Posted by nodir

1) "Variables hold data. Functions hold code. Don't put code inside variables! " from here:
http://mywiki.wooledge.org/BashFAQ/050
(i for one am not that sure in this case, just saying)
2) don't user upper case variables
3) quote *every* substitution
4) #bash IRC bot "Google is NOT a preferred source for learning bash, because almost all the "tutorials" and scripts out there are JUNK." (the reasoning for that harsh comment should be clear from that very short example you found via google).

Disagree strongly with #2! In a case-sensitive environment, upper-case variables are recommended.

scasey · 11-26-2018, 09:07 AM

Quote:

Originally Posted by theCapitain

the purpose to unset PATH, based on the source script comments, is to avoid accidental use of $PATH. Do you think it is unnecessary?

Not only unnecessary, but probably unwise, IMO.
Note (again), that unsetting $PATH has caused the mount command to fail.

nodir · 11-26-2018, 09:23 AM

Quote:

Originally Posted by scasey

Disagree strongly with #2! In a case-sensitive environment, upper-case variables are recommended.

recommended by whom? sure not by #bash

Quote:

By convention, environment variables (PATH, EDITOR, SHELL, ...) and internal shell variables (BASH_VERSION, RANDOM, ...) are fully capitalized. All other variable names should be lowercase. Since variable names are case-sensitive, this convention avoids accidentally overriding environmental and internal variables.

theCapitain · 11-26-2018, 11:18 AM

Quote:

Originally Posted by scasey

Note (again), that unsetting $PATH has caused the mount command to fail.

Sure, it's crystal clear now, I got this all wrong. But my script now works great.
Thank you all.

KenJackson · 11-26-2018, 03:51 PM

Quote:

Originally Posted by theCapitain

But my script now works great.

Excellent!

Quote:

1) "Variables hold data. Functions hold code. Don't put code inside variables! " from here:
http://mywiki.wooledge.org/BashFAQ/050
(i for one am not that sure in this case, just saying)
2) don't user upper case variables
3) quote *every* substitution
4) #bash IRC bot "Google is NOT a preferred source for learning bash, because almost all the "tutorials" and scripts out there are JUNK."

I recommend ignoring this advice.

nodir · 11-26-2018, 04:17 PM

"this advise" you recommend to ignore is from mywki.wooledge.org, #bash irc channel and wiki.bash-hackers.org.
I gave the links and the quotes for the reasoning, instead of simply a "recommendation". User can decide on their own if it makes sense or not.

KenJackson · 11-26-2018, 06:17 PM

Quote:

Originally Posted by nodir

3) quote *every* substitution

Let me give just one reason why just one of these is bad. Do you think this is likely to do what a user intends?

Code:

LIST="file1 file2 file3"
for f in "$LIST"; do     # Quote *every* substitution!
    process "$f"
done

pan64 · 11-27-2018, 12:57 AM

Quote:

Originally Posted by KenJackson

Let me give just one reason why just one of these is bad. Do you think this is likely to do what a user intends?

Code:

LIST="file1 file2 file3"
for f in "$LIST"; do     # Quote *every* substitution!
    process "$f"
done

I'm sorry, but this is not a really good example. It can hardly handle filenames containing spaces.

Code:

LIST=( "file1" "file2" "file3" )
for f in "${LIST[@]}"; do     # Quote *every* substitution!
    process "$f"
done

is the correct syntax.