Xref: utzoo comp.sources.wanted:4390 comp.sys.att:3558 unix-pc.general:878 Path: utzoo!utgpu!water!watmath!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!eos!amelia!ames!ucsd!ucsdhub!jack!elgar!ford From: ford@elgar.UUCP (Mike "Ford" Ditto) Newsgroups: comp.sources.wanted,comp.sys.att,unix-pc.general Subject: Re: Wanted Dead or Alive: A ps that displays all command args... Keywords: unixpc ps u.u_ucomm Message-ID: <196@elgar.UUCP> Date: 22 Jun 88 18:02:03 GMT References: <103@tarkus.UUCP> <2300002@cpe> <398@icus.UUCP> Reply-To: ford@kenobi.cts.com (Mike "Ford" Ditto) Organization: Omnicron Data Systems, Bonita, CA Lines: 26 In article <398@icus.UUCP> lenny@icus.UUCP (Lenny Tropiano) writes: >Ok. I was wrong ... It can be done. For some reason AT&T took a short-cut >and only displayed the u_comm string in the user block that only contains >the first argument. The real way of doing it and really the "-f" >option of the ps(1) should do this. But as usual... THe shortcut on the Unix PC is in the exec function, which doesn't store the full args. On a normal system V (at least in release 2) there is a field in the user area (called u_psargs) reserved for storing the first 40-or-so characters of the exec arguments. This is what ps normally prints, but for some reason, the Unix PC doesn't have this field, so ps prints u.u_comm (which is NOT argv[0], but the "path" argument to exec - the name of the file being run). >A few people mentioned the way of doing it is to look up the user's stack >space in memory and read back the arguments from the "argv-block". This is the way ps worked in version 7, and probably still does in BSD. -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford@kenobi.cts.com This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads