[9fans] /sys/src/cmd/ps.c

[9fans] /sys/src/cmd/ps.c

[lucio]

I've (trivially) added a "-f procdir" option to ps(1) so that I could
use a different source for the /proc information.  It would have been
as easy to spawn a new window and import the remote /proc in it, but
I'm sure I'm not the only person who feels they may want access to the
local and the remote /proc simultaneously.  Is it worth documenting
the option and submit a patch?

++L

Re: [9fans] /sys/src/cmd/ps.c

[Fco. J. Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 121 bytes --]

You could have used also something like

rfork n
bind $1 /proc
shift
ps $*

without having to open a new window.

[-- Attachment #2: Type: message/rfc822, Size: 2699 bytes --]

From: lucio@proxima.alt.za
To: 9fans@cse.psu.edu
Subject: [9fans] /sys/src/cmd/ps.c
Date: Thu, 2 Sep 2004 08:44:04 +0200
Message-ID: <f13d110d4c4c8e59a7fb943757ca3aff@proxima.alt.za>

I've (trivially) added a "-f procdir" option to ps(1) so that I could
use a different source for the /proc information.  It would have been
as easy to spawn a new window and import the remote /proc in it, but
I'm sure I'm not the only person who feels they may want access to the
local and the remote /proc simultaneously.  Is it worth documenting
the option and submit a patch?

++L

Re: [9fans] /sys/src/cmd/ps.c

[Russ Cox]

> I've (trivially) added a "-f procdir" option to ps(1) so that I could
> use a different source for the /proc information.  It would have been
> as easy to spawn a new window and import the remote /proc in it, but
> I'm sure I'm not the only person who feels they may want access to the
> local and the remote /proc simultaneously.  Is it worth documenting
> the option and submit a patch?

i'd rather you just used bind.
next all the debuggers will 
need the flag too.  where will
it stop?

we have shorthands like /proc
and /dev/mouse and the like
for a reason.

Re: [9fans] /sys/src/cmd/ps.c

[lucio]

> i'd rather you just used bind.
> next all the debuggers will 
> need the flag too.  where will
> it stop?
> 
That was the intention in asking first.  Without wanting to be purely
argumentative, I believe that enhancing ps(1) does not mandate
enhancing the debuggers, although there may be other mundane utilities
that might require a similar extension.  It is not large, complex or
error prone (give or take that psu(1) has a minute amount of trouble
with it).  So _I'm_ willing to draw the line, if anyone else feels a
similar desire.

> we have shorthands like /proc
> and /dev/mouse and the like
> for a reason.

And a good reason it is too, but I think it is unnecessarily
restrictive to compel its use under all circumstances.  On the other
hand, we still have our "arbitres elegantiarum" (I hope my Latin isn't
letting me down) to lay down the rules and we ought to listen to them.

++L