site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Jan 31, 2008, at 3:48 AM, Martin Costabel wrote: Juan Manuel Palacios wrote: [] The evidence: 1) In screen.c, there is a line, conditioned on #ifdef __APPLE__ if (_vprocmgr_move_subset_to_user(real_uid, "Background") != NULL) $[jmpp @MacBookPro: MacPorts](666/0,1) -> login -pflq login: jmpp $[jmpp @MacBookPro: MacPorts](1/0,0) -> exit $[jmpp @MacBookPro: MacPorts](667/0,1) -> [jmpp @MacBookPro: MacPorts](703/0 0,3) -> which screen /usr/bin/screen $[jmpp @MacBookPro: MacPorts](705/0 0,3) -> which login /usr/bin/login Hope these help as cues to further research ;-) Regards,... -jmpp -- Martin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. 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: 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](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](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! 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. This email sent to site_archiver@lists.apple.com