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 09:35:49 +0200 [thread overview]
Message-ID: <4E647BD5.8060609@viscovery.net> (raw)
In-Reply-To: <7v7h5nxxwf.fsf@alter.siamese.dyndns.org>
Am 9/5/2011 9:15, schrieb Junio C Hamano:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>>> run_backend() {
>>> echo "$2" |
>>> - QUERY_STRING="${1#*\?}" \
>>> - PATH_TRANSLATED="$HTTPD_DOCUMENT_ROOT_PATH/${1%%\?*}" \
>>
>> What happens if you write these as
>>
>> QUERY_STRING=${1#*\?} \
>> PATH_TRANSLATED=$HTTPD_DOCUMENT_ROOT_PATH/${1%%\?*} \
>>
>> i.e., drop the double-quotes?
>
> Interesting. Your conjecture is that the shell may be dropping the
> backslash inside dq context when it does not understand what follows the
> backslash, i.e. "\?" -> "?", losing the quote. I find it very plausible.
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.
Other shells seem to parse the pattern following % and # in a different
mode, which keeps the quoting ability of the backslash even inside
double-quotes... (And to me it looks like those shells are wrong.)
Without double-quotes, backslashes (that are not themselves quoted) are
always removed and give the subsequent character its literal meaning.
Hence, in my version, the question mark would unambiguously (I think) act
as a literal rather than a wildcard.
> If that is the case, either the above or my [?] would work it around, I
> would think.
[?] instead of \? is certainly also worth a try.
-- Hannes
next prev parent reply other threads:[~2011-09-05 7:36 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 [this message]
2011-09-05 7:45 ` Junio C Hamano
2011-09-05 8:16 ` Johannes Sixt
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=4E647BD5.8060609@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.