ps output line length change

[Mike Karels]

A couple of weeks ago, I sent email on the committers list proposing
reversion of r314685 changing the output line length for ps. In
particular, it uses unlimited line length if stdout is not a tty.
The previous code used the tty width if any of stdout, stderr, or
stdin was a tty. The change in r314685 has not been shipped in
any release yet.

The responses to that email all agreed with reversion. However, there
has been some additional discussion in private email. Therefore, I
am sending this to ***@.

My reasoning is this;

1. The output line length for the following commands should reasonably
be the same in an interactive session: ps, ps | more, ps | grep.

2. The previous behavior is the way things have worked since 1990,
as Conrad pointed out. As others pointed out, it has long been known
that -ww was required to get unlimited lines, e.g. in a script. I
don't see any significant justification to change 28 years of precedent.

3. The rationale for the change included that it is easier for scripts
(which I maintain are broken if they assume this), and that it doesn't
matter if using less with left-right scrolling. We shouldn't make
assumptions about what the output is going through, let alone assume
left-right scrolling. The previous algorithm was described as magic,
but I think it is straightforward. Perhaps a comment is in order.

I tried to think of a compromise solution, but the only thing that
comes to mind is messy: an environment variable that would enable
unlimited line length when the output was not a tty. That would not
be easier for scripts. And as Bruce noted, aliasing ps to "ps -ww"
does not work with old BSD-stype "ps axu".

What do people think should be done?

Thanks,
Mike

------- End of Forwarded Message

[Cy Schubert]

Post by Mike Karels
A couple of weeks ago, I sent email on the committers list proposing
reversion of r314685 changing the output line length for ps. In
particular, it uses unlimited line length if stdout is not a tty.
The previous code used the tty width if any of stdout, stderr, or
stdin was a tty. The change in r314685 has not been shipped in
any release yet.
The responses to that email all agreed with reversion. However, there
has been some additional discussion in private email. Therefore, I
My reasoning is this;
1. The output line length for the following commands should reasonably
be the same in an interactive session: ps, ps | more, ps | grep.
2. The previous behavior is the way things have worked since 1990,
as Conrad pointed out. As others pointed out, it has long been known
that -ww was required to get unlimited lines, e.g. in a script. I
don't see any significant justification to change 28 years of precedent.
3. The rationale for the change included that it is easier for scripts
(which I maintain are broken if they assume this), and that it doesn't
matter if using less with left-right scrolling. We shouldn't make
assumptions about what the output is going through, let alone assume
left-right scrolling. The previous algorithm was described as magic,
but I think it is straightforward. Perhaps a comment is in order.
I tried to think of a compromise solution, but the only thing that
comes to mind is messy: an environment variable that would enable
unlimited line length when the output was not a tty. That would not
be easier for scripts. And as Bruce noted, aliasing ps to "ps -ww"
does not work with old BSD-stype "ps axu".

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.

Post by Mike Karels
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.

[Jamie Landeg-Jones]

Post by Cy Schubert
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.

I agree entirely. This change effectively changes the output data simply due to
presence of a pipe.

So, the output of "ps" could be somewhat different to "ps | cat".. (*)

It's a total break of POLA.
It's unnecessary (-ww already exists to achieve it)
And I think it will actually make scripts more unreliable going forward... Which version
of "ps" are we running? Do we "-ww" or not?

Surely we want to remove ambiguity not add it.

I know it's a weird one - I remember long long ago getting bitten by scripts that
parsed "ps" getting seemingly unexplained truncation. But that's when I learnt how
"ps" works, and that's when I learnt of "-ww"

Now, if "ps" had never defaulted to tty-width truncation, then that would be fine,
but changing how it determines to do so now would be awful, in my opinion.

(*) I realise that piped output is often changed to remove control/colour attributes,
and "ls" switches off column mode, but the former is a different situation, and the
latter? Well, something we have to live with now, and it doesn't really affect the
actual raw data that's displayed.

Cheers, Jamie

[Ian Lepore]

Post by Mike Karels
[...]

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.

Post by Mike Karels
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?

-- Ian

[Cy Schubert]

Post by Ian Lepore

Post by Mike Karels
[...]

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.

Post by Mike Karels
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?

[Rodney W. Grimes]

Post by Cy Schubert

Post by Ian Lepore

Post by Mike Karels
[...]

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.

Post by Mike Karels
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.

[Edward Napierala]

2018-02-17 21:12 GMT+00:00 Rodney W. Grimes <

Karels??

Post by Cy Schubert

Post by Ian Lepore

Post by Mike Karels
[...]

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

Post by Cy Schubert

Post by Ian Lepore

the change was made to be more Linux compatible and allow greater??
portability.

Post by Mike Karels
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??

Post by Cy Schubert

Post by Ian Lepore

different so, Linux compatibility is... well just isn't.
My vote is to revert and have an environment variable with

defaults,??

Post by Cy Schubert

