* 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-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-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 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
* 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
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).