Re: [PATCH] Improve sed portability
- From
- Chris Ridd <chris.ridd@isode.com>
- Date
- Jun 11, 2008, 15:29 UTC
- Message-ID
- <484FEF71.2030909@isode.com>
- In-Reply-To
- <484FDB5D.7060606@viscovery.net>
Johannes Sixt wrote:
Show 9 quoted lines
> Chris Ridd schrieb: >> On Solaris /usr/bin/sed apparently fails to process input that doesn't >> end in a \n. Consequently constructs like >> >> re=$(printf '%s' foo | sed -e 's/bar/BAR/g' $) >> >> cause re to be set to the empty string. > > So does /usr/bin/sed of AIX 4.3!
I ought to have mentioned this occurs on Solaris 8, 10, build 90 of OpenSolaris, and on HP-UX 11iv1. I stared at that regex for quite a while before realising the problem was with the input :-)
Show 9 quoted lines
>> @@ -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 :-(
Of course, using a plain old:
echo "$1"
should work well too. Why is printf being used here and not echo, anyway?
Show 5 quoted lines
>> name=$( git config -f .gitmodules --get-regexp '^submodule\..*\.path$' | >> sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' ) > > I trust you have tested this. But I wonder whether this leaves a stray > newline in $re that gets in the way inside the sed expression...
Yes, I've tested this as we use submodules heavily. I think the $( .. ) notation will remove the trailing \n printed by sed, but to be sure I inserted a 'set -x' at the top of the module_name() function and double-checked that the re variable didn't get any stray \n character(s). Bash versions 2 and 3 were used.
So without the change, on Solaris I get:
No submodule mapping found in .gitmodules for path 'foobar'
for the first submodule that we use, and the repository clone fails.
With the change, all our repositories clone OK.
Cheers,
Chris