Re: bin/44347: sh does not respect editrc

[Julio Merino <jmmv%NetBSD.org@localhost>]

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
> Cc:
> 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 
>  jmmv@blackbird:/home/jmmv/os/netbsd/obj.i386/home/jmmv/os/netbsd/src/sys/arch/i386/compile/GENERIC
>  i386
>  > 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
modified accordingly.

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 
> selecting
>  >      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.

-- 
Julio Merino