Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
stty echoctl
93 views
Skip to first unread message
Ivan Shmakov
Jan 21, 2012, 1:48:04 AM1/21/12
to
>>>>> p...@gmail.com <phil.g...@gmail.com> writes:
>>>>> On Jan 20, 7:08 pm, Kaz Kylheku <k...@kylheku.com> wrote:
[Cc: alt.os.linux, as I believe that the subject being discussed
is more specific to the Linux kernel itself.]
[…]
>> Works for me in bash.
>> bash$ ^C
>> bash$ while true; do : ; done
>> ^C
>> bash$ cat
>> ^C
>> bash$
[…]
> It always worked by default for Bash under Debian and Ubuntu, but now
> I'm on an ancient RedHat box.
It's a somewhat recent change in the Linux kernel's behavior,
controlled by the stty(1)'s echoctl option. IIUC, when the
option was on, the codes used to send a signal were /not/ sent
back ^-encoded, while, e. g., ESC (^[), and thus the functional
keys' codes, etc. were. Now, all the control codes are sent
back ^-encoded when the echoctl option is active.
However, I find this feature mildly annoying. In particular, to
copy a command line from the history into, e. g., a different
Screen window, I use C-r to search the history, then, upon
finding the command, C-c to drop it from the command line (while
still having it displayed at screen.) Now, it works like:
(reverse-i-search)`foo': echo foo bar
and after C-c it becomes:
(reverse-i-search)`foo': echo ^Co bar
$
Thus, I've ended up disabling echoctl completely with:
$ stty -echoctl
As an unfortunate side-effect, when the standard input is echoed
by the kernel, the arrow keys now move the cursor, instead of
producing the familiar ^[[A's, etc.
--
FSF associate member #7257
>>>>> On Jan 20, 7:08 pm, Kaz Kylheku <k...@kylheku.com> wrote:
[Cc: alt.os.linux, as I believe that the subject being discussed
is more specific to the Linux kernel itself.]
[…]
>> Works for me in bash.
>> bash$ ^C
>> bash$ while true; do : ; done
>> ^C
>> bash$ cat
>> ^C
>> bash$
[…]
> It always worked by default for Bash under Debian and Ubuntu, but now
> I'm on an ancient RedHat box.
It's a somewhat recent change in the Linux kernel's behavior,
controlled by the stty(1)'s echoctl option. IIUC, when the
option was on, the codes used to send a signal were /not/ sent
back ^-encoded, while, e. g., ESC (^[), and thus the functional
keys' codes, etc. were. Now, all the control codes are sent
back ^-encoded when the echoctl option is active.
However, I find this feature mildly annoying. In particular, to
copy a command line from the history into, e. g., a different
Screen window, I use C-r to search the history, then, upon
finding the command, C-c to drop it from the command line (while
still having it displayed at screen.) Now, it works like:
(reverse-i-search)`foo': echo foo bar
and after C-c it becomes:
(reverse-i-search)`foo': echo ^Co bar
$
Thus, I've ended up disabling echoctl completely with:
$ stty -echoctl
As an unfortunate side-effect, when the standard input is echoed
by the kernel, the arrow keys now move the cursor, instead of
producing the familiar ^[[A's, etc.
--
FSF associate member #7257
Alan Curry
Jan 21, 2012, 2:36:36 AM1/21/12
to
In article <86sjj9a6...@gray.siamics.net>,
http://debbugs.gnu.org/9620
It was defended as a fix to a difference between Linux and the other unixes.
There didn't seem to be any room for consideration of the idea that Linux
might have been different in a good way.
> controlled by the stty(1)'s echoctl option. IIUC, when the
> option was on, the codes used to send a signal were /not/ sent
> back ^-encoded, while, e. g., ESC (^[), and thus the functional
> keys' codes, etc. were. Now, all the control codes are sent
> back ^-encoded when the echoctl option is active.
echoctl is only indirectly relevant. It controls how the character is echoed
(literally or as caret+letter), not whether the character is echoed. If you
turn it off, the echoing is still happening, but it's in the form of a
literal 0x03 control character (called "ETX" in ascii), which in a vt100-ish
terminal's normal mode has no visible effect.
>
>$ stty -echoctl
>
> As an unfortunate side-effect, when the standard input is echoed
> by the kernel, the arrow keys now move the cursor, instead of
> producing the familiar ^[[A's, etc.
It's a bad workaround for a problem that shouldn't have been introduced in
the first place.
--
Alan Curry
Ivan Shmakov <onei...@gmail.com> wrote:
>
> It's a somewhat recent change in the Linux kernel's behavior,
Between 2.6.24 and 2.6.25. There's been an argument about it before:
>
> It's a somewhat recent change in the Linux kernel's behavior,
http://debbugs.gnu.org/9620
It was defended as a fix to a difference between Linux and the other unixes.
There didn't seem to be any room for consideration of the idea that Linux
might have been different in a good way.
> controlled by the stty(1)'s echoctl option. IIUC, when the
> option was on, the codes used to send a signal were /not/ sent
> back ^-encoded, while, e. g., ESC (^[), and thus the functional
> keys' codes, etc. were. Now, all the control codes are sent
> back ^-encoded when the echoctl option is active.
(literally or as caret+letter), not whether the character is echoed. If you
turn it off, the echoing is still happening, but it's in the form of a
literal 0x03 control character (called "ETX" in ascii), which in a vt100-ish
terminal's normal mode has no visible effect.
>
>$ stty -echoctl
>
> As an unfortunate side-effect, when the standard input is echoed
> by the kernel, the arrow keys now move the cursor, instead of
> producing the familiar ^[[A's, etc.
the first place.
--
Alan Curry
Ivan Shmakov
Jan 21, 2012, 8:45:48 AM1/21/12
to
>>>>> Alan Curry <pac...@kosh.dhis.org> writes:
>>>>> Ivan Shmakov <onei...@gmail.com> wrote:
[Dropped news:comp.unix.shell.]
>> It's a somewhat recent change in the Linux kernel's behavior,
> Between 2.6.24 and 2.6.25. There's been an argument about it before:
> http://debbugs.gnu.org/9620
ACK, thanks.
[...]
>> $ stty -echoctl
>> As an unfortunate side-effect, when the standard input is echoed by
>> the kernel, the arrow keys now move the cursor, instead of producing
>> the familiar ^[[A's, etc.
> It's a bad workaround for a problem that shouldn't have been
> introduced in the first place.
Agreed. And I find it almost as annoying as the recent switch
to having Kernel Mode-Setting (KMS) enabled at boot (resulting
in a high-resolution graphics mode being used for text VT's.)
Unfortunately, maintaining a build of the kernel patched for
just this issue is hardly an option for me.
>>>>> Ivan Shmakov <onei...@gmail.com> wrote:
[Dropped news:comp.unix.shell.]
>> It's a somewhat recent change in the Linux kernel's behavior,
> Between 2.6.24 and 2.6.25. There's been an argument about it before:
> http://debbugs.gnu.org/9620
[...]
>> $ stty -echoctl
>> As an unfortunate side-effect, when the standard input is echoed by
>> the kernel, the arrow keys now move the cursor, instead of producing
>> the familiar ^[[A's, etc.
> It's a bad workaround for a problem that shouldn't have been
> introduced in the first place.
to having Kernel Mode-Setting (KMS) enabled at boot (resulting
in a high-resolution graphics mode being used for text VT's.)
Unfortunately, maintaining a build of the kernel patched for
just this issue is hardly an option for me.
Kaz Kylheku
Jan 21, 2012, 1:13:53 PM1/21/12
to
On 2012-01-21, Alan Curry <pac...@kosh.dhis.org> wrote:
>> As an unfortunate side-effect, when the standard input is echoed
>> by the kernel, the arrow keys now move the cursor, instead of
>> producing the familiar ^[[A's, etc.
>
> It's a bad workaround for a problem that shouldn't have been introduced in
> the first place.
Clearly, the useful purpose of echoctl is to disable the echoing of control
>> As an unfortunate side-effect, when the standard input is echoed
>> by the kernel, the arrow keys now move the cursor, instead of
>> producing the familiar ^[[A's, etc.
>
> It's a bad workaround for a problem that shouldn't have been introduced in
> the first place.
characters (when echo is otherwise turned on), not to enable them to be echoed
with a stupid spelling.
Now you have no way to disable echoing of control characters. It's either
literal or ^<letter>.
Why do the stupid Linux people cave in to stupid Unix people?
Fuck what Unix does; it's totally irrelevant.
Aragorn
Jan 21, 2012, 1:40:04 PM1/21/12
to
On Saturday 21 January 2012 19:13, Kaz Kylheku conveyed the following to
alt.os.linux...
It is far less stupid than the tendency of many of the GNU/Linux
developers to cave in to stupid Windows influences.
And as to the why, that's easy. GNU/Linux strives for compliance with
the Single UNIX Specification and the POSIX standards.
> Fuck what Unix does; it's totally irrelevant.
Not quite. But unfortunately it is slowly moving in that direction, and
closer towards what Microsoft Windows does. That's what you get when
the latest generation of developers comes from the Windows world.
--
= Aragorn =
(registered GNU/Linux user #223157)
alt.os.linux...
developers to cave in to stupid Windows influences.
And as to the why, that's easy. GNU/Linux strives for compliance with
the Single UNIX Specification and the POSIX standards.
> Fuck what Unix does; it's totally irrelevant.
closer towards what Microsoft Windows does. That's what you get when
the latest generation of developers comes from the Windows world.
--
= Aragorn =
(registered GNU/Linux user #223157)
Alan Curry
Jan 21, 2012, 7:19:52 PM1/21/12
to
In article <201201211...@kylheku.com>,
version of Linux or any other unix as far as I know.
The only thing that changed here is the echoing of control characters that
generate a signal. All others are still doing what they did before: echo as
caret+letter if echoctl is on or as an actual control character if it's off.
>
>Now you have no way to disable echoing of control characters. It's either
>literal or ^<letter>.
You never did have a way of disabling it. The specific case of ^C wasn't
echoed in the older kernel, regardless of echoctl setting, because it's the
SIGINT generator.
--
Alan Curry
Kaz Kylheku <k...@kylheku.com> wrote:
>On 2012-01-21, Alan Curry <pac...@kosh.dhis.org> wrote:
>>> As an unfortunate side-effect, when the standard input is echoed
>>> by the kernel, the arrow keys now move the cursor, instead of
>>> producing the familiar ^[[A's, etc.
>>
>> It's a bad workaround for a problem that shouldn't have been introduced in
>> the first place.
>
>Clearly, the useful purpose of echoctl is to disable the echoing of control
>characters (when echo is otherwise turned on), not to enable them to be echoed
>with a stupid spelling.
Well, maybe that would be useful, but it has never worked that way on any
>On 2012-01-21, Alan Curry <pac...@kosh.dhis.org> wrote:
>>> As an unfortunate side-effect, when the standard input is echoed
>>> by the kernel, the arrow keys now move the cursor, instead of
>>> producing the familiar ^[[A's, etc.
>>
>> It's a bad workaround for a problem that shouldn't have been introduced in
>> the first place.
>
>Clearly, the useful purpose of echoctl is to disable the echoing of control
>characters (when echo is otherwise turned on), not to enable them to be echoed
>with a stupid spelling.
version of Linux or any other unix as far as I know.
The only thing that changed here is the echoing of control characters that
generate a signal. All others are still doing what they did before: echo as
caret+letter if echoctl is on or as an actual control character if it's off.
>
>Now you have no way to disable echoing of control characters. It's either
>literal or ^<letter>.
echoed in the older kernel, regardless of echoctl setting, because it's the
SIGINT generator.
--
Alan Curry
0 new messages