Re: [PATCH] Fix typo in ed(1) manpage

2022-06-21 Thread Ingo Schwarze
Hi Jason, Jason McIntyre wrote on Sun, Jun 19, 2022 at 06:51:26AM +0100: > On Sat, Jun 18, 2022 at 11:17:43PM +, S M wrote: >> Sending a separate patch as this is unrelated to my previous e-mail. > fixed, thanks. Thanks. > i note that the same text is present in regress/usr.bin/diff/t11.1

Re: [PATCH] man - apmd(8) reference

2022-06-19 Thread Ingo Schwarze
Hi, wdaver wrote on Sun, Jun 19, 2022 at 02:09:06PM -0700: > Ah - mangl returns Whoa, i wasn't even aware that "mangl" exists, but it appears it does exist and we even have a port for it: sysutils/mangl. It isn't very happy on my machine, though: schwarze@isnote $ mangl mangl

Re: apmd(8): reconnecting AC, not battery

2022-05-28 Thread Ingo Schwarze
Hi Jason, Jason McIntyre wrote on Sat, May 28, 2022 at 05:10:08PM +0100: > On Sat, May 28, 2022 at 10:34:35AM +0100, Stuart Henderson wrote: >> On 2022/05/28 06:52, Jason McIntyre wrote: >>> On Fri, May 27, 2022 at 07:19:37PM +0200, Jan Stary wrote: apmd says: When the power

Re: bwfm(4): show modulation type for the various chipsets

2022-04-23 Thread Ingo Schwarze
Hi Stuart, Stuart Henderson wrote on Sat, Apr 23, 2022 at 06:52:46PM +0100: > saves time if you want to ignore 11n-only devices. ok? Adding useful information is good in general, but i can't really comment on the content. If you add a column to a -column list, usually you also want to update

Re: Security support status of xnf(4) and xbf(4)

2022-03-26 Thread Ingo Schwarze
Hi Demi Marie, Demi Marie Obenour wrote on Fri, Mar 25, 2022 at 12:13:59PM -0400: > Linux’s netfront and blkfront drivers recently had a security > vulnerability (XSA-396) that allowed a malicious backend to potentially > compromise them. In follow-up audits, I found that OpenBSD’s xnf(4) >

Re: __read_mostly

2022-03-20 Thread Ingo Schwarze
Hi, >> A downside of this is that it becomes easier to guess the addresses >> of the tagged variables. > No kidding. It partly undoes the effort of KARL. I don't feel qualified to comment on the patch, but i can't resist mentioning that i still love tedu@'s classical dictum "attack

Re: mandoc.1: update example to reflect current options

2022-02-08 Thread Ingo Schwarze
Hello Anders, Anders Damsgaard wrote on Tue, Feb 08, 2022 at 08:36:11AM +0100: > The mandoc(1) option alias -l for -a was removed from the documentation > in revision 1.107: > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/mandoc.1.diff?r1=1.106=1.107 > > The -l option still

Re: rev(1): pull MB_CUR_MAX out of the hot loop

2022-01-12 Thread Ingo Schwarze
ert@ for his feedback. Ingo > On Sun, 2022-01-09 at 00:45 +0100, Ingo Schwarze wrote: >> Index: rev.c >> === >> RCS file: /cvs/src/usr.bin/rev/rev.c,v >> retrieving revision 1.13 >> diff -u -p -r1.

Re: rev(1): pull MB_CUR_MAX out of the hot loop

2022-01-08 Thread Ingo Schwarze
Oopsie... Ingo Schwarze wrote on Sun, Jan 09, 2022 at 12:45:27AM +0100: > # Demonstate broken error handling in the old code. > >$ ./obj/wrap /obin/rev >$ echo $? > 42 Stupid me, this is what i meant, of course: $ ./obj/wrap /oldbi

Re: rev(1): pull MB_CUR_MAX out of the hot loop

2022-01-08 Thread Ingo Schwarze
Hi, Martijn van Duren wrote on Sat, Jan 08, 2022 at 08:30:20AM +0100: > Why not go for the following diff? > It has a comparable speed increase, but without the added complexity > of a second inner loop. Actually, i like the idea of not duplicating the loop, in cases where that is possible

Re: rev(1): pull MB_CUR_MAX out of the hot loop

2022-01-07 Thread Ingo Schwarze
Hi Scott, thank you for spending quite some work on our small utility programs, and sorry for failing to follow up as often as i should. Scott Cheloha wrote on Fri, Jan 07, 2022 at 09:45:41AM -0600: > In rev(1), we call MB_CUR_MAX for every byte in the input stream. > This is extremely

Re: rpki-client: check ipAddrBlock and autonomousSysNum for criticality

2021-12-25 Thread Ingo Schwarze
Hi Claudio, Claudio Jeker wrote on Sat, Dec 25, 2021 at 05:48:53PM +0100: > On Sat, Dec 25, 2021 at 11:36:50AM +0100, Theo Buehler wrote: >> These extensions MUST be marked critical by the sections of the spec >> mentioned in the cryptowarnx(). That's determined by the ASN1_BOOLEAN >> that is

Re: document patch(1) not supporting binary diffs

