Bug 6047 - New version of ps breaks existing scripts
Summary: New version of ps breaks existing scripts
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: procps
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-10-18 12:30 UTC by tchrist
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2002-06-19 14:54:31 UTC

Attachments (Terms of Use)

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@redhat.com 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.

Note You need to log in before you can comment on or make changes to this bug.