^W killed my line
Greywolf
# Now I've got most of my machines to 1.4R, I notice that /bin/sh is linked
# with libedit. This is a nice feature, apart from one thing that is annoying
# me. The default setting of werase is ^W. However, ^W acts just like kill.
# If I change werase to something else (say ^F) it works like werase should.
# Is this just my setup?
emacs bindings dictate that ^W is bound to kill-region.
I typically bind ^W to kill-previous-word and ^X^K to kill-region.
You might want to edit your .inputrc to reflect this (or does -ledit
not use .inputrc, e.g. I am thinking of something else?).
#
# J
#
# PS. History editing for multi-line commands is also a little, er, wacky.
# --
# My other computer also runs NetBSD
# http://www.netbsd.org/
#
--*greywolf;
--
NetBSD: demonic power.
Julian Coleman
J
PS. History editing for multi-line commands is also a little, er, wacky.
--
My other computer also runs NetBSD
Julian Coleman
> emacs bindings dictate that ^W is bound to kill-region.
> I typically bind ^W to kill-previous-word and ^X^K to kill-region.
> You might want to edit your .inputrc to reflect this (or does -ledit
> not use .inputrc, e.g. I am thinking of something else?).
I don't have a .inputrc. Presumably, that's for something else. Anyway,
isn't werase the stty equivalent of emacs' kill-previous-word? Thus,
shouldn't sh/libedit behave in the same fashion if I have either :
stty werase ^W
or :
stty werase ^F
?
J
Greg A. Woods
> Subject: Re: ^W killed my line
>
> isn't werase the stty equivalent of emacs' kill-previous-word? Thus,
> shouldn't sh/libedit behave in the same fashion if I have either :
>
> stty werase ^W
>
> or :
>
> stty werase ^F
>
> ?
Yes (if I understand you correctly).
If libedit is in control then the "editing" features of the tty driver
should be disabled. If the current libedit bindings happen to map to
the same keys as are set in the tty driver then that's probably a good
thing for some or even most people. However I don't think libedit
should every override any default bindings with any current stty
settings -- let the user do this purposefully rather than doing it by
magic.
Where this gets confusing is in the transition between something using
libedit and normal stdin. Those of us who've been using "set -o emacs"
for ever and a day are accustomed to this transition and usually have
trained ourselves to know when to press <ESC>-<BACKSPACE> and when to
press <CTRL-W> (though we are often somewhat surprised, and usually
pleasantly so, when we find new applications other than just /bin/sh
supporting command-line editing).
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
der Mouse
> using libedit and normal stdin.
Or people who use stty to change their tty characters and are silly
enough to expect that the change will actually take effect.
I was so ticked when I found that ftp ignored a typed EOF, simply
because my eofc wasn't ^D. gdb used to get that right *despite*
providing command line editing, but then someone took a big step
backward and broke it a la ftp.
Today, I even saw indications that -current /bin/sh comes up with
command line editing on by default(!), but that's so hard to credit
that I won't be convinced I wasn't hallucinating until I've
investigated a good deal more.
Why not just snip out stty's ability to set special characters, since
NetBSD obviously doesn't care about anyone who wants to actually use
that capability?! (Or even, it appears, use some of the defaults for
their documented purposes, like ^W for word-erase - or the dsuspc,
something that's been broken for longer than I've used NetBSD, and I
keep meaning to figure out what's wrong with it. I can only assume
that *nobody* actually uses the dsuspc.)
Yes, I'm annoyed. Very much so. This linking libedit into everything
and its dog is rapidly becoming a right royal pain.
der Mouse
mo...@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Greg A. Woods
> Subject: Re: ^W killed my line
>
> > using libedit and normal stdin.
>
> Or people who use stty to change their tty characters and are silly
> enough to expect that the change will actually take effect.
Ah, why would anyone expect that changing the tty line edit characters
would have any effect on a character-oriented editor that's built into
some application (such as /bin/sh, ftp, gdb, or whatever)? Would you
really expect "stty werase :" to change vi's interpretation of ':'? I
sure wouldn't. Neither do I assume that "stty erase ^?" will change my
settings of delete-backward-char in emacs or jove.
The only real issues are with us old fogeys who remember the days before
applications had their own built-in command-line editors, and of course
with the problem that there are many input "editors" not just one.
Yes there is some trickery with /bin/sh since it is fundamentally
perceived to be tied to the very idea of command-line input. However
there's a big difference between "cat -u | sh" and "sh -E"!
> Why not just snip out stty's ability to set special characters, since
> NetBSD obviously doesn't care about anyone who wants to actually use
> that capability?! (Or even, it appears, use some of the defaults for
> their documented purposes, like ^W for word-erase
I think you're hung up on the idea that the tty driver should be the one
and only king of input editing.
Why not remove vi and perhaps even ed and just use cat if that's the
case? :-)
(Indeed that's essentially what Pike did with 8½ in Plan 9.)
> - or the dsuspc,
> something that's been broken for longer than I've used NetBSD, and I
> keep meaning to figure out what's wrong with it. I can only assume
> that *nobody* actually uses the dsuspc.)
Most machines are fast enough these days (even a 486!) that I don't
think anyone cares about the difference between DSUSP and SUSP.
> Yes, I'm annoyed. Very much so. This linking libedit into everything
> and its dog is rapidly becoming a right royal pain.
Old habits die hard? Many folks, including myself, look at this in
quite the opposite way!
Indeed I find it somewhat wasteful that all the extra baggage from
"newcrt" was codified (in a new and different way, of course!) in the
termios "standard" (even though I was quite happy about it at the time! :-).
With libedit in enough applications we could probably ditch it all again
and go back to the much more basic V7 style tty line discipline. I
don't really know where the economy lies, but I would rather see more
complex input editing functions in the applications than in the tty
code, especially if they can all share code from the same library.
der Mouse
>> enough to expect that the change will actually take effect.
> Ah, why would anyone expect that changing the tty line edit
> characters would have any effect on a character-oriented editor
> that's built into some application
The point is that it is fundamentally a line-oriented interface, so
(absent user configuration to the contrary) I expect, not unreasonably
I think, that it behave the way "everything else" with a line-oriented
interface does.
I like command-line editing -- when I ask for it. (For me to ask for
it, it has to be configurable enough; I have yet to figure out how to
configure ftp or gdb to behave sanely for my definition of "sanely", so
I wouldn't turn on command-line editing for them. The problem is, I'm
not given the choice - they come up with line editing on. ftp at least
has a switch to turn it off, but that's the wrong default.)
> Would you really expect "stty werase :" to change vi's interpretation
> of ':'?
No; vi's interface isn't line-oriented, so I don't expect line-oriented
input editing to happen. I *would* expect it to affect ed (and
arguably line-oriented subsets of visual programs, such as
non-open-mode ex or vi's : command-line, though these are a gray area).
> Yes there is some trickery with /bin/sh since it is fundamentally
> perceived to be tied to the very idea of command-line input. However
> there's a big difference between "cat -u | sh" and "sh -E"!
Right. I have no problem with sh, because I have to ask for
command-line editing to get it. If I like it, I can use it; if I
don't, I can leave it off. As it happens, I do often turn it on.
>> Why not just snip out stty's ability to set special characters,
>> since NetBSD obviously doesn't care about anyone who wants to
>> actually use that capability?! (Or even, it appears, use some of
>> the defaults for their documented purposes, like ^W for word-erase
> I think you're hung up on the idea that the tty driver should be the
> one and only king of input editing.
I don't think so; I think you misunderstood. This paragraph is about a
*human* point, not a *technical* one - "it works for me, so ship it",
without considering that not everybody uses eofc=^D, or suspc=^Z, or
whatever. I submitted a PR about ftp when I first noticed the EOF
problem. It was closed by someone who apparently read the one-line
summary, tried it (with eofc=^D), found it worked, and didn't bother
reading my "how to repeat" section which carefully said to use
something other than ^D. This sort of "it works when I use the
standard settings, so it's not broken" attitude is what I'm actually
upset about here.
If you want ftp and gdb to have input line editing that enforces ^D as
the effective eofc, that's fine - PROVIDED it's turned off by default!
>> - or the dsuspc, something that's been broken for longer than I've
>> used NetBSD, and I keep meaning to figure out what's wrong with it.
>> I can only assume that *nobody* actually uses the dsuspc.)
> Most machines are fast enough these days (even a 486!) that I don't
> think anyone cares about the difference between DSUSP and SUSP.
I don't know what planet you're from, but I still have plenty of
commands that take longer than fifteen seconds to complete. The
fastest NetBSD machine I've ever used still took over an hour to "make
build". And I relatively often do over-the-net compares which I would
like to auto-suspend things upon completion of - exactly the sort of
thing the dsuspc is designed for. Yet I don't think I've seen an OS
dsuspc has worked on in the last decade, not since mtXinu 4.3+NFS and
possibly not even there - I forget.
>> Yes, I'm annoyed. Very much so. This linking libedit into
>> everything and its dog is rapidly becoming a right royal pain.
> Many folks, including myself, look at this in quite the opposite way!
Obviously. And what I'm upset about is those folks forcing their idea
of how to do line editing down my throat. (It is *almost* enough to be
able to "echo edit off > ~/.editrc", but (a) I shouldn't have to do
anything special to get standard input line editing, and (b) I'm still
screwed in single-user mode.)
> Indeed I find it somewhat wasteful that all the extra baggage from
> "newcrt" was codified (in a new and different way, of course!) in the
> termios "standard" (even though I was quite happy about it at the
> time! :-). With libedit in enough applications we could probably
> ditch it all again and go back to the much more basic V7 style tty
> line discipline.
You would really compel every program author to deal with the editline
API in order to get rudimentary command line editing?? And talk about
a portabilityi nightmare....
> I don't really know where the economy lies, but I would rather see
> more complex input editing functions in the applications than in the
> tty code, especially if they can all share code from the same
> library.
The way sh shares it with ftp and gdb? Right. I foresee serious bloat
in /bin down that road.
I would much rather let people who want all-singing all-dancing command
line editing do it with a user-land front-end, for which hooks would
exist in the tty driver. Indeed, most of the necessary support is
already there; I've seen programs that provide line-editing front ends
to any command-line application. Add a little smarts, possibly some
hooks, for process groups (to distinguish history lists between
applications) and it sounds a lot like what you want.
PER4MANCE, J. Dolecek
> The point is that it is fundamentally a line-oriented interface, so
> (absent user configuration to the contrary) I expect, not unreasonably
> I think, that it behave the way "everything else" with a line-oriented
> interface does.
editline should be fixed to honour stty settings. I'll try to do
something with this in a few days.
Jaromir
Greg A. Woods
> Subject: Re: ^W killed my line
>
> > something with this in a few days.
>
Ah, no, it should not be fixed, especially not for "emacs" mode....
> Thought - what to do about the basic incompatabilities between stty settings
> and readline shortcuts? For example, if I set stty werase ^A and use sh -E,
> what will happen when I press ^A? I suppose that the readline shortcuts
> should take precedence.
Exactly -- the application key bindings must take precedence. Perhaps
it might make sense to allow stty settings to be the default in "vi"
mode, but it definitely does not make sense to do in "emacs" mode.
Olaf Seibert
> I think you're hung up on the idea that the tty driver should be the one
> and only king of input editing.
Exactly. That's what the tty driver is for. To provide a consistent way
to input one's text to programs (and correct it). That can be configured
in a single place. That works for all programs, even those that don't
include specific support for it. That has no unneeded code duplication.
AmigaOS got all of that right. The CON: console windows (yes, opening a
file opens a new window for you) do command line editing, history and
file name completion for applications (when in cooked mode). No need for
any text application to reinvent the wheel. And if you don't like the
default CON: system, you can replace it too.
And, as der Mouse suggested, using a userland program to do this (with
ptys for instance) is also a good idea. I can think of fep and screen
which do this sort of thing (although screen has command line editing in
some form, I found it too difficult to use, probably because it is not
the main focus of screen).
-Olaf.
--
___ Olaf 'Rhialto' Seibert - rhi...@polder.ubc. -- If one tells the truth,
\X/ .kun.nl -- one is sure, sooner or later, to be found out. (Oscar Wilde)
Julian Coleman
> something with this in a few days.
Thanks.
Thought - what to do about the basic incompatabilities between stty settings
and readline shortcuts? For example, if I set stty werase ^A and use sh -E,
what will happen when I press ^A? I suppose that the readline shortcuts
should take precedence.
J
Julian Coleman
> Ah, why would anyone expect that changing the tty line edit characters
> would have any effect on a character-oriented editor that's built into
> really expect "stty werase :" to change vi's interpretation of ':'? I
> sure wouldn't. Neither do I assume that "stty erase ^?" will change my
> settings of delete-backward-char in emacs or jove.
Ah! I take it you haven't tried this? Try setting `stty werase :`, fire
up vi, enter insert mode, then type a few words. Type a ':', see the last
word get deleted. What did you expect to happen? If your strange editor
doesn't do this, then perhaps you should change it ;-)
Anyway, even if sh/libedit ignores werase, shouldn't ^W still delete the word
before the cursor? This seems to be the standard setting for readline.
> Yes there is some trickery with /bin/sh since it is fundamentally
> perceived to be tied to the very idea of command-line input. However
> there's a big difference between "cat -u | sh" and "sh -E"!
On my 1.4 system (don't have anything newer to test at hand), it means that
`sh -E` always uses ^W for delete last word, but `sh` follows the `stty
werase` setting. Neither uses ^W for kill. I've obviously missed your
point ...
Ignoring all this, I take it that it's not something strange that I'm doing
and other people also see ^W act like kill and not werase?
Thanks,
Greg A. Woods
> Subject: Re: ^W killed my line
>
> > I think you're hung up on the idea that the tty driver should be the one
> > and only king of input editing.
>
> Exactly. That's what the tty driver is for. To provide a consistent way
> to input one's text to programs (and correct it).
That's nice in theory, but this is Unix, not AmigaOS, and the tty
driver's real job is to do the I/O, not to do input editing. In Unix
the application does the editing and the commonality and consistency is
achieved by using the same code in every application (eg. in this case
linking against libedit).
Yes the Unix tty driver has always had some basic editing skills, though
usually restricted to just erasing the most recently typed character and
killing the entire input line. The additional features of killing the
previous word, redrawing the line, stopping erase drawing at the
beginning of the current input, etc., were all added by the "newcrt"
line discipline sometime in the early 4BSD days (or maybe even slightly
before). Someone at that time even experimented with putting an output
"pager" in the tty driver, but thankfully that was removed before it
spread too far.... These features never made it into Research Unix and
were not in any other major AT&T Unix release until SysVr4.
In any case if an application wants to do character editing in Unix it
must turn off canonical input processing in the tty driver. This means
that any such application would have to look at the current tty settings
in order to mimic them, but that this would obviously only make sense to
do if it fit into the UI paradigm the application presents. Perhaps it
might make sense for an input editor in "vi" mode, but it certainly does
not make sense to do in an input editor mimicing "emacs".
I'd recommend that anyone interested in this heritage of Unix look not
only at some of the older papers on the subject, but also look at the
way Plan 9 approached this stuff too.
Greg A. Woods
> Subject: Re: ^W killed my line
>
> up vi, enter insert mode, then type a few words. Type a ':', see the last
> word get deleted.
Eghads! That's weird! Oddly enough <CTRL-W> still does a word-erase in
vi too but suddenly there's no way to get to the extended command
prompt.
> What did you expect to happen?
That ':' would continue to have its default meaning of beginning an
extended (ex) command....
> If your strange editor
> doesn't do this, then perhaps you should change it ;-)
On the contrary if I wanted my editor to behave in such a way then I
would configure it to do so on purpose. I would not program it to
blindly follow the tty setting and get itself into the kind of trouble
vi seems willing to do.
> Anyway, even if sh/libedit ignores werase, shouldn't ^W still delete the word
> before the cursor? This seems to be the standard setting for readline.
Not in emacs mode.... :-)
> On my 1.4 system (don't have anything newer to test at hand), it means that
> `sh -E` always uses ^W for delete last word, but `sh` follows the `stty
> werase` setting. Neither uses ^W for kill. I've obviously missed your
> point ...
Hmmm.... that's not the case for 'sh' in any prior systems that I'm
running, nor in 1.4.1 or -current(1.4T), and I'd have reported it as a
bug if I'd discovered it in any other version! All the systems I've
tried it on always treat '^W' as "kill-region" as the default, just as
in Emacs or most of its clones.
(I see there's a bug of this nature in ksh now though....)
> Ignoring all this, I take it that it's not something strange that I'm doing
> and other people also see ^W act like kill and not werase?
If you're in emacs mode then the emacs interpretation of ^W (i.e.
kill-region) should always prevail unless the you have explicitly
re-configured it using the applications key rebinding functionality
(assuming there is any).
Olaf Seibert
> Someone at that time even experimented with putting an output
> "pager" in the tty driver, but thankfully that was removed before it
> spread too far....
The V7 system I used had that, yes. It was quite convenient.
Christos Zoulas
PER4MANCE, J. Dolecek <dol...@ics.muni.cz> wrote:
>der Mouse wrote:
>> The point is that it is fundamentally a line-oriented interface, so
>> (absent user configuration to the contrary) I expect, not unreasonably
>> I think, that it behave the way "everything else" with a line-oriented
>> interface does.
>
>something with this in a few days.
that is what tty_map is for. If it is broken in /current it should be
fixed.
christos
e...@nimenees.com
> Eghads! That's weird! Oddly enough <CTRL-W> still does a word-erase in
> vi too but suddenly there's no way to get to the extended command
> prompt.
> That ':' would continue to have its default meaning of beginning an
> extended (ex) command....
stty werase :
vi /tmp/foo
ibar baz<ESC>:wq
and I'm back at the command prompt.
eric
Greg A. Woods
> Subject: Re: ^W killed my line
>
> (absent user configuration to the contrary) I expect, not unreasonably
> I think, that it behave the way "everything else" with a line-oriented
> interface does.
Actually in modern "readline", "libedit", etc., the command-line editor
is usually a multi-line editor that just happens to have a one-line
"window".
> I like command-line editing -- when I ask for it. (For me to ask for
> it, it has to be configurable enough; I have yet to figure out how to
> configure ftp or gdb to behave sanely for my definition of "sanely", so
> I wouldn't turn on command-line editing for them. The problem is, I'm
> not given the choice - they come up with line editing on. ftp at least
> has a switch to turn it off, but that's the wrong default.)
Ah, ha! OK, I can certainly respect that.
The problem with choosing defaults in user interfaces is that the "safe"
default for one group of users might not be "safe" for another.
I don't know how to resolve this in general. What I've done is to
carefully craft a set of personal configuration files that are also
portable to all of the unix-like environments I use. These files
attempt to ensure that all the tools I'm bound to use will be in the
mode I expect them to be in at all times. Obviously this is an
imperfect and ongoing process....
> I don't think so; I think you misunderstood. This paragraph is about a
> *human* point, not a *technical* one - "it works for me, so ship it",
> without considering that not everybody uses eofc=^D, or suspc=^Z, or
> whatever. I submitted a PR about ftp when I first noticed the EOF
> problem. It was closed by someone who apparently read the one-line
> summary, tried it (with eofc=^D), found it worked, and didn't bother
> reading my "how to repeat" section which carefully said to use
> something other than ^D. This sort of "it works when I use the
> standard settings, so it's not broken" attitude is what I'm actually
> upset about here.
I think my point is that applications (including /bin/sh) that offer
command-line editing cannot be expected to always honour the stty
settings when they are in "edit" mode.
I agree that if you expect stty settings to prevail by default then
command-line editing must be turned off by default.
This is in effect a close cousin of the AT&T philosophy that kept ERASE
and KILL set to "#" and "@" respectively by default all of these years.
I must admit that I did once present a case suggesting that GNU Emacs
should honour ERASE (though only ERASE! ;-). However I had an ulterior
motive and indeed my goals were fulfilled without actually having to
have GNU Emacs peek at the stty settings.
> I don't know what planet you're from, but I still have plenty of
> commands that take longer than fifteen seconds to complete. The
> fastest NetBSD machine I've ever used still took over an hour to "make
> build". And I relatively often do over-the-net compares which I would
> like to auto-suspend things upon completion of - exactly the sort of
> thing the dsuspc is designed for. Yet I don't think I've seen an OS
> dsuspc has worked on in the last decade, not since mtXinu 4.3+NFS and
> possibly not even there - I forget.
Ah ha. I see. I've never used job control that way. Indeed I've been
using windowing systems long before I used X11 and I've almost always
agreed with the idea that job control should only be handled in the
windowing system, not in the tty driver. When I do suspend a job it's
usually only to put it into the background after I forgot to use '&'.
I've never found a desire to suspend a job on completion.
> You would really compel every program author to deal with the editline
> API in order to get rudimentary command line editing?? And talk about
> a portabilityi nightmare....
There's the option, as you suggest, of doing it in a front-end processor
(eg. the windowing system). I've always wanted to do more than just
cut&paste in an xterm for example (especially searching, like I can do
on my DMDs!).
Andrew Gillham
> On Tue 29 Feb 2000 at 15:50:19 -0500, Greg A. Woods wrote:
> > Someone at that time even experimented with putting an output
> > "pager" in the tty driver, but thankfully that was removed before it
> > spread too far....
>
> The V7 system I used had that, yes. It was quite convenient.
Hey, if someone would just write some SNA code, we could hook 3174
controllers to our NetBSD boxes, and then our 3270 terminals would
have builtin pagers also!! Whoopee! Where's my clear key?
Wow, I think someone beat me to it, look at pkgsrc/misc/fep. That
has got to be a Front End Processor implementation.
Ok, enough silliness from me. :-)
-Andrew
--
-----------------------------------------------------------------
Andrew Gillham | This space left blank
gil...@whirlpool.com | inadvertently.
I speak for myself, not for my employer. | Contact the publisher.
Christos Zoulas
Greg A. Woods <curren...@netbsd.org> wrote:
>[ On Tuesday, February 29, 2000 at 15:57:22 (+0000), Julian Coleman wrote: ]
>> Subject: Re: ^W killed my line
>>
>> > something with this in a few days.
>>
>
>Ah, no, it should not be fixed, especially not for "emacs" mode....
>
>> and readline shortcuts? For example, if I set stty werase ^A and use sh -E,
>> what will happen when I press ^A? I suppose that the readline shortcuts
>> should take precedence.
>
>mode, but it definitely does not make sense to do in "emacs" mode.
I suggest that the change then should be to have people put their
preferences in a file as described in editrc(5).
christos
Andrew Brown
>> That ':' would continue to have its default meaning of beginning an
>> extended (ex) command....
> huh? it works fine for me.:
>stty werase :
>vi /tmp/foo
>ibar baz<ESC>:wq
> and I'm back at the command prompt.
sure...that works fine. but try this:
vi /tmp/foo
ibar baz:<ESC>:wq
and tell us what the foo file contains. i think it contains "bar \n".
--
|-----< "CODE WARRIOR" >-----|
codew...@daemon.org * "ah! i see you have the internet
twof...@graffiti.com (Andrew Brown) that goes *ping*!"
and...@crossbar.com * "information is power -- share the wealth."
Andrew Brown
>commands that take longer than fifteen seconds to complete. The
>fastest NetBSD machine I've ever used still took over an hour to "make
>build". And I relatively often do over-the-net compares which I would
>like to auto-suspend things upon completion of - exactly the sort of
>thing the dsuspc is designed for. Yet I don't think I've seen an OS
>dsuspc has worked on in the last decade, not since mtXinu 4.3+NFS and
>possibly not even there - I forget.
if it does what i think it does (send a tstp to a process when it next
asks for input), then i think solaris has it working the way you
expect. just an fyi...
der Mouse
>> something with this in a few days.
Whether I think this is good depends on what you mean by it.
I'm not convinced you want it to do anything in particular with stty
settings when editing is turned on...though arguably if they don't
conflict with characters with other meaning it might be nice to pick
them up.
When editing hasn't been turned on, it should act just like the tty
driver; indeed, I see no reason it shouldn't actually let the tty
driver do it - making userland honor all the relevant bits correctly
would not be trivial to get right.
der Mouse
> doing and other people also see ^W act like kill and not werase?
You're not alone; I see it too.
Since these days most of my input-line-editing consists of sh with "set
-o emacs" in effect, where I don't use EOF often, this is the most
annoying single case, for me, of line editing ignoring stty settings.
So far it's just annoying, not serious, because it happens only when I
explicitly turn on line editing - losing word-erase is a price I know
I'm paying for getting the rest of line editing.
der Mouse
> preferences in a file as described in editrc(5).
Except that that affects only what happens once line editing is on. My
point is that line editing shouldn't *be* on unless and until the user
asks for it. (Eg, sh gets this right but ftp doesn't.)
der Mouse
> if it does what i think it does (send a tstp to a process when it
> next asks for input),
Basically, yes - it's just like suspc, except that suspc takes effect
when it's typed, whereas dsuspc takes effect when some process tries to
read it.
> then i think solaris has it working the way you expect.
Interesting. Sun must have fixed it - I just now tried SunOS 4.1.4 and
it didn't do diddly. ("sleep 5; cat" and type the dsuspc...nothing
happens when the sleep expires.)
And "Solaris" doesn't have it working, though perhaps some of the more
modern Solarices do. (And no, I'm not quibbling about SunOS being
retconned to Solaris 1.x.) I just now tried it on a machine running,
according to uname -a, SunOS 5.5.1 (ie, Solaris 2.5.1), and it failed
same as on SunOS 4.1.4.
der Mouse
>>> the one and only king of input editing.
>> Exactly. That's what the tty driver is for. To provide a
>> consistent way to input one's text to programs (and correct it).
> That's nice in theory, but this is Unix, not AmigaOS, and the tty
> driver's real job is to do the I/O, not to do input editing. In Unix
> the application does the editing and the commonality and consistency
> is achieved by using the same code in every application (eg. in this
> case linking against libedit).
It's hard to believe you're sitting there with a straight face and
recommending code duplication in *every application* instead of putting
the code in *one* place. (Well, okay, only those that take
line-oriented input; that's most of the programs that read from stdin
at all, based on a quick look at /bin and /usr/bin.)
But quite aside from that...this simply is false to historical fact, at
least in the last what, ten, fifteen years - however long I've been at
this stuff. Everything since 4.1c, the first UNIX variant I used, has
done it as described, using the tty driver as *the* means of line
editing for line-oriented input. A very few programs, most notably
shells, have had more sophisticated input line editors added to them,
but only recently (the last year or two) have I noticed it creeping
into other programs.
Before that...yes, the line editing provided by the tty driver was even
more rudimentary (typically just erase and kill). So was everything
else; certainly in those days there was no libedit, readline, or
whatever you call it, infecting programs that did line-based input.
> I'd recommend that anyone interested in this heritage of Unix look
> not only at some of the older papers on the subject, but also look at
> the way Plan 9 approached this stuff too.
Weren't you the one who just recently was saying that Plan 9 was
definitely *not* UNIX? It's an interesting alternative approach, but I
can't see much point in recommending it to someone interested "this
heritage of Unix", except perhaps for contrast - and then I'd
definitely point at a few others as well, like (say) VMS.
Greg A. Woods
> Subject: Re: ^W killed my line
>
> -o emacs" in effect, where I don't use EOF often, this is the most
> annoying single case, for me, of line editing ignoring stty settings.
> So far it's just annoying, not serious, because it happens only when I
> explicitly turn on line editing - losing word-erase is a price I know
> I'm paying for getting the rest of line editing.
In emacs mode you don't lose word-erase capability. It is: <ESC><BACKSPACE>
(If you haven't done "stty intr ^?" then <ESC><DELETE> will work too.)
der Mouse
>> rest of line editing.
> In emacs mode you don't lose word-erase capability. It is:
> <ESC><BACKSPACE>
> (If you haven't done "stty intr ^?" then <ESC><DELETE> will work
> too.)
Hmm. Thanks for the note, though I think that as far as I'm concerned
it makes little difference; it's not worth teaching my fingers yet a
third type of word-erase. (They currently know ^W for line-oriented
input (and vi insert mode) and esc-h within emacs.)
Sean Doran
> Wow, I think someone beat me to it, look at pkgsrc/misc/fep. That
> has got to be a Front End Processor implementation.
Actually, this is kinda neat, but invoking 'ssh somehost'
from within a shell under fep (or doing 'fep ssh somehost'
causes ugly results).
Sean.