Bug 182397

please try the following: 
> bash              # run another shell as this one will be killed after  
                    # exec 
> exec -l ksh - 
 
# now check if the environment variables are set 
 
This bug is similar to bug 164112, but for FC4 instead of -devel 

Yes, variables are set with "exec -l ksh -".
When I connect the linux box with "ssh" they are set too.
It seems to be related to the graphical login.

This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

I'm seeing this exact problem on FC6. Login shell is ksh. Logging in through
graphical shell results in profile not being processed. Boot to run level 3 
and log in using text login results in the profile being properly sourced.
*Clearly* the problem is with the graphical login.

Please change the version to FC6.

Workaround: Boot to run level 3, use text login, then startx to enter desktop.

Hi Michael,

what is the value of echo $SHELL ?

does 

exec -l $SHELL 

cause /etc/profile to get executed for you?

SHELL is /bin/ksh, and No. ;^) I was already looking into this further, so
here's the cut and paste of what I was doing when you updated the bug:

From instrumenting Xsession, SHELL is /bin/ksh. Xsession is running:

exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH /etc/X11/xinit/Xclients"

for me. Some experiments emulating what Xsession is doing:
33> bash
[mwc@jackie ~]$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/bin:/usr/games
[mwc@jackie ~]$ cat /var/tmp/z
#!/bin/sh

echo $*

echo "PATH is $PATH"
[mwc@jackie ~]$ exec -l /bin/sh -c "/var/tmp/z"

PATH 
is /bin:/usr/bin:/sbin:/usr/sbin:/opt/misc/bin:/usr/X11R6/bin:/home/mwc/bin:/home/mwc/bin/i686:.
34> bash
[mwc@jackie ~]$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/bin:/usr/games
[mwc@jackie ~]$ exec -l /bin/ksh -c "/var/tmp/z"

PATH is /usr/local/bin:/usr/bin:/bin:/usr/bin:/usr/games
35>

So it appears the ksh is missing the leading '-' being prepended to $0 by
bash's exec -l. bash and sh as invoked shells see it just fine and process
/etc/profile ok.

okay, thanks.  reassigning to ksh.

(In reply to comment #4)
> 
> Workaround: Boot to run level 3, use text login, then startx to enter desktop.

As other workaround, I modify /etc/X11/xinit/xinitrc-common. I replace:
# Set up i18n environment
#if [ -r /etc/profile.d/lang.sh ]; then
#  . /etc/profile.d/lang.sh
#fi

with 

for i in /etc/profile.d/*.sh
do
   if [ -r $i ]; then
      .  $i
   fi
done

to process all files in /etc/profile.d at this level. It solves my problem
temporarily but $HOME/.profile is still not processed.

Patrick

I've found that there is difference between 'exec -l ksh' and 'exec -l
/bin/ksh'. I put this into my ~/.profile:

export MY_VAR="My variable"

And then try to run ksh from bash:

[tsmetana@dhcp-lab-165 ksh-20060214]$ exec -l ksh
$ echo $MY_VAR
My variable
$ ps aux | grep ksh
tsmetana 31000  0.0  0.0   5200  1600 pts/0    Ss   12:49   0:00 -ksh
tsmetana 31037  0.0  0.0   3884   680 pts/0    S+   12:51   0:00 grep ksh
$ 

Now with full path:

[tsmetana@dhcp-lab-165 ksh-20060214]$ exec -l /bin/ksh
$ echo $MY_VAR

$ ps aux | grep ksh
tsmetana 31038  0.0  0.0   5004  1324 pts/0    Ss   12:52   0:00 -/bin/ksh
tsmetana 31057  0.0  0.0   3880   676 pts/0    S+   12:52   0:00 grep ksh
$

The fix is quite easy -- ksh strips the path from argv[0] but if the path starts
with '-' character, it's removed as well and ksh will never find out that it
should run as a login shell. I only wonder whether this was not intentional.

The latest version in rawhide should invoke a login shell whenever argv[0]
starts with '-'.