ps output line length change

[Edward Napierala]

2018-02-17 21:12 GMT+00:00 Rodney W. Grimes <
freebsd-rwg at pdx.rh.cn85.dnsmgr.net>:

> > In message <1518882702.72050.204.camel at freebsd.org>, Ian Lepore writes:
> > > On Fri, 2018-02-16 at 18:03 -0800, Cy Schubert wrote:
> > > > In message <201802170046.w1H0kvxN032252 at mail.karels.net>, Mike
> Karels??
> > > > writes:
> > > > >
> > > > > [...]
> > > > Agreed. I also agree scripts that expect wide output without ww are??
> > > > broken. However Linux ps, at least Red Hat, behaves the same. I
> believe??
> > > > the change was made to be more Linux compatible and allow greater??
> > > > portability.
> > > >
> > > > >
> > > > >
> > > > > What do people think should be done?
> > > > That's a tough one. Break Linux compatibility or break BSD??
> > > > compatibility?
> > > >
> > > > Generally Linux users use ps -ef which we don't support and columns
> are??
> > > > different so, Linux compatibility is... well just isn't.
> > > >
> > > > My vote is to revert and have an environment variable with
> defaults,??
> > > > e.g., PS=--linux or something similar.
> > > >
> > > >
> > >
> > > Linux compatibility is good and desirable, right up to the point where
> > > it stomps on BSD compatibility. ??I think we should revert to historic
> > > behavior.
> > >
> > > I'm agnostic about whether an env var is a good idea or not. ??I use
> the
> > > env vars for LESS and TOP and love the idea, but hate hate hate the
> > > names (I've fought with conflicts on the too-common name TOP multiple
> > > times over the years, most recently just last week my env var TOP
> > > confused some makefile that had a TOP var in it). ??Could the var be
> > > named something like PS_OPTS?
> >
> > Sure. I'm ok even if there is no Linux compatibility. If we choose an
> > environment variable, I'm ok with any name as long as it makes sense.
> >
> > However Solaris had (I haven't used Solaris since Solaris 9) /usr/ucb
> > for BSD compatible utilities. Should we consider something similar for
> > linux compatibility?
>
> We already ahve the whole linuxlator thing, if they want a linux
> ps cant they just.. um actually use a linux ps from /compat/linux?
> I know ps grovels around in a lot of internals but this would,
> imho, be the route to persue a "linux compatible" ps output.
>

Or install sysutils/coreutils and use the gls(1) - GNU version of ls(1),
the same that's used with Linux - built as a native FreeBSD binary.