ps output line length change

[Rodney W. Grimes]

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


-- 
Rod Grimes                                                 rgrimes at freebsd.org