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

[Bruce Evans]

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.

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

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

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.

/etc/skel/dot.profile is more careful about this.  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.

Bruce