zsh-workers
 help / color / mirror / code / Atom feed
* Test ./E03posix.ztst was expected to fail, but passed.
@ 2022-03-15 16:33 Vincent Lefevre
  2022-03-15 16:53 ` Mikael Magnusson
  0 siblings, 1 reply; 12+ messages in thread
From: Vincent Lefevre @ 2022-03-15 16:33 UTC (permalink / raw)
  To: zsh-workers

With the git repository on Debian/unstable:

[...]
./E03posix.ztst: starting.
Test ./E03posix.ztst was expected to fail, but passed.
Was testing: Width of %s is computed in bytes not characters
./E03posix.ztst: test XPassed.
The following may (or may not) help identifying the cause:
  This is considered a bugfix in zsh
[...]
**************************************
60 successful test scripts, 1 failure, 3 skipped
**************************************

I don't know the current status... Has this been discussed in the
austin-group list?

Note that "wc" has 2 versions (-c for characters, -m for bytes)
because each of them may be useful. I would expect something
similar for "printf".

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test ./E03posix.ztst was expected to fail, but passed.
  2022-03-15 16:33 Test ./E03posix.ztst was expected to fail, but passed Vincent Lefevre
@ 2022-03-15 16:53 ` Mikael Magnusson
  2022-03-16 15:30   ` Jun. T
  0 siblings, 1 reply; 12+ messages in thread
From: Mikael Magnusson @ 2022-03-15 16:53 UTC (permalink / raw)
  To: zsh-workers

On 3/15/22, Vincent Lefevre <vincent@vinc17.net> wrote:
> With the git repository on Debian/unstable:
>
> [...]
> ./E03posix.ztst: starting.
> Test ./E03posix.ztst was expected to fail, but passed.
> Was testing: Width of %s is computed in bytes not characters
> ./E03posix.ztst: test XPassed.
> The following may (or may not) help identifying the cause:
>   This is considered a bugfix in zsh
> [...]
> **************************************
> 60 successful test scripts, 1 failure, 3 skipped
> **************************************
>
> I don't know the current status... Has this been discussed in the
> austin-group list?
>
> Note that "wc" has 2 versions (-c for characters, -m for bytes)
> because each of them may be useful. I would expect something
> similar for "printf".

Noticed and discussed a bit on IRC the other week/month (sorry for
unedited irc log)

19:16 <Mikachu> oh speaking of tests, i have this in master
19:16 <Mikachu> Test ./E03posix.ztst was expected to fail, but passed.
19:16 <Mikachu> Was testing: Width of %s is computed in bytes not characters
19:16 <Mikachu> ./E03posix.ztst: test XPassed.
19:16 <Mikachu> The following may (or may not) help identifying the cause:
19:16 <Mikachu>   This is considered a bugfix in zsh
19:16 <Mikachu> was this fixed and someone forgot to remove xfail?
19:16 <Mikachu> or is my system magical
19:19 <danielsh> not sure
19:20 <danielsh> what does bin_printf do with 's'?
19:24 <Mikachu> also not sure
19:24 <Mikachu> if i replace two characters with a single ま it
misaligns for me though so no idea what's going on
19:24 <Mikachu> (3 bytes, 2 cells wide)
19:24 <danielsh> one more thing
19:24 <danielsh> I tried the printf manually, outside the test suite
19:25 <danielsh> prints the expected result
19:25 <danielsh> I run the test.  passes.  (= failed as expected)
19:25 <Mikachu> does it fail as expected in the suite for you
19:25 <Mikachu> ah
19:25 <Mikachu> maybe it only sets specific LC vars
19:26 <Mikachu> with LC_ALL=C it works
19:26 <Mikachu> but also wouldn't consider it a bug in this case
19:26 <Mikachu> hmm, also with LC_ALL=sv_SE.UTF-8
19:26 <Mikachu> but my LC_CTYPE is set to that, and LC_ALL is unset
19:26 <Mikachu> confusion
19:26 <danielsh> LC_ALL=C gives me a single space.  which is reasonable
19:27 <Mikachu> oh these are explicitly run with sh emulation too
19:27 <danielsh> the tests run force some locales but not others
19:28 <danielsh> oh forgot that
19:28 <danielsh> still produces expected output interactively
19:28 <danielsh> try running 'locale' in the test and removing the 'f'
flag so we see what locale it runs as ?
19:29 <Mikachu> i'm very confused by this test, when i edit the
command, it doesn't change the result of the test, but if i remove the
whole line it complains about a syntax error, so i AM editing the
right file...
19:29 <danielsh> the test has the 'f' flag
19:29 <Mikachu> oh right
19:30 <Mikachu> it has my locale except LANG=C which is irrelevant
19:31 <danielsh> my locale is C.UTF-8 (mostly) and I get plain C instead
19:31 <danielsh> I wonder if the test should move to D07multibyte
19:32 <danielsh> yeah it passes in D07 without f
19:33 <Mikachu> still fails with a doublewidth japanese char though
19:33 <Mikachu> very strange...
19:34 <Mikachu> anyway, i guess it's not an urgent issue then
19:35 <danielsh> with \'e and Japanese I get three spaces
19:35 <danielsh> but in the test and interactively
19:35 <danielsh> should still move the test though?
19:35 <danielsh> or figure what sets the locale to C
19:36 <danielsh> oh fun ztst.zsh:27-31
19:38 <Mikachu> i don't get why i get different results when LANG is
set to C, LANG isn't used since all my LC_* vars are set
19:38 <danielsh> in D07 ?
19:39 <danielsh> or in E03 ?
19:39 <Mikachu> in E03
19:40 <danielsh> so with LANG=C it fails as expected and with LANG
unset it xpasses, right ?
19:41 <Mikachu> well, the only difference i could spot in the locale
output was LANG, i didn't try unsetting it to see if that affected
it...
19:41 <phy1729> Seems more consistent to  unset $parameters[(I)LC_*]
19:41 <danielsh> the modload may not be available
19:41 <Mikachu> LANG *should* have no effect
19:41 <danielsh> you remember that 'locale' output uses "" specially ?
19:41 <Mikachu> just set LC_ALL
19:41 <Mikachu> yeah
19:41 <phy1729> It's loaded on L44
19:42 <danielsh> L44 of?
19:42 <phy1729> Test/ztst.zsh
19:42 <danielsh> line 43 is wrong though
19:42 <danielsh> you would know :)
19:43 <phy1729> Yes but if no one has complained yet that
zsh/parameter is required, I say keep it :)
19:44 <danielsh> but how will we port zsh to abacuses?
19:44 <Mikachu> we can port zsh to other systems without requiring the
full test suite to be available


-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test ./E03posix.ztst was expected to fail, but passed.
  2022-03-15 16:53 ` Mikael Magnusson
@ 2022-03-16 15:30   ` Jun. T
  2022-03-22  3:32     ` Jun T
  2022-03-29  9:00     ` Jun T
  0 siblings, 2 replies; 12+ messages in thread
From: Jun. T @ 2022-03-16 15:30 UTC (permalink / raw)
  To: zsh-workers


> 2022/03/16 1:53, Mikael Magnusson <mikachu@gmail.com> wrote:
> 
> On 3/15/22, Vincent Lefevre <vincent@vinc17.net> wrote:
>> 
>> Test ./E03posix.ztst was expected to fail, but passed.
>> Was testing: Width of %s is computed in bytes not characters
>> ./E03posix.ztst: test XPassed.
(snip)
>> I don't know the current status... Has this been discussed in the
>> austin-group list?
(snip)
> Noticed and discussed a bit on IRC the other week/month (sorry for
> unedited irc log)
(snip)
> 19:26 <Mikachu> but my LC_CTYPE is set to that, and LC_ALL is unset


Please try the following patch.

The patch for E03posix.ztst may not be necessary for fixing the
current problem, but I think it is always safer to use 'zsh -f'.


diff --git a/Test/E03posix.ztst b/Test/E03posix.ztst
index b191199ad..9695777f6 100644
--- a/Test/E03posix.ztst
+++ b/Test/E03posix.ztst
@@ -125,39 +125,39 @@
 F:POSIX requires a solitary "-" to be a plain argument
 >-
 
-  ARGV0=sh $ZTST_testdir/../Src/zsh -c 'foreach() { true; }'
+  ARGV0=sh $ZTST_testdir/../Src/zsh -fc 'foreach() { true; }'
 -f:"foreach" is not a reserved word
 
-  ARGV0=sh $ZTST_testdir/../Src/zsh -c 'end() { true; }
+  ARGV0=sh $ZTST_testdir/../Src/zsh -fc 'end() { true; }
 -f:"end" is not a reserved word
 
-  a='a:b:' ARGV0=sh $ZTST_testdir/../Src/zsh -c 'IFS=:; printf "<%s>\n" $a'
+  a='a:b:' ARGV0=sh $ZTST_testdir/../Src/zsh -fc 'IFS=:; printf "<%s>\n" $a'
 0f:IFS is a separator, not a delimiter
 ><a>
 ><b>
 
-  a=$'\ra\r\rb' ARGV0=sh $ZTST_testdir/../Src/zsh -c 'IFS=:; printf "<%s>\n" $a'
+  a=$'\ra\r\rb' ARGV0=sh $ZTST_testdir/../Src/zsh -fc 'IFS=:; printf "<%s>\n" $a'
 0f:All whitespace characters are "IFS whitespace"
 F:isspace('\r') is true so \r should behave like space, \t, \n
 F:This may also need to apply to multibyte whitespace
 ><a>
 ><b>
 
-  ARGV0=sh $ZTST_testdir/../Src/zsh -c 'IFS=2; printf "<%s>\n" $((11*11))'
+  ARGV0=sh $ZTST_testdir/../Src/zsh -fc 'IFS=2; printf "<%s>\n" $((11*11))'
 0f:IFS applies to math results (numbers treated as strings)
 ><1>
 ><1>
 
-  ARGV0=sh $ZTST_testdir/../Src/zsh -c 'inf=42; echo $((inf))'
+  ARGV0=sh $ZTST_testdir/../Src/zsh -fc 'inf=42; echo $((inf))'
 0:All identifiers are variable references in POSIX arithmetic
 F:POSIX has neither math functions nor floating point
 >42
 
-  ARGV0=sh $ZTST_testdir/../Src/zsh -c 'EUID=10; echo "$EUID"'
+  ARGV0=sh $ZTST_testdir/../Src/zsh -fc 'EUID=10; echo "$EUID"'
 -f:EUID is not a special variable
 >10
 
-  ARGV0=sh $ZTST_testdir/../Src/zsh -c "printf '<%10s>\n' St$'\M-C\M-)'phane"
+  ARGV0=sh $ZTST_testdir/../Src/zsh -fc "printf '<%10s>\n' St$'\M-C\M-)'phane"
 0f:Width of %s is computed in bytes not characters
 F:This is considered a bugfix in zsh
 ><  Stéphane>
diff --git a/Test/ztst.zsh b/Test/ztst.zsh
index a59c06dcf..43f8ed730 100755
--- a/Test/ztst.zsh
+++ b/Test/ztst.zsh
@@ -25,6 +25,7 @@ emulate -R zsh
 # Ensure the locale does not screw up sorting.  Don't supply a locale
 # unless there's one set, to minimise problems.
 [[ -n $LC_ALL ]] && LC_ALL=C
+[[ -n $LC_CTYPE ]] && LC_CTYPE=C
 [[ -n $LC_COLLATE ]] && LC_COLLATE=C
 [[ -n $LC_NUMERIC ]] && LC_NUMERIC=C
 [[ -n $LC_MESSAGES ]] && LC_MESSAGES=C






^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test ./E03posix.ztst was expected to fail, but passed.
  2022-03-16 15:30   ` Jun. T
