Am 09.01.2008 um 01:58 schrieb Jamie Kennea:
I want to start the server via '/bin/bash --login /usr/X11/bin/startx' rather than just '/usr/bin/startx' because I want to make sure that / etc/profile and ~/.profile are sourced to setup the user's environment. Not doing so would cause $PATH to be just "/usr/X11/ bin:/ usr/bin:/bin:/usr/sbin:/sbin". Thus if they use macports and have 'rxvt' as one of their applications in X11's Applications menu, they'll need to give the full path to the application. This is actually the way the 10.5 shipped X11 behaved, but I regard this as a bug and fixed it by using 'login -f <username> /bin/sh -c /usr/X11/ bin/ Xquartz' to exec the server within server-main.c. That carried over to a bash --login in the current configuration.
I'm still on Tiger (and only a digest customer), why can't you just use 'login -f <user>' which then launches this user's login shell? That's "here" the way an user gets logged in. Or, to be exact, it uses the -p switch, too, to discard the previous process environment settings. From pstree: \-+- 00379 pete /Applications/Utilities/Terminal.app/Contents/ MacOS/Terminal -psn_0_1572865 |-+= 00402 root login -pf pete | \-+= 00405 pete -tcsh | \-+= 07310 pete pstree -w -p 379 | \--- 07311 root ps -axwwo user -- Greetings Pete A morning without coffee is like something without something else.
On Jan 9, 2008, at 08:43, Peter Dyballa wrote:
Am 09.01.2008 um 01:58 schrieb Jamie Kennea:
I want to start the server via '/bin/bash --login /usr/X11/bin/ startx' rather than just '/usr/bin/startx' because I want to make sure that / etc/profile and ~/.profile are sourced to setup the user's environment. Not doing so would cause $PATH to be just "/usr/X11/ bin:/ usr/bin:/bin:/usr/sbin:/sbin". Thus if they use macports and have 'rxvt' as one of their applications in X11's Applications menu, they'll need to give the full path to the application. This is actually the way the 10.5 shipped X11 behaved, but I regard this as a bug and fixed it by using 'login -f <username> /bin/sh -c /usr/X11/ bin/ Xquartz' to exec the server within server-main.c. That carried over to a bash --login in the current configuration.
I'm still on Tiger (and only a digest customer), why can't you just use 'login -f <user>' which then launches this user's login shell? That's "here" the way an user gets logged in. Or, to be exact, it uses the -p switch, too, to discard the previous process environment settings. From pstree:
\-+- 00379 pete /Applications/Utilities/Terminal.app/Contents/ MacOS/Terminal -psn_0_1572865 |-+= 00402 root login -pf pete | \-+= 00405 pete -tcsh | \-+= 07310 pete pstree -w -p 379 | \--- 07311 root ps -axwwo user
That's what I want to do (see previous posts from me when your digest comes for more detail), but launchd.plist doesn't have an easy way to get <user>.
Am 09.01.2008 um 23:22 schrieb Jeremy Huddleston:
That's what I want to do (see previous posts from me when your digest comes for more detail), but launchd.plist doesn't have an easy way to get <user>.
Why does it need to have or provide it? Doesn't the environment in which launchd works supply $USER? Wouldn't 'id -un' give the right value at run-time? A little helper script could record with defaults the key/value pair near login-time ... -- Mit friedvollen Grüßen Pete Let's face it; we don't want a free market economy either. – James Farley, president, Coca-Cola Export Corp., 1959
On Jan 9, 2008, at 16:33, Peter Dyballa wrote:
Am 09.01.2008 um 23:22 schrieb Jeremy Huddleston:
That's what I want to do (see previous posts from me when your digest comes for more detail), but launchd.plist doesn't have an easy way to get <user>.
Why does it need to have or provide it? Doesn't the environment in which launchd works supply $USER? Wouldn't 'id -un' give the right value at run-time?
It does supply $USER in the environment, but it can't be set on the command line when launched from launch (hence the sh -c '... $USER ...' attempt).
A little helper script could record with defaults the key/value pair near login-time ...
I'm not sure what you mean by this.
Am 10.01.2008 um 04:13 schrieb Jeremy Huddleston:
It does supply $USER in the environment, but it can't be set on the command line when launched from launch (hence the sh -c '... $USER ...' attempt).
This is what I don't understand, but we can quit here.
A little helper script could record with defaults the key/value pair near login-time ...
I'm not sure what you mean by this.
I meant that "the system" could provide information by filling-in this information into certain files when a user logs in. This could be handled by kind of a login item which gets installed with X11 (a hook in Emacs speak). I have written a suite of shell scripts that set up the environment via ~/.MacOSX/environment.plist plus provide some helpful things to be used in Terminal. The purpose is to provide X11 with the same environment, particularly PATH, as Terminal has, to be able to use TeX with xterm, texdoc, xdvi, GNU Emacs/XEmacs. "Side-effects" provide DISPLAY from ~/.MacOSX/environment.plist when ~/.xinitrc is executed (until then DISPLAY is unknown and calculated by ~/.login or ~/.profile on the basis of already logged-in local users), which then can be used in Terminal to update its preliminary DISPLAY setting. If needed. (When the X server quits, ~/.xinitrc deletes DISPLAY from ~/.MacOSX/environment.plist.) Anyway, I'm not using Leopard right now so I am not completely understanding the problems. Could be, when I'll manage to compile X11R7.2 for Tiger, I'll see them clearer ... (full compilation is just a matter of one or two days) -- Greetings Pete When confronted with actual numbers, a mathematician is at a loss. – Steffen Hokland
participants (2)
-
Jeremy Huddleston
-
Peter Dyballa