Re: [PATCH] git-submodule.sh: Don't use $path variable in eval_gettext string
From: Jens Lehmann <hidden>
Date: 2016-06-15 22:53:37
Am 17.04.2012 20:00, schrieb Ramsay Jones:
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <redacted>
---To me it makes sense to rename the problematic $path variable to get rid of this problem.
quoted hunk ↗ jump to hunk
git-submodule.sh | 161 +++++++++++++++++++++++++++--------------------------- 1 file changed, 82 insertions(+), 79 deletions(-)diff --git a/git-submodule.sh b/git-submodule.sh index 3d94a14..64a70d6 100755 --- a/git-submodule.sh +++ b/git-submodule.sh@@ -101,11 +101,12 @@ module_list() module_name() { # Do we have "submodule.<something>.path = $1" defined in .gitmodules file? + sm_path="$1" re=$(printf '%s\n' "$1" | sed -e 's/[].[^$\\*]/\\&/g') name=$( git config -f .gitmodules --get-regexp '^submodule\..*\.path$' | sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' ) test -z "$name" && - die "$(eval_gettext "No submodule mapping found in .gitmodules for path '\$path'")" + die "$(eval_gettext "No submodule mapping found in .gitmodules for path '\$sm_path'")" echo "$name" }
And as an extra this part fixes the bug that the die won't print the submodule path in case of an error as to do that it would have had to use $1 here ;-)