From: Johannes Sixt <j.sixt@viscovery.net>
Date: Wed, 11 Jun 2008 14:04:13 GMT
Subject: Re: [PATCH] Improve sed portability
Message-ID: <484FDB5D.7060606@viscovery.net>
In-Reply-To: <1213189759-11565-1-git-send-email-chris.ridd@isode.com>

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!

> @@ -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?

>  	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...

>         test -z "$name" &&


-- Hannes