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:
echo "-a=N do something (default value @A@)"
echo "-b=ABC do something else (default value @B@)"
while getopts "a:b:" par; do
case $par in
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
expect) - the only really legitimate case for "
sed is changing script"
/main.shwhen you use
sed -i? Also
./source.sh "name"does not set any variables in the calling shell. Putting your script in
/is also a bad idea.