2021-12-21 Thread Ingo Schwarze
Hi Theo, Theo de Raadt wrote on Mon, Dec 20, 2021 at 10:37:00AM -0700: > Ingo Schwarze wrote: >> The patch(1) manual talks about "lines" throughout, >> and for binary files, a concept of "lines" does not even exist. > That is a bit strong. Some ut

Re: document patch(1) not supporting binary diffs

2021-12-21 Thread Ingo Schwarze
Jason McIntyre wrote on Mon, Dec 20, 2021 at 04:13:19PM +: > i'm ok with your diff Thanks for checking. > but it is slightly misleading in context of > reading from stdin. i suppose that is no biggie. I think i see why you say so. Speaking *formally*, what we usually do is describing what

Re: document patch(1) not supporting binary diffs

2021-12-20 Thread Ingo Schwarze
Hi Christopher, Christopher Zimmermann wrote on Mon, Dec 20, 2021 at 04:01:49PM +0100: > base patch cannot work with diffs of binary files. It might help to say > so in the manpage since other implementations do support this (ab)use of > patch. OK? I agree you are pointing out a slight

Re: Fix typo in '}' command in less.1

2021-12-10 Thread Ingo Schwarze
Hi Richard, Richard Ulmer wrote on Fri, Dec 10, 2021 at 04:04:11PM +0100: > this is just a minor copy-and-paste error fix for the less(1) man page. Committed, thank you. > I also contributed this upstream: https://github.com/gwsw/less/pull/228 > > I hope this is the right mailing list for

Re: Explicitly tag commands in vi(1)

2021-11-21 Thread Ingo Schwarze
Hi Simon, Simon Branch wrote on Sat, Nov 20, 2021 at 03:10:22PM -0800: > Here's a diff that adds explicit .Tg macros to vi(1), We don't want that: $ man -O tag=Tg mdoc [...] In most cases, adding a Tg macro would be redundant because mandoc(1) is able to automatically tag most

Re: diff: improve legibility of structs in several manpages

2021-11-20 Thread Ingo Schwarze
Hi Jan, sorry that i failed to look at this earlier. Even with your diff, the style is still not completely consistent. I think that inside .Bd -literal, the best style is exactly the same as in source code: structname{ typename; type*name; }; where * can be more than one tab if some of

Re: locale in expr(1)

2021-11-15 Thread Ingo Schwarze
Hi Marc, Marc Espie wrote on Mon, Nov 15, 2021 at 05:06:23PM +0100: > On Mon, Nov 15, 2021 at 03:43:47PM +0100, Jan Stary wrote: >> On Nov 10 18:46:08, h...@stare.cz wrote: >>> On Nov 10 18:15:44, h...@stare.cz wrote: expr(1) says expr1 {=, >, >=, <, <=, !=} expr2

Re: Typo in ASN1_STRING_length.3

2021-11-14 Thread Ingo Schwarze
Hi Matthias, Matthias Schmidt wrote on Sun, Nov 14, 2021 at 10:41:40AM +0100: > in the recent commit to ASN1_STRING_length.3 a typo sneaked in: Committed. Thank you for reading such patches and for reporting the error! Yours, Ingo > diff 96921f4986cebab89014f4b188cc00426e2e11d8 /usr/src >

Re: locale in who(1)

2021-11-10 Thread Ingo Schwarze
Hi, Martijn van Duren wrote on Wed, Nov 10, 2021 at 02:03:51PM +0100: > I see no reason to keep it. > OK martijn@ if anyone wants to commit this. Done. > On Wed, 2021-11-10 at 13:37 +0100, Jan Stary wrote: >> Why does who(1) need to setlocale()? On some systems, setlocale(LC_TIME) influences

Re: [patch] httpd static gzip compression

2021-11-05 Thread Ingo Schwarze
Hi Theo, Theo de Raadt wrote on Thu, Nov 04, 2021 at 08:27:47AM -0600: > prx wrote: >> On 2021/11/04 14:21, prx wrote: >>> The attached patch add support for static gzip compression. >>> >>> In other words, if a client support gzip compression, when "file" is >>> requested, httpd will check if

Re: uniq: add HISTORY section

2021-11-02 Thread Ingo Schwarze
Hi Todd, Todd C. Miller wrote on Tue, Nov 02, 2021 at 08:20:47AM -0600: > uniq appeared in research Unix version 3. OK schwarze@. If - like in this case - the indicated release is the first one in any system to ever contain the feature, and not just the first one among the direct ancestors of

Re: uniq(1): ignore newline when comparing lines?

2021-11-02 Thread Ingo Schwarze
Hi, Todd C. Miller wrote on Tue, Nov 02, 2021 at 08:12:00AM -0600: > On Mon, 01 Nov 2021 21:04:54 -0500, Scott Cheloha wrote: >> Yes it would be simpler. However I didn't want to start changing the >> input -- which we currently don't do -- without discussing it. >> >> The standard says we

Re: demystify vport(4) in vport(4) and ifconfig(8)

2021-10-29 Thread Ingo Schwarze
Hi Stuart, Stuart Henderson wrote on Fri, Oct 29, 2021 at 01:59:38PM +0100: > On 2021/10/29 14:08, Ingo Schwarze wrote: >> Stuart Henderson wrote on Fri, Oct 29, 2021 at 10:53:41AM +0100: >>> On 2021/10/28 23:19, Klemens Nanni wrote: >>>> On Fri, Oct 29, 2021 at 1

