Re: Bash login shells with X11 (executing .bash_profile, .bashrc)
Re: Bash login shells with X11 (executing .bash_profile, .bashrc)
- Subject: Re: Bash login shells with X11 (executing .bash_profile, .bashrc)
- From: Randy Ford <email@hidden>
- Date: Sat, 8 Feb 2003 02:17:32 -0600
On Friday, February 7, 2003, at 06:58 PM, magenta wrote:
On Fri, Feb 07, 2003 at 10:18:42AM -0800, Lawrence You wrote:
At 9:42 AM -0800 2/7/03, magenta wrote:
It's subtle, I think I'm being pedantic, but I would like that last
line to say "Yes."
Which doens't make a lot of sense to those of us who actually prefer
tcsh
for their commandline interface.
You're right, bash is only one example and I wouldn't want or expect
.bash_profile to be executed for tcsh users. But if you're using
tcsh or csh then wouldn't you want .profile or .login to be executed
once? I think that's the same idea.
True.
As others have stated, if you want
something to happen in all interactive shells, it goes into .bashrc,
not
.bash_profile.
Yes, that is close, but not quite what I want. For example, I don't
want .bashrc (or .cshrc) to keep appending to PATH each time it is
started as a subshell.
Good point. And in those cases, you can start your .xinitrc with
#!/usr/bin/tcsh -l
Starting your .xinitrc doesn't affect other shells started by X11.app,
such as from the Application menu.
Most shells have a way to have a login script and a non-login script.
For instance, tcsh executes .tcshrc and .login if it's a login shell,
but only .tcsh if it's not a login shell. Everything that should only
be done once is done in .login, other are done in .tcshrc. (I'm
ignoring that it will execute other things in /etc and other scripts if
the others don't exist.)
Csh uses .cshrc and .login like tcsh. Bash has .bash_profile for
logins, and .bashrc for non-login interactives. Ksh uses .profile and
then $ENV for logins, and just $ENV for non-login interactives. Bourn
sh uses .profile, but not $ENV. The /bin/sh on MacOS X acts like bash.
(Does /bin/sh on MacOS X have a name?) (Caveat emptor: I wrote this
quickly, I may have mixed up some. Rely on man and experimentation!)
I have a .bash_profile that sources my .profile: the .bash_profile only
has bash-specific code. Similarly, my .bashrc sources .env, which is
also set in $ENV in my .profile. Then, even if some tool misbehaves
and gives me a bourn shell, I still get a good environment. It takes
something like X11.app to break my system. <grin>
So, the problem of something needing to run once at login, or on every
shell invocation is already handled by the shells (except bourne.)
Unfortunately X11.app breaks this. We have either the choice of not
having any of the shells launched as login shells, or all of them. (I
know, we can always manually execute our shell as a login shell after
our xterm starts. There's been much discussion to show the problems
this causes.)
What should happen is that X11.app should set the environment like
login does [login(1), environ(7)]. Then it should execute the default
shell as a login shell. It should launch the X server, execute
~/.xintrc or the system xinitrc (which launches the windows manager.)
Have you noticed the default path? It doesn't match any path that I've
found. (It's
/usr/bin:/bin:/usr/sbin:/sbin:/Users/randy:/usr/X11R6/bin.) For
instance it has /usr/bin before /bin. I don't know if that'll cause
anybody problems, but it's strange. It also includes the users home
directory. I've never seen that before. (I normally include ~/bin,
bit that's just me.) I view it as a security risk since it's not well
documented. I don't expect files in my home directory to be executed.
It's also very different than what I get with Terminal.app
(/bin:/sbin:/usr/bin:/usr/sbin).
randy.
_______________________________________________
x11-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/x11-users
X11 for Mac OS X FAQ: http://developer.apple.com/qa/qa2001/qa1232.html
Report issues, request features, feedback: http://developer.apple.com/bugreporter
Do not post admin requests to the list. They will be ignored.