Subject: dash: interactive dash mishandles the quit character (^\)
Date: Tue, 17 Nov 2015 14:31:43 +0100
Package: dash
Version: 0.5.7-4+b1
Severity: normal
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html
says:
If the shell is interactive:
SIGQUIT and SIGTERM signals shall be ignored.
The behavior of dash is correct when the signal has been sent with
"kill" from another terminal, but if I type "foo", then the quit
character (Ctrl-\ by default), then "bar", I get:
$ foo^\bar
dash: 1: bar: not found
instead of:
$ foobar
dash: 1: foobar: not found
-- System Information:
Debian Release: stretch/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.1.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dash depends on:
ii debianutils 4.5.1
ii dpkg 1.18.3
ii libc6 2.19-22
dash recommends no packages.
dash suggests no packages.
-- debconf information:
* dash/sh: true
Subject: Re: dash: interactive dash mishandles the quit character (^\)
Date: Sun, 6 Dec 2015 23:22:11 +0100
On Tue, 17 Nov 2015 14:31:43 +0100 Vincent Lefevre <[email protected]> wrote:
> Package: dash
> Version: 0.5.7-4+b1
> Severity: normal
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html
> says:
> If the shell is interactive:
> SIGQUIT and SIGTERM signals shall be ignored.
> The behavior of dash is correct when the signal has been sent with
> "kill" from another terminal, but if I type "foo", then the quit
> character (Ctrl-\ by default), then "bar", I get:
> $ foo^\bar
> dash: 1: bar: not found
> instead of:
> $ foobar
> dash: 1: foobar: not found
Dash is behaving correctly here. The flush of the input queue occurs
because the NOFLSH flag is not set in termios c_lflag. After 'stty
noflsh', there is still '^\' visible but the characters before it are
not discarded. The default (to flush) is probably more useful, though.
--
Jilles Tjoelker
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Gerrit Pape <[email protected]>.
(Mon, 07 Dec 2015 01:30:08 GMT) (full text, mbox, link).
Subject: Re: Bug#805375: dash: interactive dash mishandles the quit character
(^\)
Date: Mon, 7 Dec 2015 02:27:29 +0100
On 2015-12-06 23:22:11 +0100, Jilles Tjoelker wrote:
> Dash is behaving correctly here. The flush of the input queue occurs
> because the NOFLSH flag is not set in termios c_lflag. After 'stty
> noflsh', there is still '^\' visible but the characters before it are
> not discarded.
The behavior is different with bash and zsh, but I suppose that this
is because neither bash nor zsh uses the cooked mode.
> The default (to flush) is probably more useful, though.
Well, if the signal is ignored, then it is more intuitive to disable
flushing, IMHO, i.e. to ignore Ctrl-\ entirely. However the terminal
handling is buggy in this case (I mean, if one types "foo" then Ctrl-\
then [Backspace], only the backslash is erased so that one gets "foo^"
displayed instead of "fo").
--
Vincent Lefèvre <[email protected]> - 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)
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Andrej Shadura <[email protected]>.
(Sat, 17 Dec 2022 22:33:05 GMT) (full text, mbox, link).
Subject: Re: Bug#805375: dash: interactive dash mishandles the quit character
(^\)
Date: Sat, 17 Dec 2022 23:28:03 +0100
Control: found -1 0.5.11+git20210903+057cd650a4ed-9
On 2015-12-07 02:27:29 +0100, Vincent Lefevre wrote:
> On 2015-12-06 23:22:11 +0100, Jilles Tjoelker wrote:
> > Dash is behaving correctly here. The flush of the input queue occurs
> > because the NOFLSH flag is not set in termios c_lflag. After 'stty
> > noflsh', there is still '^\' visible but the characters before it are
> > not discarded.
>
> The behavior is different with bash and zsh, but I suppose that this
> is because neither bash nor zsh uses the cooked mode.
About the default behavior, there are several behaviors, depending
on the shell. I've just asked in the austin list what is expected:
https://www.mail-archive.com/[email protected]/msg10539.html
> > The default (to flush) is probably more useful, though.
>
> Well, if the signal is ignored, then it is more intuitive to disable
> flushing, IMHO, i.e. to ignore Ctrl-\ entirely. However the terminal
> handling is buggy in this case (I mean, if one types "foo" then Ctrl-\
> then [Backspace], only the backslash is erased so that one gets "foo^"
> displayed instead of "fo").
There are still display issues, whether noflsh is used or not.
--
Vincent Lefèvre <[email protected]> - 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)
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.