Re: demystify vport(4) in vport(4) and ifconfig(8)

2021-10-29 Thread Ingo Schwarze
Hi Stuart, Stuart Henderson wrote on Fri, Oct 29, 2021 at 10:53:41AM +0100: > On 2021/10/28 23:19, Klemens Nanni wrote: >> On Fri, Oct 29, 2021 at 12:57:54AM +0200, Ingo Schwarze wrote: >>> MANPAGER=firefox man -T html $(ifconfig -C) >> This doesn't work if fi

Re: demystify vport(4) in vport(4) and ifconfig(8)

2021-10-28 Thread Ingo Schwarze
Hi Klemens, Klemens Nanni wrote on Thu, Oct 28, 2021 at 11:19:30PM +: > On Fri, Oct 29, 2021 at 12:57:54AM +0200, Ingo Schwarze wrote: >> MANPAGER=firefox man -T html $(ifconfig -C) > This doesn't work if firefox is already running It is true that it sometimes works and som

Re: demystify vport(4) in vport(4) and ifconfig(8)

2021-10-28 Thread Ingo Schwarze
Hi, Sebastian Benoit wrote on Thu, Oct 28, 2021 at 11:05:54PM +0200: > We tend to forget that there are other output formats for manpages > as well. right now, i can got to https://man.openbsd.org/ifconfig and > jump from there to all of these manpages. With them removed, i can no > longer do

Re: Missing include in sys/device.h

2021-09-28 Thread Ingo Schwarze
Hi Rafael, Rafael Sadowski wrote on Tue, Sep 28, 2021 at 08:22:06AM +0200: > On Mon Sep 27, 2021 at 11:20:55PM -0600, Theo de Raadt wrote: >> Oh, like how about you try compiling a kernel after your proposed diff? >> >> in userland - >>size_t comes from sys/types.h >>or a header file

Re: Unwind + NSD usage question

2021-09-28 Thread Ingo Schwarze
Hello Paul, Paul de Weerd wrote on Tue, Sep 28, 2021 at 12:44:07PM +0200: > 'local-data-ptr:' in unbound.conf(5): > http://man.openbsd.org/unbound.conf#local~2 > http://man.openbsd.org/unbound.conf#local~3 heh, thank you for *both* of these bug reports, i'm adding them to the mandoc TODO file

Re: OpenBSD `ftp` port for MSVC (Windows)

2021-09-05 Thread Ingo Schwarze
Hi Samuel, first, note that this is off-topic on tech@. If you see a need to continue the thread, please move it to misc@. Samuel Marks wrote on Sun, Sep 05, 2021 at 02:10:14PM -0400: > WiP, basically just started this: >

Re: man sed(1) diff

2021-09-05 Thread Ingo Schwarze
Hello, i see where Ian's confusion is coming from, even though arguably, the existing text is accurate. But it is not a good idea to insert exceptions as parenthetic remarks in the middle of an enumeration of steps that is already somewhat long and complicated. I think it is better to explain

Re: timeout: Prettify man page and usage

2021-09-04 Thread Ingo Schwarze
Hi Jason, Jason McIntyre wrote on Sat, Sep 04, 2021 at 09:47:12PM +0100: > pretty damning that my ok is on that commit ;) > i'll try to remember... Heh. With the amount of work you are doing - your current commit count stands at 9113, on average 1.34 per day, during a time of over eightteen

Re: timeout: Prettify man page and usage

2021-09-04 Thread Ingo Schwarze
Hi Jason, Jason McIntyre wrote on Fri, Sep 03, 2021 at 02:46:47PM +0100: > On Fri, Sep 03, 2021 at 03:42:21PM +0200, Ingo Schwarze wrote: >> Theo de Raadt wrote on Thu, Sep 02, 2021 at 09:57:11AM -0600: >>> I think we should list shorts, and longs which have no shorts. >&

Re: mark getsubopt(3) as part of POSIX

2021-09-03 Thread Ingo Schwarze
Hi Theo, as you sent it, your patch is misleading since our manual page describes two features that are not required by POSIX. So i propose the larger patch shown below instead. While here, clarify what "null-terminated" means. It matters for this page in particular because the page talks

Re: timeout: Prettify man page and usage

2021-09-03 Thread Ingo Schwarze
Hi, Theo de Raadt wrote on Thu, Sep 02, 2021 at 09:57:11AM -0600: > I think we should list shorts, and longs which have no shorts. I agree, and i think we arrived at the same conclusion in the past. It applies to both usage() and SYNOPSIS, and ideally, both should match, except maybe in very

Re: rm.1: remove extraneous word

2021-09-03 Thread Ingo Schwarze
Hi Jason, Jason McIntyre wrote on Fri, Sep 03, 2021 at 07:47:19AM +0100: > On Thu, Sep 02, 2021 at 11:10:54PM +0100, Jason McIntyre wrote: >> i wonder if it was originally an attempt to not quote posix >> (or posix attempting to not quote bsd). posix refers to removing >> "directory entries",

