|Summary:||New version of ps breaks existing scripts|
|Product:||[Retired] Red Hat Linux||Reporter:||tchrist|
|Component:||procps||Assignee:||Alexander Larsson <alexl>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2002-06-19 14:54:31 UTC||Type:||---|
|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 documented! 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 --cols -j,j job control s signal --group --user --sid --rows -O,O preloaded -o v virtual memory --cumulative --format --deselect -l,l long u user-oriented --sort --tty --forest --version X registers --heading --no-heading ********* misc options ********* -V,V show version L list format codes f ASCII art forest -m,m show threads S children in sum -y change -l format -n,N set namelist file c true command name n numeric WCHAN,UID -w,w wide output e show environment -H process heirarchy 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$$ ) FLAGS UID PID PPID PRI NI SIZE RSS WCHAN STA TTY TIME COMMAND 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 Linux 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. --tom
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.