One look at the man page for ps(1)
<https://manpages.debian.org/1/ps.1.en.html> and you see all the
different traditional option syntaxes it tries to be compatible with.
The BSD style doesn’t even prefix options with dashes, which can lead
to ambiguities and is best avoided. If this is what you’re used to,
try to wean yourself off it.

To list some useful info about all processes, you can do

ps -ef

or, for even more info, try

ps -eF

One thing I find annoying about this it reports less precision in
process start times for long-running processes. To get around this, you
can use a custom format. For example

ps -eo pid,ppid,lstart,tty,etime,cmd

shows some similar info to the default “-f” format, but always includes
start time and elapsed time to the nearest second, regardless of how
long the process has been running.

Another useful command to use with ps is pgrep(1)
<https://manpages.debian.org/1/pgrep.1.en.html>, which lets you filter
processes to get information for according to various criteria. Or you
could just use grep(1) on the output from ps, as I suspect a lot of
people do. ;)

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.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 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>:

ps -p$(pgrep -d, bash) -wwo pid,ppid,lstart,tty,etime,cmd
PID PPID STARTED TT ELAPSED CMD
1332 1327 Thu Jul 18 10:12:28 2024 pts/1 14-10:02:20 bash
2019 2018 Thu Jul 18 20:20:31 2024 pts/3 13-23:54:17 bash
2237 2236 Thu Jul 18 20:39:49 2024 pts/4 13-23:34:59 bash
10821 10820 Sat Jul 20 14:45:57 2024 pts/6 12-05:28:51 bash
20342 20341 Wed Jul 31 09:58:54 2024 pts/7 1-10:15:54 bash

ps -C bash -wwo pid,ppid,lstart,tty,etime,cmd
PID PPID STARTED TT ELAPSED CMD
1332 1327 Thu Jul 18 10:12:28 2024 pts/1 14-10:02:35 bash
2019 2018 Thu Jul 18 20:20:31 2024 pts/3 13-23:54:32 bash
2237 2236 Thu Jul 18 20:39:49 2024 pts/4 13-23:35:14 bash
10821 10820 Sat Jul 20 14:45:57 2024 pts/6 12-05:29:06 bash
20342 20341 Wed Jul 31 09:58:54 2024 pts/7 1-10:16:09 bash

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'.

Jerry

On Fri, 2 Aug 2024 00:19:58 -0000 (UTC), Jerry Peters wrote:

> Or just use ps -C <command>:

Neat. But note this <https://manpages.debian.org/1/ps.1.en.html>:

-C cmdlist
Select by command name. This selects the processes whose
executable name is given in cmdlist. NOTE: The command name is not
the same as the command line.

That might matter in some cases.

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,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'.

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.

> Jerry
Rene

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,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'.
>
> 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.

Using `-C` to select a command isn't supported by POSIX, GNU, FreeBSD,
OpenBSD, etc. so yes - portability would be a significant issue if you
relied on it in your scripts.

Ed.
>
>> Jerry
> Rene

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,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'.
>>
>> 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.

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,cmd
>>>>>
>>>>> 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'.
>>>
>>> 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

On Sat, 3 Aug 2024 15:51:12 -0000 (UTC), Rene Kita 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...

I wonder why they need different versions?

In article <v8m0ss$3jh1j$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>I wonder why they need different versions?

Illumos includes ps(1) and ps(1B)
<URL:https://illumos.org/man/1/ps>
<URL:https://illumos.org/man/1B/ps>

John
groenveld@acm.org

Joerg Mertens <joerg-mertens@t-online.de> wrote:
> 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,cmd
>>>>>>
>>>>>> 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'.
>>>>
>>>> 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.

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.

> Regards

Rene Kita <mail@rkta.de> wrote:
> 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.

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´.

Joerg

On 2024-08-03, Rene Kita <mail@rkta.de> wrote:

> 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.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

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]]

This has been unchanged since the initial fork from NetBSD in 1995.
Digging further, I see that this comes straight from 4.4BSD, and
that the -M, -N, -W flags were added in 1991 and the older argument
syntax was left in place for backward compatibility.

FreeBSD changed this twenty years ago and now treats additional
arguments as a list of PIDs.

A further complication, going back to 4.4BSD, is that the arguments
are run through a function kludge_oldps_options() before actual
argument parsing, again for backward compatibility:

ps foo -> ps -foo
ps 34 -> ps -p34

--
Christian "naddy" Weisgerber naddy@mips.inka.de

On 2024-08-04, Christian Weisgerber <naddy@mips.inka.de> wrote:

>> 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").

The flags [-cfHhjkLMmNOrSTvWwx] are extensions to IEEE Std 1003.1-2008
("POSIX.1").

Only the following keywords are recognised by IEEE Std 1003.1-2008
("POSIX.1"): args, comm, etime, group, nice, pcpu, pgid, pid, ppid,
rgroup, ruser, time, tty, user, and vsz.
<-------------------

--
Christian "naddy" Weisgerber naddy@mips.inka.de

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?

On Sun, 4 Aug 2024 12:55:27 -0000 (UTC), Christian Weisgerber wrote:

> 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").

Compare the Linux version <https://manpages.debian.org/1/ps.1.en.html>:

STANDARDS
This ps conforms to:

1 Version 2 of the Single Unix Specification
2 The Open Group Technical Standard Base Specifications, Issue 6
3 IEEE Std 1003.1, 2004 Edition
4 X/Open System Interfaces Extension [UP XSI]
5 ISO/IEC 9945:2003

Christian Weisgerber <naddy@mips.inka.de> wrote:
> 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]]
[...]

Thanks for this explanation. Might be worth to document this in the man
page.

Joerg Mertens <joerg-mertens@t-online.de> wrote:
> 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.

Guilty. :-)

> 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´.

That's what I thought. I was just surprised that it's not documented.
But the man page seems to be silent about all old style things. Looks
like it's by design.

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.

Regards

In article <v8r977$10rjj$1@jmertens.eternal-september.org>,
Joerg Mertens <joerg-mertens@t-online.de> wrote:
>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.

I think the whole point of the BSDs is to be retro.

If they wanted to be modern, they'd be Linux.

--
In Usenet, as in life, as you go through it, you will run into lots of nonsense.
Each time, you will have to decide from the following courses of action:
1) Argue with it or 2) Ignore it.
Experience shows that the later course is usually the best.

On 2024-08-04, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

>> http://cvsweb.openbsd.org/src/bin/ps/ps.c ...
>
> Why are they still using CVS? And not HTTPS?

The second question is counterfactual:
https://cvsweb.openbsd.org/

--
Christian "naddy" Weisgerber naddy@mips.inka.de