@ 2022-03-22  3:32     ` Jun T
  2022-03-22 13:03       ` Vincent Lefevre
  2022-03-22 21:04       ` Bart Schaefer
  2022-03-29  9:00     ` Jun T
  1 sibling, 2 replies; 12+ messages in thread
From: Jun T @ 2022-03-22  3:32 UTC (permalink / raw)
  To: zsh-workers


> 2022/03/17 0:30, I wrote:
> 
> Please try the following patch.

[1] Does this patch solve the problem?

[2] Why is the test marked "expected to fail"?
What does 'F:This is considered a bugfix in zsh' mean?

If the test is expected to be run in C locale, then isn't
< Stéphane>  (a single space before S)
the "correct" result?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test ./E03posix.ztst was expected to fail, but passed.
  2022-03-22  3:32     ` Jun T
@ 2022-03-22 13:03       ` Vincent Lefevre
  2022-03-22 21:04       ` Bart Schaefer
  1 sibling, 0 replies; 12+ messages in thread
From: Vincent Lefevre @ 2022-03-22 13:03 UTC (permalink / raw)
  To: zsh-workers

On 2022-03-22 12:32:41 +0900, Jun T wrote:
> > 2022/03/17 0:30, I wrote:
> > 
> > Please try the following patch.
> 
> [1] Does this patch solve the problem?

I've just tried, and it fixes the problem for me. Thanks.

**************************************
61 successful test scripts, 0 failures, 3 skipped
**************************************

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test ./E03posix.ztst was expected to fail, but passed.
  2022-03-22  3:32     ` Jun T
  2022-03-22 13:03       ` Vincent Lefevre
@ 2022-03-22 21:04       ` Bart Schaefer
  2022-03-23  2:26         ` Vincent Lefevre
  2022-03-23  7:14         ` Jun T
  1 sibling, 2 replies; 12+ messages in thread
