passing string containing spaces as command-line argument from within script

Question

I'm using a bash shell on mac.

I want to write a shell script 'gac' such that running

> gac one two three

produces exactly the same effect as running

> git add .
> git commit -m "one two three"

So far my script is this:

function gac() {
    git add .
    concatenated="'$*'"
    git commit -m "$concatenated"
}

I found the trick for concatenating the shell arguments into a single space-separated string (second line of script) here. The above script almost works, except that the log message reads

a382806 'one two three'

when I use my shell script, instead of

a382806 one two three

as when I manually type in

> git commit -m "one two three"

on the command line.

Any ideas?

Solution

When you place double quotes around an expansion, such as the parameter expansion $*, the expanded text is not subject to word splitting. (That's one of the reasons to use double quotes around $ expansions; the other is to prevent globbing.) Furthermore, inside double quotes, single quotes are not treated specially, so they do not perform quoting and they are not removed.

So, as Michael Homer says, you can just omit the spurious ' ' marks and your function should work. I suggest writing it like this:

gac() {
    git add .
    git commit -m "$*"
}

You can use the function keyword to define functions in Bash but the syntax shown above works just as well and is portable across Bourne-style shells.

---

To address the conceptual issue here more directly, this line in your original code shows that you wanted to expand a parameter whose value contained spaces, in such a way that you could pass it as a single argument to git:

    concatenated="'$*'"

When you write a single argument yourself that contains spaces, you quote the spaces, usually with quotes around the whole string. The presence of ' ' inside the " " in that line tells me that you were trying to include the quotes that you would normally type.

The reason that approach does not work is that the shell itself is what interprets your quotes; they don't typically mean anything to the command you run from the shell. Suppose you have the command:

some-command 'foo bar' baz

That command does not actually pass any quotation marks to the some-command command. Instead, it runs some-command with foo bar as argument 1 and baz as argument 2. (There is also an argument 0, which tells a program how it was run; the shell passes some-command for that.)

Using quotes enables you to tell the shell where arguments begin and end. Spaces normally tell the shell to treat the text on each side as separate arguments¹, but you want to suppress the spaces' special meaning to the shell, which is what quoting does. When quotes are quoted, like the inner ' ' inside " ", that removes their special meaning too. Then they don't perform quoting, but are instead passed literally to your command, as git showed in its log:

a382806 'one two three'

---

¹ In the operation of the shell, spaces and tabs divide text into separate words in two related but distinct ways. First, when a command is initially parsed, unquoted spaces and tabs separate lexical tokens. Other metacharacters do this, too, but they have additional effects--for example, ; divides a line into multiple commands. Second, where parameter expansion or any other shell expansion signified by a $² is performed in an unquoted context, the result is immediately subjected to word splitting, which uses the characters in $IFS as delimiters. The default value of IFS is a space followed by a tab followed by a newline.

² Or command substitution, even if the ` ` syntax is used instead of the $( ) syntax.

Comments

[Michael Homer]

Have you tried removing the ' characters in "'$*'" that you don't want to be there?

[Eliah Kagan]

It seems this was closed as being about "a typo," which is not the case. Here, the OP deliberately concatenated ' ' with text generated by expanding a parameter. This also isn't a case of ' ' being used where " " is needed; both were used. I'm confident that this is a conceptual question, and I've expanded my answer to address it better, since it occurs to me that if close-voters did not recognize this, then novices who find this by searching may not either. This really shouldn't have been closed and I recommend reopening it.

[azamat alibaev]

by the way the git commit -am 'my message' does the same

[Labrador]

Hi, thanks. I guess I should have looked a bit more closely at what I had copy-and-pasted from the other answer, I could have figured this out on my own :/

[Eliah Kagan]

@Labrador Perhaps so. However, the fundamental issue here is that concatenating quote marks to the result of expanding a parameter does not have the intended effect, but instead passes the quote marks as part of the parameter. Thus the problem being asked about there is not directly relevant to the problem you were trying to solve here. I've added a section to this answer that explains that specifically.

[Gulzar]

this is by far the best answer on this topic, as it actually links to the concepts old linux users assume are trivial