Re: [SLUG] .bashrc settings

From: Mike Manchester (mchester@pobox.com)
Date: Wed Apr 03 2002 - 05:59:14 EST


Thanks Ian for correcting me on that. I knew that, but had strings on
my mind from some things I had been doing earlier.
Mike M

Ian C. Blenke wrote:

>On Tue, 2002-04-02 at 06:01, Mike Manchester wrote:
>
>>You can execute everything in the .bashrc or .bash_profile or for that matter
>>any file by doing
>>strings .bashrc
>>This way you can test your profiles without having to play windows and reboot
>>after every change.
>>Mike M.
>>
>
>Actually, not quite. The "strings" command will merely find all of the
>ASCII sequences in a binary file and spit them to stdout. This does not
>execute your script at all.
>
>In a Bourne/Korn shell, you source it with the dot (".") command, ie:
>
> $ . ~username/.bashrc
>
>In a csh/tcsh shell, you source it with the "source" command, ie:
>
> $ source ~/.cshrc
>
>By sourcing a script, the commands run in your current interactive shell
>rather than spawning a subshell to run the script.
>
>What you are trying to do is get an alias to be sourced by every shell
>spawned by the user. Remember, shells can be interactive or
>non-interactive. Interactive shells can be "login" shells (Bourne shells
>look at ".profile", Bash uses a ".bash_login" and a ".bash_profile",
>Korn can source a ".kshrc") or "normal" shells.(Bash will look at
>".bashrc").
>
>The easiest way to do what you're trying to do is to put it in
>/etc/profile so that all Bourne/Korn shells on the system will source
>it, making that alias "global" to the entire machine.
>
>If you don't want to make this global, add the alias command to BOTH
>".bash_profile" (sourced by Bash in a login shell), and ".bashrc"
>(sourced by Bash in a non-login shell). You may also need to add it to
>".profile" as well if you ever start Bash merely by running /bin/sh (a
>symlink to Bash, forcing it to run in compatibility mode).
>
>Here is a snippet from the man page that might help:
>
> 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.
>
> When a login shell exits, bash reads and executes commands
> from the file ~/.bash_logout, if it exists.
>
> 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. The --rcfile file option will force bash
> to read and execute commands from file instead of
> ~/.bashrc.
>
> 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.
>
> 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 interactive 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 exe­
> cute. Since a shell invoked as sh does not attempt to
> read and execute 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.
>
> 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.
>
>Hope this helps.
>
>- Ian
>
>
>



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:38:17 EDT