RESOLVED
If SLUG were to form a for-profit consulting company, I'd have to say
"Watch out!" to the other consulting firms. We've go a lot of very
intelligent people here. Thanks to all for the overwhelming
responses.
The problem I encountered on Debian 2.2r5 for Sparc was in the
.bash_profile for the user. I was oblivious to the fact that the
bulk of the file was commented out (by default) except for the first
line with "umask 022". Here's the crucial portion of the script:
#include .bashrc if it exists
#if [ -f ~/.bashrc ]; then
# source ~/.bashrc
#fi
I got curious when I didn't see my echo lines during login and then I
tried 'source .bashrc' and my settings worked. I looked higher up on
the tier and found what I had overlooked in .bash_profile. I'm a big
DUHmy. Everything is peachy now.
Mario
>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:35:46 EDT