It's the shell (and the subshell in the latter two examples). Some of
the backslashes are being processed as quoting the next character. The
remainder are being treated literally by echo.
> It's the shell (and the subshell in the latter two examples). Some of
> the backslashes are being processed as quoting the next character. The
> remainder are being treated literally by echo.
I am wondering why case 1 and case 2 give the same output but when
they are put into subshell the output is different?
>> It's the shell (and the subshell in the latter two examples). Some of
>> the backslashes are being processed as quoting the next character. The
>> remainder are being treated literally by echo.
> I am wondering why case 1 and case 2 give the same output
Unquoted backslashes remove special meaning from the following
character (with an exception for a backslash+newline pair).
In the first example the first backslash quotes the second.
echo \\n
\\ -> \
n -> n
echo \n <- final command
In the second example the first backslash quotes the second and the
third backslash quotes the 'n'
echo \\\n
\\ -> \
\n -> n
echo \n <- final command
> but when
> they are put into subshell the output is different?
In the third and fourth examples the backslashes are being processed
twice -- once by the parent shell (outside the `...`) and again by the
subshell (inside the `...`).
When processing a back-quoted command substitution the parent shell
will only treat a backslash as escaping the next character if the next
character is a back-quote, a backslash or a dollar sign. If the
command substitution is within double quotes a backslash also escapes
a double quote.
In the third example the parent shell treats the first backslash as
quoting the second. As the third backslash is not followed by one
of [`\$] it is treated as a literal character. The subshell then
processes the command within back-quotes using unquoted backslash
rules.
echo `echo \\\n`
\\ -> \ }
\ -> \ } parent processing
n -> n }
echo \\n <- subshell command
\\ -> \ } subshell processing
n -> n }
echo \n <- command executed by subshell
\n <- captured output
echo \n <- final command
In the fourth example the parent shell treats the first backslash as
escaping the second. The subshell then processes the backslashes and
treats the '\' as escaping the 'n'.
echo `echo \\n`
\\ -> \ } parent processing
n -> n }
echo \n <- subshell command
\n -> n } subshell processing
echo n <- command executed by subshell
n <- captured output
echo n <- final command
You may be expecting your shell's echo to behave like echo -e.
On Feb 8, 7:20 am, Foo <no-such-u...@gmail.com> wrote:
> Can anyone help me to understand the following behavior of echo?
> bash-4.2$ echo \\n
> \n
> bash-4.2$ echo \\\n
> \n
> bash-4.2$ echo `echo \\\n`
> \n
> bash-4.2$ echo `echo \\n`
> n
I just recently posted a response that is pertainent to this issue,
ostensively dealing with options parsing, but with a script example
and addendum that expands upon your issue:
As for "shell quoting", the only thing that you have to know now, is
that shell, quote parsing, and "word separation" really are internally
consistent, and when (with more scripting experience) you understand
how the shell (an interpreter) differs in the parsing of its code from
a
compiler's usual approach, it will eventually become understandable to
you. In the meantime, some documents to help you on your way are:
On Fri, 10 Feb 2012 at 12:02 GMT, Dave Gibson <dave.gma+news...@googlemail.com.invalid> wrote:
> Foo <no-such-u...@gmail.com> wrote:
>> On Thu, 09 Feb 2012 at 18:35 GMT, Dave Gibson <dave.gma+news...@googlemail.com.invalid> wrote:
>>> Foo <no-such-u...@gmail.com> wrote:
>>>> Hi,
>>>> Can anyone help me to understand the following behavior of echo?
>>> It's the shell (and the subshell in the latter two examples). Some of
>>> the backslashes are being processed as quoting the next character. The
>>> remainder are being treated literally by echo.
>> I am wondering why case 1 and case 2 give the same output
> Unquoted backslashes remove special meaning from the following
> character (with an exception for a backslash+newline pair).
> In the first example the first backslash quotes the second.
> echo \\n
> \\ -> \
> n -> n
> echo \n <- final command
> In the second example the first backslash quotes the second and the
> third backslash quotes the 'n'
> echo \\\n
> \\ -> \
> \n -> n
> echo \n <- final command
>> but when
>> they are put into subshell the output is different?
> In the third and fourth examples the backslashes are being processed
> twice -- once by the parent shell (outside the `...`) and again by the
> subshell (inside the `...`).
> When processing a back-quoted command substitution the parent shell
> will only treat a backslash as escaping the next character if the next
> character is a back-quote, a backslash or a dollar sign. If the
> command substitution is within double quotes a backslash also escapes
> a double quote.
> In the third example the parent shell treats the first backslash as
> quoting the second. As the third backslash is not followed by one
> of [`\$] it is treated as a literal character. The subshell then
> processes the command within back-quotes using unquoted backslash
> rules.
> echo `echo \\\n`
> \\ -> \ }
> \ -> \ } parent processing
> n -> n }
> echo \\n <- subshell command
> \\ -> \ } subshell processing
> n -> n }
> echo \n <- command executed by subshell
> \n <- captured output
> echo \n <- final command
> In the fourth example the parent shell treats the first backslash as
> escaping the second. The subshell then processes the backslashes and
> treats the '\' as escaping the 'n'.
> echo `echo \\n`
> \\ -> \ } parent processing
> n -> n }
> echo \n <- subshell command
> \n -> n } subshell processing
> echo n <- command executed by subshell
> n <- captured output
> echo n <- final command
> You may be expecting your shell's echo to behave like echo -e.
>>>>> Dave Gibson <dave.gma> writes:
>>>>> Foo <no-such-u...@gmail.com> wrote:
>>>>> On Thu, 09 Feb 2012 at 18:35 GMT, Dave Gibson wrote:
>>>>> Foo <no-such-u...@gmail.com> wrote:
>>> It's the shell (and the subshell in the latter two examples). Some
>>> of the backslashes are being processed as quoting the next
>>> character. The remainder are being treated literally by echo.
[...]
>> but when they are put into subshell the output is different?
> In the third and fourth examples the backslashes are being processed
> twice -- once by the parent shell (outside the `...`) and again by
> the subshell (inside the `...`).
... And that's why they prefer $() over `` nowadays. Consider,
e. g.:
In addition to the links already provided, let me add another one just
discovered and appreciated of Sven Mascheck's great resource
regarding shell versions, portability concerns, and their host OSes,
in regard to my most recent posting:
