Bash – Using Bash -c with Positional Parameters

bash

Usually, $0 in a script is set to the name of the script, or to whatever it was invoked as (including the path). However, if I use bash with the -c option, $0 is set to the first of the arguments passed after the command string:

bash -c 'echo $0' foo bar 
# foo

In effect, it seems like positional parameters have been shifted, but including $0. However shift in the command string doesn't affect $0 (as normal):

bash -c 'echo $0; shift; echo $0' foo bar
# foo
# foo

Why this apparently odd behaviour for command strings?
Note that I am looking for the reason, the rationale, behind implementing such odd behaviour.

One could speculate that such a command string wouldn't need the $0 parameter as usually defined, so for economy it is also used for normal arguments. However, in that case the behaviour of shift is odd. Another possibility is that $0 is used to define the behaviour of programs (a la bash called as sh or vim called as vi), but that cannot be, since $0 here is only seen in the command string and not by programs called within it. I cannot think of any other uses for $0, so I am at a loss to explain this.

Best Answer

That gives you an opportunity to set/choose $0 when using an inline script. Otherwise, $0 would just be bash.

Then you can do for instance:

$ echo foo > foo
$ bash -c 'wc -c < "${1?}"' getlength foo
4
$ rm -f bar
$ bash -c 'wc -c < "${1?}"' getlength bar
getlength: bar: No such file or directory
$ bash -c 'wc -c < "${1?}"' getlength
getlength: 1: parameter not set

Not all shells used to do that. The Bourne shell did. The Korn (and Almquist) shell chose to have the first parameter go to $1 instead. POSIX eventually went for the Bourne way, so ksh and ash derivatives reverted to that later (more on that at http://www.in-ulm.de/~mascheck/various/find/#shell). That meant that for a long time for sh (which depending on the system was based on the Bourne, Almquist or Korn shell), you didn't know whether the first argument went into $0 or $1, so for portability, you had to do things like:

sh -c 'echo foo in "$1"' foo foo

Or:

sh -c 'shift "$2"; echo txt files are "$@"' tentative-arg0 3 2 *.txt

Thankfully, POSIX has specified the new behavior where the first argument goes in $0, so we can now portably do:

sh -c 'echo txt files are "$@"' meaningful-arg0-for-error *.txt

Related Solutions

Bash – Function caller positional parameters

A function cannot affect its caller's positional parameters. This is by design: positional parameters are meant to be private to the function.

Make your function work on an array.

myfunction () {
  local _myfunction_arrayname=$1
  shift
  … # work on the positional parameters
  eval "$_myfunction_arrayname=(\"\$@\")"
}
myfunction foo "$@"
set -- "${foo[@]}"

In ksh93 and bash, there's a roundabout way to do something approaching by combining an alias and the . (source) builtin with a process substitution. Example.

alias myfunction='. <(echo myfunction_body \"\$@\"; echo set -- "\"\${new_positional_parameters[@]}\"")'

Put the meat of the work of the function in myfunction_body and make it set the array new_positional_parameters. After a call to myfunction, the positional parameters are set to the values that myfunction_body puts in new_positional_parameters.

bash – Passing Braces as Arguments to Bash Function

When you run findinfiles {*.js,*.html,} {release,dev,} "span", here is what happens:

Bash parses quotes and splits the command into words: findinfiles, {*.js,*.html,} {release,dev,} span.
Bash expands the braces, resulting in the list of words findinfiles, *.js, *.html, release, dev, span.
Bash expands the wildcard patterns *.js and *.html to the list of matching file names. If no file name matches either pattern, it is left alone.
Bash looks up the name findinfiles, finds out that it's a function, and executes the function with the supplied parameters.

You can prevent the braces and wildcards from being expanded at the function call, but then the braces will appear literally in the arguments, which isn't particularly useful.

I suggest changing the format of your function call. Instead of using braces, use only commas, and manually split the arguments at commas inside the function.

findinfiles () {
  local patterns="$1" excludes="$2" pattern="$3"
  shift 3
  typeset -a cmd dirs
  if [[ $# -eq 0 ]]; then dirs=(.); else dirs=("$@"); fi
  cmd=(grep --color=auto -iRnHr)
  local IFS=,
  for x in $patterns; do
    cmd+=("--include=$x")
  done
  for x in $excludes; do
    cmd+=("--exclude-dir=$x")
  done
  "${cmd[@]}" "${dirs}"
}

Explanations:

Store the first three parameters in local variables. Any extra parameters are directories to search in.
Set dirs to the list of extra parameters. If there are none, use . (current directory) instead.
Set IFS to a comma. When a script contains an unquoted variable expansion like $patterns and $excludes above, the shell performs the following:
1. Replace the variable by its value.
2. Split the variable into separate words wherever it contains a character that is present in IFS. By default, IFS contains whitespace characters (space, tab and newline).
3. Treat each word as a wildcard pattern and expand it to the list of matching files. If there is no matching file, leave the pattern alone.
(To avoid these expansion steps, use double quotes around the variable substitution, as in patterns="$1" and so on in the script above.)
The function builds the command line to execute incrementally in the array variable cmd. At the end, the command is executed.

Alternatively, you could build on the following settings:

shopt -s extglob globstar
fif_excludes='release dev'
alias fif='grep --color=auto -inH $fif_excludes'

Run commands like

fif span **/*.@(js|html)

Explanations:

shopt -s extglob activates the @(js|html) form of wildcard pattern, which matches either js or html. (This option activates other pattern forms, see the manual for details.)
shopt -s globstar actives the pattern **/ which matches subdirectories at any depth (i.e. it performs a recursive traversal).
To change the exclude list (which I expect doesn't happen often), modify the fif_excludes variable.

Best Answer

Related Solutions

Bash – Function caller positional parameters

bash – Passing Braces as Arguments to Bash Function

Related Question