Re: Atomic signal flags for vi(1)

2021-09-02 Thread Ingo Schwarze
Hi Tim, trondd wrote on Wed, Sep 01, 2021 at 08:46:28PM -0400: > Ingo Schwarze wrote: >> Ingo Schwarze wrote on Wed, Sep 01, 2021 at 04:38:51PM +0200: >>> Note that the h_hup() and h_term() signal handlers are still unsafe >>> after this commit because they also set t

Re: timeout: execvp(2) return is always an error

2021-09-02 Thread Ingo Schwarze
Hi Sebastien, Sebastien Marie wrote on Thu, Sep 02, 2021 at 09:09:43AM +0200: > If execvp(2) returns, it is always an error: there is no need to check > if the return value is -1. Just unconditionally call err(3). > > Comments or OK ? OK schwarze@ Ingo > timeout: execvp(2) should not

Re: Atomic signal flags for vi(1)

2021-09-01 Thread Ingo Schwarze
Hi, Ingo Schwarze wrote on Wed, Sep 01, 2021 at 04:38:51PM +0200: > Note that the h_hup() and h_term() signal handlers are still unsafe > after this commit because they also set the "killersig" (how fitting!) > field in a global struct. I like it when fixing two bugs on

Re: Atomic signal flags for vi(1)

