I'm reading Wicked Cool Shell Scripts. For some reason, the function pasted in below gives the error: ./inpath2: line 10: [: too many arguments. What am I missing?
in_path()
4 {
5 cmd=$1 ourpath=$2 result=1
6 oldIFS=$IFS IFS=":"
7
8 for directory in "$ourpath"
9 do
10 if [ -x $directory/$cmd ] ; then
11 result=0
12 fi
13 done
14
15 IFS=$oldIFS
16 return $result
17
18 }
Are there spaces in any of the $directory ($ourpath) or arguments to the script ($cmd)?
It's always a good idea to double-quote variables, including when they're passed to the function. for works on words, so if there are spaces around it will iterate once for each word in the string.
There's not supposed to be spaces. The script is meant to find and determine if a file is executable based on the user's path. The idea is that it can deal with "ls" or "/bin/ls."
The first thing I would usually do here is echo the variables before the test (before the if), and do some sanitation on them. I would also declare each variable on its own line, and quote them when using them.
To be honest i don't see how this is supposed to be "cool". "Wicked" yes, but cool?
I'd write it this way and you will understand why once you have scripts several thousand lines long to maintain. If this is meant for bash instead of ksh replace "typeset" with "local":
in_path()
{
typeset chCmd="$1" # command
typeset fOurPath="$2" # list of colon-separated dirs
typeset fDir="" # single directory buffer
$chFullDebug
echo "$fOurPath" |\
while IFS=":" read fDir ; do
if [ -x "${fDir}/${chCmd}" ] ; then
return 0
fi
done
return 1
}
A few things to notice:
Variables can change their content easily in shell scripts. Strings can become numbers and vice versa. To maintain a modicum of runtime security i always use qualifiers (see "Hungarian Style Notation") to denote the "type" of a variable. This helps me to keep track in complicated and long scripts. I use:
f... = "file", a filename, directory or generally a path
i... = "int", an integer number
ch.. = "char", a string
l... = "logical", basically an int, but i use only values 0 and 1
It doesn't matter what system you use as long as you stay consistently with it. You do not need to adopt my system, but you should have some system, otherwise you will create a mess over time.
Second: i have declared all my variables i use in the function. This not only encapsulates the function (there is no danger with side effects) but i can also document what i use the variables for and what they should contain. If something goes wrong i can display what is in the variables and compare that with the the mini-data-dictionary at the top of the function.
Third: when the test for an executable is positive there is no point in testing the rest of the path. Therefore i leave the loop immediately via the return -statement in this case.
Fourth: using the while-loop i can specify a custom IFS for the single read -command, so i do not need to save and restore the IFS.
Fifth: all the strings are protected by double-quotes always. This increases run-time security because this way i never have to worry about strings containing white space.
And finally: you notice the line $chFullDebug . This variable is nowhere defined or used in the function. It is a global which i set in my scripts. Under normal conditions the variable is an empty string and the line does nothing. If i need to fully debug a script i set this to set -xv because setting these shell options in the main program would have them switched off with every entering of a subfunction. This way, by writing it into every function i can globally switch debugging on or off.
I hope this helps.
bakunin
Thanks for the quick replies. I'm at work now, but I will try this when I get home. Thanks again.
Wrong quoting.
The for loop actually needs to split on IFS that is set to : so $ourpath must not be in quotes.
The arguments in the following [ ] test should be quoted in general.
8 for directory in $ourpath
9 do
10 if [ -x "$directory/$cmd" ] ; then
Not quoting the $ourpath bares a risk with special characters.
However, a IFS=: read line has the problem that the full line is read into line ; splitting would take place with FS=: read field1 field2 but then you must know the number of fields, so you would need to split into an array, but arrays are a bit specific to bash or ksh...
I found the problem. I really, really hope someone can explain it. The top line does not work. The bottom one does. I manually typed the top line in. I copied and pasted the bottom line from the scripts supplied with the book. The quote marks look different. What in the world is going on here? I'm doing this on KDE Neon and in vim.
for directory in "$ourpath"
for directory in �$ourpath�
I think you have that backwards. The top line should work; the bottom line can't work. The shell command language has rules for constructing commands just like English has rules for constructing sentences. In English, sentences are terminated by a period, a question mark, or an exclamation point. The following is not an English sentence, because a semicolon is not a period, is not a question mark, and is not an exclamation point.
This is not a valid English sentence;
In the shell command language quoted strings are surrounded by double-quote characters ( " ) or single-quote characters ( ' ). And, the opening-double-quote character ( � ) and closing-double-quote character ( � ) is not a double-quote character (although in some fonts they look similar). Instead of being characters delimiting a double-quoted string, they are regular characters that are part of an unquoted string (or if there are whitespace characters between those quotes, part of multiple unquoted strings).
The top line has the normal ASCII quotes.
They work in the sense "protect the variable from splitting and globbing".
But in this case a splitting is wanted (as I said in post #7).
The "wrong" (alternate?) quotes in the second line might, after splitting into words, be added at the beginning of the first word and at the end of the last word. So might also spoil it, in this case the first and last path element.