Re: screen clobbers PATH
Re: screen clobbers PATH
- Subject: Re: screen clobbers PATH
- From: Juan Manuel Palacios <email@hidden>
- Date: Thu, 31 Jan 2008 10:16:43 -0430
On Jan 31, 2008, at 3:48 AM, Martin Costabel wrote:
Juan Manuel Palacios wrote:
[]
I don't have a solution to the problem, but at least a few words
of comfort telling you that I'm also experiencing the exact same
problem: Tiger's screen, OK; MacPorts' screen, OK; Leopard's
screen, no PATH. I have to supply the full path to whatever
program I want to run under Leopard's screen, otherwise I get not
found errors.
Thanks. I have now looked some more at the source code, in
particular at the Apple-specific patches, and I am now seeing the
point where the deed is done.
Again, not having looked at the source code myself, I can only follow
your lead.
But I am hitting a wall there. To me (but what do I know) it looks
like there is some private undocumented code at work here, something
that smells of Solaris; but that's about the extent of what I am
understanding.
The evidence:
1) In screen.c, there is a line, conditioned on #ifdef __APPLE__
if (_vprocmgr_move_subset_to_user(real_uid, "Background") != NULL)
That function _vprocmgr_move_subset_to_user comes from a private
header vproc_private.h, and I haven't found it documented.
2) in windows.c, there is code replacing execve by a call to /usr/
bin/login with the flags "-pflq". Indeed, if you run /usr/bin/screen
on Leopard and look at the started processes with 'ps x', you see a
process "login -pflq". Now the "-l" flag to login is nowhere
documented, as far as I can see.
These two things play together:
- If you only remove 1 and leave 2 in place, screen does not work,
it quits immediately. If you remove both of them, you get standard
screen behavior with the usual unclobbered PATH and no additional
login process.
- If you leave 1 and 2 in place and only remove the "l" flag from "-
pflq", you get an unclobbered PATH, too.
- I was not able to test "login -pflq" at the command line, it gives
an error message. This seems to hint that this flag in 2 needs 1 for
running.
All the login(1) flags you mention are properly documented in its
Leopard man page. In a nutshell:
-p don't start with a clean environment: presumably forces login(1) to
inherit that of the calling shell, which should contain the customized
PATH;
-f don't prompt for password;
-l tell the executed program that they are *not* under a login
session: not too sure about the effect of this, maybe it keeps
login(1) from re-reading shell config files and thus overwriting the
environment (consistent with -p above), or maybe it wipes the
environment clean and keeps the executed program from inheriting any
settings at all (would conflict with -p above);
-q quiet operation;
So I agree the questionable flag is indeed -l, but it doesn't seem to
me like some kind of KGB dark sekret. Also:
$[jmpp @MacBookPro: MacPorts](666/0,1) -> login -pflq
login: jmpp
$[jmpp @MacBookPro: MacPorts](1/0,0) -> exit
$[jmpp @MacBookPro: MacPorts](667/0,1) ->
So, maybe the -l flag does not need
_vprocmgr_move_subset_to_user().... or maybe login(1) already has that
symbol? Lets see:
[jmpp @MacBookPro: MacPorts](703/0 0,3) -> which screen
/usr/bin/screen
$[jmpp @MacBookPro: MacPorts](704/0,3) -> nm -m /usr/bin/screen | grep
_vprocmgr_move_subset_to_user
(undefined [lazy bound]) external
__vprocmgr_move_subset_to_user (from libSystem)
$[jmpp @MacBookPro: MacPorts](705/0 0,3) -> which login
/usr/bin/login
$[jmpp @MacBookPro: MacPorts](706/0,3) -> nm -m /usr/bin/login | grep
_vprocmgr_move_subset_to_user
$[jmpp @MacBookPro: MacPorts](707/0 1,3) ->
So, in conclusion, login(1)'s -l flag works for me without using the
_vprocmgr_move_subset_to_user() symbol, but /usr/bin/screen still
clobbers my PATH.... /me scratches head!
Hope these help as cues to further research ;-) Regards,...
-jmpp
In conclusion, the cause of this problem seems to be an undocumented
"feature" of Leopard's /usr/bin/login that is used by Apple's
variant of /usr/bin/screen. Why they are doing this, I cannot imagine.
--
Martin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden