If you can rewrite the script to use parameters instead of script modifications - do so.
There are some legitimate or semi-legitimate cases when you want to modify the script:
- The script can have too many parameters which would be inconvenient to pass in command line. In this case it can be easier to do something like
sed -i "s/@PARAM1@/a/" main.sh
sed -i "s/@PARAM2@/b/" main.sh
...
sed -i "s/@PARAM99999@/zzzzzzzz/" main.sh
But in this case it, would be better to put these parameters into a config file and just read it from the script
- The script can be part of a huge suit of scripts. There the call to
sed
can be looped over several scripts which should share the same hardcoded value. This approach often used in various auto-generators and/or build systems.
But in this case the scripts in question are usually done in a dual way - they do read parameters in a normal fashion, but the sed
sets the default values. Something like:
#!/bin/bash
usage() {
echo "-a=N do something (default value @A@)"
echo "-b=ABC do something else (default value @B@)"
}
A=@A@
B=@B@
while getopts "a:b:" par; do
case $par in
a) A=$OPTARG
;;
b) B=$OPTARG
;;
*) usage
;;
esac
done
echo $A
echo $B
If you have multiple such scripts inside a complicated application, it could be very convenient to pass all them through a loop with sed -i "s/@A@/somevalue" $script
. And after the initial setup of default values you would use parameters.
- The script in question can be not a shell script and not be able to do parameters reading at all. This usually happens with scripts which are by themself are input to some tools (like
sqlplus
or expect
) - the only really legitimate case for "sed
is changing script"
/main.sh
when you usesed -i
? Also./source.sh "name"
does not set any variables in the calling shell. Putting your script in/
is also a bad idea.