Bug 6047

Summary: New version of ps breaks existing scripts
Product: [Retired] Red Hat Linux Reporter: tchrist
Component: procpsAssignee: Alexander Larsson <alexl>
Severity: high Docs Contact:
Priority: medium    
Version: 6.0CC: procps-bugs, tchrist
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-06-19 14:54:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description tchrist 1999-10-18 12:30:18 UTC
[I apologize in advance for mis-classifying the component
that this bug pertains to, but you do not appear to offer
sufficient choices to cover these.]

I had existing scripts that I developed on your 5.2 release
which you gratuitously broke in your 6.0 release.   These
were sysadmin scripts used to help manage the system, so
the impact was severe.  I could locate no release notes
that documented this particular bug.  Did I somewhere
miss such a list of impacts?  Any release that breaks
something in a previous release should be strongly

The case I'm talking about is the standard "ps" command.

doriath(tchrist)% ps l$$
ERROR: Unsupported option (BSD syntax)
********* simple selection *********  ********* selection by
list *********
-A all processes                      -C by command name
-N negate selection                   -G by real group ID
(supports names)
-a all w/ tty except session leaders  -U by real user ID
(supports names)
-d all except session leaders         -g by session leader
OR by group name
-e all processes                      -p by process ID
T  all processes on this terminal     -s processes in the
sessions given
a  all w/ tty, including other users  -t by tty
g  all, even group leaders!           -u by effective user
ID (supports names)
r  only running processes             U  processes for
specified users
x  processes w/o controlling ttys     t  by tty
*********** output format **********  *********** long
options ***********
-o,o user-defined  -f full            --Group --User --pid
-j,j job control   s  signal          --group --user --sid
-O,O preloaded -o  v  virtual memory  --cumulative --format
-l,l long          u  user-oriented   --sort --tty --forest
                   X  registers       --heading --no-heading
                    ********* misc options *********
-V,V show version       L  list format codes  f  ASCII art
-m,m show threads       S  children in sum    -y change -l
-n,N set namelist file  c  true command name  n  numeric
-w,w wide output        e  show environment   -H process

doriath(tchrist)% ps --version
procps version 2.0.2

doriath(tchrist)% cd ~tchrist/procps-1.2.9
doriath(tchrist)% ( setenv LD_LIBRARY_PATH $cwd/proc ; ./ps
l$$ )
   100   502 10284 10282  10   0   2560  1692 rt_sigsuspe
S   ?   0:02 -tcsh

doriath(tchrist)% ( setenv LD_LIBRARY_PATH $cwd/proc ; ./ps
--version )
procps version 1.2.9

As you see, you have gratuitously chosen to recognize and
scold.  You did
not have to break this.  You have managed to break sysadmin
scripts that ran
perfectly well as is.  I am seriously considering backing
off to 1.2.9 so
that things works right again.

Can you please explain to me why 'ps l$$' is somehow
inherently evil?  It's
obviously not conflicting with anything, not just because it
worked fine before,
but because you still recognize it.

This makes it gratuitously difficult to port scripts between
and BSD.  Please, this isn't a war to piss people off.
Users just want
things to work.

And while I'm at it, having all those 23 lines of output
ends up scrolling
off the 24x80 screen of anyone with more than a one line
prompt, or,
like me, with an extra line that says "Exit 1" if needed.
Please don't try
to put a manpage in an error/usage message.  Just tell them
to RTFM.


Comment 1 David Lawrence 1999-10-20 17:35:59 UTC
I have verified that this does work properly in 5.2 but no longer in
6.0 and 6.1. I am assigning this report to the proper developer.

Comment 2 Michael K. Johnson 1999-11-04 22:31:59 UTC
ps is in the "procps" component.  This is an historical accident,
back from when we had ps (kmem-based) and procps had to be
distinguished from the kmem-based ps.

Comment 3 Michael K. Johnson 1999-11-04 22:40:59 UTC
Added procps-bugs to CC list so that I can review this
when looking at procps bugs in my normal manner.  :-)

Comment 4 Michael K. Johnson 1999-11-05 00:18:59 UTC
This will be fixed in procps-2.0.7.  I do not yet have a release
date set.

Comment 5 acahalan 2000-05-17 05:35:59 UTC
'still recognize it' is flat-out wrong

Comment 6 Alexander Larsson 2002-06-20 13:32:09 UTC
Works for me in 2.0.7-14 at least.