zsh-workers
 help / color / mirror / Atom feed
* [Fixed Hardwrap][BUG] Pipe fails even when using ' || true '
@ 2021-03-26 13:09 Rudi C
  2021-03-26 17:16 ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Rudi C @ 2021-03-26 13:09 UTC (permalink / raw)
  To: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

Sorry, gmail hard-wrapped my previous email, which causes hardships in just
copying the code. I am resending it in HTML mode to avoid this problem.

---

This pipe unexpectedly fails:

```
$ setopt pipefail
$ { print -nr -- "x" || true } | eval 'print -rn -- "${(q+@)brish_stdin}"'
; echo $'\n'Returned $?:"${(j.|.)pipestatus[@]}"
''
Returned 141:141|0
```

This is the simplest thing I have found that works:
```
$ ( ( print -nr -- "l" ) || true ) | eval 'print -rn -- "${(q+@)brish_stdin}"'
; echo $'\n'Returned $?:"${(j.|.)pipestatus[@]}"
''
Returned 0:0|0
```

Even this fails:
```
$ ( { print -nr -- "l" } || true ) | eval 'print -rn -- "${(q+@)brish_stdin}"'
; echo $'\n'Returned $?:"${(j.|.)pipestatus[@]}"
''
Returned 141:141|0
```

The behavior is nondeterministic on macOS, and it actually doesn't usually
fail at all!
```
$ for i in {1..100} ; { { print -nr -- "x" || true } | eval 'print -rn --
"${(q+@)brish_stdin}"' ;echo $'\n'Returned $?:"${(j.|.)pipestatus[@]}" }
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 141:141|0
''
Returned 0:0|0
''
Returned 0:0|0
''
Returned 0:0|0
```

BTW, there seems to be another weird thing going on; Adding two spaces
before `echo` breaks the whole loop both on Linux and macOS:

```
for i in {1..100} ; { { print -nr -- "x" || true } | eval 'print -rn --
"${(q+@)brish_stdin}"' ;  echo $'\n'Returned $?:"${(j.|.)pipestatus[@]}" }

''zsh: command not found:
''zsh: command not found:
''zsh: command not found:
''zsh: command not found:
...
```

[-- Attachment #2: Type: text/html, Size: 2919 bytes --]

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

* Re: [Fixed Hardwrap][BUG] Pipe fails even when using ' || true '
  2021-03-26 13:09 [Fixed Hardwrap][BUG] Pipe fails even when using ' || true ' Rudi C
@ 2021-03-26 17:16 ` Bart Schaefer
  2021-03-27  8:30   ` Mikael Magnusson
  0 siblings, 1 reply; 4+ messages in thread
From: Bart Schaefer @ 2021-03-26 17:16 UTC (permalink / raw)
  To: Rudi C; +Cc: Zsh hackers list

On Fri, Mar 26, 2021 at 6:09 AM Rudi C <rudiwillalwaysloveyou@gmail.com> wrote:
>
> This pipe unexpectedly fails:
>
> ```
> $ setopt pipefail
> $ { print -nr -- "x" || true } | eval 'print -rn -- "${(q+@)brish_stdin}"' ; echo $'\n'Returned $?:"${(j.|.)pipestatus[@]}"
> ''
> Returned 141:141|0
> ```

Exit status 141 indicates that the entire { ... } construct was killed
by SIGPIPE,which is occurring because there's nothing in the "eval" on
the right side to read the output from "print".

Whether this happens depends on order of events (does the right side
of the pipe exit before the left side finishes printing) which can in
turn depend on OS-level process scheduling algorithms over which zsh
has little or no control; or because of pipe buffering, which is also
an OS thing, although with only one character sent on the pipe that is
unlikely to be the cause in this case.

> The behavior is nondeterministic on macOS, and it actually doesn't usually fail at all!

See "order of events".  Process scheduling may depend on how many
actual cores are in the CPU, for example, determining whether the
pipeline executes in true parallel fashion or via time-slicing.

> BTW, there seems to be another weird thing going on; Adding two spaces before `echo` breaks the whole loop both on Linux and macOS:

If you're copy-pasting from an edit in browser gmail, for example, it
has a tendency to insert non-breaking spaces whenever there is more
than one consecutive space, which the shell interprets as
non-whitespace and attempts to execute as commands.  Annoys the hell
out of me whenever I forget that it happens.


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

* Re: [Fixed Hardwrap][BUG] Pipe fails even when using ' || true '
  2021-03-26 17:16 ` Bart Schaefer
@ 2021-03-27  8:30   ` Mikael Magnusson
  2021-03-27  8:32     ` Mikael Magnusson
  0 siblings, 1 reply; 4+ messages in thread
From: Mikael Magnusson @ 2021-03-27  8:30 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On 3/26/21, Bart Schaefer <schaefer@brasslantern.com> wrote:
> If you're copy-pasting from an edit in browser gmail, for example, it
> has a tendency to insert non-breaking spaces whenever there is more
> than one consecutive space, which the shell interprets as
> non-whitespace and attempts to execute as commands.  Annoys the hell
> out of me whenever I forget that it happens.

You can use bindkey -s (or some postprocessing in your paste handler,
depending), to get rid of these since you pretty much never actually
want them in a shell command line anyway (and you could use ctrl-v if
you really do want to type one).

-- 
Mikael Magnusson


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

* Re: [Fixed Hardwrap][BUG] Pipe fails even when using ' || true '
  2021-03-27  8:30   ` Mikael Magnusson
@ 2021-03-27  8:32     ` Mikael Magnusson
  0 siblings, 0 replies; 4+ messages in thread
From: Mikael Magnusson @ 2021-03-27  8:32 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On 3/27/21, Mikael Magnusson <mikachu@gmail.com> wrote:
> On 3/26/21, Bart Schaefer <schaefer@brasslantern.com> wrote:
>> If you're copy-pasting from an edit in browser gmail, for example, it
>> has a tendency to insert non-breaking spaces whenever there is more
>> than one consecutive space, which the shell interprets as
>> non-whitespace and attempts to execute as commands.  Annoys the hell
>> out of me whenever I forget that it happens.
>
> You can use bindkey -s (or some postprocessing in your paste handler,
> depending), to get rid of these since you pretty much never actually
> want them in a shell command line anyway (and you could use ctrl-v if
> you really do want to type one).

I see now that you already covered this (after 65 years, gmail
incredibly still doesn't support email threads and just groups mails
by subject line).

-- 
Mikael Magnusson


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

end of thread, other threads:[~2021-03-27  8:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-26 13:09 [Fixed Hardwrap][BUG] Pipe fails even when using ' || true ' Rudi C
2021-03-26 17:16 ` Bart Schaefer
2021-03-27  8:30   ` Mikael Magnusson
2021-03-27  8:32     ` Mikael Magnusson

zsh-workers

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-workers

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-workers zsh-workers/ http://inbox.vuxu.org/zsh-workers \
		zsh-workers@zsh.org
	public-inbox-index zsh-workers

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


code repositories for the project(s) associated with this inbox:

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

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git