Details
- Reviewers
emaste ziaee olce - Group Reviewers
manpages - Commits
- rG93a94ce731a8: ps(1): Make '-a' and '-A' always show all processes
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 63315 Build 60199: arc lint + arc unit
Event Timeline
These changes are way way more than the note about a vs A.... they appear to cover other things and also sort and maybe other stuff. Eachbof the logical changes should be separate
bin/ps/ps.1 | ||
---|---|---|
1034 | This is a subjective claim. |
bin/ps/ps.1 | ||
---|---|---|
1034 | And ps -p pid -a is so strange to type, I don't see it being a common case. For me I type out ps uaxw as muscle memory and adding p pid on the end is a logical extension. So what's the "common sense argument" for this change? I think it should be improved or reverted. |
bin/ps/ps.1 | ||
---|---|---|
1034 | The old behavior was just violating POSIX, this is not a subjective claim. In particular, it made it incompatible with what procps does on Linux. The "common sense" part refers to the consistent behavior of other options, i.e., all options *add* to the list (except for -x and -X, controlling the only filter that ps has; all other options are not filters, in particular not -a nor -p), so it was natural to expect -a and -A to behave the same (which, again, the standard explicitly requires). We know this changed a long-time behavior, and have warned users in consequence in RELNOTES and the release notes document. So, no, we will not change this behavior again. An idea of improvement would be to introduce some syntax that allows to specify a simple logical formula (supporting AND, OR and parentheses), which would be a natural extension of what currently exists (implicit ORs). This is however non-trivial and requires some time and care to do properly. Be aware that I intend to reject requests to add new isolated filtering options, as this is not generic and will lead to a too great increase of command-line options. |
bin/ps/ps.1 | ||
---|---|---|
1034 | You can also find more context and explanations in the following bug report: |