Hi,
where should 'ps' reside, according to the standard?
In the latest version it moved from /bin/ps to /usr/bin/ps.
Thanks,
Ulf
--
#include signature
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
-BEGIN PGP SIGNED MESSAGE-
On Thu, 8 Jan 1998, Ulf Jaenicke-Roessler wrote:
where should 'ps' reside, according to the standard?
In the latest version it moved from /bin/ps to /usr/bin/ps.
According to the maintainer, it will be moved back to /bin.
This is bug #16705. Thanks.
BTW,
Does anyone know where killall went? procps_1.2.2-1 doesn't seem to
include it. killall is used in quite a lot of scripts, which are now
starting to break.
--
Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the
Lunatech Research http://www.lunatech.com/
[EMAIL PROTECTED] (Ulf Jaenicke-Roessler) writes:
where should 'ps' reside, according to the standard?
In the latest version it moved from /bin/ps to /usr/bin/ps.
I noticed this too, and filed a bug. The maintainer says it will return to
/bin in the next release.
Martin.
--
TO
On Thu, 8 Jan 1998, Bart Schuller wrote:
BTW,
Does anyone know where killall went? procps_1.2.2-1 doesn't seem to
include it. killall is used in quite a lot of scripts, which are now
starting to break.
Yes, it got broken out upstream into a seperate psmisc package. Which is
now stuck in
On Jan 8, Scott Ellis wrote
On Thu, 8 Jan 1998, Bart Schuller wrote:
Does anyone know where killall went? procps_1.2.2-1 doesn't seem to
include it. killall is used in quite a lot of scripts, which are now
starting to break.
Yes, it got broken out upstream into a seperate psmisc package.
On Thu, Jan 08, 1998 at 03:10:19PM +0100, Bart Schuller wrote:
Does anyone know where killall went? procps_1.2.2-1 doesn't seem to
include it. killall is used in quite a lot of scripts, which are now
starting to break.
Yes, it got broken out upstream into a seperate psmisc package.
On Thu, Jan 08, 1998 at 03:13:05PM +0100, Martin Schulze wrote:
On Thu, Jan 08, 1998 at 03:10:19PM +0100, Bart Schuller wrote:
I mut say I find the policy with respect to split or renamed packages
getting stuck in Incoming suboptimal. First e2fsprogsg, now killall.
Please file a bugreport
On Jan 8, [EMAIL PROTECTED] wrote
Please file a bugreport against ftp.debian.org so Guy remembers this.
Note that this is probably already covered:
#4378: Dependencies should be checked automatically
#9857: ftp 'dinstall' needs to check dependancies
Now you're really scaring me: out of
Joey Hess wrote:
BTW, could you make a procps-dev package with a libproc.a, and libproc's .h
files in it? I need this for a package I would like to make called
w.bassman, it's a different version of 'w', that links with libproc, and
needs whattime.h to build.
This would be the libproc-dev
BTW, could you make a procps-dev package with a libproc.a, and libproc's .h
files in it? I need this for a package I would like to make called
w.bassman, it's a different version of 'w', that links with libproc, and
needs whattime.h to build.
--
see shy jo
--
TO UNSUBSCRIBE FROM THIS MAILING
Nobody's going to be upset if you create the new package. I think you should
go ahead.
Thanks
Bruce
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Two options:
I merge the psmic into procps
I create a new package called psmisc.
procps is required. pure compatability would argue that
psmisc also be required (or something very close).
--
Raul
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e
[I emailled the talk about procps and colors on debian-private, but on second
thoughts it probably should go here]
Ok, so I have patched procps so it now does colors, and compiles and works.
But, killall is no longer in procps. It is now part of a package called
psmisc. This was done
[EMAIL PROTECTED] wrote:
will NOT HAVE KILLALL. I think this is probably a Bad Thing.
Two options:
I merge the psmic into procps
I create a new package called psmisc.
The second, and make procps recommend or suggest the new psmisc package.
--
see shy jo
--
TO UNSUBSCRIBE FROM
I have written a 'tmem' program, similiar to tload, and would like to
see if there is interest in including it in procps. So.. since Helmut
Geyer seems to have dissappeared (anyone know if he is ok?:-(, I'm
curious who I ought to be sending this to...
Thanks,
--
David Welton
Package: procps
Kernel 1.3.53 seems to have changed the way memory use is reported (I
think it reports a new value in /proc/meminfo, cached:, referring to
cached VM pages) and also has an internal process kernel bdflush that
has a space in its name. The result is that top and ps can dump
core
Note that current 1.3.x kernels seem to have everything in /proc/ksyms,
instead of just one page. Using that information, psupdate and System.map
are completely unnecessary.
Jeff
Package: procps
Version: 0.97-4
valour$ w
5:07pm up 15 days, 20:31, 7 users, load average: 0.16, 0.11, 0.09, 3/76
User tty login@ idle JCPU PCPU what
and1000 ttyp0 4:15pm49 24 -bash (bash
Package: procps
Version: 0.97
Package_Revision: 4
The manpage ps(1) tells us:
--- happs 8--
COMMAND-LINE OPTIONS
Command line arguments may optionally be preceeded by a
'-', but there is no need for it. There are also
201 - 220 of 220 matches
Mail list logo
