From owner-freebsd-standards@FreeBSD.ORG Sat Mar 20 14:21:32 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26D1216A4CE for ; Sat, 20 Mar 2004 14:21:32 -0800 (PST) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBC7643D39 for ; Sat, 20 Mar 2004 14:21:31 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp1.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i2KMLUHB019082 for ; Sat, 20 Mar 2004 17:21:31 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Sat, 20 Mar 2004 17:21:29 -0500 To: freebsd-standards@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: PATCH for a more-POSIX `ps', and related adventures X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 22:21:32 -0000 Apologies in advance for the length of this. I seem to be in "stream-of-consciousness" mode this week... - - - - - >That does not get us matching POSIX/SUSv3, but it does get us a >lot closer. There are a few questions/issues that came up for me >while writing this, but I'll list those in separate messages. I'll >also do a minimal update to the man page before commiting this. Wrt "standards issues", the following things came up. I made arbitrary decisions on these things, and wanted to know what other people felt. With the new '-g pgidlist' option: This is a standard option in posix, and I never remembered using a -g option, and our man page for `ps' does not mention one. Much to my surprise, there already was a -g option in the option-processing code of `ps': case 'g': break; /* no-op */ A quick check of FreeBSD, NetBSD, and OpenBSD shows that everyone has had this no-op option, going back to 1993/1994. More amusing, SUSv3 writes: "The -A option is equivalent to the BSD -g and the SVID -e. Because the two systems differed, a mnemonic compromise was selected." So, what BSD had a `-g' option which behaved like `-A'? In any case, I figured that if the option has been a no-op, and undocumented for 10+ years, that it would be safe to just steal it. I am going to assume this is okay, unless there is some strong objection to it. - - - - - The SUSv3 standard describes an option `-U userlist': Write information for processes whose real user ID numbers or login names are given in userlist We already have a `-u`, and I even use it, so I wasn't going to steal that! However, I did want to have this ability, so I added it as -R. I will assume this seems reasonable. - - - - - SUSv3 does not describe the option `-s sidlist', but many of the other ps's that I work with have it, and I like having that ability. I can imagine people screaming "creeping featurism!", but hey, I was on a roll and it seemed like a pretty safe thing (standards- wise) to add. I *like* creeping features, as long as they don't bloat the code too much... - - - - - Indirectly related to that, I noticed that there was a flag named KERN_PROC_SESSION defined for the kvm_getprocs() routine. But when I tried to use that flag, I get an error: ps: kvm_getprocs: No such file or directory I do not have the time to look into this, so I guess I should write up a PR for it. (or is it not-supposed to work?). It was easy to avoid that by having the main() routine always do the selection for '-s' processing. - - - - - One of the things I puzzled over for awhile was how `-x' processing should interact with all the "selector options". I decided that by default, all the options (except -p) should act like -x was NOT specified. By that I mean they will NOT match processes which have no controlling terminal. (it is a little confusing to discuss this, due to all the double-and-triple negatives...). That way, if the user does want to see those extra processes, they can specify -x to see them, no matter what selectors were specified. If I did it the other way, then the user would need yet another (new) option to indicate that they did NOT want to see those processes. I also reasoned that 'ps' (with no options) should behave the same as 'ps -U myuserid'. Prior to my updates, 'ps -U userid' DID show the extra processes, but a plain 'ps' did not. So, what I have implemented is a slight change in behavior. The code in question had said: case 'U': uids = getuids(optarg, &nuids); xflg++; /* XXX: intuitive? */ break; And I decided to answer that as "No". This is a minor change in behavior, but I'm hoping that in practice nobody will have any problems due to this. If they do, "just add -x"... - - - - - Obviously the code for `-p pidlist' should show every process it is told to, without caring if it has a controlling terminal. The code used to do this by: case 'p': pid = atol(optarg); xflg = 1; break; But that sets the "global xflg processing switch" for *all* selector options given on the command, and I didn't think that was right. So I removed the xflg setting from there, but changed the way the selection was done such that the pidlist is matched before checking xflag. - - - - - For `-U', there is a minor change in error-processing behavior which should probably be done to match the standards, and to match how other operating systems handle the same errors. But I did not make that change, because it was possible someone cares about the behavior. And that is: If you specify multiple userids, and if any of those userids are *invalid* (which is to say, there *is* no such username or userid), then we presently print out a warning message and ignore that one parameter. We do not abort the command. So if you do: ps -U root,gad,mail,baduser you get a full 'ps' output with the warning message way at the top of it. When I tried this on other operating systems, they all aborted the command with an error, and did not list any processes. That is what I would *like* to do with our `ps', but I could imagine someone who was used to that behavior and depended on it for some silly scripts or command-aliases that they have written. So, I left it as a warning -- but only for the `-U' option. For all other options, any value which would never be valid is treated as a fatal error. Would it be alright if I changed that to a fatal error, and thus removed the ten lines of comments where I'm wringing my hands in angst over making that change? - - - - - My original intent was to MFC all of this to 4.x-stable before 4.10-release, but if I do that I will skip anything which is a "new behavior". I think that means it would be easier to skip MFC-ing it at all (or at least wait until after 4.10-release). -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu