Sorting and piping with ps, sort and sed

453 views

Skip to first unread message

hq4...@gmail.com

unread,

Aug 29, 2006, 2:18:49 PM8/29/06

to bash tips

> Even in unix, you need several parts of the command line to cooperate. For
> example,
>
> ls | ps
>
It's a silly example. If you cannot answer "what do I want this to do",
then the fact it doesn't do anything is meaningless.
> A little less silly example is
>
> ps | sort
>
> Doesn't do what you want, because sort doesn't know how to extract data from
> ps - it doesn't know that the first line is a header or that the first
> column are numbers.
ps | tail -n +2 | sort -n

No cooperation from ps is necessary. I'll grant you that sort is a
problematic one, as it can only sort on the beginning of the row, but
even this is not something a simple sed cannot solve.
> You *do* need the cooperation of both programs to pass
> the data - even if it's just text - between them.
As I think I have shown, no, you don't.
> I'm not saying that passing objects, rather than text, in pipelines is the
> best idea since sliced bread, but I think it's an interesting idea that's
> definitely worth thinking about. For example, imagine that you had a "ps"
> command which returns an array of objects of type Process. Now you could do
> things like
>
> ps | sort
>
> Where the sort command receives an array of objects, sorts it according to
> the way that Process objects know how to sort themselves (or, if this isn't
> know, just use the .toString() method to convert the Process objects into
> strings).
> You could also do something like
>
> procs=`ps` # procs now holds a Process array
> echo $procs[2] # print the second Process's toString().
> $procs[3].waitFor # run the waitFor method of the second process
>
> and so on.
>
This design is very typical to the way Microsoft defines all of its
APIs. It set its engineers to try and come up with all possible uses
for
the technology, and then write a function to each. The result is a
bloated API that no one has a prayer of a hope of understanding all of
it, and which proves horribly difficult to do anything that may not
have
come up in the initial brain-storming.

As I said before, sort is a problematic one, as it doesn't know how to
deal with columns that are not the first one, or with stuff such as
comparing "8M" to "5G". All of those problems can be solved with enough
script-fu, however, which just goes to show my original point. Even if
they weren't, there's nothing stopping you from writing "better sort",
and solving it.

For example:
$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
COMMAND
root 1 0.1 0.0 1960 668 ? S 16:40 0:00 init
[2]
root 2 0.0 0.0 0 0 ? SN 16:40 0:00
[ksoftirqd/0]
root 3 0.0 0.0 0 0 ? S 16:40 0:00
[watchdog/0]
..

Let's sort it by pid:
$ ps aux | tail -n +2 | sed -e's/^$[^ ]*$ *$[^ ]*$/\2 \1/' | sort
-n
1 root 0.0 0.0 1960 668 ? S 16:40 0:00 init [2]
2 root 0.0 0.0 0 0 ? SN 16:40 0:00 [ksoftirqd/0]
3 root 0.0 0.0 0 0 ? S 16:40 0:00 [watchdog/0]
4 root 0.0 0.0 0 0 ? S< 16:40 0:00 [events/0]
5 root 0.0 0.0 0 0 ? S< 16:40 0:00 [khelper]
6 root 0.0 0.0 0 0 ? S< 16:40 0:00 [kthread]

Sorting by time is no different - just change the sed regexps. If you
want to keep it in the original column order, just put another sed at
the end to switch the columns back. You can do whatever you want,
because you get to decide what to take.

Now, if the MS developers didn't think that sorting on tty is something
someone would want to do, bang, you CAN'T. Pure and simple.

Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html

Reply all

Reply to author

Forward

0 new messages