Post by Ian Lepore

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

Post by Cy Schubert

Post by Ian Lepore
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.

[Garance A Drosehn]

Post by Mike Karels
A couple of weeks ago, I sent email on the committers list proposing
reversion of r314685 changing the output line length for ps. In
particular, it uses unlimited line length if stdout is not a tty.
The previous code used the tty width if any of stdout, stderr, or
stdin was a tty. The change in r314685 has not been shipped in
any release yet.
The responses to that email all agreed with reversion. However,
there has been some additional discussion in private email.

I've lost track of how many times I've said this, but I'll say it
one more: I think the change should be reverted. What the code
currently does is fine, and is flexible enough. I've written
many scripts which parse the output of 'ps', and the historical
behavior has never hampered me. And I do write scripts which
have to run on multiple unixes (in fact, most of my work is done
on systems which are not running FreeBSD).

[Eric van Gyzen]

Post by Mike Karels
A couple of weeks ago, I sent email on the committers list proposing
reversion of r314685 changing the output line length for ps. In
particular, it uses unlimited line length if stdout is not a tty.
The previous code used the tty width if any of stdout, stderr, or
stdin was a tty. The change in r314685 has not been shipped in
any release yet.
The responses to that email all agreed with reversion. However, there
has been some additional discussion in private email. Therefore, I
My reasoning is this;
1. The output line length for the following commands should reasonably
be the same in an interactive session: ps, ps | more, ps | grep.
2. The previous behavior is the way things have worked since 1990,
as Conrad pointed out. As others pointed out, it has long been known
that -ww was required to get unlimited lines, e.g. in a script. I
don't see any significant justification to change 28 years of precedent.
3. The rationale for the change included that it is easier for scripts
(which I maintain are broken if they assume this), and that it doesn't
matter if using less with left-right scrolling. We shouldn't make
assumptions about what the output is going through, let alone assume
left-right scrolling. The previous algorithm was described as magic,
but I think it is straightforward. Perhaps a comment is in order.
I tried to think of a compromise solution, but the only thing that
comes to mind is messy: an environment variable that would enable
unlimited line length when the output was not a tty. That would not
be easier for scripts. And as Bruce noted, aliasing ps to "ps -ww"
does not work with old BSD-stype "ps axu".
What do people think should be done?

I agree that the change should be reverted.

Eric

[Cy Schubert]

Iirc cem@ committed the original patch. Maybe someone should ask him to revert.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<***@cschubert.com> or <***@freebsd.org>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Garance A Drosehn
Sent: 21/02/2018 11:52
To: Mike Karels
Cc: ***@freebsd.org
Subject: Re: ps output line length change

Post by Mike Karels
A couple of weeks ago, I sent email on the committers list proposing
reversion of r314685 changing the output line length for ps. In
particular, it uses unlimited line length if stdout is not a tty.
The previous code used the tty width if any of stdout, stderr, or
stdin was a tty. The change in r314685 has not been shipped in
any release yet.
The responses to that email all agreed with reversion. However,
there has been some additional discussion in private email.

I've lost track of how many times I've said this, but I'll say it
one more: I think the change should be reverted. What the code
currently does is fine, and is flexible enough. I've written
many scripts which parse the output of 'ps', and the historical
behavior has never hampered me. And I do write scripts which
have to run on multiple unixes (in fact, most of my work is done
on systems which are not running FreeBSD).

[John Baldwin]

Mike has. This thread is to determine what the consensus is.

My preference is for the old behavior.

Post by Cy Schubert
---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.
Cy Schubert
The need of the many outweighs the greed of the few.
---
-----Original Message-----
From: Garance A Drosehn
Sent: 21/02/2018 11:52
To: Mike Karels
Subject: Re: ps output line length change

Post by Mike Karels
A couple of weeks ago, I sent email on the committers list proposing
reversion of r314685 changing the output line length for ps. In
particular, it uses unlimited line length if stdout is not a tty.
The previous code used the tty width if any of stdout, stderr, or
stdin was a tty. The change in r314685 has not been shipped in
any release yet.
The responses to that email all agreed with reversion. However,
there has been some additional discussion in private email.

I've lost track of how many times I've said this, but I'll say it
one more: I think the change should be reverted. What the code
currently does is fine, and is flexible enough. I've written
many scripts which parse the output of 'ps', and the historical
behavior has never hampered me. And I do write scripts which
have to run on multiple unixes (in fact, most of my work is done
on systems which are not running FreeBSD).

[Mike Karels]

Post by John Baldwin
Mike has. This thread is to determine what the consensus is.
My preference is for the old behavior.

Everyone who expressed an opinion about reversion of r314685 on arch@
said that they prefered the old behavior. There were similar results
on the committers list earlier. Accordingly, I have put a change
that reverts r314685 and adds comments explaining the old behavior
up for review. It is https://reviews.freebsd.org/D14530.

Mike