2021-09-01 Thread Ingo Schwarze
Hi Tim, trondd wrote on Tue, Aug 24, 2021 at 07:45:33PM -0400: > "Theo de Raadt" wrote: >> +h_alrm(int signo) >> +{ >> + GLOBAL_CLP; >> + >> + F_SET(clp, CL_SIGALRM); >> >> F_SET is |=, which is not atomic. >> >> This is unsafe. Safe signal handlers need to make single stores to

Re: averse to lisp in base?

2021-08-29 Thread Ingo Schwarze
Hi, Tomasz Rola wrote on Sun, Aug 29, 2021 at 08:21:03PM +0200: > On Sun, Aug 29, 2021 at 03:27:27AM +0200, mayur...@kathe.in wrote: >> Would the core team consider including a minimalist lisp in the base? >> e.g. http://t3x.org/klisp/index.html [...] > If I would want to propose any Lisp into

Re: Atomic signal flags for vi(1)

2021-08-29 Thread Ingo Schwarze
Hi Theo, Theo de Raadt wrote on Sun, Aug 29, 2021 at 11:38:18AM -0600: > Ingo Schwarze wrote: >> *If* more than one GS object ever existed and/or the .gp pointers >> in different SCR objects could point to different GS objects, this >> patch might change behaviour.

Re: Atomic signal flags for vi(1)

2021-08-29 Thread Ingo Schwarze
Hi, Theo de Raadt wrote on Sun, Aug 29, 2021 at 02:54:57AM -0600: > This does look better. > > I appreciate that you are fixing this underlying problem first, before > overlaying your timer diff. Indeed. > Is this working for the vi crowd? *If* more than one GS object ever existed and/or the

Re: allow KARL with config(8)'d kernels

2021-08-29 Thread Ingo Schwarze
Hi, Theo de Raadt wrote on Sun, Aug 29, 2021 at 07:15:34AM -0600: > I am not thrilled with the name "kernel.conf". > It does not seem intuitively discoverable. What would be a canonical name? It is a command file for config(8). Note that the "config-file" for config is something else, and

Re: cal(1): Clean up mutually exclusive options

2021-08-16 Thread Ingo Schwarze
Hi Theo, Theo de Raadt wrote on Mon, Aug 16, 2021 at 08:15:03AM -0600: > Jason McIntyre wrote: >> well, in those cases i think the authors shared the viewpoint that >> mutually exclusive means you can;t mix them but in this case it is >> essentially not an error to do so, and so documented it

Re: cal(1): Clean up mutually exclusive options

2021-08-16 Thread Ingo Schwarze
Hi Jason, Jason McIntyre wrote on Mon, Aug 16, 2021 at 12:02:13PM +0100: > when i wrote my mail, i failed to understand that "overrides earlier" > was really just another way of saying "mutually exclusive". That is incorrect. This is what "mutually exclusive" means (without further

Re: cal(1): Clean up mutually exclusive options

2021-08-16 Thread Ingo Schwarze
Hi Theo, Theo de Raadt wrote on Sun, Aug 15, 2021 at 05:42:13PM -0600: > Is it really reasonable that we should strictly follow a non-applicable > standard in such rarely used non-standard utilities, Not strictly, no. Usefulness needs to be considered in individual cases. There is value in

Re: cal(1): Clean up mutually exclusive options

2021-08-16 Thread Ingo Schwarze
Hi Jason, Jason McIntyre wrote on Sun, Aug 15, 2021 at 11:30:05PM +0100: > can't we take a stance that where options override each other, > the last one wins? Yes, that is possible. Cases exist where one option overrides another and order does not matter - for example, "lock -n -t -1" is the

Re: cal(1): Clean up mutually exclusive options

2021-08-16 Thread Ingo Schwarze
Hi Martijn, Martijn van Duren wrote on Sun, Aug 15, 2021 at 11:40:49PM +0200: > To quote schwarze in the jot mutually exclusive thread: > On Fri, 2021-08-13 at 11:48 +0200, Ingo Schwarze wrote: >> In this case, even though this is not a POSIX command, POSIX utility >>

Re: fresh prompt after Ctrl-C in cdio(1)

2021-08-13 Thread Ingo Schwarze
Hi, Christian Weisgerber wrote on Thu, Aug 12, 2021 at 06:31:56PM +0200: > Ingo Schwarze: >> deraadt@ recently pointed out to me in private mail that it is good >> for usability if interactive programs providing line editing >> functionality are consistent what they do

Re: jot(1): make -b -c and -w mutually exclusive

2021-08-13 Thread Ingo Schwarze
Hi Martijn, Martijn van Duren wrote on Fri, Aug 13, 2021 at 08:51:42AM +0200: > So here's the first one: > - When -b is set, but followed by -w it doesn't remove the boring flag > and the -w is interpreted as a -b string I agree that can't be quite right. > - -c is defined as "This is an

Re: fresh prompt after Ctrl-C in cdio(1)

2021-08-12 Thread Ingo Schwarze
Hi Martijn, Martijn van Duren wrote on Thu, Aug 12, 2021 at 04:37:24PM +0200: > Maybe I've used cdio once or twice and I don't have a cd-player at hand > (at least connected to my workstation) to test this. So purely from code > inspection: You set the signal handler before entering el_gets and

fresh prompt after Ctrl-C in cdio(1)

2021-08-12 Thread Ingo Schwarze
Hi, deraadt@ recently pointed out to me in private mail that it is good for usability if interactive programs providing line editing functionality are consistent what they do with Ctrl-C, ideally discard the current input line and provide a fresh prompt. At least that is what bc(1), ftp(1),

libedit: stop playing hopeless games with FIONBIO

2021-08-11 Thread Ingo Schwarze
Hi, in its current state, the editline(3) library is completely unfit to work with non-blocking I/O. Neither the API nor the implementation are even designed for that purpose. I do have some candidate ideas to minimally extend the API - without adding any new functions - to also work with

Re: date -j and seconds since the Epoch

2021-08-11 Thread Ingo Schwarze
Hi, > ok gerhard@ Thanks for reporting, for the initial patch, and for checking the final one. This now committed. Yours, Ingo >> Index: date.c >> === >> RCS file: /cvs/src/bin/date/date.c,v >> retrieving revision 1.56 >> diff

Re: libedit: stop ignoring SIGINT

2021-08-09 Thread Ingo Schwarze
Hi Martijn, Martijn van Duren wrote on Mon, Aug 09, 2021 at 02:15:42PM +0200: > If we're stripping down fixio to a single function, why not > inline the whole thing? I deliberately tried to: 1. Keep patches that change behaviour as small as possible to make review as simple as possible

libedit: stop ignoring SIGINT

2021-08-09 Thread Ingo Schwarze
Hi, as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C. Fixing that without longjmp(3) requires making editline(3) better behaved. Currently, when read(2) from the terminal gets interrupted by a signal, editline(3) ignores the (first) signal and unconditionally calls read(2) a

Re: libedit: read__fixio cleanup

2021-08-09 Thread Ingo Schwarze
Hi Martijn, Martijn van Duren wrote on Mon, Aug 09, 2021 at 11:04:35AM +0200: > Btw, would there be any benefit to declare zero as const in this > context? I dont think so. At least according to the ioctl(2) manual page, FIONBIO expects an int * argument, not a const int *. Yours, Ingo

libedit: read__fixio cleanup

2021-08-08 Thread Ingo Schwarze
Hi, deraadt@ recently reported to me that the editline(3) library, while line editing is active - for example inside el_gets(3) - ignores the first SIGINT it receives, for example the the first Ctrl-C the user presses. I consider that a bug in the editline(3) library. Some programs, for example

Re: less(1): refreshing file of size 0 results in file being treated as a pipe

2021-08-07 Thread Ingo Schwarze
Hi, thank you for reporting this bug and for providing a patch to fix it. I just committed your patch. Also thanks to tb@ and deraadt@ for cross-checking the patch. Yours, Ingo user wrote on Thu, Aug 05, 2021 at 12:43:21AM -0500: > Oops, forgot that OpenBSD doesn't have ! capability in

Re: date -j and seconds since the Epoch

2021-08-06 Thread Ingo Schwarze
Hi, sorry for the afterthought, i just noticed that the Subject: line is misleading. This patch has nothing to do with -j. If -j is not specified, this patch changes the value passed to adjtime(2) or settimeofday(2), which arguably matters even more than something merely printed on stdout.

Re: date -j and seconds since the Epoch

2021-08-06 Thread Ingo Schwarze
Hi Gerhard and Bryan, Gerhard Roth wrote on Mon, Aug 02, 2021 at 10:36:05AM +0200: > Bryan Vyhmeister found a strange behavior in date(1): > > # date -f %s -j 1627519989 > Thu Jul 29 01:53:09 PDT 2021 > # date -u -f %s -j 1627519989 > Thu Jul 29 00:53:09 UTC 2021 > >

Re: less(1): refreshing file of size 0 results in file being treated as a pipe

2021-08-06 Thread Ingo Schwarze
Hi, after quite some head-scratching, i consider the following bug report legitimate: user wrote on Thu, Aug 05, 2021 at 12:43:21AM -0500: > On Thu, Aug 05, 2021 at 12:37:00AM -0500, user wrote: >> On Fri, Jul 23, 2021 at 11:15:59AM -0500, user wrote: >>> Less contains a hack to force files of

Re: time.3: miscellaneous cleanup and rewrites

2021-08-05 Thread Ingo Schwarze
Hi Scott, since i see this wasn't committed yet, it is OK schwarze@, too. Consider leaving the .Nd alone since both jmc@ and millert@ recommended that, and use "That version counted the time" in the HISTORY section as recommended by jmc@. I think you should indeed remove the sentence about

Re: Add versioned lib to system perl's @INC for non-packaged modules

2021-08-05 Thread Ingo Schwarze
Hi, thanks to sthen@ for providing more background! so the bottom line seems to be that, once the code changes are tested, committed, and prove stable and once people come round to it, moving the site manual page directories out of /usr/local/man/ and making them versioned in exactly the same

Re: Add versioned lib to system perl's @INC for non-packaged modules

2021-08-04 Thread Ingo Schwarze
Hi Andrew, Andrew Fresh wrote on Fri, Jul 30, 2021 at 05:34:40PM -0700: > On Sun, May 16, 2021 at 03:30:39PM -0700, Andrew Hewus Fresh wrote: >> There do appear to be some annoyances with still shared directories for >> man pages, in that if you install a CPAN module and then attempt to >>

Re: sleep.3: miscellaneous cleanup and rewrites

2021-07-29 Thread Ingo Schwarze
Hi Scott, Scott Cheloha wrote on Tue, Jul 27, 2021 at 05:15:09PM -0500: > On Mon, Jul 26, 2021 at 10:37:03AM -0600, Todd C. Miller wrote: >> On Mon, 26 Jul 2021 07:55:00 -0500, Scott Cheloha wrote: >>> Still wondering whether we need an Errors section to mention that >>> sleep(3) can set errno.

Re: nanosleep.2: miscellaneous cleanup

2021-07-21 Thread Ingo Schwarze
Hi Scott, Scott Cheloha wrote on Wed, Jul 21, 2021 at 11:02:00AM -0500: [ EFAULT ] > Given deraadt@'s response I'm just going to leave the existing > language. Fine with me. > I guess I will need to dig into it a bit. Finding the text of the > really early documents, prior to SUSv2, is

Re: nanosleep.2: miscellaneous cleanup

2021-07-21 Thread Ingo Schwarze
Hi Theo, Theo de Raadt wrote on Tue, Jul 20, 2021 at 08:14:20PM -0600: > Ingo Schwarze wrote: >> [EFAULT] foo points outside the process's allocated address space. >> >> But i don't really i like that. The word "allocated" makes me wonder >> because it

Re: nanosleep.2: miscellaneous cleanup

2021-07-20 Thread Ingo Schwarze
Hi Scott, Scott Cheloha wrote on Tue, Jul 20, 2021 at 05:20:16PM -0500: > The nanosleep.2 page could use some cleanup. Here's a bunch of fixes, > rewrites, etc. > > I've included my notes on the changes below. I have some (mostly > stylistic) questions in there, too. Thanks for explaining

Re: ualarm.3: cleanup

2021-07-01 Thread Ingo Schwarze
Hi, fair enough. When there are good reasons to not merge manual pages - in this case, causing confusion about types and encouraging type conversion, overflow, and truncation bugs, and alarm(3) and ualarm(3) not being part of the same subsystem in the first place (if i understand deraadt@

Re: ualarm.3: cleanup

2021-06-30 Thread Ingo Schwarze
Hi Scott, Scott Cheloha wrote on Wed, Jun 30, 2021 at 03:15:31PM -0500: > As it would turn out, there are not one, but *two* simplified > interfaces to setitimer(2). We just cleaned up the alarm(3) manpage, > but did you know there is also a ualarm(3) interface? I certainly didn't... :-) >

Re: Replace .Ar macros with .Fa in pledge.2

2021-06-30 Thread Ingo Schwarze
Hi Emil, Emil Engler wrote on Wed, Jun 30, 2021 at 07:09:27PM +0200: > The pledge.2 man-page makes use of the incorrect .Ar macro which is > not intended for manuals in section 2 as .Fa exists for that purpose. > Similar to 1.18 in /cvs/src/lib/libm/man/sqrt.3 Note that the pledge(2) manual

Re: More use of mdoc macros in sqrt.3

2021-06-29 Thread Ingo Schwarze
Hi Emil, Emil Engler wrote on Tue, Jun 29, 2021 at 03:41:31PM +0200: > This diff inserts an .Fa to the places where it belongs to as well > as an .Er for EDOM. This patch is completely correct and i just committed it. Thank you, Ingo > Index: lib/libm/man/sqrt.3 >

Re: mandoc style warning about text lines > 80 bytes

2021-06-27 Thread Ingo Schwarze
Hi Jason, Jason McIntyre wrote on Sat, Jun 26, 2021 at 06:55:44PM +0100: > i count mkhybrid as 3rd party. the man page is still old style, and has > only 2 commits in 20 years. if it is ours, it needs considerable work. Fair enough, you are probably right about that. > i have no strong

Re: Patch: ksh: fix input handling for 4 byte UTF-8 sequences

2021-06-27 Thread Ingo Schwarze
Hi Soeren, Soeren Tempel wrote on Mon, Jun 07, 2021 at 07:02:25PM +0200: > Nice, wasn't aware that you also had a patch ready. Yeah, that was due to the fact that we, as developers, often use the lists but sometimes also send comments and patches privately, to reduce the mail volume for

Re: Patch: ksh: fix input handling for 4 byte UTF-8 sequences

2021-06-27 Thread Ingo Schwarze
Hi Jeremie, Jeremie Courreges-Anglas wrote on Thu, Jun 03, 2021 at 11:17:08PM +0200: > On Wed, Jun 02 2021, Ingo Schwarze wrote: >> I'm also adding a few comments as suggested by jca@. Parsing of UTF-8 >> is less trivial than one might think, witnessed once again by the fac

mandoc style warning about text lines > 80 bytes

2021-06-26 Thread Ingo Schwarze
Hi Jason and Theo, Jason McIntyre wrote on Tue, Jun 22, 2021 at 06:37:27AM +0100: > On Tue, Jun 22, 2021 at 04:48:39AM +0200, Theo Buehler wrote: >> You have two overlong lines as indicated below. I would have thought >> that mandoc -Tlint complains about that, but apparently it doesn't have >>

Patch: ksh: fix input handling for 4 byte UTF-8 sequences

2021-06-02 Thread Ingo Schwarze
Hi, feeling hesitant to commit into ksh without at least one proper OK, i'm resending this patch here, sorry if i missed private feedback. What the existing code does: It tries to make sure that multi-byte UTF-8 characters get passed on by the shell without fragmentation, not one byte at time.

Re: mandoc: -Tlint: search /usr/local/man as well

2021-05-15 Thread Ingo Schwarze
Hi Klemens, Klemens Nanni wrote on Mon, Apr 05, 2021 at 09:33:13PM +0200: > On Mon, Apr 05, 2021 at 06:47:58PM +0200, Ingo Schwarze wrote: >> Klemens Nanni wrote on Sun, Apr 04, 2021 at 03:54:43PM +0200: >>> On Sun, Apr 04, 2021 at 03:42:03PM +0200, Tim van der Molen wrote: &

Re: wcwidth of soft hyphen

2021-04-05 Thread Ingo Schwarze
Hi, Martijn van Duren wrote on Thu, Apr 01, 2021 at 09:30:36AM +0200: > When it comes to these discussions I prefer to go back to the standards I would propose an even more rigorous stance: not only go back to the standards, but use whatever the Unicode data files (indirectly, via the Perl

Re: mandoc: -Tlint: search /usr/local/man as well

2021-04-05 Thread Ingo Schwarze
Hi, Klemens Nanni wrote on Sun, Apr 04, 2021 at 03:54:43PM +0200: > On Sun, Apr 04, 2021 at 03:42:03PM +0200, Tim van der Molen wrote: >> Doesn't mandoc -Tlint -Wstyle do what you want? > I don't think so. Oddly enough, `-Wstyle' does not do what I would > expect: it omits STYLE messages

Re: Patch for crypt(3) man page.

2021-01-27 Thread Ingo Schwarze
Hi, this page is a mess. It is full of unclear wordings, in some cases verging incorrect statements. At the same time, parts of it are wordy. Here is an attempt to start fixing it. I refrained from trying to explain $2a$ (as suggested by sthen@) or to document the missing bcrypt_gensalt(3) in

Re: man: help pagers recognise HTML files as such

2021-01-26 Thread Ingo Schwarze
Hi Klemens, Klemens Nanni wrote on Sat, Jan 16, 2021 at 10:31:49AM +0100: > On rare occasions I'd like to use the following idiom to read manuals in > browsers, mostly to better readability and navigation of long sections: > > MANPAGER=netsurf-gtk3 man -Thtml jq > > (jq(1) has lots of

Re: syspatch exit state

2020-12-07 Thread Ingo Schwarze
Hi Antoine, Antoine Jacoutot wrote on Mon, Dec 07, 2020 at 01:39:30PM +0100: > On Mon, Dec 07, 2020 at 01:30:55PM +0100, Ingo Schwarze wrote: >> Antoine Jacoutot wrote on Mon, Dec 07, 2020 at 01:01:27PM +0100: >>> I just tested this change and it seems to work: [...] >>

Re: syspatch exit state

2020-12-07 Thread Ingo Schwarze
Hello Antoine, Antoine Jacoutot wrote on Mon, Dec 07, 2020 at 01:01:27PM +0100: > I just tested this change and it seems to work: I did not repeat my testing, but here is some quick feedback purely from code inspection: The proposed code change makes sense to me. The proposed manual page text

Re: syspatch exit state

2020-12-07 Thread Ingo Schwarze
Hi Antoine, Antoine Jacoutot wrote on Mon, Dec 07, 2020 at 09:48:36AM +0100: > On Sun, Dec 06, 2020 at 10:52:37PM +0100, Alexander Hall wrote: >> On December 6, 2020 8:13:26 PM GMT+01:00, Antoine Jacoutot wrote: >>> On Sun, Dec 06, 2020 at 05:20:31PM +, Stuart Henderson wrote: On

Re: sio_open.3: clarify what sio_start() does

2020-11-28 Thread Ingo Schwarze
Hi Alexandre, Alexandre Ratchov wrote on Fri, Nov 27, 2020 at 07:05:27PM +0100: > this wording is shorter and more precise and complete. This looks good mdoc(7)-wise, so go ahead, but please consider the two nits below when committing. Yours, Ingo > Index: sio_open.3 >

Re: AUDIORECDEVICE environment variable in sndio lib

2020-11-17 Thread Ingo Schwarze
Hi Solene, sorry if i misunderstand because i did not fully follow the thread... Solene Rapenne wrote on Tue, Nov 17, 2020 at 07:36:38PM +0100: > I added the new variable after MIDIDEVICE in the ENVIRONMENT section > to keep order of appearance in the document. Usually, we order the

Re: Import seq(1) from FreeBSD

2020-11-17 Thread Ingo Schwarze
contain UTF-8 and it just works. No need to call setlocale(3) or inspect LC_*. Yours, Ingo Todd C. Miller wrote on Mon, Nov 16, 2020 at 10:08:08AM -0700: > On Mon, 16 Nov 2020 16:14:31 +0100, Ingo Schwarze wrote: >> are you really sure this is a good idea? The version you sent is

Re: Import seq(1) from FreeBSD

2020-11-16 Thread Ingo Schwarze
Hi Todd, are you really sure this is a good idea? The version you sent is wildly incompatible with GNU sed. So we add a non-standard utility that exhibits different behaviour on different systems even though a standard utility already exists for the purpose? Is this needed for porting work?

Re: accton(8) requires a reboot after being enabled

2020-11-03 Thread Ingo Schwarze
Hi Jason, Jason McIntyre wrote on Mon, Nov 02, 2020 at 05:29:37PM +: > - adding EXIT STATUS makes sense. i agree. So i added just the .Sh and .Ex lines. All the rest (both regarding "file" and "install") seems controversial and hardly worth have a long discussion, so i dropped all the

Re: accton(8) requires a reboot after being enabled

2020-11-02 Thread Ingo Schwarze
Hi Theo, Theo de Raadt wrote on Fri, Oct 30, 2020 at 12:10:41PM -0600: > Yes, that diff is a whole bunch of TOCTUO. > > If this was going to be changed, it should be in the kernel. > > But I don't know if it should be changed yet, which is why I asked > a bunch of questions. > > Stepping back

Re: accton(8) requires a reboot after being enabled

2020-10-30 Thread Ingo Schwarze
Hi Solene, Solene Rapenne wrote on Fri, Oct 30, 2020 at 06:34:09PM +0100: > Following diff changes accton(8) behavior. > > If the file given as parameter doesn't exists, accton will create it. > Then it will check the ownership and will make it root:wheel if > it's different. > > I added a

Re: accton(8) requires a reboot after being enabled

2020-10-30 Thread Ingo Schwarze
Hi Theo, Theo de Raadt wrote on Fri, Oct 30, 2020 at 09:59:09AM -0600: > With a careful reading of the current manual page, everything is there > and it is accurate. > > With an argument naming an existing file > > > Ok so let's create it with touch.

Re: [PATCH] Fix link in Porting Guide

2020-10-29 Thread Ingo Schwarze
Hi Martin, Martin Vahlensieck wrote on Wed, Oct 28, 2020 at 09:02:21PM +0100: > This refers to the libc function. Committed, thanks. > P.S.: I noticed that e.g. sysmerge(8) is mentioned like this but not a > link. Is this intentional? Probably not, i added a few more links while there.

Re: [PATCH] Mention unsupported stacking in softraid(4)

2020-10-25 Thread Ingo Schwarze
Hi Jeremie and Filippo, Jeremie Courreges-Anglas wrote on Sun, Oct 25, 2020 at 03:05:04PM +0100: > On Sun, Oct 25 2020, "Filippo Valsorda" wrote: >> Based on the text in faq14.html, but using the manpage language. > Makes sense. I'm not sure .Em is useful here, though. Indeed. We use .Em

Re: diff: fixing a few broken links on 68.html, and other minor things

2020-10-22 Thread Ingo Schwarze
Hi, Andras Farkas wrote on Wed, Oct 21, 2020 at 09:19:43PM -0400: > While reading 68.html I noticed some of the man page links pointed to > the man pages in the wrong section of the manual. (at least, given the > manual section numbers listed next to them in the 68.html text) > I decided to fix

Re: libexec/security: don't prune mount points

2020-10-11 Thread Ingo Schwarze
Hi Todd, Todd C. Miller wrote on Wed, Oct 07, 2020 at 09:36:33AM -0600: > The recent changes to the daily security script will result in it > not traversing file systems where the parent mount point is mounted > with options nodev,nosuid but the child is mounted with setuid > enabled. > > For

  1   2   3   4   5   6   7   8   9   10   >