Not really, since no one guarantees your shell is bash. GNU bash is the default 
shell only in Linux. Almost all other architectures default to either the original bourne 
shell /bin/sh or to the C shell (tcsh). 
 
You can symlink your ~/.bash_profile to ~/.profile to make it be read during session 
start up. 

i prefer to put any not bash-specific commands into .profile and make .bash_profile 
source .profile in addition to making any bash-specific setup. 
 

Although XSession can be configured to source ones profile, I would find it nice if there was a checkbox for sourcing the .profile file (either when logging in using kdm or in kcontrol. or both;). 
Using a .profile file doesn't rely on using bash or any other shell, so I guess this should be acceptable for all users.

Currently .profile doesn't seem to be sourced (on Linux at least). 
This seems to be completely in accordance with the man page for bash: 
 
       If  bash  is  invoked  with  the name sh, it tries to mimic the startup 
       behavior of historical versions of sh as  closely  as  possible,  while 
       conforming  to the POSIX standard as well.  When invoked as an interac- 
       tive login shell, or a non-interactive shell with the  --login  option, 
       it  first  attempts  to read and execute commands from /etc/profile and 
       ~/.profile, in that order.  The  --noprofile  option  may  be  used  to 
       inhibit  this  behavior.  When invoked as an interactive shell with the 
       name sh, bash looks for the variable ENV, expands its value  if  it  is 
       defined,  and uses the expanded value as the name of a file to read and 
       execute.  Since a shell invoked as sh does not attempt to read and exe- 
       cute  commands from any other startup files, the --rcfile option has no 
       effect.  A non-interactive shell invoked with  the  name  sh  does  not 
       attempt  to  read  any  other  startup files.  When invoked as sh, bash 
       enters posix mode after the startup files are read. 
 
(Note that 'startkde' is invoked using 'sh': 
 
homealone[2]head -1 /usr/bin/startkde 
#!/bin/sh 
) Anyway I am not able to put any environment variables in a KDE session using 
.profile. If I put 
 
export TTT=hh 
 
in .profile the TTT variable will not be set in subshells of startkde. 
 
Why not make the startkde script symmetric, i.e., it sources startup scripts 
just as it executes shutdown scripts? This would mean putting something like 
 
