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.
>
> : INVOCATION
> : 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.
AR
Reply to: