Johannes Sixt wrote:
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 :-)
@@ -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?
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
--
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
