I think I'm just going to release the 'bash --login startx' launchd.plist with startx pushing /usr/X11/bin into PATH if it's not there already. This doesn't assume your users will use bash. It just uses bash because it's there. When the users start xterm from the Applications menu, they'll get their tcsh shell as expected, and they'll get a login tcsh shell because it's started by '/usr/bin/login -fp <username> /usr/X11/bin/xterm' which tells xterm to be a login terminal which tells the shell to be a login shell. Other applications (maybe 'xemacs' as an example) will inherit the BASH environment provided to them. I honestly don't see an easy, robust, clean solution for this, and the 'bash --login' route is what I came up with as the cleanest one, but it provides the BASH environment. Your users could probably change /System/Library/ org.x.X11.plist to something better for their tcsh setup... or even just start a terminal and execute something from there... Now that I think about it, I don't see how this is even a regression. Are you absolutely positive that XQuartz is even getting your tcsh environment with 2.1.1 (or any previous version)? I don't think it should be. You can test this by: mkdir ~/tcsh_only_bin echo "/usr/X11/bin/xterm" > ~/tcsh_only_bin/tcsh_xterm chmod 755 ~/tcsh_only_bin/tcsh_xterm <edit ~/.login ~/.cshrc or whatnot to put ~/tcsh_only_bin in $PATH> restart X Add 'tcsh_only_bin' to the Applications menu (without the full path) Launch that menu item. My bet is that it won't work as I don't believe it should be getting the environment currently. Can you please check that out for me? --Jeremy On Jan 9, 2008, at 06:51, Jamie Kennea wrote:
On Jan 9, 2008, at 2:55 AM, Martin Costabel wrote:
For people who don't have bash as their login shell, this is a regression.
Assuming people are going to use bash is troublesome. Most of our users are set up to use tcsh, the policy which is set by our LDAP server which we use to authenticate our users on Linux and Mac. I know Macs default to bash, but one shouldn't assume the default is kept, especially in environments like ours.
Jamie
Jeremy Huddleston wrote:
I think I'm just going to release the 'bash --login startx' launchd.plist with startx pushing /usr/X11/bin into PATH if it's not there already.
I guess that we'll be able to live with this. The standard users who might want to use the X11 Applications menu will have bash as their login shell anyway, because it's the default. And with the "bash --login startx", they get their login environment. For users with tcsh or another shell as login shell, it may give unexpected results, depending on the contents of possibly existing random bash login scripts.
This doesn't assume your users will use bash. It just uses bash because it's there. When the users start xterm from the Applications menu, they'll get their tcsh shell as expected, and they'll get a login tcsh shell because it's started by '/usr/bin/login -fp <username> /usr/X11/bin/xterm' which tells xterm to be a login terminal which tells the shell to be a login shell.
Except that it doesn't. This is perhaps what /usr/bin/login should do, but it doesn't. Currently its only effect is that it sets the working directory to $HOME and that it leaves an entry in lastlog. Its influence on the environment is zero. The only way to make xterm run a real login terminal is to call it as "xterm -ls", whether preceded by /usr/bin/login or not.
Other applications (maybe 'xemacs' as an example) will inherit the BASH environment provided to them. I honestly don't see an easy, robust, clean solution for this, and the 'bash --login' route is what I came up with as the cleanest one, but it provides the BASH environment. Your users could probably change /System/Library/ org.x.X11.plist to something better for their tcsh setup... or even just start a terminal and execute something from there...
That's what I am telling people anyway. I don't myself understand why one would want to use anything as old and ugly as an xterm :-)
Now that I think about it, I don't see how this is even a regression.
You are right, I was wrong about this. It didn't work in previous versions either. There were so many different versions around, some of them my own DIY versions, that I forgot which one did what. BTW, it was rather difficult to go back to the original Leopard X11 and have it work, because one needs to replace the new /System/Library/LaunchAgents/org.x.X11.plist by the old one, and this file is not in the original Leopard X11 pkg's, but in Essentials.pkg which one doesn't really want to reinstall. I had also two kernel panics in the process. Possibly unrelated, but before that I had only seen one in the last 5 years. -- Martin
participants (2)
-
Jeremy Huddleston
-
Martin Costabel