https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288647

            Bug ID: 288647
           Summary: ps filtering options broke
           Product: Base System
           Version: 14.3-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: [email protected]
          Reporter: [email protected]

Previous behavior of ps was:

* Specifying -a and -x would remove the default filters revealing more
processes.
* Specifying -U would imply -a, then impose a filter hiding processes unrelated
to the UID(s).
* Specifying -p would impose a filter, hiding processes unrelated to specified
PID(s).
* Specifying -d would change the display to tree format, AND loosen -p to
include descendent processes of the specified PIDs.

Put by example:

`ps -ax -U mongodb` would remove the default filters that hide PIDs for
(a)other users and (x)unattached to terminals. Then it would impose a filter to
just the UID for mongodb. Now, -x is ignored with -U, and -a overrides -U
showing everything. Admittedly, being able to include -a with -U wasn't really
important before because -U superseded -a, but it was nice that a shell alias
with -a could be overridden with -U.

`ps -d -p 123` would show PID 123 and its descendants in tree format -- VERY
useful for cron as `ps -d -p $(cat /var/run/cron.pid)`. Now adding -d to -p
does nothing.

I'm not sure if these changes were intentional, but I fail to see any use-case
for them, and there are use-cases for the previous behavior.

I believe changes to -d with -p happened in 14.0, and changes to -U happened in
14.3.

I'd also lodge a friendly complaint that some of these breaking changes came in
a minor release. My understanding is, breaking changes wait for the next major
release unless they're security-related. The changes in 14.3 caused us some
consternation because we normally test our upgrades more thoroughly on major
releases, and generally save a lot of time by mostly trusting that nothing
breaks on minor releases. I hope we can continue to trust that minor releases
don't change usages in incompatible ways.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to