[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Activating ls colors by default

On Sat, May 01, 2004 at 05:59:36PM -0600, Bob Proulx wrote:
> Markus Lindström wrote:
> > Bob Proulx wrote:
> > > Please be specific.  What does "activated" mean?  Does it mean that
> > > you have this following alias in your ~/.bashrc file?
> > >
> > >    eval `dircolors -b`
> > >    alias ls='ls --color=auto'
> > 
> > Yes, that's the behavior I'm trying to obtain.
> Does your ~/.bash_profile source your ~/.bashrc file?  The default
> skeleton contains the following commented out.  Uncomment it.
>   # include .bashrc if it exists
>   if [ -f ~/.bashrc ]; then
>       source ~/.bashrc
>   fi
> That will cause your login shell to source your .bashrc file.
> Otherwise it won't be loaded at login time.  I think that is the part
> you are missing.
> > I need to identify the config file that bash uses in the virtual 
> > consoles. Any ideas on this?
> Let me repeat snippets from the bash manual in the "INVOCATION"
> section.  I will annotate.
> :       A  login  shell  is  one whose first character of argument
> :       zero is a -, or one started with the --login option.
> On the virtual consoles my shells are login shells.
>   echo $0
>   -bash
> As login shells the rules concerning them apply.  This is in contrast
> to xterm et al windows which are usually not login shells.
> :       When  bash is invoked as an interactive login shell, or as
> :       a non-interactive shell with the --login option, it  first
> :       reads and executes commands from the file /etc/profile, if
> :       that file exists.  After reading that file, it  looks  for
> :       ~/.bash_profile,  ~/.bash_login,  and  ~/.profile, in that
> :       order, and reads and executes commands from the first  one
> :       that  exists  and is readable.  The --noprofile option may
> :       be used when the shell is started to inhibit  this  behav­
> :       ior.
> The virtual console invokes 'getty' which invokes 'login' which
> launches '-bash' which looks at itself and sees the leading '-' and so
> knows it is a login shell.  It reads /etc/profile, one of
> ~/.bash_profile or ~/.bash_login or ~/.profile.
> Notice that ~/.bashrc is not sourced in the above.  I guess the
> rationale goes that a user might want one thing one place and another
> thing another place.  But typically you will always want the .bashrc
> sourced and will therefore need the following in your .bash_profile.
>   # include .bashrc if it exists
>   if [ -f ~/.bashrc ]; then
>       source ~/.bashrc
>   fi
> That is part of the skeleton but commented out.  You will need to
> uncomment it in order to get your .bashrc filed when you log into your
> account with a login shell.  This also applies to logging in with ssh
> and other network transports.
> :       When an interactive shell that is not  a  login  shell  is
> :       started,  bash reads and executes commands from ~/.bashrc,
> :       if that file exists.  This may be inhibited by  using  the
> :       --norc  option.
> Shells that are started by the window manager are not login shells
> normally.  However it is possible to specify them to be.  I have seen
> people be confused trying getting their .profile sourced and will
> specify the terminal to start up login shells as one method.  Better
> to set up ~/.xsession to do this instead.
> Shells that are not login shells will source ~/.bashrc file while
> login shells will not unless specifically told to do so.  However you
> will almost always tell bash to source the ~/.bashrc file explicitly
> in your ~/.bash_profile unless you really have a special purpose in
> mind.  I don't know why it is not the default in the skel file.  But
> since your ~/ is yours you can customize your ~/ files to do this
> easily.
> :       When  bash  is  started  non-interactively, to run a shell
> :       script, for example, it looks for the variable BASH_ENV in
> :       the  environment,  expands  its value if it appears there,
> :       and uses the expanded value as the name of a file to  read
> :       and  execute.   Bash  behaves  as if the following command
> :       were executed:
> :              if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
> :       but the value of the PATH variable is not used  to  search
> :       for the file name.
> Never set BASH_ENV.  It is most often a source of breakage for
> scripts.
> :       When  bash  is  started in posix mode, as with the --posix
> :       command line option, it follows  the  POSIX  standard  for
> :       startup  files.   In  this mode, interactive shells expand
> :       the ENV variable and commands are read and  executed  from
> :       the  file  whose  name  is  the  expanded value.  No other
> :       startup files are read.
> Never set ENV either for similar reasons.  But ENV is required for ksh
> users and sometimes follows ksh user's environment over when they
> switch to bash.  An easy mistake to make.  But bash does not need it.
> :       Bash attempts to determine when it is  being  run  by  the
> :       remote  shell daemon, usually rshd.  If bash determines it
> :       is being run by rshd, it reads and executes commands  from
> :       ~/.bashrc,  if  that file exists and is readable.
> This is tricky to use and can get people in trouble.  But the intent
> is to make aliased commands and other environment available the same
> as if you had logged in directly and run the command interactively.
> For example a typical alias is 'alias ls=ll'.  With that in place the
> following works both locally and remotely.
>   ll
>   ssh example.com ll
> The last piece of the puzzle is the ~/.xsession file.  This controls
> your graphical login.  The best way to have your graphical terminal
> shells load your environment is to have your .xsession file be invoked
> as a login shell.
>   #!/bin/bash --login
>   exec x-session-manager
> Make sure it is executable or it will have no effect.
>   chmod a+x $HOME/.xsession
> With that in place your xsession will be invoked as a login shell so
> /etc/profile and ~/.bash_profile will be sourced as illustrated above.
> The shells started with each terminal window will source the ~/.bashrc
> files and the environment will load exactly as one expects.
> When you log into the xdm, kdm, gdm graphical login managers you have
> a choice of selecting 'default' or of selecting a particular sesssion
> such as 'kde', 'gnome', fvwm, etc.  Make sure you select 'default' if
> you want your envionment sourced.  Selecting 'default' executes your
> ~/.xsession and the rest follows.  Selecting a specific window manager
> avoids ~/.xsession and sources only that window manager's files.  That
> is useful for when you have an error in your files which are
> preventing you from logging into the system.  But it can lead to
> confusion.
> Hope that helps.
> Bob

Tremendously. I have been following the thread with interest. Good
dissertation Bob, thanks again.


Reply to: