ps output line length change

Cy Schubert Cy.Schubert at cschubert.com
Sat Feb 17 21:43:28 UTC 2018


In message <201802172112.w1HLCI2k069334 at pdx.rh.CN85.dnsmgr.net>, 
"Rodney W. Gri
mes" writes:
> > 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.

Except for linuxy scripts that might be in ports or apps ported to 
FreeBSD.

To argue against myself, that's what porting is. Either way, revert 
back to BSD compatibility.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.




More information about the freebsd-arch mailing list