Question for all you UNIX masters out there...

Post #27,497 by jb4 2/6/02 10:03:08 AM Reply	Question for all you UNIX masters out there... What is the API function that returns the name of the current process (or the name of the process given a particular pid)? By "name", I mean the executable's filename (which can be fully-qualified pathname...it doesn't matter). If ps and pidin can get them, so should I. So the question is, what this the magic incantation that does this feat of derring-do? Thanks in advance... jb4 (Enquiring minds want to know...)
Post #27,499 by boxley 2/6/02 10:38:27 AM Reply	if you called it cause it is current how come ya dont know? need a better idea of what yer trying to do. thanx, bill "If you're half-evil, nothing soothes you more than to think the person you are opposed to is totally evil." Norman Mailer
Post #27,509 by jb4 2/6/02 12:12:16 PM Reply	I'm an error library, and I don't know which proc called me I can be called from any number of processes, and I generally do the same thing everywhere, except when I'm called from our GUI manager. I need to know that I'm in the GUI manager proc, so that I don't do anything...er, stupid... I do NOT have access to the command line, so argv[0] is out. Any ideas? jb4 (Resistance is not futile...)
Post #27,528 by kmself 2/6/02 2:14:04 PM Reply	GUI detection Check the value of $DISPLAY. If it's not set, you're safe to assume a non-GUI environment, though you might want to check to see if you're attached to a terminal or not. If $DISPLAY is set, you'd then do an appropriate GUIfied response. If that fails, say because $LUSER is an idiot and isn't running an actual X11 session, then you would abort miserably, complaining loudly to stdout with a nonzero exit status. Of several programs I've looked at lately, testing $DISPLAY to see that there is/isn't a GUI session attached is occasionally omitted. It's a seriously brain-dead mistake. SAS does it in its v8/v9 incarnations. The user has to provide an extra flag to the program to tell it it's not in an X11 session. This is Bad Code™ `-- Karsten M. Self [link\|mailto:kmself@ix.netcom.com\|kmself@ix.netcom.com] [link\|http://kmself.ix.netcom.com/\|[link\|http://kmself.ix.netcom.com/\|http://kmself.ix.netcom.com/]] What part of "gestalt" don't you understand?`
Post #27,888 by ben_tilly 2/9/02 12:47:27 AM Reply	Stupid but reliable solution Have the error library have an internal flag for this, which defaults false, but which can be reset. When the GUI application starts, have it set the flag. Yeah, yeah, it is a global. So are environment variables. And some day you may have your application called from a process that inherited an environment from an unrelated GUI. (But you are backgrounded.) Globals which are shared across processes are worse than globals inside of processes... Cheers, Ben
Post #28,009 by jb4 2/11/02 9:24:39 AM Reply	I'm not that doctrinare... ...but I would try to keep globals to a minimum. There is precedent for such a solution in this system, however, so it wouldn't be hard getting it past a code inspection. Thanks for the input, Ben. jb4 (Resistance is not futile...)
Post #27,518 by pwhysall 2/6/02 12:55:19 PM Reply	Re: Question for all you UNIX masters out there... in C, argv[0] holds the name of the program. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #27,526 by jb4 2/6/02 2:01:32 PM Reply	Thank you, but... ...as I said [link\|http://z.iwethey.org/forums/render/content/show?contentid=27509\|here], I don't have access to argv[0]. (And, for that matter, neither does ps, but s/he manages to get this datum for all processes in the system.) jb4 (Resistance is not futile...)
Post #27,616 by pwhysall 2/7/02 2:59:23 AM Reply	Why don't you sneak a look at the source code for ps or top? Cut out the middleman, so to speak... Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #27,667 by jb4 2/7/02 1:22:10 PM Reply	Good Plan! Hadn't thought of that.... jb4 (Resistance is not futile...)
Post #27,570 by lordbeatnik 2/6/02 7:12:24 PM Reply	Try the environment variable "_" Bash at least sets the environment variable "_" to the name of the new process. You could try that. As far as ps goes, the way ps gets information depends on the version of unix. Linux and some others now lift the information out of a "proc" filesystem. Others may be using a special system call. So, I don't know of any portable way to get a process name other than parsing ps output. 8( David "Lord Beatnik"
Post #27,723 by boxley 2/7/02 7:37:20 PM Reply	well if yer inside the app store all the pids in a tmp file name progpidxxxx where xxxx is the pidno then print the /tmp and grep the pidno the text returning the procname or go proc diving (bad idea that) thaxn, bill "If you're half-evil, nothing soothes you more than to think the person you are opposed to is totally evil." Norman Mailer
Post #28,010 by jb4 2/11/02 9:33:56 AM Reply	Here's what I got so far... First, I should probably state that this is being written in QNX, which is sorta UNIX, sorta POSIX, and sorta...something else. We're using it as a real-time microkernel for an embedded system (a real embedded system, not "embedded system" as Micros~1 would bastardize the term). QNX's internal library supplies the QNX-specific function _cmdname(), which, according to its (typically terse) documentation: The _cmdname() function determines the fullpath that the current process was invoked from and stores it in the buffer specified by buff. Once I get this path, I can use the Unix standard basename() function to denude the path of all cruft except the actual file name. This provides he information I need. My current question is: Is there a UNIX/POSIX equivalent of _cmdname() that you Masters know about? BTW, to all, thanks for your help thus far!!! jb4 (Resistance is not futile...)

Welcome to IWETHEY!