On Sat, Jan 30, 2021 at 7:00 AM Beverly Pope <countryone77@gmail.com> wrote:
>
> On Jan 30, 2021, at 4:50 AM, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
>
> > print -rC1 --
> >
> > This command doesn't print anything.
>
> % print -rC1 -- no_such_file(N)
>
> zsh 5.8 (Ubuntu): prints nothing
> zsh 5.7.1 (Mac): prints return
Hm; I get no output, in both cases. Similarly on Centos (zsh 5.0).
This behavior seems like a bug to me. Neither -n nor -N were
specified, so "print" should always output at least a newline.
However, it's been around for quite some time and obviously some
people know about it, so I suppose it should just be documented. The
doc does make a very oblique reference to it under the -N option:
print -rNC1 -- "$list[@]" is a canonical way to print an
arbitrary list as null-delimited records.
The implication is that -C prevents the terminating NUL byte from
being printed when $list is empty.
ubuntu% print -rN -- | od -c
0000000 \0
0000001
ubuntu% print -rN -- 1 2 3 | od -c
0000000 1 \0 2 \0 3 \0
0000006
ubuntu% print -rNC1 -- | od -c
0000000
ubuntu% print -rNC1 -- 1 2 3 | od -c
0000000 1 \0 2 \0 3 \0
0000006
The related behavior of -n is a bit weird:
ubuntu% print -rnN -- | od -c
0000000
ubuntu% print -rnN -- 1 2 3 | od -c
0000000 1 \0 2 \0 3
0000005
This, however, is more questionable:
ubuntu% print -raNC1 -- 1 2 3 | od -c
0000000 1 \0 2 \0 3 \0
0000011
This explains the trailing spaces on the test case for globbing that I
posted a few days ago. I sort of get why -a needs to do that when
the column count is >1, but it shouldn't be inserting trailing spaces
when the column count is 1.
[-- Attachment #1: Type: text/plain, Size: 683 bytes --] > On Jan 30, 2021, at 12:51 PM, Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Sat, Jan 30, 2021 at 7:00 AM Beverly Pope <countryone77@gmail.com <mailto:countryone77@gmail.com>> wrote: >> >> On Jan 30, 2021, at 4:50 AM, Roman Perepelitsa <roman.perepelitsa@gmail.com <mailto:roman.perepelitsa@gmail.com>> wrote: >> >>> print -rC1 -- >>> >>> This command doesn't print anything. >> >> % print -rC1 -- no_such_file(N) >> >> zsh 5.8 (Ubuntu): prints nothing >> zsh 5.7.1 (Mac): prints return > Sorry! When I copied/pasted the command, I accidentally copied the return at the end of the line. I tried it again on Mac and it didn’t print anything/ [-- Attachment #2: Type: text/html, Size: 3490 bytes --]
On Sat, Jan 30, 2021 at 7:52 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Sat, Jan 30, 2021 at 7:00 AM Beverly Pope <countryone77@gmail.com> wrote:
> >
> > On Jan 30, 2021, at 4:50 AM, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
> >
> > > print -rC1 --
> > >
> > > This command doesn't print anything.
> >
> > % print -rC1 -- no_such_file(N)
>
> This behavior seems like a bug to me. Neither -n nor -N were
> specified, so "print" should always output at least a newline.
> However, it's been around for quite some time and obviously some
> people know about it, so I suppose it should just be documented.
I learned about it from the documentation for print:
-l Print the arguments separated by newlines instead of spa-
ces. Note: if the list of arguments is empty, print -l
will still output one empty line. To print a possi-
bly-empty list of arguments one per line, use print -C1,
as in `print -rC1 -- "$list[@]"'.
I don't think I ever wrote or saw code where -l is correct and -C1 is wrong.
Roman.
On Sat, Jan 30, 2021 at 2:47 PM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > I learned about it from the documentation for print: The paragraph about the "-l" option seems like an odd place for the only mention of this, but the zsh doc is like that a lot. > I don't think I ever wrote or saw code where -l is correct and -C1 is wrong. With the exception of those doc examples, I don't think I ever saw or wrote code where the argument to -C was less than two (unless it was a variable). Oh, well.
2021-01-30 17:08:21 -0800, Bart Schaefer: > On Sat, Jan 30, 2021 at 2:47 PM Roman Perepelitsa > <roman.perepelitsa@gmail.com> wrote: > > > > I learned about it from the documentation for print: > > The paragraph about the "-l" option seems like an odd place for the > only mention of this, but the zsh doc is like that a lot. > > > I don't think I ever wrote or saw code where -l is correct and -C1 is wrong. > > With the exception of those doc examples, I don't think I ever saw or > wrote code where the argument to -C was less than two (unless it was a > variable). Oh, well. [...] I have always been annoyed at that behaviour of print -rl - outputting an empty line when not being given any argument (and print -f '%s\n' -- has the same problem). Until I saw someone on unix.stackexchange.com use print -rC1 -- which addresses the problem. I was the one suggesting it be more explicitly documented at https://www.zsh.org/mla/workers/2019/msg01202.html Since then, I've replaced all my (broken) usages of print -rl with print -rC1. I agree it wouldn't harm to also clarify in the -C documentation that nothing is output if no argument is given. This: ~$ print -raC2 a b c | sed -n l a b $ c $ ( ~$ print -rC2 a b c | sed -n l a c$ b$ ) could also be improved. -- Stephane
On Sun, Jan 31, 2021 at 1:36 AM Stephane Chazelas <stephane@chazelas.org> wrote: > > ~$ print -raC2 a b c | sed -n l > a b $ > c $ > > could also be improved. Is that just this? diff --git a/Src/builtin.c b/Src/builtin.c index 09eb3728c..35a0fb2db 100644 --- a/Src/builtin.c +++ b/Src/builtin.c @@ -4822,7 +4822,7 @@ bin_print(char *name, char **args, Options ops, int func) { fwrite(args[n], len[n], 1, fout); l = widths[n]; - if (n < argc) + if (n < argc && ic < nc - 1) for (; l < sc; l++) fputc(' ', fout); }