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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
