Re: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'
On 2/6/20 2:29 PM, Harald van Dijk wrote: > On 06/02/2020 16:12, Martijn Dekker wrote: >> When executing test.bash with dash, gwsh, Busybox ash, or FreeBSD sh, >> then test.ash simply waits forever on executing 'wait "$!"'. > > Nice test. bash leaves the process in a state where SIGCHLD is blocked, and > the various ash-based shells do not unblock it. Thanks for the investigation. Bash does leave SIGCHLD blocked in this exact set of circumstances (lastpipe+function+return at end of pipeline+exec). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: AW: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'
Op 07-02-20 om 12:19 schreef Walter Harms: IMHO is the bug on bash side. ash can assume to get an "healthy" environment from the caller. You can simply not fix everything that can possible go wrong. That is a rather fallacious argument. Of course you cannot fix *everything* that could possibly go wrong. You can certainly fix *this* thing, though. I know, because every non-Almquist shell does it. These days, no program can realistically assume a "healthy" environment. Computers have become unimaginably complex machines, built on thousands of interdependent abstraction layers, each as fallible as the humans that designed and implemented them. So "unhealthy" environments happen all the time, due to all sorts of unforeseen causes. It's well past time to accept that the 1980s are behind us. In 2020, systems have to be programmed robustly and defensively. Obviously it should not segfault but so far i understand it is bsd as that does, not busybox ash. True. But instead, it simply gets stuck forever, with no message or other indicator of what went wrong. How is that better? (Going slightly off-topic below...) Segfaulting is actually a good thing: it's one form of failing reliably. And failing reliably is vastly better than what often happens instead, especially in shell scripts: subtle breakage, which can take a lot of detective work to trace, and in some cases can cause serious damage due to the program functioning inconsistently and incorrectly (instead of not at all). Failing reliably is something the shell is ATROCIOUSLY bad at, and it's one of the first things modernish aims to fix. - Martijn -- modernish -- harness the shell https://github.com/modernish/modernish
Re: Opening a `.HFS+ Private Directory Data'$'\r` folder messes up terminal prepended prompt
On Fri, Feb 07, 2020 at 05:11:43PM +1000, Magnon Damant wrote: > I noticed a bug where when I open a Time Machine Backup folder (called .HFS+ > Private Directory Data'$'\r) the terminal cursor position gets messed up. "Open" is a bit ambiguous here > prompt [@ > ]$ gets messed up > > I guess the '$'\r name ending is causes the issue [maybe not escaped > properly?]. > Prepended prompt should display [something like]: > [magnon@magnon-desktop .HFS+ Private Directory Data^M]$ So, by "open", you mean "cd into". wooledg:~$ mkdir $'crtest\r' wooledg:~$ cd crtest^M/ $ oledg:~/crtest Line 2 was generated by tab completion, not by typing caret-shift-M. The carriage return in the directory name is simply being printed literally to the terminal by the prompt. It's not escaped, which is why it looks like this. I'm not sure I'd call this a bug -- more of a feature request, for bash to present control characters in directory names (or partial names), that are expanded from PS1, in an escaped form. Meanwhile, I strongly advise you to rename this directory so that it doesn't end with a carriage return. This won't be the only problem it causes you.
AW: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'
IMHO is the bug on bash side. ash can assume to get an "healthy" environment
from the caller. You can simply not fix everything that can possible go wrong.
Obviously it should not segfault but so far i understand it is bsd as that
does, not busybox ash.
re,
wh
Von: busybox im Auftrag von Harald van Dijk
Gesendet: Donnerstag, 6. Februar 2020 20:29
An: Martijn Dekker; DASH shell mailing list; busybox; Bug reports for the GNU
Bourne Again SHell; Robert Elz; Jilles Tjoelker
Betreff: Re: Bizarre interaction bug involving bash w/ lastpipe + Almquist
'wait'
On 06/02/2020 16:12, Martijn Dekker wrote:
> This is probably the strangest bug (or maybe pair of bugs) I've run into
> in nearly five years of breaking shells by developing modernish.
>
> I've traced it to an interaction between bash >= 4.2 (i.e.: bash with
> shopt -s lastpipe) and variants of the Almquist shell, at least: dash,
> gwsh, Busybox ash, FreeBSD sh, and NetBSD 9.0rc2 sh.
>
> Symptom: if 'return' is invoked on bash in the last element of a pipe
> executed in the main shell environment, then if you subsequently 'exec'
> an Almquist shell variant so that it has the same PID, its 'wait'
> builtin breaks.
>
> I can consistently reproduce this on Linux, macOS, FreeBSD, NetBSD
> 9.0rc2, OpenBSD, and Solaris.
>
> To reproduce this, you need bash >= 4.2, some Almquist shell variant,
> and these two test scripts:
>
> ---begin test.bash---
> fn() {
> : | return
> }
> shopt -s lastpipe || exit
> fn
> exec "${1:-dash}" test.ash
> ---end test.bash---
>
> ---begin test.ash---
> echo '*ash-begin'
> : &
> echo '*ash-middle'
> wait "$!"
> echo '*ash-end'
> ---end test.ash---
>
> When executing test.bash with dash, gwsh, Busybox ash, or FreeBSD sh,
> then test.ash simply waits forever on executing 'wait "$!"'.
Nice test. bash leaves the process in a state where SIGCHLD is blocked,
and the various ash-based shells do not unblock it. Because of that,
they do not pick up on the fact that the child process has terminated. I
would consider this a bug both in bash and in the ash-based shells.
Cheers,
Harald van Dijk
___
busybox mailing list
busy...@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
