# ps pw 1 ERROR: Process ID list syntax error. ********* 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 # ps p 1 PID TTY STAT TIME COMMAND 1 ? S 0:03 init [3] # I think there is a parsing problem. It worked before.
Oracle just released Oracle Appliction Server 4.0.7 and is using some of outdated ps arguments like "ps mh" and "ps pw" that cause problems in runing applications. Would it be posible to make backward compatible version of ps that implements these commands as defined in RedHat Relase 6.0.36
ps pw 1 # not working in procps-2.0.2-3, either
only johnsonm can figure this out :-)
The p option is defined to mean that the next option is the process id to list. pw means list process w. To make ps DWYM in this case would make the code significantly harder to follow.
ps m is simply unimplemented. The kernel doesn't give enough info to trace threads. To implement it for convenience in this case would be to cause trouble in other cases.
To clarify what I said earlier: to *fake* an implementation of tracing threads could be detrimental in other cases and would, in fact, give undefined resultes for oracle. I'd rather see a shell script to fix the oracle shell scripts than try to hack ps to pretend to try to do the right thing and perhaps screw up other software that depends on ps...