NetBSD Problem Report #44347

From jmmv@netbsd.org  Sat Jan  8 09:17:49 2011
Return-Path: <jmmv@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 26BC563B89A
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  8 Jan 2011 09:17:49 +0000 (UTC)
Message-Id: <20110108091748.DA4E719CED8@mail.netbsd.org>
Date: Sat,  8 Jan 2011 09:17:48 +0000 (UTC)
From: jmmv@netbsd.org
Reply-To: jmmv@netbsd.org
To: gnats-bugs@gnats.NetBSD.org
Subject: sh does not respect editrc
X-Send-Pr-Version: 3.95

>Number:         44347
>Category:       bin
>Synopsis:       sh does not respect editrc
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 08 09:20:00 +0000 2011
>Closed-Date:    Mon Nov 22 05:31:13 +0000 2021
>Last-Modified:  Mon Nov 22 05:31:13 +0000 2021
>Originator:     Julio Merino
>Release:        NetBSD 5.99.43
>Organization:
Julio Merino
>Environment:


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.
>How-To-Repeat:
	Add 'bind -v' to ~/.editrc.
	Start 'ENV= /bin/sh'.
	Type 'set -o' and see how /bin/sh completely ignored you.

	You may also try to rebind ^I in ~/.editrc and later notice that your
	binding disappears in sh.
>Fix:
	I certainly do not understand why on earth we want to start the shell
	with editing disabled -- after all, if it was built against libedit
	(i.e. !SMALL) we may as well use it when we are interactive.

	So the fix is easy: at startup, load ~/.editrc and set the internal
	values of Vflag and Eflag depending on what the editing mode for
	libedit is (use el_get to query EL_EDITOR and EL_EDITMODE).  *Then*
	override those with any -V or -E flag that the user may have given.

	If the user wants to disable editing for whatever reason, he should
	still be able to do so by doing set +V or set +E... but starting with
	editing enabled by default makes things much easier.

	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.

>Release-Note:

>Audit-Trail:
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
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 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.

 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.


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

 	David

 -- 
 David Laight: david@l8s.co.uk

From: Julio Merino <jmmv@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/44347: sh does not respect editrc
Date: Sat, 8 Jan 2011 16:13:45 +0000

 On Sat, Jan 8, 2011 at 2:10 PM, David Laight <david@l8s.co.uk> wrote:
 > The following reply was made to PR bin/44347; it has been noted by GNATS.
 >
 > From: David Laight <david@l8s.co.uk>
 > To: gnats-bugs@NetBSD.org
 > Cc:
 > Subject: Re: bin/44347: sh does not respect editrc
 > Date: Sat, 8 Jan 2011 14:12:56 +0000
 >
 > =A0On Sat, Jan 08, 2011 at 09:20:01AM +0000, jmmv@netbsd.org wrote:
 > =A0> >Number: =A0 =A0 =A0 =A0 44347
 > =A0> >Category: =A0 =A0 =A0 bin
 > =A0> >Synopsis: =A0 =A0 =A0 sh does not respect editrc
 > =A0...
 > =A0> System: NetBSD blackbird 5.99.43 NetBSD 5.99.43 (GENERIC) #0: Fri Ja=
 n =A07 23:25:13 GMT 2011 =A0jmmv@blackbird:/home/jmmv/os/netbsd/obj.i386/ho=
 me/jmmv/os/netbsd/src/sys/arch/i386/compile/GENERIC i386
 > =A0> Architecture: i386
 > =A0> Machine: i386
 > =A0> >Description:
 > =A0> =A0 =A0 =A0/bin/sh does not respect the editing mode set in ~/.editr=
 c (nor it
 > =A0> =A0 =A0 =A0does respect whether editing is enabled/disabled at all).
 > =A0>
 > =A0> =A0 =A0 =A0The problem is that sh will only enable editing if set -V=
  or set -E
 > =A0> =A0 =A0 =A0are specified, defaulting to editing disabled otherwise.
 >
 > =A0That is the way it needs to be :-)
 > =A0The edit mode for a shell comes from the shells initialisation files.
 > =A0I'm not rure how you reconcile this with setup from .editrc, particula=
 ry
 > =A0since the effect of switching the shell between 'vi' and 'emacs' line
 > =A0editing has to work correctly - even though the .editrc mappings can
 > =A0only (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.

 > =A0filename completion is, in patticular, a double edged sword.
 > =A0I don't necessarily enable it, I type <tab> chars inside commands and
 > =A0filename completetion makes that a PITA (it really ought to be disable=
 d
 > =A0inside single quotes).
 >
 > =A0Command name completion is even more problematical, since it causes co=
 nfusing
 > =A0network delays if any of your path references a network filesystem.
 >
 > =A0Then we get the versions that use CDPATH when completing for 'cd' - wh=
 ich
 > =A0is 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.

 > =A0> =A0 =A0 =A0In other words: the defaults for the interactive shell sh=
 ould be those
 > =A0> =A0 =A0 =A0provided by ~/.editrc or, if not present, those built in =
 into libedit.
 > =A0> =A0 =A0 =A0It is up to the user to later override these values by ei=
 ther selecting
 > =A0> =A0 =A0 =A0a particular editing mode or disabling it altogether.
 >
 > =A0The presence of libedit shouldn't affect the shell.
 > =A0The 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.

 --=20
 Julio Merino

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: jmmv@netbsd.org
Subject: Re: bin/44347: sh does not respect editrc
Date: Wed, 17 Nov 2021 23:36:27 +0700

 After the initial discussion (all in Jan 2011) nothing happened
 about this, though the sh/libedit interface has been improved a
 little in  the interim.

 Unless there's some compelling reason to keep this open, I plan
 on closing it soon.

 Note: sh(1) is in control here, it has startup files that control
 how it is configured (and .editrc is not one of them - though that
 file can, and sometimes will, be consulted).   That is not going to
 change - if command line editing is to be enabled, it needs to be
 enabled in one of the shell startup files.

 kre

State-Changed-From-To: open->closed
State-Changed-By: kre@NetBSD.org
State-Changed-When: Mon, 22 Nov 2021 05:31:13 +0000
State-Changed-Why:
Overtaken By Events (no longer relevant)


>Unformatted:

Home	PR Database Search