1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-05-08 10:56:08 +02:00

Compare commits

...

3 Commits

Author SHA1 Message Date
Junio C Hamano 7b19149425 Merge branch 'bc/zsh-compatibility' into seen
* bc/zsh-compatibility:
  vimdiff: make script and tests work with zsh
  t4046: avoid continue in &&-chain for zsh
2024-04-26 16:31:59 -07:00
brian m. carlson fedd5c79ff vimdiff: make script and tests work with zsh
When we process the $LAYOUT variable through sed, the result will end
with the character "#".  We then split it at the shell using IFS so that
we can process it a character at a time.

POSIX specifies that only "IFS white space shall be ignored at the
beginning and end of the input".  The hash mark is not a white space
character, so it is not ignored at the beginning and end of the input.

POSIX then specifies that "[e]ach occurrence in the input of an IFS
character that is not IFS white space, along with any adjacent IFS white
space, shall delimit a field, as described previously."  Thus, the final
hash mark delimits a field, and the final field is the empty string.

zsh implements this behavior strictly in compliance with POSIX (and
differently from most other shells), such that we end up with a trailing
empty field.  We don't want this empty field and processing it in the
normal way causes us to fail to parse properly and fail the tests with
"ERROR" entries, so let's just ignore it instead.  This is the behavior
of bash and dash anyway and what was clearly intended, so this is a
reasonable thing to do.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-26 16:31:46 -07:00
brian m. carlson 058b8dc2c2 t4046: avoid continue in &&-chain for zsh
zsh has a bug in which the keyword "continue" within an &&-chain is not
effective and the code following it is executed nonetheless.
Fortunately, this bug has been fixed upstream in 12e5db145 ("51608:
Don't execute commands after "continue &&"", 2023-03-29).  However, zsh
releases very infrequently, so it is not present in a stable release
yet.

That, combined with the fact that almost all zsh users get their shell
from their OS vendor, means that it will likely be a long time before
this problem is fixed for most users.  We have other workarounds in
place for FreeBSD ash and dash, so it shouldn't be too difficult to add
one here, either.

Replace the existing code with a test and if-block, which comes only at
the cost of an additional indentation, and leaves the code a little more
idiomatic anyway.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-26 16:31:46 -07:00
2 changed files with 10 additions and 9 deletions

View File

@ -72,7 +72,6 @@ gen_cmd_aux () {
nested=0
nested_min=100
# Step 1:
#
# Increase/decrease "start"/"end" indices respectively to get rid of
@ -87,7 +86,7 @@ gen_cmd_aux () {
IFS=#
for c in $(echo "$LAYOUT" | sed 's:.:&#:g')
do
if test "$c" = " "
if test -z "$c" || test "$c" = " "
then
continue
fi

View File

@ -20,13 +20,15 @@ test_expect_success setup '
for t in o x
do
path="$b$o$t" &&
case "$path" in ooo) continue ;; esac &&
paths="$paths$path " &&
p=" $path" &&
case "$b" in x) echo "$m1$p" ;; esac &&
case "$o" in x) echo "$m2$p" ;; esac &&
case "$t" in x) echo "$m3$p" ;; esac ||
return 1
if test "$path" != ooo
then
paths="$paths$path " &&
p=" $path" &&
case "$b" in x) echo "$m1$p" ;; esac &&
case "$o" in x) echo "$m2$p" ;; esac &&
case "$t" in x) echo "$m3$p" ;; esac ||
return 1
fi
done
done
done >ls-files-s.expect &&