| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 108:41:16 |
| Calls: | 290 |
| Files: | 905 |
| Messages: | 76,699 |
On 8/3/2024 2:08 AM, Rene Kita wrote:
Jerry Peters <jerry@example.invalid> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:[...]
On Sat, 27 Jul 2024 00:40:49 -0000 (UTC), I wrote:
[...]ps -p$(pgrep -d, bash) -wwo pid,ppid,lstart,tty,etime,cmdOr just use ps -C <command>:
to report all the bash sessions I have running (quite a lot). The ???ww??? >>>> says not to truncate the output, which is handy for long command lines. >>>
Does noone know about -C? I keep seeing things like 'ps -ef | grep
<something> in scripts to see if <something is running, rather than
using 'ps -C'.
I did not know about it.
The man page on OpenBSD does not mention -C, but calling 'ps -C' does
not give an error. But:
#v+
$ ps -C ksh
ps: /dev/mem: Permission denied'
#v-
Dunno what to make out of it, but apparently one reason to use grep
instead of -C is portability.
Its described in the man page for FreeBSD ps, https://man.freebsd.org/cgi/man.cgi?ps(1), as:
-C Change the way the CPU percentage is calculated by using a
"raw" CPU calculation that ignores "resident" time (this nor-
mally has no effect).
so maybe you're running FreeBSD instead of the OpenBSD version.
Ed Morton <mortonspam@gmail.com> wrote:
On 8/3/2024 2:08 AM, Rene Kita wrote:
Jerry Peters <jerry@example.invalid> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:[...]
On Sat, 27 Jul 2024 00:40:49 -0000 (UTC), I wrote:
[...]ps -p$(pgrep -d, bash) -wwo pid,ppid,lstart,tty,etime,cmdOr just use ps -C <command>:
says not to truncate the output, which is handy for long command lines. >>>>
Does noone know about -C? I keep seeing things like 'ps -ef | grep
<something> in scripts to see if <something is running, rather than
using 'ps -C'.
I did not know about it.
The man page on OpenBSD does not mention -C, but calling 'ps -C' does
not give an error. But:
#v+
$ ps -C ksh
ps: /dev/mem: Permission denied'
#v-
Dunno what to make out of it, but apparently one reason to use grep
instead of -C is portability.
Its described in the man page for FreeBSD ps,
https://man.freebsd.org/cgi/man.cgi?ps(1), as:
-C Change the way the CPU percentage is calculated by >> using a
"raw" CPU calculation that ignores "resident" time (this nor- >> mally has no effect).
so maybe you're running FreeBSD instead of the OpenBSD version.
I'm pretty sure I know which version of BSD I'm running and I would be
very surprised if OpenBSD would ship the FreeBSD version of ps...
But let's have a look at the source:
#v+
while ((ch = getopt(argc, argv,
"AaCcefgHhjkLlM:mN:O:o:p:rSTt:U:uvW:wx")) != -1)
switch (ch) {
case 'A':
all = 1;
xflg = 1;
break;
case 'a':
all = 1;
break;
case 'C':
break; /* no-op */
#v-
'-C' does nothing. I did not look further to see where that error is
coming from.
I'm pretty sure I know which version of BSD I'm running and I would be
very surprised if OpenBSD would ship the FreeBSD version of ps...
I wonder why they need different versions?
Rene Kita <mail@rkta.de> wrote:
Ed Morton <mortonspam@gmail.com> wrote:
On 8/3/2024 2:08 AM, Rene Kita wrote:
Jerry Peters <jerry@example.invalid> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:[...]
On Sat, 27 Jul 2024 00:40:49 -0000 (UTC), I wrote:
[...]ps -p$(pgrep -d, bash) -wwo pid,ppid,lstart,tty,etime,cmdOr just use ps -C <command>:
says not to truncate the output, which is handy for long command lines. >>>>>
Does noone know about -C? I keep seeing things like 'ps -ef | grep
<something> in scripts to see if <something is running, rather than
using 'ps -C'.
I did not know about it.
The man page on OpenBSD does not mention -C, but calling 'ps -C' does
not give an error. But:
#v+
$ ps -C ksh
ps: /dev/mem: Permission denied'
#v-
Dunno what to make out of it, but apparently one reason to use grep
instead of -C is portability.
Its described in the man page for FreeBSD ps,
https://man.freebsd.org/cgi/man.cgi?ps(1), as:
-C Change the way the CPU percentage is calculated by >>> using a
"raw" CPU calculation that ignores "resident" time (this nor- >>> mally has no effect).
so maybe you're running FreeBSD instead of the OpenBSD version.
I'm pretty sure I know which version of BSD I'm running and I would be
very surprised if OpenBSD would ship the FreeBSD version of ps...
But let's have a look at the source:
#v+
while ((ch = getopt(argc, argv,
"AaCcefgHhjkLlM:mN:O:o:p:rSTt:U:uvW:wx")) != -1)
switch (ch) {
case 'A':
all = 1;
xflg = 1;
break;
case 'a':
all = 1;
break;
case 'C':
break; /* no-op */
#v-
'-C' does nothing. I did not look further to see where that error is
coming from.
The error message also is printed, when you run ps with a valid
flag plus some string, like `ps -a xyz´, so it seems to be independent
of the `-C´-option. Maybe it has to do with parsing of the old-style
flags vs. the dashed ones.
Regards
Joerg Mertens <joerg-mertens@t-online.de> wrote:
Rene Kita <mail@rkta.de> wrote:
I'm pretty sure I know which version of BSD I'm running and I would be
very surprised if OpenBSD would ship the FreeBSD version of ps...
But let's have a look at the source:
#v+
while ((ch = getopt(argc, argv,
"AaCcefgHhjkLlM:mN:O:o:p:rSTt:U:uvW:wx")) != -1)
switch (ch) {
case 'A':
all = 1;
xflg = 1;
break;
case 'a':
all = 1;
break;
case 'C':
break; /* no-op */
#v-
'-C' does nothing. I did not look further to see where that error is
coming from.
The error message also is printed, when you run ps with a valid
flag plus some string, like `ps -a xyz´, so it seems to be independent
of the `-C´-option. Maybe it has to do with parsing of the old-style
flags vs. the dashed ones.
You got me curious and I got my debugger out for my morning coffee.
The error message comes from a function kvm_openfiles, which is called
after the flag parsing is done. From a quick glance, this function takes
what looks like three file names. If the second one is NULL, it will
default to /dev/mem. Trying to open /dev/mem it will error out - which
could be due to me being on a VPS.
While the man page mentions kvm(3) in the SEE ALSO section, there is no mentioning nor explanation what additional arguments can be passed to
ps.
$ ps -C ksh
ps: /dev/mem: Permission denied'
The error message also is printed, when you run ps with a valid
flag plus some string, like `ps -a xyz´, so it seems to be independent
of the `-C´-option. Maybe it has to do with parsing of the old-style
flags vs. the dashed ones.
Dunno what to make out of it, but apparently one reason to use grep
instead of -C is portability.
Dunno what to make out of it, but apparently one reason to use grep
instead of -C is portability.
ps(1)'s arguments are not portable in practice anyway.
I'll just quote the OpenBSD man page:
------------------->
STANDARDS
The ps utility is compliant with the IEEE Std 1003.1-2008
("POSIX.1") specification, except that the flag [-G] is unsupported
and the flags [-ptU] support only single arguments, not lists.
The flags [-defglnu] are marked by IEEE Std 1003.1-2008 ("POSIX.1")
as being an X/Open System Interfaces option. Of these, [-dfgn] are
not supported by this implementation of ps; behaviour for the flags
[-elu] differs between this implementation and the X/Open System
Interfaces option of IEEE Std 1003.1-2008 ("POSIX.1").
You can find the relevant commit message under http://cvsweb.openbsd.org/src/bin/ps/ps.c ...
Rene Kita <mail@rkta.de> wrote:[...]
Joerg Mertens <joerg-mertens@t-online.de> wrote:
The error message also is printed, when you run ps with a valid
flag plus some string, like `ps -a xyz´, so it seems to be independent
of the `-C´-option. Maybe it has to do with parsing of the old-style
flags vs. the dashed ones.
You got me curious and I got my debugger out for my morning coffee.
The error message comes from a function kvm_openfiles, which is called
after the flag parsing is done. From a quick glance, this function takes
what looks like three file names. If the second one is NULL, it will
default to /dev/mem. Trying to open /dev/mem it will error out - which
could be due to me being on a VPS.
While the man page mentions kvm(3) in the SEE ALSO section, there is no
mentioning nor explanation what additional arguments can be passed to
ps.
As I understand it, `ps´ can not only be used to examine the processes
of your currently running system, but also those of another system represented by an image file. Normally you would use the `N´ option
plus a filename to tell ps to do this, but the original way seems to
have been to just add the filename to the commandline as an additional argument.
Now when you call `ps xy´, the argument xy is interpreted as a string
of old style options which can be written without dashes. Some
people still write `ps aux´ for example to look at their processes.
But when you write `ps a xy´ (or `ps -a xy´), xy is interpreted as
a "kernel image to be examined" (see the first argument to
kvm_openfiles(3)), which leads to the `permission denied´ error.
To get back to the `-C´ option - it is there for compatibility
reasons with old scripts. You can find the relevant commit message
under http://cvsweb.openbsd.org/src/bin/ps/ps.c when you search for the string `-C´.
On 2024-08-03, Joerg Mertens <joerg-mertens@t-online.de> wrote:[...]
[OpenBSD ps(1)]
$ ps -C ksh
ps: /dev/mem: Permission denied'
The error message also is printed, when you run ps with a valid
flag plus some string, like `ps -a xyz´, so it seems to be independent
of the `-C´-option. Maybe it has to do with parsing of the old-style
flags vs. the dashed ones.
A quick look at the options parsing shows that
ps xxx [yyy [zzz]]
is equivalent to
ps -N xxx [-M yyy [-W zzz]]
On Sun, 4 Aug 2024 13:01:25 +0200, Joerg Mertens wrote:
You can find the relevant commit message under
http://cvsweb.openbsd.org/src/bin/ps/ps.c ...
Why are they still using CVS? And not HTTPS?
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 4 Aug 2024 13:01:25 +0200, Joerg Mertens wrote:
You can find the relevant commit message under
http://cvsweb.openbsd.org/src/bin/ps/ps.c ...
Why are they still using CVS? And not HTTPS?
I know that both topics have been discussed on the OpenBSD `misc
mailing list (probably more than once) but this was some time ago
and I did not pay much attention. If you search the list archive
you should be able to find some answers.
http://cvsweb.openbsd.org/src/bin/ps/ps.c ...
Why are they still using CVS? And not HTTPS?
Another useful command to use with ps is pgrep(1) <https://man7.org/linux/man-pages/man1/pgrep.1.html>
On Sat, 27 Jul 2024 00:40:49 -0000 (UTC), I wrote:
Another useful command to use with ps is pgrep(1)
<https://man7.org/linux/man-pages/man1/pgrep.1.html>
If you are expecting more than one process to match your criteria, it
is easy enough to use the ???-d,??? option to comma-separate them. Then the output becomes acceptable to the ???-p??? option in ps, e.g.
ps -p$(pgrep -d, bash) -wwo pid,ppid,lstart,tty,etime,cmd
to report all the bash sessions I have running (quite a lot). The ???ww??? says not to truncate the output, which is handy for long command lines.
Or just use ps -C <command>:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:[...]
On Sat, 27 Jul 2024 00:40:49 -0000 (UTC), I wrote:
[...]ps -p$(pgrep -d, bash) -wwo pid,ppid,lstart,tty,etime,cmd
to report all the bash sessions I have running (quite a lot). The ???ww??? >> says not to truncate the output, which is handy for long command lines.
Or just use ps -C <command>:
Does noone know about -C? I keep seeing things like 'ps -ef | grep <something> in scripts to see if <something is running, rather than
using 'ps -C'.
JerryRene