Parameter checking in scripts

[Peter Nikitka]

Hi,

your error is using
. myscript

This is executed directly in the running shell.
Check this:
. myscript a b c

echo $1
a

You have to call the script 'in normal way':

myscript a b c

without leading '. '.

mfG Peter

[James R. Ferguson]

Hi Pete:

Both Hein and Peter N. are correct. A dot character followed by a space followed by the script name means *read* or 'source' the file.

This is used to bring environmental variables into your current environment (shell). For instance, do this:

# cat /tmp/env
#!/usr/bin/sh
export VAR1=jrf
export VAR2=hein
export VAR3=peter

Now, compare:

# /tmp/env
echo "${VAR1}, ${VAR2} ${VAR3}"
sh: VAR1: Parameter not set.

...to:

# . /tmp/env
echo "${VAR1}, ${VAR2} ${VAR3}"
jrf, hein peter

Regards!

...JRF...

[Bill Hassell]

As James points out, 'sourcing' a script means that the current shell remembers any variables that are previously set. So to allow for maximum flexibility, you should always test for the quantity of parameters passed to the script and ignore anything in the variables if the quantity is not correct (or in your case, preset the default values):

#!/usr/bin/sh
set -u

[ $# -eq 1 ] && VAR1=$1 || VAR1=4

echo "VAR1 is $VAR1"

In this case, the test is explicitly for one parameter so anything else (ie, no parameters, two parameters, etc) will leave VAR1=4, otherwise, VAR1 is assigned the first parameter on the command line. As with all interactive scripts, you should assume that monkeys are typing on the keyboard and the value for VAR1 should be tested for validity (ie, not a number, number too large or small, etc)

[PJJ]

I'm lost now, seeing no diff in your explanation.
Using /usr/bin/sh :
$ more /tmp/env
#!/usr/bin/sh
echo "${VAR1}, ${VAR2} ${VAR3}"

$ export VAR1=jrf
$ export VAR2=hein
$ export VAR3=peter

$ /tmp/env
jrf, hein peter
$ . /tmp/env
jrf, hein peter

[Peter Nikitka · Accepted solution]

Hi,

JRF's solutions was (sorry) a bit misleading, because the variables VARi should NOT exported in the calling shell.

Let us try my way:
cat myscript
#!/usr/bin/sh
v1=${1:-jrf}
v2=${2:-hein}
v3=${3:-nik}
echo v1=$v1 v2=$v2 v3=$v3

Now try:
myscript
v1=jrf v2=hein v3=nik

myscript set your params
v1=set v2=your v3=params

. myscript set your params
v1=set v2=your v3=params

. myscript
v1=set v2=your v3=params

myscript
v1=jrf v2=hein v3=nik

set try this
. myscript
v1=try v2=this v3=nik

But you always get your desired result via
myscript Jong
v1=Jong v2=hein v3=nik

mfG Peter

[James R. Ferguson]

Hi (again):

THe 'echo' is run after either running the script or sourcing it. It wasn't part of the script I meant you to run. Eliminating the superflous (yes, misleading) 'export', what I showed was:

#!/usr/bin/sh
VAR1=jrf
VAR2=hein
VAR3=peter
exit

Now, compare:

# /tmp/env #...run the script
# echo "${VAR1}, ${VAR2} ${VAR3}"
sh: VAR1: Parameter not set.
# set #...to see the environmental variables
...to:

# . /tmp/env #...source the script
# echo "${VAR1}, ${VAR2} ${VAR3}"
jrf, hein peter
# set #...now shows VAR1, VAR2 and VAR3 too!

Regards!

...JRF...

[PJJ]

With all this help the 'global-' or 'localness' is clear now.

And for the parameterquestion this is elegant: v1=${1:-jrf}

Thanks all!
Pete

[PJJ]

Closed, thank to all.