$("$@") substitutes all the arguments and execute them as a command in command substitution. Since the result of the command resides alone on its own line, it is further executed as a command. This may bring to errors.
Example: suppose the list of arguments is "ls my_dir" and my_dir is a directory containing a file called "testfile". First the shell performs
parameter expansion by substituting $@ with "ls my_dir":
then it performs
command substitution and the statement becomes:
finally it tries to execute testfile as a command, which obviously can trigger a "command not found" error. I think the whole thing serves to log the status of a command without showing the output. In my opinion it would be more correct to assign the result of the command to a dummy (unused) variable. For example:
Code:
log() {
local label=$1
shift
dummy=$("$@")
if [[ $? == 0 ]]
then
status=OK
else
status=ERRPR
fi
echo "$label : status : $status"
}
The log function will be invoked with an identifying label and the command to execute along with its options and arguments. The label will appear in the output but it will not be
executed in command substitution, since the shift statement makes the shell to skip it. Example:
Code:
log "Disk Space" df -k
Regarding the difference between $@ and $*, the former preserve spaces in the arguments so that if you have two arguments, "some string" and "another word", they will be seen as two, whereas $* will see them as four. A last thought is about the order of expansion: the shell performs different types of expansion and they are made in a strict order. Ignoring it can bring to unpredictable behavior in some circumstances.
Here is a complete list of expansion in the order they are executed. Hope this helps.
error handling shell script
