It's basically the same as the last rc, but I added in a 'login_shell' option that users of tcsh can set to '/bin/tcsh' so applications launched from the Applications menu get the tcsh environment instead of the bash environment: defaults write org.x.X11 login_shell /bin/tcsh http://trac.macosforge.org/projects/xquartz/wiki/X112.1.2 --Jeremy
Why not just read the login shell out of the user's password entry and use that? On 1/12/08, Jeremy Huddleston <jeremyhu@freedesktop.org> wrote:
It's basically the same as the last rc, but I added in a 'login_shell' option that users of tcsh can set to '/bin/tcsh' so applications launched from the Applications menu get the tcsh environment instead of the bash environment:
defaults write org.x.X11 login_shell /bin/tcsh
http://trac.macosforge.org/projects/xquartz/wiki/X112.1.2
--Jeremy
-- Mark J. Reed <markjreed@mail.com>
Because they might choose a shell that doesn't work as: /usr/bin/login -fp <username> <shell> -c <application to run> And I don't want to deal with that possibility. On Jan 12, 2008, at 14:29, Mark J. Reed wrote:
Why not just read the login shell out of the user's password entry and use that?
On 1/12/08, Jeremy Huddleston <jeremyhu@freedesktop.org> wrote:
It's basically the same as the last rc, but I added in a 'login_shell' option that users of tcsh can set to '/bin/tcsh' so applications launched from the Applications menu get the tcsh environment instead of the bash environment:
defaults write org.x.X11 login_shell /bin/tcsh
http://trac.macosforge.org/projects/xquartz/wiki/X112.1.2
--Jeremy
-- Mark J. Reed <markjreed@mail.com> _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Jeremy Huddleston wrote:
It's basically the same as the last rc, but I added in a 'login_shell' option that users of tcsh can set to '/bin/tcsh' so applications launched from the Applications menu get the tcsh environment instead of the bash environment:
defaults write org.x.X11 login_shell /bin/tcsh
Am I right that this concerns only the xterm that is automatically opened when X11.app is started? Not the programs started from the Applications menu? -- Martin
No. It applies to both the app_to_run application started from X11.app and the applications launched from the Applications menu. http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=b549cf18cebd343... On Jan 12, 2008, at 17:35, Martin Costabel wrote:
Jeremy Huddleston wrote:
It's basically the same as the last rc, but I added in a 'login_shell' option that users of tcsh can set to '/bin/tcsh' so applications launched from the Applications menu get the tcsh environment instead of the bash environment: defaults write org.x.X11 login_shell /bin/tcsh
Am I right that this concerns only the xterm that is automatically opened when X11.app is started? Not the programs started from the Applications menu?
-- Martin
Jeremy Huddleston wrote:
No. It applies to both the app_to_run application started from X11.app and the applications launched from the Applications menu.
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=b549cf18cebd343...
Well, it doesn't for me. Maybe I need to install the pkg a second time, I'll see tomorrow. In any case, if it is only the /usr/bin/login... command where sh is replaced by tcsh, I don't think it will have the desired effect. -- Martin
Ah, you're right... I made a copy-paste error when I did that... Doh. I just made sure it worked in the default case. I'll release a fix for you after I test it some more. --Jeremy On Jan 12, 2008, at 18:30, Martin Costabel wrote:
Jeremy Huddleston wrote:
No. It applies to both the app_to_run application started from X11.app and the applications launched from the Applications menu. http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=b549cf18cebd343...
Well, it doesn't for me. Maybe I need to install the pkg a second time, I'll see tomorrow.
In any case, if it is only the /usr/bin/login... command where sh is replaced by tcsh, I don't think it will have the desired effect.
-- Martin
Here you go, Martin. This one should work for you. Just replace 2.1.2's /usr/X11/bin/Xquartz with it. http://xquartz.macosforge.org/downloads/Xquartz-1.3.0-apple8.bz2 --Jeremy On Jan 12, 2008, at 18:30, Martin Costabel wrote:
Jeremy Huddleston wrote:
No. It applies to both the app_to_run application started from X11.app and the applications launched from the Applications menu. http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=b549cf18cebd343...
Well, it doesn't for me. Maybe I need to install the pkg a second time, I'll see tomorrow.
In any case, if it is only the /usr/bin/login... command where sh is replaced by tcsh, I don't think it will have the desired effect.
-- Martin
Jeremy Huddleston wrote:
Here you go, Martin. This one should work for you. Just replace 2.1.2's /usr/X11/bin/Xquartz with it.
http://xquartz.macosforge.org/downloads/Xquartz-1.3.0-apple8.bz2
Thanks. Indeed, this one now runs a tcsh login shell and gets the tcsh login environment including PATH. It still additionally inherits the bash login environment, of course, from the initial "/bin/bash --login /usr/X11/bin/startx", but that's negligeable now. -- Martin
Sat, 12 Jan 2008 (12:35 -0800 UTC) Jeremy Huddleston wrote:
It's basically the same as the last rc, but I added in a 'login_shell' option that users of tcsh can set to '/bin/tcsh' so applications launched from the Applications menu get the tcsh environment instead of the bash environment:
defaults write org.x.X11 login_shell /bin/tcsh
http://trac.macosforge.org/projects/xquartz/wiki/X112.1.2
--Jeremy
Two things I notice on my system after installing this upgrade 1. It forced a restart (during a TimeMachine hourly backup), and after the restart backups would not run. There was a file marked ".incomplete" for that backup. I have read of other forced restarts (other than from Apple updates) appearing to interfere with TimeMachine. I am still waiting to see if the next window for TM leads to a backup--so far there have been seven failed attempts. 2. I did the defaults write, but top shows an extra bash process--is that to be expected? I do not see any tcsh processes other than the ones I started on my own. Why do we need to restart OS X and not just the X system? I mention TM because I wonder whether there are incompatibilities between TM and forced restart by third-party installers. I can't imagine that any changes in Xquartz or X11.app would affect TM. -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky
On Jan 13, 2008, at 13:36, robert delius royar wrote:
Two things I notice on my system after installing this upgrade 1. It forced a restart (during a TimeMachine hourly backup), and after the restart backups would not run. There was a file marked ".incomplete" for that backup. I have read of other forced restarts (other than from Apple updates) appearing to interfere with TimeMachine. I am still waiting to see if the next window for TM leads to a backup--so far there have been seven failed attempts.
Ok, well unfortunately I can't do anything about time machine. My advice is to not install stuff during the backup if it's buggy about handling that.
2. I did the defaults write, but top shows an extra bash process--is that to be expected? I do not see any tcsh processes other than the ones I started on my own.
You need to install Xquartz-1.3.0-apple8 in /usr/X11/bin. That was a last minute change I made for Martin, and I didn't thuroughly test it. 1.3.0-apple8 should work as you expect. You will see the original bash --login process still, but all your applications will be launched using tcsh on top of that. If you really want to get rid of the bash process, then edit /System/Library/LaunchAgents/ org.x.X11.plist and get rid of those two lines. XQuartz will then have a stripped down environment which means you'll need to give full paths to applications in the Applications menu that live outside of / usr/X11/bin {/,/usr/}{s,}bin
Why do we need to restart OS X and not just the X system?
See the release notes: http://trac.macosforge.org/projects/xquartz/wiki/X112.1.2
I mention TM because I wonder whether there are incompatibilities between TM and forced restart by third-party installers.
This isn't a third party installer. This is Apple's Installer.app. We're not using vise or anything like that.
I can't imagine that any changes in Xquartz or X11.app would affect TM.
Yeah, I don't think that is the case either. --Jeremy
On Sun, Jan 13, 2008 at 02:10:34PM -0800, Jeremy Huddleston wrote:
On Jan 13, 2008, at 13:36, robert delius royar wrote:
Why do we need to restart OS X and not just the X system?
See the release notes: http://trac.macosforge.org/projects/xquartz/wiki/X112.1.2
Restart Notice Because we've changed the way launchd starts the server, you will need to restart your machine after installation. Hmm. I recall an Apple doc that showed the launchd process tree is different in 10.5 vs 10.4. In 10.4 there is one lauchd, in 10.5 there is a launchd per user login (on console). So surely at worst one would have to log out and back in again, causing the per user launchd to be recreated? At best one would hope there is a way to make launchd reload its config files (kill -HUP ?). DF
Mon, 14 Jan 2008 (12:09 -0000 UTC) Derek Fawcus wrote:
On Sun, Jan 13, 2008 at 02:10:34PM -0800, Jeremy Huddleston wrote:
On Jan 13, 2008, at 13:36, robert delius royar wrote:
Why do we need to restart OS X and not just the X system?
See the release notes: http://trac.macosforge.org/projects/xquartz/wiki/X112.1.2
Restart Notice Because we've changed the way launchd starts the server, you will need to restart your machine after installation.
Hmm. I recall an Apple doc that showed the launchd process tree is different in 10.5 vs 10.4. In 10.4 there is one lauchd, in 10.5 there is a launchd per user login (on console).
So surely at worst one would have to log out and back in again, causing the per user launchd to be recreated?
At best one would hope there is a way to make launchd reload its config files (kill -HUP ?).
DF
There ought (as in a "moral" oblligation) to be a way for the installer to do the following: stop org.x.X11 unload -w /System/Library/LaunchAgents/org.x.X11.plist killall X11.app rm /System/Library/LaunchAgents/org.x.X11.plist cp org.x.X11.plist /System/Library/LaunchAgents/org.x.X11.plist load -w /System/Library/LaunchAgents/org.x.X11.plist Assuming the installer could manage such, would this be enough to make X11 run correctly with an update and not require a system restart? I understand that on a system with multiple users logged in, this may not be the correct approach. -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky
Hmm. I recall an Apple doc that showed the launchd process tree is different in 10.5 vs 10.4. In 10.4 there is one lauchd, in 10.5 there is a launchd per user login (on console).
So surely at worst one would have to log out and back in again, causing the per user launchd to be recreated?
well, I tried just forcing a logout, but something doesn't refresh right. Try disabling, then enabling org.x.X11, logging out, then logging back in. It doesn't work. Forcing the restart does. /shrug
At best one would hope there is a way to make launchd reload its config files (kill -HUP ?).
It's also an issue that reloading the config files might cause it to create a new socket rather than use the old one in which case $DISPLAY is invalid. If you can find a minimal way to do this, then great. Please let me know what it is. I tried for a while to find something less intrusive, failed, then gave up and forced reboot. --Jeremy
participants (6)
-
Derek Fawcus
-
Jeremy Huddleston
-
Jeremy Huddleston
-
Mark J. Reed
-
Martin Costabel
-
robert delius royar