aterm -e screen does not source .bashrc

[Alex Zbyslaw]

Giorgos Keramidas wrote:

>On 2006-07-11 09:09, Peter <petermatulis at yahoo.ca> wrote:
>  
>
>>I have the following in my .xinitrc file:
>>
>>aterm -e screen &
>>
>>What is happening is that neither /etc/profile nor ~/.profile are
>>being read.  How can I get either of them to be sourced?
>>    
>>
>
>By default, xterm, rxvt, aterm and various other terminal emulators
>start non-login shells.  This means that .profile is not sourced by the
>shell spawned by the terminal.  You can enable a `login shell' inside
>one of these terminal emulators with the -ls option:
>
>	aterm -ls -e screen &
>  
>
But a better option, IMHO,  is to correctly separate the functionality 
in your .profile from that in some other (e.g. .shinit) file.  One is 
for only stuff that happens at login, one for stuff that happens regardless.

from man sh

>      When first starting, the shell inspects
>      argument 0, and if it begins with a dash (-), the shell is also 
> consid-
>      ered a login shell.  This is normally done automatically by the 
> system
>      when the user first logs in.  A login shell first reads commands 
> from the
>      files /etc/profile and then .profile if they exist.  If the 
> environment
>      variable ENV is set on entry to a shell, or is set in the 
> .profile of a
>      login shell, the shell then reads commands from the file named in 
> ENV.
>      Therefore, a user should place commands that are to be executed 
> only at
>      login time in the .profile file, and commands that are executed 
> for every
>      shell inside the ENV file.  The user can set the ENV variable to some
>      file by placing the following line in the file .profile in the home
>      directory, substituting for .shinit the filename desired:
>
>            ENV=$HOME/.shinit; export ENV


IMHO, this one one of the ways that csh was miles ahead of sh as a login 
(as opposed to a scripting) shell.  These days, of course, a modern 
shell like bash has many of the best features of both, and even sh can 
(finally) do command line editing.

--Alex