[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/44347: sh does not respect editrc
On Sat, Jan 8, 2011 at 2:10 PM, David Laight <david%l8s.co.uk@localhost> wrote:
> The following reply was made to PR bin/44347; it has been noted by GNATS.
> From: David Laight <david%l8s.co.uk@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Subject: Re: bin/44347: sh does not respect editrc
> Date: Sat, 8 Jan 2011 14:12:56 +0000
> On Sat, Jan 08, 2011 at 09:20:01AM +0000, jmmv%netbsd.org@localhost wrote:
> > >Number: 44347
> > >Category: bin
> > >Synopsis: sh does not respect editrc
> > System: NetBSD blackbird 5.99.43 NetBSD 5.99.43 (GENERIC) #0: Fri Jan 7
> 23:25:13 GMT 2011
> > Architecture: i386
> > Machine: i386
> > >Description:
> > /bin/sh does not respect the editing mode set in ~/.editrc (nor it
> > does respect whether editing is enabled/disabled at all).
> > The problem is that sh will only enable editing if set -V or set -E
> > are specified, defaulting to editing disabled otherwise.
> That is the way it needs to be :-)
> The edit mode for a shell comes from the shells initialisation files.
> I'm not rure how you reconcile this with setup from .editrc, particulary
> since the effect of switching the shell between 'vi' and 'emacs' line
> editing has to work correctly - even though the .editrc mappings can
> only (probably) apply to one of the modes.
I guess it could work like this:
1) sh explicitly disables editing after el_init.
2) sh loads editrc with el_source.
3) If editrc enabled editing and/or set the editing mode explicitly,
sh deduces the initial value of its own vi/emacs variables.
4) If the user specified -V, +V, -E or +E, the libedit state is
bash does something similar.
> filename completion is, in patticular, a double edged sword.
> I don't necessarily enable it, I type <tab> chars inside commands and
> filename completetion makes that a PITA (it really ought to be disabled
> inside single quotes).
> Command name completion is even more problematical, since it causes confusing
> network delays if any of your path references a network filesystem.
> Then we get the versions that use CDPATH when completing for 'cd' - which
> is again a pita.
Sure, this is the "normal" behavior of the autocompletion. I am not
saying that tab completion should be enabled by default. I am just
saying that if a user sets whatever binding for ^I they want in
.editrc, sh will silently ignore it.
> > In other words: the defaults for the interactive shell should be those
> > provided by ~/.editrc or, if not present, those built in into libedit.
> > It is up to the user to later override these values by either
> > a particular editing mode or disabling it altogether.
> The presence of libedit shouldn't affect the shell.
> The shell uses libedit to implement it's own command editing.
So, then, why is sh reading .editrc *at all*? It seems to only cause
problems and getting it to "work right" (whatever that means, as I'm
not even sure) is non-trivial and surely controversial.
Main Index |
Thread Index |