From owner-freebsd-bugs@FreeBSD.ORG Wed Jun 2 20:42:48 2010 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8986F1065675; Wed, 2 Jun 2010 20:42:48 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 1E0C58FC24; Wed, 2 Jun 2010 20:42:48 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 2221A35A822; Wed, 2 Jun 2010 22:42:47 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 16760172A0; Wed, 2 Jun 2010 22:42:47 +0200 (CEST) Date: Wed, 2 Jun 2010 22:42:47 +0200 From: Jilles Tjoelker To: Bruce Evans Message-ID: <20100602204246.GC19165@stack.nl> References: <201005281033.o4SAXjlv078228@freefall.freebsd.org> <20100528103618.GJ56080@hoeg.nl> <20100528103830.GK56080@hoeg.nl> <20100528124557.GA50785@stack.nl> <20100529013419.D22843@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100529013419.D22843@delplex.bde.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Ed Schouten , freebsd-bugs@freebsd.org, Guy Yur , brucec@freebsd.org Subject: Re: bin/146916: [patch] sh(1) uses dumb terminal in single-user mode X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 20:42:48 -0000 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 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@. 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