Date: Mon, 29 Mar 2004 12:52:50 +1000 From: Stephen McKay <smckay@internode.on.net> To: Albert Cahalan <albert@users.sourceforge.net> Cc: Stephen McKay <smckay@internode.on.net> Subject: Re: posix ps (was Re: Adding `pgrep' and `pkill' to /usr/bin) Message-ID: <200403290252.i2T2qosv004559@dungeon.home> In-Reply-To: <1080523435.2255.1869.camel@cube> from Albert Cahalan at "28 Mar 2004 20:23:56 -0500" References: <p0602046abc879c5fe2f9@[128.113.24.47]> <20040325070120.GA67497@VARK.homeunix.com> <1a9c01c41359$b3da45e0$7890a8c0@dyndns.org> <p06020494bc8a5738af2f@[128.113.24.47]> <200403280808.i2S88aJ7016011@dungeon.home> <20040328184244.I10175@beagle.fokus.fraunhofer.de> <200403290042.i2T0g2sv003657@dungeon.home> <1080523435.2255.1869.camel@cube>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 28th March 2004, Albert Cahalan wrote: >On Sun, 2004-03-28 at 19:42, Stephen McKay wrote: >> On Sunday, 28th March 2004, Harti Brandt wrote: >> >> >Well, that is just like LANG or LC_ALL. You cannot depend on parsing >> >utility output until you set LC_ALL=C, yet I have still to see a script >> >that does this. >> >> Yes, that is a significant deficiency of the internationalisation scheme. >> That doesn't mean we should copy it though. > >At least this is proof that the idea is nothing crazy. I'm happy to agree that you disagree with me on this point. :-) >It has problems, but then so does everything else. In my mind it is one of those insidious problems that keeps giving you difficulties long after you thought you fixed them all. It's a bit like "const" in C, which looks like a great idea but which bites you over and over again. Hence the term "const poisoning". Perhaps there is a similar name for using environment variables to change the behaviour of existing utilities so that you can no longer predict their output in scripts. >Generally, no. You set the personality when you run >a large, complicated, or read-only script that expects >some non-default behavior. >Personality support is a compatibility hack. You use >it to make stuff work, not to break things. My fear (and expectation) based on experience with such things as Pyramid's dual unix personalities (and others) is that users will set every variable they can and to the weirdest of things. This forces every script to handle every possible variable. The people I worked with responded by locking everything down with huge numbers of hard-coded paths (to defeat the user selected unix personality). The possibility of having portable scripts disappeared. My hope is that reworking ps can introduce better portability, not harm it. >You have that flipped around. Personality support allows >you to make your old or foreign-OS scripts work. Repeating myself here, but I believe users will set the variable and that will break every script, so instead of this feature being used selectively to breath new life into old scripts, it will add a burden onto the authors of every new script. >You can get fancy. There are some tricks to make a >transition easier or more useful. For example, Linux >ps will give a warning and fall back to BSD mode if >the UNIX-style parser encounters problems. You can >allow mixed options; my users really like this. I'm happy for users to get whatever they like as long as use in scripts is completely predictable. Personally, I like it when "ps axl" and "ps -ef" do magic based on the hyphen. That's not a hidden variable though. >I'll end with a chunk of my man page. Please note the comment >"In general, it is a bad idea to set these variables." applying >to all environment variables (not just personality) and the >fact that the 4 non-POSIX personalities are marked with the >comment "(totally non-standard)" to warn the users. I think we've both got our arguments in front of everyone, so I probably won't counter your counter-counter arguments. :-) I'm not against you providing such a full featured universal ps command, but I don't think it is the right thing for /bin/ps in FreeBSD. Your "in general it is a bad idea" advice is much weaker than it should be though, and this is the core of my argument. I believe that every time you add a hidden parameter to a program you weaken its utility because using it portably, reliably and predictably becomes more difficult. It's the same argument I make against using global variables in subroutines. Stephen.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403290252.i2T2qosv004559>