ps.1: '-A' and '-a': Note change in behavior

[emaste]

The doc change should be included in the same commit that changes the behaviour

[olce]

• Update base (impacts of changes earlier in the series).

[imp]

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

[olce]

In D49618#1132119, @imp wrote:

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

Ah, I just updated a wrong diff...

[olce]

Update with the right diff

[olce]

@imp The erroneous diff was that of D49605. Thanks for the heads up.

[olce]

In D49618#1131522, @emaste wrote:

The doc change should be included in the same commit that changes the behaviour

Yes, will do that on commit.

[bdrewery]

bin/ps/ps.1

1034

This is a subjective claim.
The new behavior is quite annoying and surprising given how long it worked the previous way.
A sane approach would make the last flag given override the previous. ps -ap pid = -p, ps -p pid -a = -a.

[bdrewery]

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.

[olce]

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.

[olce]

bin/ps/ps.1

1034

You can also find more context and explanations in the following bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id= 288647
and in the ps(1)'s manual page that was revamped months ago.