# Source scripts found in $KDEDIRS/startup 
for prefix in `kde-config --path exe| sed -e 's^bin/^startup/^g;s^:^ ^'` 
do 
  for file in $prefix/* 
  do 
    if test -f $file 
    then 
       . $file 
    fi 
  done 
done 
 
 
somewhere in 'startkde'. 

Subject: Re:  .bash_profile is not executed

On Fri, Sep 19, 2003 at 05:46:42AM -0000, Torsten Ekedahl wrote:
> Currently .profile doesn't seem to be sourced (on Linux at least). 
>
correct. startkde is not supposed to source any shell's startup scripts.
if you want it to see an environment resembling one of an interactive
shell, patch your Xsession - kdm's default Xsession already pretends to
be an interactive posix shell by sourcing /etc/profile and  ~/.profile.

> Why not make the startkde script symmetric, i.e., it sources startup scripts 
> just as it executes shutdown scripts?
>
the idea is, that startup scripts are already handled by the Autostart
folder. anyway, some symmetry certainly would not hurt. i'm all for it.
coolo?

Sorry I shouldn't have said symmetry as I want the files to 
be *sourced* which is not quite symmetric. In this way environment variables 
 can be set which is not possible with Autostart. 
 
I agree that it is actually a bad idea to source .profile as that could 
lead to undesirable results. 

I am at a total loss to see why this bug was closed!

The problem does exist.  On Linux systems, there is NO file:

$HOME/.profile

and there is a file:

$HOME/.bash_profile

The only solution that I see for this is for the install to determine if the shell it is using is Bash and do an "Xsession.in" file with the appropriate variables.

I have found that the best way to acomplish the Bash startup is to make the Xsession script a login script -- possibly this is only suitable for Linux -- by changing first line:

#! /bin/bash --login

and let Bash run: "/etc/profile" and: "$HOME/.bash_profile".

IMO, it would be best to have seperate script prototypes for Shell & Bash and have install choose the correct one to install.  We should not create a problem for every Linux user in order to also have this run on non-Linux systems.

--
JRT

I have confirmed the bug in HEAD.

--
JRT

you decide which files are on your system.
i'm not going to make Xsession pretend to be every known bourne compatible shell. this would a) be a mess and b) still leave the users of non-sh shells in the dark. actually Xsession is not supposed to pretend to be any shell at all, but using the lowest common denominator (plain sh) won't cause too many problems and covers quite some cases. the user just has to make sure that parts that are common to all shs are in sh's profiles and that the clones' scripts source the common files. of course that's beyond the casual user, but that's what we have distributors for - try to convince them to fix their crap, not me to work around it.

The fact is that we have a lot of non-experts installing KDE from source on Linux.

If you read the help lists, you would know that the failure to source the: "~/.bash_profile" script has been a common problem for some time.

The 'Ostrich algorithm' is not a proper solution.

I do not believe that there are a not a lot of shells that need compatibility, only Bash.

This is a BUG not a WISHLIST item.  Please leave it open till it is fixed.

--
JRT

sorry, but you're an arrogant asshole (or simply a dumbass). you should seriously rethink the way you're "presenting" your opinion (too bad that bugzilla does not visibly log state changes).

this is the last time i repeat it, so listen carefully:
- neither Xsession nor startkde (the alternative victim, err, candidate for your ideas) are any existing other shell - whether Xsession can be considered a shell at all is arguable. ergo, them not sourcing other shells' startup scripts is NOT a bug. Xsession has xprofile, and startkde recently got the env directory - _those_ are the relevant configs.
- you wanting to WORK AROUND the problem of users being unable/unwilling to modify the proper configs IS a wish. it does NOT matter, how many users are faced with it.
- I am the kdm (and consequently Xsession) maintainer, and i decided that i don't want that modification. you can try to convince me to give up my good taste, but "grabbing" the report (obviously with the intention to "fix" it yourself behind my back) is definitely NO option.

Wouldn't the proper fix be to let the shell behave as the
login shell it is?

--- Xsession~   2004-02-26 10:45:04.000000000 +0100
+++ Xsession    2004-02-26 10:45:27.000000000 +0100
@@ -1,4 +1,4 @@
-#! /bin/sh
+#! /bin/sh -l
 # Xsession - run as user

 # redirect errors to a file in user's home directory if we can
@@ -13,8 +13,6 @@
 done

 DM_PATH=$PATH
-test -f /etc/profile && . /etc/profile
-test -f $HOME/.profile && . $HOME/.profile
 IFS_SAVE=$IFS
 IFS=:
 for i in $PATH; do

this is unportable ...

Re: Comment #12

IIUC the "--login" option is a Bash extension (a very useful one, IMHO).  The original Bourne shell will only do a login when called by: "login" so this:

	#! /bin/bash --login

would be a Linux only solution.  This is the way my Linux system is setup and it works fine.

For your suggestion to work on Linux you also would need to deal with the PATH MUNGing code:

DM_PATH=$PATH
PATH=

 * * *

IFS_SAVE=$IFS
IFS=:
for i in $DM_PATH; do
    case :$PATH: in
      *:$i:*) ;;
      ::) PATH=$i;;
      *) PATH=$PATH:$i;;
    esac
done
IFS=$IFS_SAVE
export PATH

I am not certain *exactly* what this code does or why it is needed, only that I don't have this 'junk' on my system and it works fine.

There are two possible PATH issues:

1.  The path for X11
2.  The path for KDE

We might want to check to see if the system had correctly set these. 

With the path for X11, I would think that this wasn't needed since a system that starts X11 without adding the X11 path to the PATH is seriously broken.  The: "kdmrc" file still indicates that it is included in the Default PATH (a bug that has never been fixed?) so it would be redundantly added if the Default KDM PATH were ever used.  

Unfortunately, the systems default PATH is embedded in: "login", so a simple and elegant solution is not possible.

The KDE path is a more complicated issue -- or perhaps a mess.  The system should set this (otherwise how are you going to be able to use KDE applications if you aren't running KDE?).  On Linux this should be done with: "profile.d/*.sh" scripts.  Unfortunately, not all *NIX systems support 'profile.d' scripts.  Currently, the: "genkdmconf" program (a very inelegant way to do this) produces a: "kdmrc" file that results in the KDE path(s) being redundantly added to PATH.  But, we should probably check for this since there will be serious problems if it isn't set.

This leads to the question: where is KDEDIR (and KDEDIRS) being set?  It appears to me that it is the: "startkde" script that should deal with the PATH & KDEDIR issues.

In conclusion, I still think that there should be separate: "Xsession" scripts -- for Bash based systems and for POSIX/Bourne based systems -- this is probably the best and most elegant solution.  I would have the: "configure" script check for Bash (with a paramater to override) and then use a "Xsession.in" file (perhaps two would be needed with install choosing the one to install) to generate the script.

--
JRT

Why not just source .bash_profile from .profile if the run-time shell is bash?

because that's even more backwards ...

under the pressure of reckless pragmatists ;) i implemented this WISH. the startup of bash, zsh and csh/tcsh is now emulated. plain sh (and ksh, which doesn't have other scripts) is still emulated, of course.

btw, the PATH merging magic is gone now, as i implemented a cleaner solution.

Hmm, if I understand this correctly, even the current "pressured" implementation of this into kdm would not help when kde is started from gdm or xdm, is that right?

With debian (and gdm) I experience a non-system-default umask setting only in KDE and all apps started in that KDE session. All other DEs work ok, maybe they are not doing it "the right way" way but it works somehow.

If there is a better way you know about how the distro should handle this please add a comment to http://bugs.debian.org/250645 simply by sending e-mail to 250645@bugs.debian.org

Kind Regards,
Christian

obviously it serves only kdm, unless the other dms use the same Xsession.

depending on the gdm version you may still be using a script-per-session-type setup - that would explain why only kde behaves differently only under gdm.

This line of code in Xsession in KDE 3.4.1 did not work for me:
eval `$SHELL -c 'if (-f /etc/csh.login) source /etc/csh.login > /dev/null; if (-f ~/.login) source ~/.login > /dev/null; /bin/sh -c export'`

What would happen is that the output of .cshrc would not be able to be executed by the eval and the whole line would bomb out.

Adding a grep for export fixes the problem.  Now someone could write a cshrc to break this code, but its not likely to happen by chance.

eval `$SHELL -c 'if (-f /etc/csh.login) source /etc/csh.login > /dev/null; if (-f ~/.login) source ~/.login > /dev/null; /bin/sh -c export' |grep ^export`

I also like this non-portable shorter version.  csh -l is not portable.

eval `echo '/bin/sh -c export' | csh -l | grep ^export`

Judd

i remembered why the grep ^export variant does not work: export might output multi-line export statements, which would be butchered. also, bash's export outputs declare statements - i wonder how many other variants exist.
applying more redirection magic like
eval `$SHELL -c 'if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login) source ~/.login; /bin/sh -c "export >&9"' 9>&1 > /dev/null` 
doesn't work, either - csh seems to close the extra fd, and apart from that the extended file handle constructs are non-portable, iirc.
outputting to a temp file and sourcing it seems like the only viable solution. but then the secure temp file creation portability problem comes up.

At least for the umask setting pam_umask seems to be the correct distro solution I asked for to recomend in order to avoid this whole scatterd setup files and sourceing mess.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314539
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248150

Maybe the same is true for other settings, so that eventually sourceing other programms rc files can be disabled again in favor of own config files (kde's /env) and global PAM setup?

for another chapter of "having fun by pretending to be a shell", see bug #89452.

> outputting to a temp file and sourcing it seems like the only viable solution.
>
so i did it ...