Bug#10445: marked as forwarded (xterm: using -e with -ls fails to open a login shell)
Your message dated Sat, 26 Apr 2003 02:43:21 +0200
with message-id <20030426004321.GA26749@diku.dk>
has caused the Debian Bug report #10445,
regarding xterm: using -e with -ls fails to open a login shell
to be marked as having been forwarded to the upstream software
author(s) Thomas Dickey <dickey@herndon4.his.com>.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
---------------------------------------
Received: (at 10445-forwarded) by bugs.debian.org; 26 Apr 2003 00:43:24 +0000
>From makholm@diku.dk Fri Apr 25 19:43:23 2003
Return-path: <makholm@diku.dk>
Received: from hugin.diku.dk [130.225.96.144] (qmailr)
by master.debian.org with smtp (Exim 3.12 1 (Debian))
id 199Dml-0003gm-00; Fri, 25 Apr 2003 19:43:23 -0500
Received: (qmail 3007 invoked from network); 26 Apr 2003 00:43:21 -0000
Received: from pc-043.diku.dk (130.225.97.43)
by hugin.diku.dk with QMQP; 26 Apr 2003 00:43:21 -0000
Date: Sat, 26 Apr 2003 02:43:21 +0200
From: Henning Makholm <henning@makholm.net>
To: Thomas Dickey <dickey@herndon4.his.com>
Cc: 10445-forwarded@bugs.debian.org
Subject: one more documentation glitch in xterm
Message-ID: <20030426004321.GA26749@diku.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.4i
Delivered-To: 10445-forwarded@bugs.debian.org
X-Spam-Status: No, hits=-10.5 required=4.0
tests=BAYES_10,QUOTED_EMAIL_TEXT,USER_AGENT_MUTT
version=2.53
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp)
Many years ago, Jon Rabone complained to the Debian BTS thus:
> The -ls option does not do the right thing if -e is also specified to
> execute a command, because xterm does an execvp _before_ the shell
> (bash in this case) can read the system and user profiles.
It is now (since xterm-111 / XFree86 4.0.1) documented in the manual
page for xterm that -e and -ls are not supposed to work at the same
time. However, there is still a bug present - the manual page says
Note that this is incompatible with -e, since the
login program does not provide a way to specify
the command to run in the new shell. If you spec
ify both, xterm uses -ls.
whereas the reality is that it is -e rather than -ls that takes
priority (which has been the case ever since that notice was added to
the manual page; I just checked on cvsweb.xfree86.org). The actual
behavior is the Right one, because -ls can also be specified as a
resource, in which case one does not want to suppress -e options.
The last "-ls" in the quoted part of the manpage should be changed to "-e".
By the way, the manpage's explanation is not really convincing as it
stands: xterm does not ordinarily use login(1) to implement -ls, and
execl("/bin/sh", "-sh", "-c", "some command here");
does work as expected on all the systems I have tested it on.
I propose this alternative explanation:
The -ls flag (and the loginShell resource) is ignored if -e is
also given, because xterm does not know how to make the shell
start the given command after whatever it does when it is a login
shell - the user's shell of choice need not be a Bourne shell
after all. Also, xterm -e is supposed to provide a consistent
functionality for other applications that need to start text-mode
programs in a window, and if loginShell were not ignored, the
result of ~/.profile might interfere with that.
If you do want the effect of -ls and -e simultaneously, you
can usually get away with something like
xterm -e /bin/bash -l -c "my command here"
To be exact, -ls will not be completely ignored, because xterm -ls -e
does write a wtmp entry (if configured to do so), whereas xterm -e
does not. This might be considered a bug, but I don't think it bothers
anyone.
--
Henning Makholm "And when we retire, we will write the gospels."
Reply to: