Hello, Thank you for your answers.
My intention was to understand if decisions about dash are still valid, not to tell Debian to switch back to bash of course. Speaking about "bug or not": This bug was confirmed by author: https://lore.kernel.org/dash/zm5y3du0c2mhd...@gondor.apana.org.au/ And here is the commit that fixes it: https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=5f094d08c5bcee876191404a4f3dd2d075571215 As one might see, it has a POSIX quote in its commit message, so this behaviour is a part of POSIX. >>> When the shell is using standard input and it invokes a command that also uses standard input, the shell shall ensure that the standard input file pointer points directly after the command it has read when the command begins execution. It shall not read ahead in such a manner that any characters intended to be read by the invoked command are consumed by the shell (whether interpreted by the shell or not) or that characters that are not read by the invoked command are not seen by the shell. >>> I am not the only one who found it: https://michael-prokop.at/blog/2017/05/18/debugging-a-mystery-ssh-causing-strange-exit-codes/ There is even a Debian bug that clearly reports POSIX conformance issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862907 So the bug, indeed, exists, but this is not a reason to switch to bash as any software has bugs. Even if it weren't covered by POSIX I wouldn't call it "undefined behaviour", but "unspecified". I am not sure if the term "undefined" is valid for shells (I guess not) but in the C world that means compiler might do anything (think "0 != 0" or the whole program optimized to "return;") in any place since the app is ill. https://en.cppreference.com/w/c/language/behavior Many modern languages do not have this concept (although they have race conditions, unspecified behaviour etc). Speaking about different shells for interactive and scripting usage and csh as an example. AFAIR csh was originally created to substitute Bourne shell and Joy tried to make it to be more C-like both for interactive and programming usage (why study new syntax if everyone in the UNIX world speaks C?) Bourne sh was pretty weak back then: it didn't even have job control, so csh was like a shiny future. Later, SysV gained Korn Shell which was as powerful as csh, but backward compatible with bourne shell. So, BSD had csh and SysV had ksh (which was not portable to BSD due to license). POSIX claimed that there should be a Bourne shell named `sh`, and BSD had to have both: csh and Bourne shell to be POSIX compatible. People started to write scripts in csh, but later on it was considered bad practice. There is a well-known document called "Csh Programming Considered Harmful" from 1996 https://harmful.cat-v.org/software/csh Csh exists on some BSDs because of lots of people who studied it long ago and do not want to change old behaviours. Do they regret this decision? I do not know, but OpenBSD, for example, adopted pdksh (which is public domain ksh) as it is free, light (lighter than bash), non-GPL and compatible with Bourne shell. They do not use csh https://misc.openbsd.narkive.com/Ekowx1ya/why-ksh I doubt that any shell was created to be "scripting only": even ash wasn't. The reason it didn't have history was that the author believed that this should be implemented by tty driver called atty: https://groups.google.com/g/comp.sources.unix/c/A6cnyKX-Gq4/m/dGKOOmXndCcJ >>> . History. It seems to me that the csh history mechanism is mostly a response to the deficiencies of UNIX terminal I/O. Those of you running 4.2 BSD should try out atty (which I am posting to the net at the same time as ash) and see if you still want history. >>> But he changed it soon after: https://www.in-ulm.de/~mascheck/various/ash/#44bsdalpha Having two implementations of the same standard is good for standard (if standard has single implementation only, I wouldn't call it real standard), but might produce compatibility issues between implementations and might be impractical. Anyway, I now see that dash is here for the good reason as Debian could still be run on 15 years old hardware, tiny computers etc. Ilya.
