Return to Answer

Using quotes enables you to tell the shell where arguments begin and end. Spaces normally tell the shell to perform word splitting, 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:

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:

¹ 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.

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 it is the shell, and not the git command, to which quoting is significant. 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 perform word splitting, 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' 

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 perform word splitting, 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' 

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.

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 it is the shell, and not the git command, to which quoting is significant. 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 perform word splitting, 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'