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