From: Bart Schaefer @ 2022-03-22 21:04 UTC (permalink / raw)
  To: Jun T; +Cc: Zsh hackers list

On Mon, Mar 21, 2022 at 8:33 PM Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
>
> [1] Does this patch solve the problem?

All tests pass for me on Ubuntu (which isn't a change from before the
patch, but is not a regression either)

> [2] Why is the test marked "expected to fail"?

POSIX printf counts bytes regardless of locale, zsh printf counts
characters in multibyte locales.  The test is expected to fail because
the sample output represents counting characters.  If the test
succeeds, zsh is not following POSIX printf requirements, and we need
to find out why.  Theoretically, if we've correctly implemented
POSIX_BUILTINS, we should not have to test in the C locale in order
for this test to "fail as expected" and if it succeeds (as not
expected) in any locale, something is wrong with the builtin.

Sorry for not following up on that sooner.  It may mean your patch is
actually masking a problem.

> What does 'F:This is considered a bugfix in zsh' mean?

# It is also possible to add lines in the redirection section beginning
# with `F:'.  The remaining text on all such lines will be concatenated
# (with newlines in between) and displayed in the event of an error.

Specifically in this instance, we consider it a POSIX bug that '%s'
always counts byte positions and that zsh has fixed this when it
counts character positions.

> If the test is expected to be run in C locale, then isn't
> < Stéphane>  (a single space before S)
> the "correct" result?

Yes it is, but it's also the expected result for POSIX_BUILTINS if run
in a different locale.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test ./E03posix.ztst was expected to fail, but passed.
  2022-03-22 21:04       ` Bart Schaefer
@ 2022-03-23  2:26         ` Vincent Lefevre
  2022-03-23 10:38           ` Stephane Chazelas
  2022-03-23  7:14         ` Jun T
  1 sibling, 1 reply; 12+ messages in thread
From: Vincent Lefevre @ 2022-03-23  2:26 UTC (permalink / raw)
  To: zsh-workers

On 2022-03-22 14:04:30 -0700, Bart Schaefer wrote:
> Specifically in this instance, we consider it a POSIX bug that '%s'
> always counts byte positions and that zsh has fixed this when it
> counts character positions.

But, AFAIK, on the POSIX side, it has never been regarded as a bug
(I haven't seen any bug report).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test ./E03posix.ztst was expected to fail, but passed.
  2022-03-22 21:04       ` Bart Schaefer
  2022-03-23  2:26         ` Vincent Lefevre
@ 2022-03-23  7:14         ` Jun T
  2022-03-29  9:10           ` Jun T
  1 sibling, 1 reply; 12+ messages in thread
From: Jun T @ 2022-03-23  7:14 UTC (permalink / raw)
  To: zsh-workers


> 2022/03/23 6:04, Bart Schaefer <schaefer@brasslantern.com> wrote:
> 
> On Mon, Mar 21, 2022 at 8:33 PM Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
> 
>> [2] Why is the test marked "expected to fail"?
> 
> POSIX printf counts bytes regardless of locale, zsh printf counts
> characters in multibyte locales.

>> What does 'F:This is considered a bugfix in zsh' mean?

> Specifically in this instance, we consider it a POSIX bug that '%s'
> always counts byte positions and that zsh has fixed this when it
> counts character positions.

Thanks for the explanation.

If the 'expected to fail' test exists for reminding us that we are
(intentionally?) contradicting with POSIX, the test need be run under
UTF-8 locale (in D07multibyte.ztst), with

>< Stéphane>      # single ' ' before 'S'

as the POSIX-conforming output. Am I right?



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test ./E03posix.ztst was expected to fail, but passed.
  2022-03-23  2:26         ` Vincent Lefevre
@ 2022-03-23 10:38           ` Stephane Chazelas
  2022-03-23 16:17             ` Vincent Lefevre
  0 siblings, 1 reply; 12+ messages in thread
From: Stephane Chazelas @ 2022-03-23 10:38 UTC (permalink / raw)
  To: zsh-workers

2022-03-23 03:26:44 +0100, Vincent Lefevre:
> On 2022-03-22 14:04:30 -0700, Bart Schaefer wrote:
> > Specifically in this instance, we consider it a POSIX bug that '%s'
> > always counts byte positions and that zsh has fixed this when it
> > counts character positions.
> 
> But, AFAIK, on the POSIX side, it has never been regarded as a bug
> (I haven't seen any bug report).
[...]

It's been raised several times on the POSIX mailing list, and
my understanding the opengroup doesn't consider it as a bug, and
they have made it clear that they would not address it. They may
consider specifying ksh93's %Ls (which pads based on display
width, not byte nor character count) if enough implementations
start to support it.

That's why I didn't bother raising it as a bug personally, but
to me, that position (where printf(1) is meant to be an
interface to printf(3) without decoding those bytes into
characters) does not make sense. printf is to print formatted
text, not doing padding of binary strings. printf(3) was
extended with wprintf(3) to handle wide characters, printf(1)
should have been enhanced to switch to that or equivalent just
like every other text utility is now specified to be able to
cope with wide characters.

printf(1) should need to decode arguments into text if only
because in the format or %b arguments, the "\" character (also
"%" in the format) is being interpreted specially. zsh doesn't
btw (which may be considered a bug, but then again those
non-UTF8 multibyte charsets are poorly supported throughout,
and to me it doesn't seem worth the effort given that hardly
anybody uses multibyte charsets other than UTF-8 these days):

$ LC_ALL=zh_HK SHELL=/bin/zsh luit
zsh$ locale charmap
BIG5-HKSCS
zsh$ printf 'αb' | hd
00000000  a3 08                                             |..|
00000002

(as α is encoded as 0xa3 0x5c in BIG5-HKSCS as used in that
locale, 0x5c being also \)

Yash is probably the only shell that does implement the POSIX
spec as POSIXly likely intends it to be:

~$ LC_ALL=zh_HK SHELL=yash luit
yash$ printf 'αb' | hd
00000000  a3 5c 62                                          |.\b|
00000003
yash$ printf %5s 'αb' | hd
00000000  20 20 a3 5c 62                                    |  .\b|
00000005
yash$ printf %5b 'αb' | hd
00000000  20 20 a3 5c 62                                    |  .\b|
00000005

That is bytes are decoded into characters for those backslashes
to be interpreted "correctly" (yash does decode everything, it's
not specific to printf¹), and then encoded back to behave as if
being passed to printf(3) as POSIX requires.

I've not verified it, but I've read somewhere the C standard was
considering enhancing printf("%.3s") so it doesn't break
characters in the middle (or maybe it's already the case?).
So printf '%.3s\n' Stéphane, where é is UTF-8 encoded in a
locale using UTF-8 would output "St" instead of "St<0xc3>".

My opinion would be:

- not change how %5s works in zsh. To me, zsh made an effort to
  fix that, I can't expect anyone relying on the POSIX
  behaviour which to me is a bug. One can always do

    printf() {
      set -o localoptions +o multibyte; builtin printf "$@"
    }

  if they want the POSIX behaviour.

- no need to fix the problems with backslashes in those
  messed-up multibyte encodings as I'd expect they're being
  phased out.

- maybe implement ksh93's %Ls (zsh does have a ${(ml[5])param}
  alternative though it does both padding and truncation).

---
¹ That approach is not tenable IMO as that means yash can't cope
with arbitrary file paths, arguments, or environment variables

-- 
Stephane


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test ./E03posix.ztst was expected to fail, but passed.
  2022-03-23 10:38           ` Stephane Chazelas
@ 2022-03-23 16:17             ` Vincent Lefevre
  0 siblings, 0 replies; 12+ messages in thread
From: Vincent Lefevre @ 2022-03-23 16:17 UTC (permalink / raw)
  To: zsh-workers

On 2022-03-23 10:38:35 +0000, Stephane Chazelas wrote:
> It's been raised several times on the POSIX mailing list, and
> my understanding the opengroup doesn't consider it as a bug, and
> they have made it clear that they would not address it. They may
> consider specifying ksh93's %Ls (which pads based on display
> width, not byte nor character count) if enough implementations
> start to support it.
> 
> That's why I didn't bother raising it as a bug personally, but
> to me, that position (where printf(1) is meant to be an
> interface to printf(3) without decoding those bytes into
> characters) does not make sense. printf is to print formatted
> text, not doing padding of binary strings. printf(3) was
> extended with wprintf(3) to handle wide characters, printf(1)
> should have been enhanced to switch to that or equivalent just
> like every other text utility is now specified to be able to
> cope with wide characters.

Counting bytes seems useful, e.g. because file formats have fields
with some maximum length in *bytes*. Counting characters seems
less common. It would be more interesting to search for scripts
that use %s with a width and/or a precision, and see what they
expect.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test ./E03posix.ztst was expected to fail, but passed.
  2022-03-16 15:30   ` Jun. T
  2022-03-22  3:32     ` Jun T
@ 2022-03-29  9:00     ` Jun T
  1 sibling, 0 replies; 12+ messages in thread
From: Jun T @ 2022-03-29  9:00 UTC (permalink / raw)
  To: zsh-workers


> 2022/03/17 0:30, I wrote:
> 
> Please try the following patch.
> 
> The patch for E03posix.ztst may not be necessary for fixing the
> current problem, but I think it is always safer to use 'zsh -f'.

The patch for E03posix.ztst (adding -f) is not necessary; if ARGV0=sh
and the shell is not interactive no initialization file will be sourced.

I will push the following patch for ztst.zsh.

Exporting MODULE_PATH has no effect since zsh will not import it
for security reason. If a child zsh (started during tests) needs
MODULE_PATH, then it must be set in the child explicitly.

I think the 'expected to fail' test must be run in UTF-8 locale;
I will send a patch in a separate post.


diff --git a/Test/ztst.zsh b/Test/ztst.zsh
index a59c06dcf..89fe69b5b 100755
--- a/Test/ztst.zsh
+++ b/Test/ztst.zsh
@@ -25,6 +25,7 @@ emulate -R zsh
 # Ensure the locale does not screw up sorting.  Don't supply a locale
 # unless there's one set, to minimise problems.
 [[ -n $LC_ALL ]] && LC_ALL=C
+[[ -n $LC_CTYPE ]] && LC_CTYPE=C
 [[ -n $LC_COLLATE ]] && LC_COLLATE=C
 [[ -n $LC_NUMERIC ]] && LC_NUMERIC=C
 [[ -n $LC_MESSAGES ]] && LC_MESSAGES=C
@@ -36,8 +37,6 @@ typeset +x WORDCHARS
 # Set the module load path to correspond to this build of zsh.
 # This Modules directory should have been created by "make check".
 [[ -d Modules/zsh ]] && module_path=( $PWD/Modules )
-# Allow this to be passed down.
-export MODULE_PATH
 
 # We need to be able to save and restore the options used in the test.
 # We use the $options variable of the parameter module for this.




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Test ./E03posix.ztst was expected to fail, but passed.
  2022-03-23  7:14         ` Jun T
@ 2022-03-29  9:10           ` Jun T
  0 siblings, 0 replies; 12+ messages in thread
From: Jun T @ 2022-03-29  9:10 UTC (permalink / raw)
  To: zsh-workers


> 2022/03/23 16:14, I wrote:
> 
> If the 'expected to fail' test exists for reminding us that we are
> (intentionally?) contradicting with POSIX, the test need be run under
> UTF-8 locale (in D07multibyte.ztst), with
> 
>> < Stéphane>      # single ' ' before 'S'


In the following patch the test is moved to D07multibyte.ztst, and
another test (expected to fail) is added to indicate that the precision
(5 in '%7.5s') should also be computed in bytes.


diff --git a/Test/D07multibyte.ztst b/Test/D07multibyte.ztst
index 7f046525a..cbd802f23 100644
--- a/Test/D07multibyte.ztst
+++ b/Test/D07multibyte.ztst
@@ -347,6 +347,18 @@
 0:Multibyte characters in printf widths
 > főo
 
+# TODO?: POSIX requires that printf should always compute width and
+# precision of '%s' conversion in bytes, while zsh computes them in
+# characters if multi-byte locale is in use.
+  ARGV0=sh $ZTST_testdir/../Src/zsh -c "printf '<%10s>\n' St$'\M-C\M-)'phane"
+0f:POSIX: width in %s should be computed in bytes, not in characters
+F:This is considered a bugfix in zsh
+>< Stéphane>
+
+  ARGV0=sh $ZTST_testdir/../Src/zsh -c "printf '<%7.5s>\n' St$'\M-C\M-)'phane"
+0f:POSIX: precision should also be computed in bytes, not in characers
+><  Stép>
+
 # We ask for case-insensitive sorting here (and supply upper case
 # characters) so that we exercise the logic in the shell that lowers the
 # case of the string for case-insensitive sorting.
diff --git a/Test/E03posix.ztst b/Test/E03posix.ztst
index b191199ad..caab97ab6 100644
--- a/Test/E03posix.ztst
+++ b/Test/E03posix.ztst
@@ -157,10 +157,5 @@ F:POSIX has neither math functions nor floating point
 -f:EUID is not a special variable
 >10
 
-  ARGV0=sh $ZTST_testdir/../Src/zsh -c "printf '<%10s>\n' St$'\M-C\M-)'phane"
-0f:Width of %s is computed in bytes not characters
-F:This is considered a bugfix in zsh
-><  Stéphane>
-
   PPID=foo
 -f:PPID is not a readonly variable

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2022-03-29  9:10 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-15 16:33 Test ./E03posix.ztst was expected to fail, but passed Vincent Lefevre
2022-03-15 16:53 ` Mikael Magnusson
2022-03-16 15:30   ` Jun. T
2022-03-22  3:32     ` Jun T
2022-03-22 13:03       ` Vincent Lefevre
2022-03-22 21:04       ` Bart Schaefer
2022-03-23  2:26         ` Vincent Lefevre
2022-03-23 10:38           ` Stephane Chazelas
2022-03-23 16:17             ` Vincent Lefevre
2022-03-23  7:14         ` Jun T
2022-03-29  9:10           ` Jun T
2022-03-29  9:00     ` Jun T

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).