bash quoting function arguments – Pass Arguments to Function Exactly As-Is

argumentsbashfunctionquoting

I have the following function:

bar() { echo $1:$2; }

I am calling this function from another function, foo. foo itself is called as follows:

foo "This is" a test

I want to get the following output:

This is:a

That is, the arguments that bar receives should be the same tokens that I pass into foo.

How does foo need to be implemented in order to achieve this? I’ve tried the following two implementations, but neither works:

foo() { bar $*; }

– output: this:is
foo() { bar "$*"; }

– output: this is a test:

My question is effectively how I can preserve the quoting of arguments. Is this possible at all?

Best Answer

Use "$@":

$ bar() { echo "$1:$2"; }
$ foo() { bar "$@"; }
$ foo "This is" a test
This is:a

"$@" and "$*" have special meanings:

"$@" expands to multiple words without performing expansions for the words (like "$1" "$2" ...).
"$*" joins positional parameters with the first character in IFS (or space if IFS is unset or nothing if IFS is empty).

Related Solutions

Bash – Which of the following shell operations are performed inside the function body when running a function definition and when calling a function

<rant>
“running a function definition” and “running the definition of a function” are not common idioms. I expect that most people would refer to that simply as “defining a function”. OK, that phrase might be interpreted to refer to

conceptually specifying the characteristics and interfaces (parameters and other inputs, processing, and outputs) of a function (this is an activity performed by a person, or a group of people)

choosing the implementation of a function; i.e., what commands to use in the function body. This is an activity performed by a person, or a group of people, possibly using paper, whiteboards, and/or blackboards.

typing the implementation of a function into a text editor or directly into an interactive shell (this, of course, is also an activity performed by a person, or possibly a group of people, or possibly a very intelligent and dexterous cat, dog or monkey)

If you fear confusion with the above, you might be better served by phrases like “reading a function definition” and “processing the definition of a function”.

You say, “A function definition is a command.” It’s not clear what a claim like that even means — it’s a matter of semantics — but, at the semantic level, it’s debatable. Section 3.2 of the Bash manual (Shell Commands) lists six kinds of shell commands: Simple Commands, Pipelines, Lists, Compound Commands, Coprocesses, and GNU Parallel. Function definitions don’t fit well into any of those categories.
</rant>

Getting to your question, and looking at the seven steps / operations,

Reading input obviously has to happen before anything else can happen. It’s, again, a matter of semantics — you could say that reading input from a file or other stream text source is part of “reading a function definition” or that it is a prerequisite / prelude to “processing the definition of a function”.
Breaking the input into words and operators is clearly part of “processing the definition of a function”.
- Breaking the input into tokens is, of course, a prerequisite / prelude to parsing the tokens (step 3, below).
- The manual says, “Alias expansion is performed by this step,” and you show in the question that you know that alias expansion happens when the function definition is read.
Parsing the tokens. This must at least start during the “processing the definition of a function” phase for the shell to realize that it is looking at a function definition and not a simple command. Beyond that, we can do this simple experiment: type either of the following into a shell:
```
myfunc1() {                     myfunc2() {
    <               or              ;
}                               }
```
It will fail with a “syntax error” before you get a chance to type the }. (> and & produce the same effect.) So clearly this step is part of processing the definition of the function.

Performing the various shell expansions is part of calling the function.
- You show in the question that you know that parameter expansion does not happen when the function definition is read.
- It’s equally trivial to demonstrate that pathname / filename expansion does not happen when the function definition is read. In your example, change echo $var (which should be echo "$var", but that’s another matter) to echo *.
  - If you look at the function definition, you’ll see that it still says echo * and has not been expanded.
  - Change directory (cd) and/or create file(s) and/or delete file(s) and/or rename file(s), and then call (execute) the function. You’ll see that it outputs the current list of files¹ in the current directory, and doesn’t reflect the contents of the directory where/when you defined the function.
Performing redirections is part of calling the function. This is also trivial to verify. In your example, change echo $var to echo hello > myfile.
- If you look at the function definition, you’ll see that it still says > myfile.
- Check the directory, and you’ll see that myfile has not been created (yet).
Executing the command — do you really need to ask?
Waiting for the command to complete can’t possibly happen until the command has been executed (step 6), so this obviously is performed only when calling the function.

In other words, exactly what @ilkkachu said.

The one exceptional special case I can think of is that steps 2 and 3 (lexical analysis and parsing) occur (again) when executing a function if the function contains eval statements — but I believe that that’s outside the scope of what your question is really asking.
____________
¹ excluding hidden (dot-) files, unless you have said shopt -s dotglob

Shell Script – Passing Arguments with Spaces and Quotes

"$@" does exactly what you want provided that you use it consistently. Here's a little experiment for you:

script1.sh:
```
#! /bin/sh
./script2.sh "$@"
```
script2.sh:
```
#! /bin/sh
./script3.sh "$@"
```
script3.sh:
```
#! /bin/sh
printf '|%s|\n' "$@"
```

With this the arguments stay unmolested all the way down:

$ ./script1.sh -i input.m4a -metadata "title=Spaces and \$pecial char's" output.m4a
|-i|
|input.m4a|
|-metadata|
|title=Spaces and $pecial char's|
|output.m4a|

Best Answer

Related Solutions

Bash – Which of the following shell operations are performed inside the function body when running a function definition and when calling a function

Shell Script – Passing Arguments with Spaces and Quotes

Related Question