Re: Deprecating ps(1)s -w switch
Brian Somers wrote: To clarify, my proposal is to silently ignore the -w switch (any/all of them) and to remove the code that reads the terminal width and truncates some columns based on the result (or based on 132). If you're going to change something that, whether you agree with it or not, a lot of other code depends on, you may as well change the name at the same time and call it myps. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Tue, 25 Aug 2009 03:40:54 -0700 Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. To clarify, my proposal is to silently ignore the -w switch (any/all of them) and to remove the code that reads the terminal width and truncates some columns based on the result (or based on 132). The pros: - ps's code becomes simpler. It was mentioned that the ps code is a minefield. This would remove a few mines. - ps IMHO has no business knowing about terminal widths (and where did the 132 column -w idea come from again?). Some programs such as iostat have similar (but way more broken) behaviour however whilst others such as ls do not. - We remove the sizing bugs (only some columns are truncation victims). The cons: - people with visual expectations would have to learn to use less -S or some similar tool. This breaks POLA. - Scripts may exist that depend on the behaviour without -w. Furthermore having to handle ps from both before and after such a change in one script can be painful. It was also suggested that rather than changing the behaviour of one flavour of ps it would be better to adopt an approach more like linux's or even implementing POSIXs suggestions. AFAIK the linux suggestion has been on the table for more time than I care to remember (wasn't Brett Glass going to provide a patch soon?). Although I haven't read the linux code, I'm pretty sure it's a scary place - perhaps this is the reason that we don't have those patches yet. Unless others have more to say on the subject, I think it's clear that the most popular vote is to do nothing. I think this is a shame as I find the pros more compelling than the cons, and I'm sure there are more than a few supporters out there on hackers@ that will stay silent. -- Brian Somers br...@awfulhak.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org signature.asc Description: PGP signature
Re: Deprecating ps(1)s -w switch
Brian Somers wrote: On Tue, 25 Aug 2009 03:40:54 -0700 Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. To clarify, my proposal is to silently ignore the -w switch (any/all of them) and to remove the code that reads the terminal width and truncates some columns based on the result (or based on 132). The pros: - ps's code becomes simpler. It was mentioned that the ps code is a minefield. This would remove a few mines. - ps IMHO has no business knowing about terminal widths (and where did the 132 column -w idea come from again?). back in the day terminals came in two widths... 80 and 132. the teletype printers were 132 and the few video terminals there were were 80. later some of the video terminals had a wide 132 mode you could switch to. Some programs such as iostat have similar (but way more broken) behaviour however whilst others such as ls do not. - We remove the sizing bugs (only some columns are truncation victims). The cons: - people with visual expectations would have to learn to use less -S or some similar tool. This breaks POLA. - Scripts may exist that depend on the behaviour without -w. Furthermore having to handle ps from both before and after such a change in one script can be painful. It was also suggested that rather than changing the behaviour of one flavour of ps it would be better to adopt an approach more like linux's or even implementing POSIXs suggestions. AFAIK the linux suggestion has been on the table for more time than I care to remember (wasn't Brett Glass going to provide a patch soon?). Although I haven't read the linux code, I'm pretty sure it's a scary place - perhaps this is the reason that we don't have those patches yet. Unless others have more to say on the subject, I think it's clear that the most popular vote is to do nothing. I think this is a shame as I find the pros more compelling than the cons, and I'm sure there are more than a few supporters out there on hackers@ that will stay silent. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Brian Somers br...@freebsd.org writes: To clarify, my proposal is to silently ignore the -w switch (any/all of them) and to remove the code that reads the terminal width and truncates some columns based on the result (or based on 132). The pros: - ps's code becomes simpler. It was mentioned that the ps code is a minefield. This would remove a few mines. Frankly, the width limiting code is the least of ps's problems. - ps IMHO has no business knowing about terminal widths (and where did the 132 column -w idea come from again?). Some programs such as iostat have similar (but way more broken) behaviour however whilst others such as ls do not. Actually, ls does pretty much the same thing (use a different layout when run on a tty), and it's far from the only Unix utility to do so. Usually, the tty layout is pretty while the non-tty layout is easier to work with in scripts. The cons: [...] - Scripts may exist that depend on the behaviour without -w. Furthermore having to handle ps from both before and after such a change in one script can be painful. Breaking existing scripts would be an *extremely* unwise and unpopular move. The only part of your proposal I support is removing the 132-column limit on 'ps -w' (which I believe would make the output from 'ps -w' identical to that from 'ps -ww') DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Wed, Aug 26, 2009 at 11:40:09PM -0700 I heard the voice of Brian Somers, and lo! it spake thus: I think this is a shame as I find the pros more compelling than the cons, and I'm sure there are more than a few supporters out there on hackers@ that will stay silent. FWIW, I'm in favor of at least carefully examining whether the cons really disqualify the change. My uses of ps pretty well fall into three categories: 1) The times I use -ww 2) The times it doesn't matter whether I did or not 3) The times I wish I'd used -ww, sometimes way later in the game when a script *DOESN'T* do what it's supposed to because ps isn't actually giving me the command. Thanks, ps. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Dag-Erling Smørgrav napisa: Actually, ls does pretty much the same thing (use a different layout when run on a tty), and it's far from the only Unix utility to do so. Usually, the tty layout is pretty while the non-tty layout is easier to work with in scripts. Actually ls doesn't work the same - ls tries to format its output according to terminal but if it can't it won't just chop off any piece of information, and if you pipe ls into other command's input ls behaves as not running on tty - ps behaves in the opposite way in both cases ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Matthew D. Fuller fulle...@over-yonder.net writes: FWIW, I'm in favor of at least carefully examining whether the cons really disqualify the change. They do. Breaking scripts is not acceptable under any circumstances. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Tuesday 25 August 2009 22:51:43 Rick C. Petty wrote: On Tue, Aug 25, 2009 at 04:09:09PM +0200, Jonathan McKeown wrote: I usually want to see ps(1) output in easily-read columns. Without width limits, this can't be guaranteed. I would strongly object to the complete removal of any option to limit the output width of ps(1) and make it easily human-readable. I'm also astonished at the suggestion that not using -ww is ``a mistake''. I very seldom need to see the whole commandline for every process. Then you must not use Java much. I almost always need the -ww option. I'm fine with the default being fit into my terminal width, but I'd be for one option to specify limited width and another option (-w) to specify as wide as possible. As it happens, you're right: I don't use Java at all. Neither do I object (much) to a change in the default behaviour such that wide output is the norm and restricted-width an option. In the original message, Brian Somers wrote: The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. The suggestion seems to be to remove the width-limiting code altogether, and make people who want width-restricted output (for example to keep it in columns which are easily scanned by eye) pipe the output through another command. That I do object to. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Tim Kientzle kient...@freebsd.org writes: The difference between ps, ps -w, and ps -ww is pretty significant for Java, in particular. Java command lines are typically enormous (thank you, CLASSPATH) which makes ps -ww often more annoying than it's worth. Java command lines aren't necessarily enormous. If they are, it is because whoever invoked Java didn't know that it respects the CLASSPATH environment variable, and that setting -classpath on the command line f*s up the user's preferences (e.g. the user may want to replace a particular set of classes with an alternative implementation). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Ivan Radovanovic riv...@gmail.com writes: I think software should evolve to be better rather then to stick with something done the wrong way, even that has been done maybe 30 years ago - that is why behavior should be changed. It is never too late to do the right thing ;-) Are you also going to rewrite 30 years' worth of scripts that expect ps(1) to have a -w option which behaves in a particular manner? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
,--- You/Dag-Erling (Wed, 26 Aug 2009 16:20:59 +0200) * | Tim Kientzle kient...@freebsd.org writes: | The difference between ps, ps -w, and ps -ww is pretty | significant for Java, in particular. Java command lines | are typically enormous (thank you, CLASSPATH) which makes | ps -ww often more annoying than it's worth. | | Java command lines aren't necessarily enormous. If they are, it is | because whoever invoked Java didn't know that it respects the CLASSPATH | environment variable, and that setting -classpath on the command line | f*s up the user's preferences (e.g. the user may want to replace a | particular set of classes with an alternative implementation). Using either the `-classpath' option to `java' or `CLASSPATH' environment variable is a pretty obsolete practice (whoever does either these days, should stop and re-think, IMHO.) The deficiency of the above, in either variation, is the need to list every `jar' file used, which gets ugly with more than a few files. A persons who keeps up with modern Java will call it with one or several of the options: -Djava.ext.dirs -Djava.library.path -Djava.endorsed.dirs Java Virtual Machine will internally list the files in each of the directories (specified on the command line or default ones), saving a user the effort to mention them explicitly in `CLASSPATH'. This cuts on the length of the command line dramatically, but still `java' processes' command lines are typically enormously long: even the lists of the directories, with their absolute paths are significant; on top of it, `java' is usually invoked with a gazillion of options modifying JVM's runtime behaviour. It's a fact of life that for real-life applications, `java' command lines are *long* -- you can't change that by moving from `-classpath' to `CLASSPATH'. (This said, I am not in favor of modifying `ps' in the manner proposed, as my previous message indicated.) -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Tue, Aug 25, 2009 at 03:40:54AM -0700, Brian Somers wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Do you want to remove '-w' switch preserving '-ww' one? IMO this seems awkward. Also, by ignoring it for now do you mean that behavior of ps with '-w' switch would be the same as without it? I would prefer that '-w' == '-ww'. One can remove all references to multiple 'w' switches from the man page but leave ps itself insensitive to any number of 'w' switches (so '-w' == '-ww' == '-www' == ...). This also would be consistent with (for example) http://www.freebsd.org/cgi/man.cgi?query=psapropos=0sektion=0manpath=Red+Hat+Linux%2Fi386+9format=html Does anyone have any objections to doing this? I don't propose merging this back into stable/8. 0.02$, Alexey. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
* Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. So ps(1) output can never be limited to the screen width? -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp2fY6nDMwf4.pgp Description: PGP signature
Re: Deprecating ps(1)s -w switch
On Tuesday 25 August 2009 15:44:47 Ed Schouten wrote: * Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. So ps(1) output can never be limited to the screen width? I usually want to see ps(1) output in easily-read columns. Without width limits, this can't be guaranteed. I would strongly object to the complete removal of any option to limit the output width of ps(1) and make it easily human-readable. I'm also astonished at the suggestion that not using -ww is ``a mistake''. I very seldom need to see the whole commandline for every process. Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Ed Schouten napisa: * Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. So ps(1) output can never be limited to the screen width? I think it would be smart not to limit width by default (ie default behavior to be like with -ww), but to have some switch (like -w) to limit width if someone really needs to do that, although with cut -c 1-80 could be achieved limiting... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
* Adrian Penisoara a...@freebsd.ady.ro wrote: Maybe we should also think about compatibility with System V Unix / Linux -- I have encountered quite a lot of scripts expecting ps -ef to give an all processes output. It would not hurt to review what the Linux folks did with their ps(1) -- it supports 3 kinds of options for UNIX/BSD/GNU flavors. In my opinion we should just implement ps(1) as documented in the POSIX Onlinepubs. If it turns out it lacks certain features we want, we could consider adding this to procstat(1) instead. I am of course too lazy to work on this. ;-) -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpcZxeT4pqza.pgp Description: PGP signature
Re: Deprecating ps(1)s -w switch
Hi, On Tue, Aug 25, 2009 at 3:59 PM, Ivan Radovanovic riv...@gmail.com wrote: Ed Schouten napisa: * Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. So ps(1) output can never be limited to the screen width? I think it would be smart not to limit width by default (ie default behavior to be like with -ww), but to have some switch (like -w) to limit width if someone really needs to do that, although with cut -c 1-80 could be achieved limiting... Let's not reverse the meaning of switches, for the sake of compatibility with (older) existent scripts... Maybe we should also think about compatibility with System V Unix / Linux -- I have encountered quite a lot of scripts expecting ps -ef to give an all processes output. It would not hurt to review what the Linux folks did with their ps(1) -- it supports 3 kinds of options for UNIX/BSD/GNU flavors. Regards, Adrian Penisoara EnterpriseBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Jonathan McKeown wrote: On Tuesday 25 August 2009 15:44:47 Ed Schouten wrote: * Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. The difference between ps, ps -w, and ps -ww is pretty significant for Java, in particular. Java command lines are typically enormous (thank you, CLASSPATH) which makes ps -ww often more annoying than it's worth. I concur with another poster that the GNU ps approach for supporting multiple argument styles deserves consideration. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Tue, 2009-08-25 at 08:48 -0700, Tim Kientzle wrote: Jonathan McKeown wrote: On Tuesday 25 August 2009 15:44:47 Ed Schouten wrote: * Brian Somers br...@freebsd.org wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. The difference between ps, ps -w, and ps -ww is pretty significant for Java, in particular. Java command lines are typically enormous (thank you, CLASSPATH) which makes ps -ww often more annoying than it's worth. I concur with another poster that the GNU ps approach for supporting multiple argument styles deserves consideration. I realized that nobody asked me, but IMHO it ain't broke so don't fix it. I use -w and -ww a lot, and yes, I do distinguish them. Sometimes -w is enough; if it isn't, then I'll use -ww but otherwise I avoid it because it gives just too much output in many cases. -- Frank Mayhar fr...@exit.com http://www.exit.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Brian Somers wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. my fingers would object as ps auxw is my standard command. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Brian Somers wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. Short version, yes, I object to changing the defaults. Longer version, I don't see anything wrong with the defaults the way that they are, and the fact that there is a teeny-tiny learning curve for people who need to see the full output isn't really an issue that deserves the time already spent on it. Bruce pointed out in the PR that most users would be surprised if 'ps -ax | grep foo' suddenly sprouted a lot more stuff that 'ps -ax' didn't have, and I agree. As a matter of personal preference I find the current defaults to be just lovely, and occasionally use -w or -ww if I need to see more. If you want the default to be something different, that's what aliases are for. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Doug Barton napisa: Brian Somers wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. Short version, yes, I object to changing the defaults. Longer version, I don't see anything wrong with the defaults the way that they are, and the fact that there is a teeny-tiny learning curve for people who need to see the full output isn't really an issue that deserves the time already spent on it. Bruce pointed out in the PR that most users would be surprised if 'ps -ax | grep foo' suddenly sprouted a lot more stuff that 'ps -ax' didn't have, and I agree. As a matter of personal preference I find the current defaults to be just lovely, and occasionally use -w or -ww if I need to see more. If you want the default to be something different, that's what aliases are for. Doug So, if the developer is presented with a task of developing utility to list running processes on the machine the right way to solve this problem is to implement it exactly the way the ps is implemented (ie, to please some aesthetic criteria (ie to format output to some width) rather than to focus on functionality)? I think software should evolve to be better rather then to stick with something done the wrong way, even that has been done maybe 30 years ago - that is why behavior should be changed. It is never too late to do the right thing ;-) Best regards, Ivan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Ivan Radovanovic wrote: So, if the developer is presented with a task of developing utility to list running processes on the machine the right way to solve this problem is to implement it exactly the way the ps is implemented (ie, to please some aesthetic criteria (ie to format output to some width) rather than to focus on functionality)? If you're developing your own app to display running processes implement it any way you wish. That's totally unrelated to the question at hand. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Doug Barton napisa: If you're developing your own app to display running processes implement it any way you wish. That's totally unrelated to the question at hand. Doug I totally disagree with you - being against change means that you believe it is done the best way it could be done. Although there is another way to solve this problem - manual can be changed to state in the first row process status formated for terminal output instead of process status which is now title for ps. That way it would be obvious at the first look that ps is tightly coupled with terminal it is running on and nobody would need to learn this harder way. Regards, Ivan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Ivan Radovanovic wrote: Doug Barton napisa: If you're developing your own app to display running processes implement it any way you wish. That's totally unrelated to the question at hand. Doug I totally disagree with you - being against change means that you believe it is done the best way it could be done. This argument is so non-sequitur that I'm tempted not to respond, but no, that's not what I'm saying at all. What I'm saying is that there are valid reasons to leave the defaults as they are, AND if you don't like the defaults there are easy ways to manipulate that in your own environment. Although there is another way to solve this problem - manual can be changed to state in the first row process status formated for terminal output instead of process status which is now title for ps. That way it would be obvious at the first look that ps is tightly coupled with terminal it is running on and nobody would need to learn this harder way. Feel free to take a crack at this and send the results to the list for review. Improving the documentation is always a worthy goal. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Doug Barton napisa: Ivan Radovanovic wrote: I totally disagree with you - being against change means that you believe it is done the best way it could be done. This argument is so non-sequitur that I'm tempted not to respond, but no, that's not what I'm saying at all. What I'm saying is that there are valid reasons to leave the defaults as they are, AND if you don't like the defaults there are easy ways to manipulate that in your own environment. You wrote : Longer version, I don't see anything wrong with the defaults the way that they are, and the fact that there is a teeny-tiny learning curve for people who need to see the full output isn't really an issue that deserves the time already spent on it. Bruce pointed out in the PR that most users would be surprised if 'ps -ax | grep foo' suddenly sprouted a lot more stuff that 'ps -ax' didn't have, and I agree. As a matter of personal preference I find the current defaults to be just lovely, and occasionally use -w or -ww if I need to see more. If you want the default to be something different, that's what aliases are for. So, valid arguments against change should be: 1. users will be surprised if ps starts displaying more stuff no matter if that stuff is correct and less stuff (current state) is incorrect 2. your personal preference is that current defaults are lovely Sorry, I don't find these arguments valid Although there is another way to solve this problem - manual can be changed to state in the first row process status formated for terminal output instead of process status which is now title for ps. That way it would be obvious at the first look that ps is tightly coupled with terminal it is running on and nobody would need to learn this harder way. Feel free to take a crack at this and send the results to the list for review. Improving the documentation is always a worthy goal. I would do that for sure if everyone thinks this ps behavior is something that should be kept at current state even if it could be made better Ivan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
,--- You/Ivan (Tue, 25 Aug 2009 22:02:56 +0200) * | Feel free to take a crack at this and send the results to the list for | review. Improving the documentation is always a worthy goal. | | I would do that for sure if everyone thinks this ps behavior is | something that should be kept at current state even if it could be made | better `---* Don't know how you are going to find about everyone, but I, for one, think that modifying the established tool's behavior in the proposed manner is an utterly bad idea. Use shell aliases, functions and scripts wrapped around the primary tool to get the behavior you like -- let others stick with their established habits and wrappers. Improving the documentation would be good, OTOH. Thanks, -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Tuesday 25 August 2009 4:02:56 pm Ivan Radovanovic wrote: Doug Barton napisa: Ivan Radovanovic wrote: I totally disagree with you - being against change means that you believe it is done the best way it could be done. This argument is so non-sequitur that I'm tempted not to respond, but no, that's not what I'm saying at all. What I'm saying is that there are valid reasons to leave the defaults as they are, AND if you don't like the defaults there are easy ways to manipulate that in your own environment. You wrote : Longer version, I don't see anything wrong with the defaults the way that they are, and the fact that there is a teeny-tiny learning curve for people who need to see the full output isn't really an issue that deserves the time already spent on it. Bruce pointed out in the PR that most users would be surprised if 'ps -ax | grep foo' suddenly sprouted a lot more stuff that 'ps -ax' didn't have, and I agree. As a matter of personal preference I find the current defaults to be just lovely, and occasionally use -w or -ww if I need to see more. If you want the default to be something different, that's what aliases are for. So, valid arguments against change should be: 1. users will be surprised if ps starts displaying more stuff no matter if that stuff is correct and less stuff (current state) is incorrect 2. your personal preference is that current defaults are lovely POLA -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Tue, Aug 25, 2009 at 04:09:09PM +0200, Jonathan McKeown wrote: I usually want to see ps(1) output in easily-read columns. Without width limits, this can't be guaranteed. I would strongly object to the complete removal of any option to limit the output width of ps(1) and make it easily human-readable. I'm also astonished at the suggestion that not using -ww is ``a mistake''. I very seldom need to see the whole commandline for every process. Then you must not use Java much. I almost always need the -ww option. I'm fine with the default being fit into my terminal width, but I'd be for one option to specify limited width and another option (-w) to specify as wide as possible. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Alex Goncharov napisa: ,--- You/Ivan (Tue, 25 Aug 2009 22:02:56 +0200) * | Feel free to take a crack at this and send the results to the list for | review. Improving the documentation is always a worthy goal. | | I would do that for sure if everyone thinks this ps behavior is | something that should be kept at current state even if it could be made | better `---* Don't know how you are going to find about everyone, but I, for one, think that modifying the established tool's behavior in the proposed manner is an utterly bad idea. Use shell aliases, functions and scripts wrapped around the primary tool to get the behavior you like -- let others stick with their established habits and wrappers. Improving the documentation would be good, OTOH. Thanks, -- Alex -- alex-goncha...@comcast.net -- I guess voting is going against me, so I would probably need to update that documentation :-) Please understand that my idea is to make tool behave as expected from its description - for example ls also formats its output according to terminal, but when you redirect it then it doesn't care about terminal (try ls and ls | less), that is what in the first place made me think that ps would behave in the same way (and btw, I still think that all non-interactive tools behave that way). And I also think that if we can make learning FreeBSD even little less difficult then we should do that. My point is if you are making tool for listing processes what you want is to LIST process (first, and most important), and later (if at all) to make that pretty formatted, after all it is unix philosophy to have small programs that do exactly one thing and that do it right - I think that philosophy is broken (because of historical reasons) with current implementation of ps On the other hand fixing ps's behavior in the proposed manner will for sure brake some scripts that depend on it, but if scripts depend on formatting behavior then those scripts are used only to display some information on the terminal and they would be easily spotted and corrected (are there scripts like that in the system - can someone point out and say Hey XXX will be broken, and that will further brake YYY and so on? Because I am beginning to think that maybe there is far less things depending on this behavior than expected... ) Ivan P.S. I am giving up of trying to explain my reasoning any more, I think I gave enough reasons for everyone to understand my motivation (although of course everyone has the right not to agree with me). I didn't want to offend anyone in this short discussion and if someone feels that way then I am truly sorry. Any pointers on how to update manual page for ps would be greatly appreciated, as well as some mail agreeing with my standpoint :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
Ivan Radovanovic wrote: Doug Barton napisa: Ivan Radovanovic wrote: I totally disagree with you - being against change means that you believe it is done the best way it could be done. This argument is so non-sequitur that I'm tempted not to respond, but no, that's not what I'm saying at all. What I'm saying is that there are valid reasons to leave the defaults as they are, AND if you don't like the defaults there are easy ways to manipulate that in your own environment. I would do that for sure if everyone thinks this ps behavior is something that should be kept at current state even if it could be made better -w was added to show more information, and -ww for all information. I find no problem understanding this and see no reason to change it. blue please p.s. -ww can get big Ivan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
At 11:50 AM -0700 8/25/09, Doug Barton wrote: Brian Somers wrote: I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. Short version, yes, I object to changing the defaults. Speaking as someone who has worked on 'ps' in the past, I recommend that you go slow in making arbitrary changes. 'ps' is already a minefield of craziness between various versions of unix, and adding this new variant will just make matters worse. You certainly can not go back to older releases and change the formatting there, so all programmers who write for a variety of machines/platforms will just end up with one extra way for things to break. -- Garance Alistair Drosehn = dros...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
