From: Johannes Sixt <j.sixt@viscovery.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Naohiro Aota <naota@elisp.net>,
git@vger.kernel.org, tarmigan+git@gmail.com
Subject: Re: [PATCH] shell portability: Use sed instead of non-portable variable expansion
Date: Mon, 05 Sep 2011 10:16:06 +0200 [thread overview]
Message-ID: <4E648546.8060303@viscovery.net> (raw)
In-Reply-To: <7v39gbxwi6.fsf@alter.siamese.dyndns.org>
Am 9/5/2011 9:45, schrieb Junio C Hamano:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Actually, it's the opposite: Within double-quotes, a backslash is only
>> removed when the next character has a special meaning (essentially $, `,
>> ", \), otherwise, it remains and loses its quoting ability. This means,
>> that the backslash would remain as a literal character in our patterns on
>> the right of % or #, and they would not work anymore as intended.
>
> That's strange...
>
> I thought that VAR=<any string without $IFS character in it> would behave
> identically to VAR="<the same string as above>". You seem to be saying
> that they should act differently.
They are not the same.
First of all, the value of $IFS is irrelevant whether or not you need
double-quotes on the RHS of an assignment, because it is purely a
syntactic matter; $IFS plays no role during syntax analysis. It is only
the presence of white-space that sometimes[*] requires quoting of some form.
The most visible difference is a backslash that is followed by a character
that is not special:
$ foo="a\xb" env | grep foo; foo=a\xb env | grep foo
foo=a\xb
foo=axb
But it is the same elsewhere in a command:
$ echo "a\xb"; echo a\xb
a\xb
axb
The reason is that a backslash inside double-quotes remains as a literal
character when it is not followed by a special character, whereas outside
double-quotes an unquoted backslash is always removed.
[*] No quoting is required in cases like this: VAR=$(echo foo)
>> [?] instead of \? is certainly also worth a try.
>
> I obviously agree. Besides, [?] would sidestep the tricky backslash vs
> double quote issue entirely, so it would be a more robust solution to
> leave it around than "sometimes you need to avoid double-quote and some
> other times you would need double-quote" for other people to mimic writing
> tests later.
Good point, and I shall prefer this solution as well.
-- Hannes
next prev parent reply other threads:[~2011-09-05 8:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-05 5:11 [PATCH] shell portability: Use sed instead of non-portable variable expansion Naohiro Aota
2011-09-05 7:03 ` Johannes Sixt
2011-09-05 7:15 ` Junio C Hamano
2011-09-05 7:35 ` Johannes Sixt
2011-09-05 7:45 ` Junio C Hamano
2011-09-05 8:16 ` Johannes Sixt [this message]
2011-09-05 8:21 ` Johannes Sixt
2011-09-05 7:55 ` Naohiro Aota
2011-09-05 7:09 ` Junio C Hamano
2011-09-05 7:54 ` Johannes Sixt
2011-09-05 8:11 ` Junio C Hamano
2011-09-05 8:22 ` Junio C Hamano
2011-09-06 19:09 ` [PATCH] Makefile: abort on shells that do not support ${parameter%word} expansion Brandon Casey
2011-09-06 19:32 ` Brandon Casey
2011-09-06 20:30 ` Brandon Casey
2011-09-06 20:01 ` Junio C Hamano
2011-09-06 20:09 ` Brandon Casey
2011-09-06 20:03 ` Junio C Hamano
2011-09-06 20:20 ` Brandon Casey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E648546.8060303@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=naota@elisp.net \
--cc=tarmigan+git@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.