home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / programm / 4315 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  3.0 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!jvnc.net!princeton!stroke.Princeton.EDU!spencer
  2. From: spencer@stroke.Princeton.EDU (S. Spencer Sun)
  3. Newsgroups: comp.unix.programmer
  4. Subject: Re: How can a program know where it was invoked?
  5. Message-ID: <1992Aug15.022032.13233@Princeton.EDU>
  6. Date: 15 Aug 92 02:20:32 GMT
  7. References: <bmckeon.713727455@unix1.tcd.ie> <1992Aug13.182509.10985@nic.umass.edu> <1992Aug14.183521.1704@sco.com>
  8. Sender: news@Princeton.EDU (USENET News System)
  9. Reply-To: spencer@phoenix.princeton.edu (S. Spencer Sun)
  10. Organization: Live Organ Transplants
  11. Lines: 47
  12. Nntp-Posting-Host: stroke.princeton.edu
  13.  
  14. In article <1992Aug14.183521.1704@sco.com>, brianm@sco.com (Brian Moffet) writes:
  15. >Not necessarily.  Under the Unix OS, you can do an attempt at figuring
  16. >out where the binary is:
  17. >
  18. >1: check to see if the argv[0] is an absolute/relative path name.
  19. >2: check to see if your psargs have any good information (may not be doable)
  20. >3: get the environment variable PATH and go through it in order
  21. >    checking to see whether the program in question exists in that directory.
  22. >4: Check to see if there is your program name in the current directory.
  23. >
  24. >If you find that the file you found was actually a symbolic link,
  25. >you have to trace that link to see if it ends with a valid executable.
  26. >
  27. >If all of these fail, you have a program which someone changed the name on
  28. >via execl() or something similar.  In this case, you're not going to have
  29. >much luck.
  30.  
  31. Just to clarify, I don't think this is really what Mr. Moffet meant, but
  32. IMHO the way his article is written implies that the very last paragraph
  33. quoted above is true only if checks 1-4 fail and this is not true.
  34. Suppose I execl something with argv[0] = "/bin/zsh" even though what I'm
  35. really running is "~spencer/zsh-beta/zsh"?  Condition 1 is satisifed,
  36. condition 3 could be satisfied, condition 4 could be satisfied if I'm in
  37. any directory with a copy of zsh in it, and maybe condition 3 could be
  38. satisfied if I knew what psargs was.  They could all be symbolic links,
  39. too, but they'd all still be wrong.
  40.  
  41. OK, any situation where this fails is likely to be extremely artificial,
  42. but then again, (1) I could say I'm looking at it from a theoretical
  43. standpoint (read: I'm just being argumentative); and (2) making a
  44. symbolic link named '-i' to a setuid shell script is pretty artificial
  45. too.
  46.  
  47. >My question would be, "why would you want to know where the program is in the
  48. >first place?"  Most cases of having some startup script can be solved by
  49. >placing the startup script (or whatever) someplace sane, not where the
  50. >directory is...
  51.  
  52. I agree with this though.  I would imagine that in general there is some
  53. other way of achieving the desired effect.  (Which isn't to say
  54. necessarily that there SHOULDN'T be a reliable way for an executable to
  55. find out exactly where it resides, but.)
  56.  
  57. ----------- The opinions expressed in this article are solely mine. -----------
  58. <Insert lame attempt at disclaimer humor>
  59. sss/PU'94 Dept of CS (spencer@phoenix.princeton.edu)/JvNCnet (spencer@jvnc.net)
  60. "'Rue the day'?  Who talks like that?"
  61.