bin/146916: [patch] sh(1) uses dumb terminal in single-user mode

[Jilles Tjoelker]

On Sat, May 29, 2010 at 02:35:34AM +1000, Bruce Evans wrote:
> On Fri, 28 May 2010, Jilles Tjoelker wrote:
> > On Fri, May 28, 2010 at 12:38:30PM +0200, Ed Schouten wrote:
> >> * Ed Schouten <ed at 80386.nl> wrote:
> >>> Why should the shell be responsible for this? Shouldn't we put stuff
> >>> like this in /sbin/init?

> Of course not.  This belongs in root's dotfiles.  Although login.conf
> supports setting TERM in 2 different ways, this is so useful that the
> default login.conf doesn't even provide a bad example of how to use it.
> Here are 2 bad examples:

> % --- login.conf~	Mon Jun  7 02:19:08 2004
> % +++ login.conf	Sat May 29 01:31:01 2010
> % @@ -22,5 +22,6 @@
> %  	:copyright=/etc/COPYRIGHT:\
> %  	:welcome=/etc/motd:\
> % -	:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
> % +	:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES,XXTERM=foo:\
> % +	:term=bar:\
> %  	:path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin /usr/X11R6/bin ~/bin:\
> %  	:nologin=/var/run/nologin:\

> Defaulting this in the wrong place login.conf is a littler further
> away for init than for login, since init only calls setusercontext()
> with a limited set of flags not including ones that set the environment.

Hmm? login.conf seems the wrong place to set TERM, as the terminal type
is either already set correctly by whatever is making the connection, or
it depends on what is connected to the port (dialin has almost died out,
and even if it is used, the shell startup file seems a better place for
setting the terminal type in that case).

> >> Oh wait. Never mind. I understand the issue. Jilles, what do you think
> >> about this?

> > Yes, I think init(8) should attempt to pass a suitable TERM to the
> > single-user shell. This value could be hard-coded (TERM=xterm will
> > usually be close enough) or taken from /etc/ttys somehow.

> I disagree.  Hard coding it is bad and login.conf bloat belongs in a
> shell even less than it does in login (login.conf doesn't infect sh
> now).  Everyone knows that they should edit their dotfiles for things
> this, but editing /etc/login.conf requires privilege and what it can
> do is less well known.  However, I'd prefer the default settings to
> be in /etc/profile instead of /root/.profile.  The release version of
> the former does too little (nothing unless things are commented in,
> and then very little), while the release version of the latter does
> too much.  I don't know what happens for csh.

> > The sh(1) patch to allow updating libedit's TERM looks OK, although it
> > probably should not react to TERM changes in subshells.

> The bug seems to be mainly that sh calls libedit before sourcing the
> dotfiles.

Likely. This may make the code a bit uglier, but I have done a similar
thing to avoid touching the initial MAIL in non-interactive shells or if
it is changed in a startup file.

> > I do not plan to revert r206182, putting 'set -o emacs' in root's shell
> > startup files instead. I did 'set -o emacs' in the shell itself so that
> > it works even if there are no startup files at all, such as 'make
> > buildenv' and chroot shells.

> Why not?  Non-interactive shells shouldn't even be initializing libedit.

And they don't. Libedit is only initialized implicitly in interactive
shells with terminals.

> chroot shells are more interesting.  Is there a single-user mode for
> chroot shells?  logins in chrooted environments may have other problems
> if there is no login.conf and/or no dotfiles.

Certainly, but it appears that libedit is not crippled much by a dumb
TERM.

> I used to type 'set -E' a lot (this is easier to type than "set -o
> emacs").  A few years ago I put 'set -o emacs' in /root/.profile.  I
> thought that this was standard in -current, but it seems that I copied
> it from a system supplied by obrien at .  This works well, even with TERM
> uninitialized when it probably shouldn't, and even with TERM initialized
> wrong when it certainly shouldn't, provided the actual terminal is
> sufficiently like cons25 (ANSI?).  I keep ignoring the message about
> the terminal being dumb, and didn't notice before that it is supposed
> to be non-dumb.  ed works with dumb terminals and using other editors
> requires more than setting TERM.  The setting of TERM in root's .profile
> was added in 1994, but apparently never really worked due to this bug.
> First it was pc3, then unconditionally cons25, then conditionally
> cons25, then conditionally xterm.

The TERM change is passed to processes started from the shell.

> /etc/skel/dot.profile is more careful about this.

That's /usr/share/skel/dot.profile these days.

> It's setting of TERM is commented out.  OTOH, its setting of PATH is
> unconditional.  The defaulting of PATH in login.conf is almost useless
> since almost everyone clobbers PATH like this in their dotfiles.

Yes. In turn, the PATH setting in login.conf clobbers _PATH_DEFPATH but
that's a good thing since _PATH_DEFPATH is too minimal.

-- 
Jilles Tjoelker