Page MenuHomeFreeBSD

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

Authored by olce on Apr 1 2025, 1:38 PM.
Tags
None
Referenced Files
F132958118: D49618.id152978.diff
Tue, Oct 21, 1:14 PM
Unknown Object (File)
Sun, Oct 19, 2:55 AM
Unknown Object (File)
Sat, Oct 18, 4:11 PM
Unknown Object (File)
Sat, Oct 18, 5:07 AM
Unknown Object (File)
Tue, Oct 14, 4:13 AM
Unknown Object (File)
Mon, Sep 22, 8:46 AM
Unknown Object (File)
Sep 12 2025, 4:00 PM
Unknown Object (File)
Sep 11 2025, 10:04 PM

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

olce requested review of this revision.Apr 1 2025, 1:38 PM

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

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

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

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...

Update with the right diff

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

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

Yes, will do that on commit.

This revision is now accepted and ready to land.Apr 28 2025, 12:40 PM
bdrewery added inline comments.
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.

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 marked 2 inline comments as done.Tue, Oct 14, 2:44 PM
olce added inline comments.
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:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id= 288647
and in the ps(1)'s manual page that was revamped months ago.