Re: [PATCH] Improve sed portability
- From
- Chris Ridd <chris.ridd@isode.com>
- Date
- Jun 12, 2008, 08:29 UTC
- Message-ID
- <4850DE67.703@isode.com>
- In-Reply-To
- <4850D45E.8000802@viscovery.net>
Johannes Sixt wrote:
Show 29 quoted lines
> Chris Ridd schrieb:
>> Johannes Sixt wrote:
>>> Chris Ridd schrieb:
>>>> @@ -73,7 +73,7 @@ resolve_relative_url ()
>>>> module_name()
>>>> {
>>>> # Do we have "submodule.<something>.path = $1" defined in
>>>> .gitmodules file?
>>>> - re=$(printf '%s' "$1" | sed -e 's/[].[^$\\*]/\\&/g')
>>>> + re=$(printf "%s\n" "$1" | sed -e 's/[].[^$\\*]/\\&/g')
>>> You change sq into dq. Is this not dangerous? Shouldn't backslash-en be
>>> hidden from the shell so that printf can interpret it?
>> It is necessary to use double quotes. This:
>>
>> printf '%s\n' foobar
>>
>> prints a literal \, a literal n, and no newline:
>>
>> foobar\n
>>
>> Not desirable :-(
>
> On both Linux and AIX 4.3 I see:
>
> $ printf 'x\ny'; echo z
> x
> yz
>
> The printf turns the \n into LF.Yes, and I don't know *what* I did yesterday, but Solaris 8, 10, (every OS I mentioned before) behave the same as your test.
I did actually have my eyes tested later on yesterday :-)
> I mentioned this in the first place because I don't know what various > shells do with \n when they see "%s\n". But one way or the other, the \n > will be turned into LF, either by the shell or by printf. So it's not a > big deal.
I agree.
Show 8 quoted lines
>> Of course, using a plain old: >> >> echo "$1" >> >> should work well too. Why is printf being used here and not echo, anyway? > > Because the "$1" could contain character sequences that some 'echo' > implementations mangle.
Indeed. If $1 started with -n that might cause problems on some platforms.
Should I revise my commit to use single quotes again?
Cheers,
Chris