Bug#740919: xterm: clears $SHELL from environment at startup
On Thu, 6 Mar 2014, Thomas Dickey wrote: ok I fixed the regression (as well as another one which doesn't affect Debian, but Fedora), and uploaded #303 OK, thanks. I’ve built me my own package, and can confirm that it fixes this problem. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740919: xterm: clears $SHELL from environment at startup
On Fri, Mar 07, 2014 at 10:08:15AM +0100, Thorsten Glaser wrote: On Thu, 6 Mar 2014, Thomas Dickey wrote: ok I fixed the regression (as well as another one which doesn't affect Debian, but Fedora), and uploaded #303 OK, thanks. I’ve built me my own package, and can confirm that it fixes this problem. no problem (report bugs) -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#740919: xterm: clears $SHELL from environment at startup
Package: xterm
Version: 302-1
Severity: important
Hi *,
I’ve got a script that dumps the contents of the environment at
startup to syslog, and just used it to investigate a user-visible
problem. tl;dr: the output of xterm -e dumpargs differs between
screen 301-1 (Debian) and 302-1 (Debian; no idea if this bug is
also upstream):
Among the usual differences like $PGRP and $WINDOWID I have:
--- x1 2014-03-06 09:28:26.356676132 +0100
+++ x2 2014-03-06 09:28:26.092672608 +0100
@@ -31,8 +31,8 @@
typeset PWD=/home/tglase
typeset -x QUILT_PATCHES=-
-typeset -i -x -U RANDOM=15871
+typeset -i -x -U RANDOM=565
typeset -i SECONDS=0
-typeset -x SHELL=
+typeset -x SHELL=/bin/mksh
typeset -x SIRCNICK='mira|AO'
typeset -x SIRCSERVER=127.0.0.1:s7000
typeset -x SSH_AGENT_PID=3511
@@ -52,12 +52,12 @@
typeset -x USER=tglase
typeset -i -U USER_ID=2339
typeset -x VISUAL=/usr/bin/jupp
-typeset -x WINDOWID=25165837
+typeset -x WINDOWID=33554445
typeset -x WINDOWPATH=7
typeset -x
XDG_SESSION_COOKIE=87bd0826b5c41524a188f458494f992f-1393518574.144306-436980184
typeset -x XDM_MANAGED='method=classic'
typeset -x XTERM_LOCALE=en_GB.UTF-8
typeset -x XTERM_SHELL=/usr/local/bin/dumpargs
-typeset -x XTERM_VERSION='XTerm(302)'
+typeset -x XTERM_VERSION='XTerm(301)'
typeset -x _=/usr/bin/xterm
args(0) 0:/usr/local/bin/dumpargs
User story: I use “xterm -e screen” (basically) to start GNU screen,
which then has “shell -${SHELL}” in ~/.screenrc which should really
really not be empty. Also, xterm IMHO has no business touching that
part of my environment.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (100,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Versions of packages xterm depends on:
ii libc6 2.18-4
ii libfontconfig1 2.11.0-5
ii libice6 2:1.0.8-2
ii libtinfo5 5.9+20140118-1
ii libutempter01.1.5-4
ii libx11-62:1.6.2-1
ii libxaw7 2:1.0.12-1
ii libxft2 2.3.1-2
ii libxmu6 2:1.1.1-1
ii libxpm4 1:3.5.10-1
ii libxt6 1:1.1.4-1
ii xbitmaps1.1.1-2
Versions of packages xterm recommends:
ii x11-utils 7.7+1
Versions of packages xterm suggests:
pn xfonts-cyrillic none
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740919: xterm: clears $SHELL from environment at startup
On Thu, Mar 06, 2014 at 09:31:36AM +0100, Thorsten Glaser wrote: Package: xterm Version: 302-1 Severity: important Hi *, I’ve got a script that dumps the contents of the environment at startup to syslog, and just used it to investigate a user-visible problem. tl;dr: the output of xterm -e dumpargs differs between screen 301-1 (Debian) and 302-1 (Debian; no idea if this bug is also upstream): Among the usual differences like $PGRP and $WINDOWID I have: --- x12014-03-06 09:28:26.356676132 +0100 +++ x22014-03-06 09:28:26.092672608 +0100 @@ -31,8 +31,8 @@ typeset PWD=/home/tglase typeset -x QUILT_PATCHES=- -typeset -i -x -U RANDOM=15871 +typeset -i -x -U RANDOM=565 typeset -i SECONDS=0 -typeset -x SHELL= +typeset -x SHELL=/bin/mksh hmm - I see that I still overlooked documenting the /etc/shells tie-in in the manpage. It's in the changelog, of course, and if you read that you may notice that the change was intentional (to fix a serious bug in contrast to a user-configurable preference). So - to the point: is /bin/mksh in /etc/shells? If not, adding it there is the way to get your intended behavior. If it is, then there's some additional aspect that I've overlooked. -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#740919: xterm: clears $SHELL from environment at startup
Thomas Dickey dixit: you may notice that the change was intentional (to fix a serious bug in contrast to a user-configurable preference). Hm, which bug? So - to the point: is /bin/mksh in /etc/shells? If not, adding it there is the way to get your intended behavior. If it is, then there's some additional aspect that I've overlooked. Yes, /bin/mksh is in /etc/shells. I can test patches, if you throw them to t.gla...@tarent.de (work eMail). In case that’s relevant, I have UXTerm*VT100*loginShell: true in my .Xresources. (And my login shell is mksh. Of course. ☺) bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740919: xterm: clears $SHELL from environment at startup
On 2014-03-06 10:20 +0100, Thomas Dickey wrote: On Thu, Mar 06, 2014 at 09:31:36AM +0100, Thorsten Glaser wrote: I’ve got a script that dumps the contents of the environment at startup to syslog, and just used it to investigate a user-visible problem. tl;dr: the output of xterm -e dumpargs differs between screen 301-1 (Debian) and 302-1 (Debian; no idea if this bug is also upstream): Among the usual differences like $PGRP and $WINDOWID I have: --- x1 2014-03-06 09:28:26.356676132 +0100 +++ x2 2014-03-06 09:28:26.092672608 +0100 @@ -31,8 +31,8 @@ typeset PWD=/home/tglase typeset -x QUILT_PATCHES=- -typeset -i -x -U RANDOM=15871 +typeset -i -x -U RANDOM=565 typeset -i SECONDS=0 -typeset -x SHELL= +typeset -x SHELL=/bin/mksh hmm - I see that I still overlooked documenting the /etc/shells tie-in in the manpage. It's in the changelog, of course, I cannot deduce from the changelog that xterm actually _clears_ the SHELL variable if it does not point to a shell in /etc/shells. Besides that, the comment you added in front of the validShell function is also rather misleading: --8---cut here---start-8--- --- a/main.c +++ b/main.c @@ -3145,6 +3151,7 @@ find_utmp(struct UTMP_STR *tofind) /* * Only set $SHELL for paths found in the standard location. + * ...or if $SHELL happens to give an absolute pathname to an executable. */ static Boolean validShell(const char *pathname) --8---cut here---end---8--- So - to the point: is /bin/mksh in /etc/shells? If not, adding it there is the way to get your intended behavior. Almost everybody can set SHELL to their liking, but they might not be allowed to change /etc/shells. Cheers, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740919: xterm: clears $SHELL from environment at startup
On Thu, Mar 06, 2014 at 07:47:51PM +0100, Sven Joachim wrote: hmm - I see that I still overlooked documenting the /etc/shells tie-in in the manpage. It's in the changelog, of course, ...however, Thorsten's report is against a regression due to a late change that I made (incorrectly) based on a Coverity report pointing out a possible null-pointer dereference in one of the paths. At the moment I'm validating a different fix. I cannot deduce from the changelog that xterm actually _clears_ the SHELL variable if it does not point to a shell in /etc/shells. Besides that, the comment you added in front of the validShell function is also rather misleading: I spent some time tonight and documented the unset in the manpage. (I meant to do this in #302, but overlooked it in the details for the discussion of the optional parameter). --8---cut here---start-8--- --- a/main.c +++ b/main.c @@ -3145,6 +3151,7 @@ find_utmp(struct UTMP_STR *tofind) /* * Only set $SHELL for paths found in the standard location. + * ...or if $SHELL happens to give an absolute pathname to an executable. I'll remove that, then. It was leftover from changes I made before factoring out validProgram(). */ static Boolean validShell(const char *pathname) --8---cut here---end---8--- So - to the point: is /bin/mksh in /etc/shells? If not, adding it there is the way to get your intended behavior. Almost everybody can set SHELL to their liking, but they might not be allowed to change /etc/shells. sure - but not all values of SHELL are usable, and at least two paths through this maze can lead to failure if SHELL happens to not be a regular shell - hence my changes to how SHELL is set (or reset). /etc/shells has a better list than I can get elsewhere - so I chose that. -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#740919: xterm: clears $SHELL from environment at startup
On Thu, Mar 06, 2014 at 08:08:54PM -0500, Thomas Dickey wrote: On Thu, Mar 06, 2014 at 07:47:51PM +0100, Sven Joachim wrote: hmm - I see that I still overlooked documenting the /etc/shells tie-in in the manpage. It's in the changelog, of course, ...however, Thorsten's report is against a regression due to a late change that I made (incorrectly) based on a Coverity report pointing out a possible null-pointer dereference in one of the paths. At the moment I'm validating a different fix. ok I fixed the regression (as well as another one which doesn't affect Debian, but Fedora), and uploaded #303 -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
