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

Re: Activating ls colors by default

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

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

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

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

:       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

:       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.

  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

Hope that helps.


Attachment: pgp8O9xFswUhY.pgp
Description: PGP signature

Reply to: