Re: make.1: Inconsistent whitespace

2021-11-11 Thread Jason McIntyre
On Thu, Nov 11, 2021 at 06:25:46PM +0100, Leon Fischer wrote:
> Some keywords in make(1)'s list of conditionals have extra spaces:
> 
>  .ifmake [!]target [operator target ...]
>  Test the target being built.
> 
>  .ifnmake [!] target [operator target ...]
>  Test the target being built.
> 

fixed, thanks.
jmc

> Index: make.1
> ===
> RCS file: /cvs/src/usr.bin/make/make.1,v
> retrieving revision 1.133
> diff -u -p -r1.133 make.1
> --- make.18 Mar 2021 06:20:50 -   1.133
> +++ make.111 Nov 2021 17:22:18 -
> @@ -1082,7 +1082,7 @@ Test the value of a variable.
>  Test the target being built.
>  .It Xo
>  .Ic .ifnmake
> -.Oo \&! Oc Ar target
> +.Oo \&! Oc Ns Ar target
>  .Op Ar operator target ...
>  .Xc
>  Test the target being built.
> @@ -1090,7 +1090,7 @@ Test the target being built.
>  Reverse the sense of the last conditional.
>  .It Xo
>  .Ic .elif
> -.Oo \&! Oc Ar expression
> +.Oo \&! Oc Ns Ar expression
>  .Op Ar operator expression ...
>  .Xc
>  A combination of
> 



Re: [PATCH] [src] share/man/man5/hostname.if.5 - nwid -> join

2021-11-11 Thread Jason McIntyre
On Thu, Nov 11, 2021 at 08:30:45PM +, Klemens Nanni wrote:
> On Thu, Nov 11, 2021 at 08:13:13PM +0000, Jason McIntyre wrote:
> > i don;t think this bit of text works well now because you say it runs
> > ifconfig 3 times then ... respectively. but you only list two things
> > (even though i understand dynamic config is two). since your text is
> > already clear, i'd omit ", respectively". or maybe say "inet4 and inet6
> > dynamic ..." to balance out the three times would be better.
> 
> Thanks, is this better?
> 
> 
> Index: hostname.if.5
> ===
> RCS file: /cvs/src/share/man/man5/hostname.if.5,v
> retrieving revision 1.77
> diff -u -p -r1.77 hostname.if.5
> --- hostname.if.5 17 Jul 2021 15:28:31 -  1.77
> +++ hostname.if.5 11 Nov 2021 20:30:05 -
> @@ -67,21 +67,13 @@ inet 10.0.0.1 255.255.255.0 10.0.0.255 d
>  Each line is processed separately and in order.
>  For example:
>  .Bd -literal -offset indent
> -nwid mynwid wpakey mywpakey
> +join mynwid wpakey mywpakey
>  inet6 autoconf
>  inet autoconf
>  .Ed
>  .Pp
> -would run ifconfig three times to set the
> -.Cm nwid
> -and
> -.Cm wpakey
> -of the interface,
> -the
> -.Sy AUTOCONF6
> -flag and the
> -.Sy AUTOCONF4
> -flag, respectively.
> +would run ifconfig three times to add a wireless network using WPA to the
> +join list and enable dynamic address configuration for IPv6 and IPv4.
>  .Sh STATIC ADDRESS CONFIGURATION
>  The following packed formats are valid for configuring network
>  interfaces with static addresses.
> 

bingo!

jmc



Re: [PATCH] [src] share/man/man5/hostname.if.5 - nwid -> join

2021-11-11 Thread Jason McIntyre
On Thu, Nov 11, 2021 at 08:01:37PM +, Klemens Nanni wrote:
> On Thu, Nov 11, 2021 at 05:48:24PM +, Stuart Henderson wrote:
> > On 2021/11/11 16:30, Klemens Nanni wrote:
> > > On Thu, Nov 11, 2021 at 04:11:10PM +, Raf Czlonka wrote:
> > > > Hello,
> > > > 
> > > > It seems like this has been missed in recent thread[0].
> > > > 
> > > > Not entirely sure whether the sentence "flows" any longer but here
> > > > it goes anyway.
> > > > 
> > > > [0] https://marc.info/?l=openbsd-tech=163507448118443=2
> > > 
> > > Thanks, I missed that!
> > > 
> > > > Index: share/man/man5/hostname.if.5
> > > > ===
> > > > RCS file: /cvs/src/share/man/man5/hostname.if.5,v
> > > > retrieving revision 1.77
> > > > diff -u -p -r1.77 hostname.if.5
> > > > --- share/man/man5/hostname.if.517 Jul 2021 15:28:31 -  
> > > > 1.77
> > > > +++ share/man/man5/hostname.if.511 Nov 2021 16:09:33 -
> > > > @@ -67,13 +67,13 @@ inet 10.0.0.1 255.255.255.0 10.0.0.255 d
> > > >  Each line is processed separately and in order.
> > > >  For example:
> > > >  .Bd -literal -offset indent
> > > > -nwid mynwid wpakey mywpakey
> > > > +join mynwid wpakey mywpakey
> > > >  inet6 autoconf
> > > >  inet autoconf
> > > >  .Ed
> > > >  .Pp
> > > >  would run ifconfig three times to set the
> > > > -.Cm nwid
> > > > +.Cm join
> > > >  and
> > > >  .Cm wpakey
> > > >  of the interface,
> > > 
> > > Maybe this reads better in general?
> > > 
> > > would run ifconfig three times to join a wireless network using WPA 
> > > and
> > > to set the AUTOCONF6 and AUTOCONF4 flags, respectively.
> > 
> > It is more "add a network to the join list", join implies that it's
> > connecting directly to that ssid (i.e. what "nwid" did).
> 
> Good point.
> Also no markup as per jmc.
> 
> OK?
> 
> 
> Index: hostname.if.5
> ===
> RCS file: /cvs/src/share/man/man5/hostname.if.5,v
> retrieving revision 1.77
> diff -u -p -r1.77 hostname.if.5
> --- hostname.if.5 17 Jul 2021 15:28:31 -  1.77
> +++ hostname.if.5 11 Nov 2021 20:00:45 -
> @@ -67,21 +67,13 @@ inet 10.0.0.1 255.255.255.0 10.0.0.255 d
>  Each line is processed separately and in order.
>  For example:
>  .Bd -literal -offset indent
> -nwid mynwid wpakey mywpakey
> +join mynwid wpakey mywpakey
>  inet6 autoconf
>  inet autoconf
>  .Ed
>  .Pp
> -would run ifconfig three times to set the
> -.Cm nwid
> -and
> -.Cm wpakey
> -of the interface,
> -the
> -.Sy AUTOCONF6
> -flag and the
> -.Sy AUTOCONF4
> -flag, respectively.
> +would run ifconfig three times to add a wireless network using WPA to the
> +join list and enable dynamic address configuration, respectively.
>  .Sh STATIC ADDRESS CONFIGURATION
>  The following packed formats are valid for configuring network
>  interfaces with static addresses.
> 

i don;t think this bit of text works well now because you say it runs
ifconfig 3 times then ... respectively. but you only list two things
(even though i understand dynamic config is two). since your text is
already clear, i'd omit ", respectively". or maybe say "inet4 and inet6
dynamic ..." to balance out the three times would be better.

jmc



Re: [PATCH] [src] share/man/man5/hostname.if.5 - nwid -> join

2021-11-11 Thread Jason McIntyre
On Thu, Nov 11, 2021 at 04:30:15PM +, Klemens Nanni wrote:
> On Thu, Nov 11, 2021 at 04:11:10PM +, Raf Czlonka wrote:
> > Hello,
> > 
> > It seems like this has been missed in recent thread[0].
> > 
> > Not entirely sure whether the sentence "flows" any longer but here
> > it goes anyway.
> > 
> > [0] https://marc.info/?l=openbsd-tech=163507448118443=2
> 
> Thanks, I missed that!
> 
> > Index: share/man/man5/hostname.if.5
> > ===
> > RCS file: /cvs/src/share/man/man5/hostname.if.5,v
> > retrieving revision 1.77
> > diff -u -p -r1.77 hostname.if.5
> > --- share/man/man5/hostname.if.517 Jul 2021 15:28:31 -  1.77
> > +++ share/man/man5/hostname.if.511 Nov 2021 16:09:33 -
> > @@ -67,13 +67,13 @@ inet 10.0.0.1 255.255.255.0 10.0.0.255 d
> >  Each line is processed separately and in order.
> >  For example:
> >  .Bd -literal -offset indent
> > -nwid mynwid wpakey mywpakey
> > +join mynwid wpakey mywpakey
> >  inet6 autoconf
> >  inet autoconf
> >  .Ed
> >  .Pp
> >  would run ifconfig three times to set the
> > -.Cm nwid
> > +.Cm join
> >  and
> >  .Cm wpakey
> >  of the interface,
> 
> Maybe this reads better in general?
> 
> would run ifconfig three times to join a wireless network using WPA and
> to set the AUTOCONF6 and AUTOCONF4 flags, respectively.
> 
> No need to explain lines command by command.  Keep it simple;  users
> must read ifconfig(8) anyway.
> 
> One might as well say to
> 
> ... and
> to enable automatic address configuration for IPv6 and IPv4, respectively.
> 
> Then we don't have the weird mix of conceptual words and technical bits,
> i.e. "connect to wifi" vs. "set if flags [they're picked up by network
> daemons, but we don't say which ones]".
> 
> DYNAMIC ADDRESS CONFIGURATION down below repeats all this, anyway.
> 
> Feedback? OK?
> 
> 
> Index: hostname.if.5
> ===
> RCS file: /cvs/src/share/man/man5/hostname.if.5,v
> retrieving revision 1.77
> diff -u -p -r1.77 hostname.if.5
> --- hostname.if.5 17 Jul 2021 15:28:31 -  1.77
> +++ hostname.if.5 11 Nov 2021 16:30:00 -
> @@ -67,21 +67,15 @@ inet 10.0.0.1 255.255.255.0 10.0.0.255 d
>  Each line is processed separately and in order.
>  For example:
>  .Bd -literal -offset indent
> -nwid mynwid wpakey mywpakey
> +join mynwid wpakey mywpakey
>  inet6 autoconf
>  inet autoconf
>  .Ed
>  .Pp
> -would run ifconfig three times to set the
> -.Cm nwid
> -and
> -.Cm wpakey
> -of the interface,
> -the
> -.Sy AUTOCONF6
> -flag and the
> -.Sy AUTOCONF4
> -flag, respectively.
> +would run ifconfig three times to
> +.Cm join
> +a wireless network using WPA
> +and enable dynamic address configuration, respectively.
>  .Sh STATIC ADDRESS CONFIGURATION
>  The following packed formats are valid for configuring network
>  interfaces with static addresses.
> 

hi.

i think this reads fine. i would not mark up "join" myself, but
whatever.

jmc



Re: Add missing .Dv in termios(4)

2021-11-09 Thread Jason McIntyre
On Tue, Nov 09, 2021 at 06:55:07AM -0800, Simon Branch wrote:
> Simple change to format this sentence correctly in non-terminal
> environments.
> 

fixed, thanks.
jmc

> diff --git share/man/man4/termios.4 share/man/man4/termios.4
> index dfb7609dd6f..89818ca46c2 100644
> --- share/man/man4/termios.4
> +++ share/man/man4/termios.4
> @@ -1011,7 +1011,7 @@ overflowing the input queue.
>  The precise conditions under which
>  .Dv STOP
>  and
> -START
> +.Dv START
>  characters are transmitted are implementation defined.
>  .Pp
>  If
> 



Re: diff: ipsec.conf(5), clarify "aes" accepts 128:256 bits

2021-11-03 Thread Jason McIntyre
On Wed, Nov 03, 2021 at 02:55:11PM +0900, YASUOKA Masahiko wrote:
> Hi,
> 
> On Tue, 2 Nov 2021 07:03:43 +0000
> Jason McIntyre  wrote:
> > On Tue, Nov 02, 2021 at 12:02:07PM +0900, YASUOKA Masahiko wrote:
> >> I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits.
> >> 
> >> sbin/ipsecctl/ike.c:
> >> 201 case ENCXF_AES:
> >> 202 enc_alg = "AES";
> >> 203 key_length = "128,128:256";
> >> 204 break;
> >> 
> >> 
> >> ok?
> >> 
> >> Clarify "aes" will accept keys which length is in 128:256 bits.
> >> 
> > 
> > i notice that the enc lists in ipsec.conf.5 and iked.conf.5 differ.
> > aren;t they supposed to be in sync?
> > 
> > for example, iked.conf.5 doesn;t mention "aes" or "aesctr". also the
> > *-gmac and *-gcm-12 discrepancy.
> 
> As for "aes", *only isakmpd(8)* supports "aes" keyword or having a
> range for the key length.  So there isn't need to sync it to
> iked.conf.5.
> 
> Also I belive "aesctr" is to support 160:288 range for key length, but
> the implemention doesn't seem to be completed.  I have another plan to
> handle this separately, then I'll update the man page.
> 
> 
> Other than the key length range, it seems there are some differences
> between iked.conf.5 and ipsec.conf.5.
> 
> 1. "-gcm-12" 
>missing this in ipsec.conf.5 is ok since isakmpd(8) doesn't support
>it yet.  (It is actually an alias ID for "-gcm" though.)
> 
> 2. "-gmac" and "null"
>iked.conf.5 has a separeted list for them to clarify they don't do
>encryption.  Applied the same to isakmpd.conf.5.
> 
> 3. "chacha20-poly1305"
>It is missing in ipsec.conf.5.
> 
> 4. explanation of "[IKE only]" or "[phase 2]"
>It is missing in ipsec.conf.5.  Copied the section from iked.conf
>and modified it.
> 
> 5. explanation of "keysize" for AES-CTR and so on
>The explanation in ipsec.conf.5 is better.  Copied that to
>iked.conf.5.
> 
> 6. "cast"
>ipsecctl(8) program doesn't support "cast" keyword actually,
>it supports "cast128" instead.  Correct "cast" to "cast128"
> 
> 
> ok?
> 

hi. tweaks inline. ok (and thanks) by me, but a technical ok would be good too.

> Index: sbin/iked/iked.conf.5
> ===
> RCS file: /cvs/src/sbin/iked/iked.conf.5,v
> retrieving revision 1.87
> diff -u -p -r1.87 iked.conf.5
> --- sbin/iked/iked.conf.5 26 Oct 2021 17:31:22 -  1.87
> +++ sbin/iked/iked.conf.5 3 Nov 2021 05:42:48 -
> @@ -998,9 +998,9 @@ keyword.
>  3DES requires 24 bytes to form its 168-bit key.
>  This is because the most significant bit of each byte is used for parity.
>  .Pp
> -The keysize of AES-CTR is actually 128-bit.
> +The keysize of AES-CTR can be 128, 192, or 256 bits.
>  However as well as the key, a 32-bit nonce has to be supplied.
> -Thus 160 bits of key material have to be supplied.
> +Thus 160, 224, or 288 bits of key material, respectively, have to be 
> supplied.
>  The same applies to AES-GCM, AES-GMAC and Chacha20-Poly1305,
>  however in the latter case the keysize is 256 bit.
>  .Pp
> Index: sbin/ipsecctl/ipsec.conf.5
> ===
> RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
> retrieving revision 1.160
> diff -u -p -r1.160 ipsec.conf.5
> --- sbin/ipsecctl/ipsec.conf.522 Oct 2021 12:30:54 -  1.160
> +++ sbin/ipsecctl/ipsec.conf.53 Nov 2021 05:42:49 -
> @@ -637,10 +637,10 @@ keyword:
>  The following cipher types are permitted with the
>  .Ic enc
>  keyword:
> -.Bl -column "aes-128-gmac" "Key Length" "Description" -offset indent
> +.Bl -column "chacha20-poly1305" "128-256 bits" "Description" -offset indent
>  .It Em "Cipher" Ta Em "Key Length" Ta ""
>  .It Li 3des Ta "168 bits" Ta ""
> -.It Li aes Ta "128 bits" Ta ""
> +.It Li aes Ta "128-256 bits" Ta ""
>  .It Li aes-128 Ta "128 bits" Ta ""
>  .It Li aes-192 Ta "192 bits" Ta ""
>  .It Li aes-256 Ta "256 bits" Ta ""
> @@ -651,21 +651,37 @@ keyword:
>  .It Li aes-128-gcm Ta "160 bits"

Re: diff: ipsec.conf(5), clarify "aes" accepts 128:256 bits

2021-11-02 Thread Jason McIntyre
On Tue, Nov 02, 2021 at 12:02:07PM +0900, YASUOKA Masahiko wrote:
> I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits.
> 
> sbin/ipsecctl/ike.c:
> 201 case ENCXF_AES:
> 202 enc_alg = "AES";
> 203 key_length = "128,128:256";
> 204 break;
> 
> 
> ok?
> 
> Clarify "aes" will accept keys which length is in 128:256 bits.
> 

i notice that the enc lists in ipsec.conf.5 and iked.conf.5 differ.
aren;t they supposed to be in sync?

for example, iked.conf.5 doesn;t mention "aes" or "aesctr". also the
*-gmac and *-gcm-12 discrepancy.

jmc

> Index: sbin/ipsecctl/ipsec.conf.5
> ===
> RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
> retrieving revision 1.160
> diff -u -p -r1.160 ipsec.conf.5
> --- sbin/ipsecctl/ipsec.conf.522 Oct 2021 12:30:54 -  1.160
> +++ sbin/ipsecctl/ipsec.conf.52 Nov 2021 02:58:13 -
> @@ -637,10 +637,10 @@ keyword:
>  The following cipher types are permitted with the
>  .Ic enc
>  keyword:
> -.Bl -column "aes-128-gmac" "Key Length" "Description" -offset indent
> +.Bl -column "aes-128-gmac" "128-256 bits" "Description" -offset indent
>  .It Em "Cipher" Ta Em "Key Length" Ta ""
>  .It Li 3des Ta "168 bits" Ta ""
> -.It Li aes Ta "128 bits" Ta ""
> +.It Li aes Ta "128-256 bits" Ta ""
>  .It Li aes-128 Ta "128 bits" Ta ""
>  .It Li aes-192 Ta "192 bits" Ta ""
>  .It Li aes-256 Ta "256 bits" Ta ""
> 



Re: diff: isakmpd.conf.5, clarify ANY can be used for some params

2021-11-02 Thread Jason McIntyre
On Tue, Nov 02, 2021 at 12:04:25PM +0900, YASUOKA Masahiko wrote:
> ok?
> 
> Clarify that ANY can be used for several parameters of IPsec transform.
> 
> Index: sbin/isakmpd/isakmpd.conf.5
> ===
> RCS file: /cvs/src/sbin/isakmpd/isakmpd.conf.5,v
> retrieving revision 1.135
> diff -u -p -r1.135 isakmpd.conf.5
> --- sbin/isakmpd/isakmpd.conf.5   17 Apr 2018 12:13:29 -  1.135
> +++ sbin/isakmpd/isakmpd.conf.5   2 Nov 2021 02:57:23 -
> @@ -726,7 +726,7 @@ See below.
>  Parameters for IPsec transform configuration
>  .Bl -tag -width Ds
>  .It Em AUTHENTICATION_ALGORITHM
> -The optional authentication algorithm in the case of this
> +The optional authentication algorithm or ANY in the case of this

hi.

i think it would be clearer to add a comma after "algorithm", like you
do below after "RFCs". it makes it clearer that only "ANY" relates to
"being an ESP transform", and not "the optional authentication
algorithm" as well.

otherwise ok by me.

jmc

>  being an ESP transform.
>  .It Em ENCAPSULATION_MODE
>  The encapsulation mode as given by the RFCs.
> @@ -745,7 +745,8 @@ List of lifetimes, each element is a
>  .Aq Sy Lifetime
>  section name.
>  .It Em TRANSFORM_ID
> -The transform ID as given by the RFCs.
> +The transform ID as given by the RFCs, or ANY to denote that any
> +transform proposed will be accepted.
>  .El
>  .It Aq Sy IPsec-ID
>  Parameters for IPsec ID configuration
> 



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

2021-10-28 Thread Jason McIntyre
On Thu, Oct 28, 2021 at 04:53:39PM +1000, David Gwynne wrote:
> 
> 
> > On 28 Oct 2021, at 15:35, Jason McIntyre  wrote:
> > 
> > On Thu, Oct 28, 2021 at 01:27:17PM +1000, David Gwynne wrote:
> >> 
> >>> that strategy does rely on individual driver docs saying upfront that
> >>> they can be created though, even if using create is not common. i wonder 
> >>> if
> >>> ifconfig already knows what it can create, and could maybe be more
> >>> helpful if "create" without an ifname gave a hint.
> >> 
> >> dlg@rpi3b trees$ ifconfig -C
> >> aggr bpe bridge carp egre enc eoip etherip gif gre lo mgre mpe mpip mpw 
> >> nvgre pair pflog pflow pfsync ppp pppoe svlan switch tap tpmr trunk tun 
> >> veb vether vlan vport vxlan wg
> >> 
> >> the "interface can be created paragraph" is in most of the manpages for
> >> these drivers, except for pair, pfsync, pppoe, and vether (and
> >> veb/vport). some of them could be improved, eg, bpe and switch.
> >> 
> > 
> > oops, missed that flag!
> 
> maybe the doco for "create" in ifconfig.8 should refer back to it too.
> 

good idea - this fits in nicely with stuart's proposal to not list every
device.

> 
> > i had thought maybe if there was such an option, we wouldn;t need the
> > "if can be created" blurb in every page. but i suppose we do need to say
> > it somewhere.
> 
> the driver manpages are in a weird place because they're supposed to be for 
> programmers, and the ifconfig manpage is for "operators". however, the driver 
> pages have the "theory of operation" for their interfaces. so you have the 
> high level theory in the driver manpage, the way 99% of use actually interact 
> with interfaces in ifconfig.8, and then you go back to the driver doco for 
> the low level programming detail. it's not the best sandwich.
> 

yep.

> > another issue is that the text is inconsistent across pages.
> 
> yeah, but that can be fixed easily.
> 

hopefully!

anyway, here' my proposal following your and sthen's advice.
ok?

jmc

Index: ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.377
diff -u -p -r1.377 ifconfig.8
--- ifconfig.8  27 Oct 2021 06:36:51 -  1.377
+++ ifconfig.8  28 Oct 2021 14:41:06 -
@@ -177,42 +177,9 @@ network.
 The default broadcast address is the address with a host part of all 1's.
 .It Cm create
 Create the specified network pseudo-device.
-At least the following devices can be created on demand:
-.Pp
-.Xr aggr 4 ,
-.Xr bpe 4 ,
-.Xr bridge 4 ,
-.Xr carp 4 ,
-.Xr egre 4 ,
-.Xr enc 4 ,
-.Xr eoip 4 ,
-.Xr etherip 4 ,
-.Xr gif 4 ,
-.Xr gre 4 ,
-.Xr lo 4 ,
-.Xr mgre 4 ,
-.Xr mpe 4 ,
-.Xr mpip 4 ,
-.Xr mpw 4 ,
-.Xr nvgre 4 ,
-.Xr pair 4 ,
-.Xr pflog 4 ,
-.Xr pflow 4 ,
-.Xr pfsync 4 ,
-.Xr ppp 4 ,
-.Xr pppoe 4 ,
-.Xr svlan 4 ,
-.Xr switch 4 ,
-.Xr tap 4 ,
-.Xr tpmr 4 ,
-.Xr trunk 4 ,
-.Xr tun 4 ,
-.Xr veb 4 ,
-.Xr vether 4 ,
-.Xr vlan 4 ,
-.Xr vport 4 ,
-.Xr vxlan 4 ,
-.Xr wg 4
+A list of devices which can be dynamically created may be shown with the
+.Fl C
+option.
 .It Cm debug
 Enable driver-dependent debugging code; usually, this turns on
 extra console error logging.



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

2021-10-27 Thread Jason McIntyre
On Thu, Oct 28, 2021 at 01:27:17PM +1000, David Gwynne wrote:
> 
> > that strategy does rely on individual driver docs saying upfront that
> > they can be created though, even if using create is not common. i wonder if
> > ifconfig already knows what it can create, and could maybe be more
> > helpful if "create" without an ifname gave a hint.
> 
> dlg@rpi3b trees$ ifconfig -C
> aggr bpe bridge carp egre enc eoip etherip gif gre lo mgre mpe mpip mpw nvgre 
> pair pflog pflow pfsync ppp pppoe svlan switch tap tpmr trunk tun veb vether 
> vlan vport vxlan wg
> 
> the "interface can be created paragraph" is in most of the manpages for
> these drivers, except for pair, pfsync, pppoe, and vether (and
> veb/vport). some of them could be improved, eg, bpe and switch.
> 

oops, missed that flag!

i had thought maybe if there was such an option, we wouldn;t need the
"if can be created" blurb in every page. but i suppose we do need to say
it somewhere.

another issue is that the text is inconsistent across pages.

jmc



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

2021-10-27 Thread Jason McIntyre
On Wed, Oct 27, 2021 at 10:12:35AM +0100, Stuart Henderson wrote:
> On 2021/10/27 17:44, David Gwynne wrote:
> > 
> > > benno@ suggested I look at vether(4) to adapt the text related to
> > > bridge(4) but I'm not sure how to rewrite it properly for veb(4).
> > 
> > i get that, but for a different reason. im too close to veb/vport, so i
> > think it's all very obvious.
> > 
> > maybe we could split the first paragraph into separate ones for veb
> > and vport, and flesh them out a bit. what is it about vport that
> > needs to be said?
> 
> I'm not so close to veb/vport (and haven't run into a situation to use
> it yet, though maybe I'll give it a try converting an etherip/ipsec
> bridge that I have). I think it's pretty obvious too, though I think
> people aren't grasping what "the network stack can be connected" means,
> would the diff below help? it feels a bit more like spelling things out
> than is usual for a manual page but maybe that's needed here.
> 
> for ifconfig I would be in favour of _not_ listing all the possible
> cloneable interface types that can be used with create, it's just another
> thing to get out of sync - maybe just a few of the common ones and tell
> the reader about ifconfig -C at that point.. "ifconfig create" barely
> seems necessary except possibly for tun/tap - for most interface types
> you are going to run another ifconfig command (like "ifconfig veb0 add
> em0") which creates the interface automatically anyway.
> 

hi.

i agree with staurt about "create": this list was once short and made
sense. now it just keeps going out of date, without providing any help
to the reader. i don;t want to stack diff on diff, but maybe once the
veb stuff is sorted i will zap the create list.

that strategy does rely on individual driver docs saying upfront that
they can be created though, even if using create is not common. i wonder if
ifconfig already knows what it can create, and could maybe be more
helpful if "create" without an ifname gave a hint.

anyway, to that end i'm ok with solene's diff.

i'm also ok with your diff, with one tweak:

> Index: veb.4
> ===
> RCS file: /cvs/src/share/man/man4/veb.4,v
> retrieving revision 1.2
> diff -u -p -r1.2 veb.4
> --- veb.4 23 Feb 2021 11:43:41 -  1.2
> +++ veb.4 27 Oct 2021 09:03:49 -
> @@ -28,20 +28,30 @@ The
>  .Nm veb
>  pseudo-device supports the creation of a single layer 2 Ethernet
>  network between multiple ports.
> -Ethernet interfaces are added to the bridge to be used as ports.
> +Ethernet interfaces are added to the
>  .Nm veb
> -takes over the operation of the interfaces that are added as ports
> -and uses them independently of the host network stack.
> -The network stack can be connected to the Ethernet network managed
> -by
> +bridge to be used as ports.
> +Unlike
> +.Xr bridge 4 ,
>  .Nm veb
> -by creating a
> +takes over the operation of the interfaces that are added as ports.
> +They are then independent of the host network stack; the individual

i think a colon would work better than a semi-colon here, since i think
the info after it is essentially an explainer of what independent means.

jmc

> +Ethernet ports no longer function as independent layer 3 devices
> +and cannot be configured with
> +.Xr inet 4
> +or
> +.Xr inet6 4
> +addresses themselves.
> +.Pp
> +The Ethernet network managed by
> +.Nm veb
> +can be connected to the network stack as a whole by creating a
>  .Nm vport
>  interface and attaching it as a port to the bridge.
>  From the perspective of the host network stack, a
>  .Nm vport
>  interface acts as a normal interface connected to an Ethernet
> -network.
> +network and can be configured with addresses.
>  .Pp
>  .Nm veb
>  is a learning bridge that maintains a table of Ethernet addresses
> 



Re: route.8: nameserver command is not resolvd(8) specific

2021-10-26 Thread Jason McIntyre
certainly ok by me.
jmc

On 26 October 2021 16:30:17 BST, Klemens Nanni  wrote:
>On Tue, Oct 26, 2021 at 04:06:20PM +0100, Jason McIntyre wrote:
>> On Tue, Oct 26, 2021 at 08:57:40AM -0600, Theo de Raadt wrote:
>> > Jason McIntyre  wrote:
>> > 
>> > > On Tue, Oct 26, 2021 at 12:21:52PM +, Klemens Nanni wrote:
>> > > > While designed to populate resolv.conf(5), there is nothing resolvd(8)
>> > > > specific about the route message route(8) sends.
>> > > > 
>> > > > At least unwind(8) consumes and acts upon it;  there might as well be
>> > > > other programs in ports that do such things, so describe it generically
>> > > > while going into required detail for our selected base daemons.
>> > > > 
>> > > > OK?
>> > > > 
>> > > > NB:  I'll fix unwind.conf(5) wrt. `route nameserver' separately.
>> > > > 
>> > > 
>> > > hi.
>> > > 
>> > > i think it sounds weird to talk about sending things without saying
>> > > where they're going. maybe there is a better word than send? maybe this
>> > > command is just recording, or specifying, or ...? i don;t have a good
>> > > grasp of the process here.
>> > 
>> > "to the route socket"
>> > 
>> > Maybe rather than 'send', does it explain things better to say 'broadcast',
>> > 
>> 
>> i think either saying to the route socket or broadcast are clear and
>> would read better.
>
>The latter is great, thanks.
>
>OK?
>
>
>Index: route.8
>===
>RCS file: /cvs/src/sbin/route/route.8,v
>retrieving revision 1.101
>diff -u -p -r1.101 route.8
>--- route.822 Oct 2021 18:31:12 -  1.101
>+++ route.826 Oct 2021 15:30:04 -
>@@ -169,11 +169,16 @@ only changes in that routing table will 
> .Ar interface
> .Op Ar address ...
> .Xc
>-Send a list of up to five nameserver address proposals to
>-.Xr resolvd 8 .
>+Broadcast a list of up to five nameserver address proposals.
>+.Pp
>+.Xr unwind 8
>+will learn them and act according to
>+.Xr unwind.conf 5 .
>+.Pp
> .Xr resolvd 8
> will replace all existing nameservers for the given interface in
> .Xr resolv.conf 5 .
>+.Pp
> If no
> .Ar address
> argument is given, a request to remove the nameservers previously entered for
>



Re: route.8: nameserver command is not resolvd(8) specific

2021-10-26 Thread Jason McIntyre
On Tue, Oct 26, 2021 at 08:57:40AM -0600, Theo de Raadt wrote:
> Jason McIntyre  wrote:
> 
> > On Tue, Oct 26, 2021 at 12:21:52PM +, Klemens Nanni wrote:
> > > While designed to populate resolv.conf(5), there is nothing resolvd(8)
> > > specific about the route message route(8) sends.
> > > 
> > > At least unwind(8) consumes and acts upon it;  there might as well be
> > > other programs in ports that do such things, so describe it generically
> > > while going into required detail for our selected base daemons.
> > > 
> > > OK?
> > > 
> > > NB:  I'll fix unwind.conf(5) wrt. `route nameserver' separately.
> > > 
> > 
> > hi.
> > 
> > i think it sounds weird to talk about sending things without saying
> > where they're going. maybe there is a better word than send? maybe this
> > command is just recording, or specifying, or ...? i don;t have a good
> > grasp of the process here.
> 
> "to the route socket"
> 
> Maybe rather than 'send', does it explain things better to say 'broadcast',
> 

i think either saying to the route socket or broadcast are clear and
would read better.

jmc

> 
> > > Index: route.8
> > > ===
> > > RCS file: /cvs/src/sbin/route/route.8,v
> > > retrieving revision 1.101
> > > diff -u -p -r1.101 route.8
> > > --- route.8   22 Oct 2021 18:31:12 -  1.101
> > > +++ route.8   26 Oct 2021 12:18:31 -
> > > @@ -169,11 +169,16 @@ only changes in that routing table will 
> > >  .Ar interface
> > >  .Op Ar address ...
> > >  .Xc
> > > -Send a list of up to five nameserver address proposals to
> > > -.Xr resolvd 8 .
> > > +Send a list of up to five nameserver address proposals.
> > > +.Pp
> > > +.Xr unwind 8
> > > +will learn them and act according to
> > > +.Xr unwind.conf 5 .
> > > +.Pp
> > >  .Xr resolvd 8
> > >  will replace all existing nameservers for the given interface in
> > >  .Xr resolv.conf 5 .
> > > +.Pp
> > >  If no
> > >  .Ar address
> > >  argument is given, a request to remove the nameservers previously 
> > > entered for
> > > 
> > 
> 



Re: route.8: nameserver command is not resolvd(8) specific

2021-10-26 Thread Jason McIntyre
On Tue, Oct 26, 2021 at 12:21:52PM +, Klemens Nanni wrote:
> While designed to populate resolv.conf(5), there is nothing resolvd(8)
> specific about the route message route(8) sends.
> 
> At least unwind(8) consumes and acts upon it;  there might as well be
> other programs in ports that do such things, so describe it generically
> while going into required detail for our selected base daemons.
> 
> OK?
> 
> NB:  I'll fix unwind.conf(5) wrt. `route nameserver' separately.
> 

hi.

i think it sounds weird to talk about sending things without saying
where they're going. maybe there is a better word than send? maybe this
command is just recording, or specifying, or ...? i don;t have a good
grasp of the process here.

jmc

> Index: route.8
> ===
> RCS file: /cvs/src/sbin/route/route.8,v
> retrieving revision 1.101
> diff -u -p -r1.101 route.8
> --- route.8   22 Oct 2021 18:31:12 -  1.101
> +++ route.8   26 Oct 2021 12:18:31 -
> @@ -169,11 +169,16 @@ only changes in that routing table will 
>  .Ar interface
>  .Op Ar address ...
>  .Xc
> -Send a list of up to five nameserver address proposals to
> -.Xr resolvd 8 .
> +Send a list of up to five nameserver address proposals.
> +.Pp
> +.Xr unwind 8
> +will learn them and act according to
> +.Xr unwind.conf 5 .
> +.Pp
>  .Xr resolvd 8
>  will replace all existing nameservers for the given interface in
>  .Xr resolv.conf 5 .
> +.Pp
>  If no
>  .Ar address
>  argument is given, a request to remove the nameservers previously entered for
> 



Re: misspellings in i386/amd64 conf/GENERIC

2021-10-25 Thread Jason McIntyre
On Mon, Oct 25, 2021 at 04:37:16PM +0200, Janne Johansson wrote:
> (Reported by Elyes Haouas on irc)
> 
> gmail probably will mangle the diff, but the replacement is quite simple.
> 

ok.
jmc

> 
> Index: amd64/conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
> retrieving revision 1.503
> diff -u -p -u -r1.503 GENERIC
> --- amd64/conf/GENERIC  21 Oct 2021 18:36:42 -  1.503
> +++ amd64/conf/GENERIC  25 Oct 2021 14:33:55 -
> @@ -110,7 +110,7 @@ kate*   at pci? # AMD K8 temperature 
> sen
>  km*at pci? # AMD K10 temperature sensor
>  ksmn*  at pci? # AMD K17 temperature sensor
>  amas*  at pci? disable # AMD memory configuration
> -pchtemp* at pci?   # Intel C610 termperature sensor
> +pchtemp* at pci?   # Intel C610 temperature sensor
>  ccp*   at pci? # AMD Cryptographic Co-processor
> 
>  # National Semiconductor LM7[89] and compatible hardware monitors
> Index: i386/conf/GENERIC
> ==
> RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
> retrieving revision 1.858
> diff -u -p -u -r1.858 GENERIC
> --- i386/conf/GENERIC   21 Oct 2021 18:36:42 -  1.858
> +++ i386/conf/GENERIC   25 Oct 2021 14:33:55 -
> @@ -94,7 +94,7 @@ iic*  at glxpcib?
>  kate*  at pci? # AMD K8 temperature sensor
>  km*at pci? # AMD K10 temperature sensor
>  amas*  at pci? disable # AMD memory configuration
> -pchtemp* at pci?   # Intel C610 termperature sensor
> +pchtemp* at pci?   # Intel C610 temperature sensor
> 
>  # power management and other environmental stuff
>  elansc*at pci? # AMD Elan SC520 System Controller
> 
> 
> -- 
> May the most significant bit of your life be positive.
> 



Re: Add missing manpage for smtpd

2021-10-25 Thread Jason McIntyre
On Mon, Oct 25, 2021 at 04:12:17PM +0100, Larry Hynes wrote:
> Hi
> 
> Crystal Kolipe  wrote:
> > I sent this to bugs@ a while back, but it seems to have been missed.
> > 
> > smtpd-filters.7 is not installed by default.
> > 
> > --- usr.sbin/smtpd/smtpd/Makefile.dist  Wed Apr 21 04:54:10 2021
> > +++ usr.sbin/smtpd/smtpd/Makefile   Mon Oct 25 11:54:39 2021
> > @@ -76,7 +76,7 @@
> >  
> >  SRCS+= stat_ramstat.c
> >  
> > -MAN=   sendmail.8 smtpd.8 smtpd.conf.5 table.5
> > +MAN=   sendmail.8 smtpd-filters.7 smtpd.8 smtpd.conf.5 table.5
> >  BINDIR=/usr/sbin
> >  
> >  LDADD+=-levent -lutil -ltls -lssl -lcrypto -lz
> 
> Following discussions with jmc@ and gilles@ I'm doing some work on the
> English language on smtpd-filters.7 with a view to getting it installed.
> 

yep, we'll hold off until you get a chance to go over it.
jmc



Re: [patch] man page improvement for sem* family of functions

2021-10-23 Thread Jason McIntyre
On Fri, Oct 22, 2021 at 10:36:55PM +0300, Mikhail wrote:
> On Sat, Oct 16, 2021 at 03:13:39PM +0300, Mikhail wrote:
> > Hello, I was troubleshooting postgresql not being able to start after
> > 'pkill -6 postgres'. The error was:
> > 
> > FATAL: could not create semaphores: No space left on device
> > DETAIL: Failed system call was semget(78927, 17, 03600).
> > HINT: This error does *not* mean that you have run out of disk space. It
> > occurs when either the system limit for the maximum number of semaphore
> > sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS),
> > would be exceeded. You need to raise the respective kernel parameter.
> > Alternatively, reduce PostgreSQL's consumption of semaphores by reducing
> > its max_connections parameter. The PostgreSQL documentation contains
> > more information about configuring your system for PostgreSQL.
> > 
> > It would have saved me about half a day, if ipcs(1) was mentioned on
> > semget(2) man page, web is very short of information about SysV
> > semaphore management.
> > 
> > I thought about adding ipcrm(1) ref too, but decided that it's already
> > mentioned on ipcs(1) man page and it would be nice to keep things short,
> > but I can redo the patch, if it will be found useful at all.
> 
> It turns out that shmat(2) and shmdt(2) man page already mentions
> ipcrm(1) and ipcs(1), but it's not mentioned on shmctl(2) and sem*
> functions - inlined patch makes things even.
> 
> mandoc -T lint is passed.
> 
> Comments, OKs?
> 

fixed, thanks.
jmc

> diff --git lib/libc/sys/semctl.2 lib/libc/sys/semctl.2
> index b76b9812692..811270269b8 100644
> --- lib/libc/sys/semctl.2
> +++ lib/libc/sys/semctl.2
> @@ -235,5 +235,7 @@ or the values in
>  are greater than the system-imposed limit.
>  .El
>  .Sh SEE ALSO
> +.Xr ipcrm 1 ,
> +.Xr ipcs 1 ,
>  .Xr semget 2 ,
>  .Xr semop 2
> diff --git lib/libc/sys/semget.2 lib/libc/sys/semget.2
> index 7627e49549a..e06023d16f7 100644
> --- lib/libc/sys/semget.2
> +++ lib/libc/sys/semget.2
> @@ -147,6 +147,8 @@ and no semaphore set associated with
>  was found.
>  .El
>  .Sh SEE ALSO
> +.Xr ipcrm 1 ,
> +.Xr ipcs 1 ,
>  .Xr semctl 2 ,
>  .Xr semop 2 ,
>  .Xr ftok 3
> diff --git lib/libc/sys/semop.2 lib/libc/sys/semop.2
> index 691cb5b1b95..6b023207664 100644
> --- lib/libc/sys/semop.2
> +++ lib/libc/sys/semop.2
> @@ -152,5 +152,7 @@ was set in
>  points to an illegal address.
>  .El
>  .Sh SEE ALSO
> +.Xr ipcrm 1 ,
> +.Xr ipcs 1 ,
>  .Xr semctl 2 ,
>  .Xr semget 2
> diff --git lib/libc/sys/shmctl.2 lib/libc/sys/shmctl.2
> index 801c7cecbda..a272d1f482d 100644
> --- lib/libc/sys/shmctl.2
> +++ lib/libc/sys/shmctl.2
> @@ -185,6 +185,8 @@ is not a valid command.
>  specifies an invalid address.
>  .El
>  .Sh SEE ALSO
> +.Xr ipcrm 1 ,
> +.Xr ipcs 1 ,
>  .Xr shmat 2 ,
>  .Xr shmget 2
>  .Sh STANDARDS
> 



Re: [patch] man page improvement for sem* family of functions

2021-10-23 Thread Jason McIntyre
On Fri, Oct 22, 2021 at 10:36:55PM +0300, Mikhail wrote:
> On Sat, Oct 16, 2021 at 03:13:39PM +0300, Mikhail wrote:
> > Hello, I was troubleshooting postgresql not being able to start after
> > 'pkill -6 postgres'. The error was:
> > 
> > FATAL: could not create semaphores: No space left on device
> > DETAIL: Failed system call was semget(78927, 17, 03600).
> > HINT: This error does *not* mean that you have run out of disk space. It
> > occurs when either the system limit for the maximum number of semaphore
> > sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS),
> > would be exceeded. You need to raise the respective kernel parameter.
> > Alternatively, reduce PostgreSQL's consumption of semaphores by reducing
> > its max_connections parameter. The PostgreSQL documentation contains
> > more information about configuring your system for PostgreSQL.
> > 
> > It would have saved me about half a day, if ipcs(1) was mentioned on
> > semget(2) man page, web is very short of information about SysV
> > semaphore management.
> > 
> > I thought about adding ipcrm(1) ref too, but decided that it's already
> > mentioned on ipcs(1) man page and it would be nice to keep things short,
> > but I can redo the patch, if it will be found useful at all.
> 
> It turns out that shmat(2) and shmdt(2) man page already mentions
> ipcrm(1) and ipcs(1), but it's not mentioned on shmctl(2) and sem*
> functions - inlined patch makes things even.
> 
> mandoc -T lint is passed.
> 
> Comments, OKs?
> 

i think this is fine. are you asking for an ok because you are a
developer? if not i'll commit it unless i hear anyone object.

jmc

> diff --git lib/libc/sys/semctl.2 lib/libc/sys/semctl.2
> index b76b9812692..811270269b8 100644
> --- lib/libc/sys/semctl.2
> +++ lib/libc/sys/semctl.2
> @@ -235,5 +235,7 @@ or the values in
>  are greater than the system-imposed limit.
>  .El
>  .Sh SEE ALSO
> +.Xr ipcrm 1 ,
> +.Xr ipcs 1 ,
>  .Xr semget 2 ,
>  .Xr semop 2
> diff --git lib/libc/sys/semget.2 lib/libc/sys/semget.2
> index 7627e49549a..e06023d16f7 100644
> --- lib/libc/sys/semget.2
> +++ lib/libc/sys/semget.2
> @@ -147,6 +147,8 @@ and no semaphore set associated with
>  was found.
>  .El
>  .Sh SEE ALSO
> +.Xr ipcrm 1 ,
> +.Xr ipcs 1 ,
>  .Xr semctl 2 ,
>  .Xr semop 2 ,
>  .Xr ftok 3
> diff --git lib/libc/sys/semop.2 lib/libc/sys/semop.2
> index 691cb5b1b95..6b023207664 100644
> --- lib/libc/sys/semop.2
> +++ lib/libc/sys/semop.2
> @@ -152,5 +152,7 @@ was set in
>  points to an illegal address.
>  .El
>  .Sh SEE ALSO
> +.Xr ipcrm 1 ,
> +.Xr ipcs 1 ,
>  .Xr semctl 2 ,
>  .Xr semget 2
> diff --git lib/libc/sys/shmctl.2 lib/libc/sys/shmctl.2
> index 801c7cecbda..a272d1f482d 100644
> --- lib/libc/sys/shmctl.2
> +++ lib/libc/sys/shmctl.2
> @@ -185,6 +185,8 @@ is not a valid command.
>  specifies an invalid address.
>  .El
>  .Sh SEE ALSO
> +.Xr ipcrm 1 ,
> +.Xr ipcs 1 ,
>  .Xr shmat 2 ,
>  .Xr shmget 2
>  .Sh STANDARDS
> 



Re: pf.conf(5) & reply-to

2021-09-22 Thread Jason McIntyre
On Wed, Sep 22, 2021 at 10:38:14AM +0100, Stuart Henderson wrote:
> On 2021/09/22 11:28, Landry Breuil wrote:
> > Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a ?crit :
> > > Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200:
> > > > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote:
> > > > > did i screwup something somewhere in my config and there's a better 
> > > > > way
> > > > > for that ?
> > > > 
> > > > This was changed in February.  No more interface, but gateway
> > > > addresses.  It seems that some parts of the documentation were
> > > > missed.
> > > > 
> > > > > should the manpage be improved for reply-to and talk about 
> > > > > 'destination
> > > > > address' instead of 'interface' like route-to does ?
> > > > 
> > > > Yes.
> > > > 
> > > > It looks like most information is in the commit message.
> > > > https://marc.info/?l=openbsd-cvs=161213948819452=2
> > > 
> > > It's also on http://www.openbsd.org/faq/upgrade69.html
> > 
> > my english sucks and i'm not sure i got the meaning right, but here's a
> > try:
> > 
> > Index: pf.conf.5
> > ===
> > RCS file: /cvs/src/share/man/man5/pf.conf.5,v
> > retrieving revision 1.587
> > diff -u -r1.587 pf.conf.5
> > --- pf.conf.5   19 Jul 2021 16:23:56 -  1.587
> > +++ pf.conf.5   22 Sep 2021 09:23:14 -
> > @@ -1103,13 +1103,14 @@
> >  option is similar to
> >  .Cm route-to ,
> >  but routes packets that pass in the opposite direction (replies) to the
> > -specified interface.
> > +specified address.
> >  Opposite direction is only defined in the context of a state entry, and
> >  .Cm reply-to
> >  is useful only in rules that create state.
> >  It can be used on systems with multiple external connections to
> > -route all outgoing packets of a connection through the interface
> > -the incoming connection arrived through (symmetric routing enforcement).
> > +route all outgoing packets of a connection through the interface the 
> > incoming
> > +connection arrived through (symmetric routing enforcement) via the address 
> > of
> > +the gateway specified in the rule.
> 
> I think using "connection" twice (internet connection, and TCP/UDP/...\
> connection) can make this harder to read. Not 100% happy with this and
> I have to go out so won't do any more wordsmithing now, but maybe it
> gives some ideas?
> 
>   It can be used on systems with multiple paths to the internet to ensure
>   that replies to an incoming network connection to a particular address
>   are sent using the path associated with that address (symmetric routing
>   enforcement).
>   This is done by specifying the address of the gateway in "reply-to".
> 

this reads fine too, stuart.
jmc

> 
> 
> >  .It Cm route-to
> >  The
> >  .Cm route-to
> > 
> > i wouldnt know how to change the example in faq/upgrade69.html as it is 
> > valid
> > (but only specific to the case of a point-to-point interface with a :peer
> > property)
> > 
> > ccing experts :)
> > 



Re: pf.conf(5) & reply-to

2021-09-22 Thread Jason McIntyre
On Wed, Sep 22, 2021 at 11:28:21AM +0200, Landry Breuil wrote:
> Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a ?crit :
> > Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200:
> > > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote:
> > > > did i screwup something somewhere in my config and there's a better way
> > > > for that ?
> > > 
> > > This was changed in February.  No more interface, but gateway
> > > addresses.  It seems that some parts of the documentation were
> > > missed.
> > > 
> > > > should the manpage be improved for reply-to and talk about 'destination
> > > > address' instead of 'interface' like route-to does ?
> > > 
> > > Yes.
> > > 
> > > It looks like most information is in the commit message.
> > > https://marc.info/?l=openbsd-cvs=161213948819452=2
> > 
> > It's also on http://www.openbsd.org/faq/upgrade69.html
> 
> my english sucks and i'm not sure i got the meaning right, but here's a
> try:
> 
> Index: pf.conf.5
> ===
> RCS file: /cvs/src/share/man/man5/pf.conf.5,v
> retrieving revision 1.587
> diff -u -r1.587 pf.conf.5
> --- pf.conf.5 19 Jul 2021 16:23:56 -  1.587
> +++ pf.conf.5 22 Sep 2021 09:23:14 -
> @@ -1103,13 +1103,14 @@
>  option is similar to
>  .Cm route-to ,
>  but routes packets that pass in the opposite direction (replies) to the
> -specified interface.
> +specified address.
>  Opposite direction is only defined in the context of a state entry, and
>  .Cm reply-to
>  is useful only in rules that create state.
>  It can be used on systems with multiple external connections to
> -route all outgoing packets of a connection through the interface
> -the incoming connection arrived through (symmetric routing enforcement).
> +route all outgoing packets of a connection through the interface the incoming
> +connection arrived through (symmetric routing enforcement) via the address of

looking at "through the interface the incomming connection arrived
through". the double "through" sounds odd (but may be correct). would it
be better to say through the interface the incoming connection arrived
"on"? or just "through the interface of the incoming connection"?

i think "using" sounds better than "via"

i think a comma after "enforcement)" might make the sentence easier to
read

all of my points above are really just opinion. the diff reads ok.

jmc

> +the gateway specified in the rule.
>  .It Cm route-to
>  The
>  .Cm route-to
> 
> i wouldnt know how to change the example in faq/upgrade69.html as it is valid
> (but only specific to the case of a point-to-point interface with a :peer
> property)
> 
> ccing experts :)



Re: Update to pcap-filter.5/tcpdump.8 (was: update to tcpdump(8))

2021-09-05 Thread Jason McIntyre
On Sun, Sep 05, 2021 at 04:43:34PM +0200, Denis Fondras wrote:
> Le Sat, Sep 04, 2021 at 09:57:10PM +0100, Jason McIntyre a ?crit :
> > the diff looks ok to me. but run any doc changes through "mandoc
> > -Tlint", and look at any issues your diff may have introduced. in this
> > case it's just trailing whitespace, but it's super helpful to check your
> > work.
> > 
> 
> Thank you Jason. There is still a warning in tcpdump.8.
> 
> Here is a new version including changes to pcap-filter.5 and tcpdump.8
> I did not change the examples though as tcpdump examples are broader than
> filters.
> 

hi.

the warning in tcpdump is fine.

the diff reads ok to me, but let's wait for a technical ok ;)

jmc

> Index: lib/libpcap/pcap-filter.5
> ===
> RCS file: /cvs/src/lib/libpcap/pcap-filter.5,v
> retrieving revision 1.9
> diff -u -p -r1.9 pcap-filter.5
> --- lib/libpcap/pcap-filter.5 2 Sep 2021 10:59:13 -   1.9
> +++ lib/libpcap/pcap-filter.5 5 Sep 2021 13:35:41 -
> @@ -40,27 +40,31 @@ or
>  .Pp
>  The filter expression consists of one or more
>  .Em primitives .
> -Primitives usually consist of an ID (name or number)
> +Primitives usually consist of an
> +.Ar id
> +.Pq name or number
>  preceded by one or more qualifiers.
>  There are three different kinds of qualifier:
>  .Bl -tag -width "proto"
> -.It type
> -Type qualifiers say what kind of thing the ID name or number refers to.
> +.It Ar type
> +Specify which kind of address component the
> +.Ar id
> +name or number refers to.
>  Possible types are
>  .Cm host ,
> -.Cm net ,
> +.Cm net
>  and
>  .Cm port .
> -For example,
> +E.g.,
>  .Dq host foo ,
>  .Dq net 128.3 ,
> -and
>  .Dq port 20 .
>  If there is no type qualifier,
>  .Cm host
>  is assumed.
> -.It dir
> -Dir qualifiers specify a particular transfer direction to and/or from an ID.
> +.It Ar dir
> +Specify a particular transfer direction to and/or from
> +.Ar id .
>  Possible directions are
>  .Cm src ,
>  .Cm dst ,
> @@ -73,11 +77,13 @@ Possible directions are
>  .Cm addr3 ,
>  and
>  .Cm addr4 .
> -For example,
> -.Cm src foo ,
> -.Cm dst net 128.3 ,
> -.Cm src or dst port ftp-data .
> -If there is no dir qualifier,
> +E.g.,
> +.Dq src foo ,
> +.Dq dst net 128.3 ,
> +.Dq src or dst port ftp-data .
> +If there is no
> +.Ar dir
> +qualifier,
>  .Cm src or dst
>  is assumed.
>  The
> @@ -89,57 +95,85 @@ The
>  and
>  .Cm addr4
>  qualifiers are only valid for IEEE 802.11 Wireless LAN link layers.
> -For some link layers, such as SLIP and the "cooked" Linux capture mode
> -used for the "any" device and for some other device types, the
> +For null link layers (i.e., point-to-point protocols such as SLIP
> +.Pq Serial Line Internet Protocol
> +or the
> +.Xr pflog 4
> +header), the
>  .Cm inbound
>  and
>  .Cm outbound
>  qualifiers can be used to specify a desired direction.
> -.It proto
> -Proto qualifiers restrict the match to a particular protocol.
> -Possible
> -protos are:
> +.It Ar proto
> +Restrict the match to a particular protocol.
> +Possible protocols are:
> +.Cm ah ,
> +.Cm arp ,
> +.Cm atalk ,
> +.Cm decnet ,
> +.Cm esp ,
>  .Cm ether ,
>  .Cm fddi ,
> -.Cm tr ,
> -.Cm wlan ,
> +.Cm icmp ,
> +.Cm icmp6 ,
> +.Cm igmp ,
> +.Cm igrp ,
>  .Cm ip ,
>  .Cm ip6 ,
> -.Cm arp ,
> +.Cm lat ,
> +.Cm mopdl ,
> +.Cm moprc ,
> +.Cm pim ,
>  .Cm rarp ,
> -.Cm decnet ,
> +.Cm sca ,
> +.Cm stp ,
>  .Cm tcp ,
> +.Cm udp ,
>  and
> -.Cm udp .
> -For example,
> +.Cm wlan .
> +E.g.,
>  .Dq ether src foo ,
>  .Dq arp net 128.3 ,
>  .Dq tcp port 21 ,
>  and
>  .Dq wlan addr2 0:2:3:4:5:6 .
> -If there is no proto qualifier,
> +If there is no protocol qualifier,
>  all protocols consistent with the type are assumed.
> -For example,
> +E.g.,
>  .Dq src foo
>  means
> -.Dq (ip or arp or rarp) src foo
> -(except the latter is not legal syntax);
> +.Do
> +.Pq ip or arp or rarp
> +src foo
> +.Dc
> +.Pq except the latter is not legal syntax ;
>  .Dq net bar
>  means
> -.Dq (ip or arp or rarp) net bar ;
> +.Do
> +.Pq ip or arp or rarp
> +net bar
> +.Dc ;
>  and
>  .Dq port 53
>  means
> -.Dq (tcp or udp) port 53 .
> +.Do
> +.Pq TCP or UDP
> +port 53
> +.Dc .
>  .Pp
>  .Cm fddi
>  is actually an alias for
>  .Cm ether ;
>  the parser treats them identically as meaning
> -"the data link level used on the specified network interface".
> -FDDI headers contain Ethernet-like source 

Re: update to tcpdump(8)

2021-09-04 Thread Jason McIntyre
On Sat, Sep 04, 2021 at 07:26:21PM +0200, Denis Fondras wrote:
> Le Thu, Sep 02, 2021 at 08:36:06AM -0600, Theo de Raadt a ?crit :
> > I think the following approach will work.
> > 
> > 1. changes from tcpdump.8 -r1.00 to -rHEAD need merging into pcap-filter.5
> > 
> 
> Here is a diff for this step.
> 

hi.

the diff looks ok to me. but run any doc changes through "mandoc
-Tlint", and look at any issues your diff may have introduced. in this
case it's just trailing whitespace, but it's super helpful to check your
work.

> I have one question though.
> 
> tcpdump.8 has :
> " tcpdump does not currently know how to parse lat, moprc, or mopdl.  "
> 
> while pcap-filter.5 has :
> " Note that not all applications using pcap_open_live(3) currently know how to
> parse these protocols. "
> 
> Should I mention explicitely tcpdump(8) in pcap-filter.5 ? It seems implicit 
> in
> the current version.
> 

i guess it would be fine to have differences in the text where they made
sense. or you could try to write the sentence in a more general way,
that will make sense in both pages.

still, doesn;t the sentence in pcap-filter.5 also include tcpdump (as an
pllication using pcap_open_live, or at least a version of it)?

jmc

> Index: pcap-filter.5
> ===
> RCS file: /cvs/src/lib/libpcap/pcap-filter.5,v
> retrieving revision 1.9
> diff -u -p -r1.9 pcap-filter.5
> --- pcap-filter.5 2 Sep 2021 10:59:13 -   1.9
> +++ pcap-filter.5 4 Sep 2021 17:04:36 -
> @@ -40,27 +40,31 @@ or
>  .Pp
>  The filter expression consists of one or more
>  .Em primitives .
> -Primitives usually consist of an ID (name or number)
> +Primitives usually consist of an
> +.Ar id
> +.Pq name or number
>  preceded by one or more qualifiers.
>  There are three different kinds of qualifier:
>  .Bl -tag -width "proto"
> -.It type
> -Type qualifiers say what kind of thing the ID name or number refers to.
> +.It Ar type
> +Specify which kind of address component the
> +.Ar id
> +name or number refers to.
>  Possible types are
>  .Cm host ,
> -.Cm net ,
> +.Cm net
>  and
>  .Cm port .
> -For example,
> +E.g.,
>  .Dq host foo ,
>  .Dq net 128.3 ,
> -and
>  .Dq port 20 .
>  If there is no type qualifier,
>  .Cm host
>  is assumed.
> -.It dir
> -Dir qualifiers specify a particular transfer direction to and/or from an ID.
> +.It Ar dir
> +Specify a particular transfer direction to and/or from
> +.Ar id .
>  Possible directions are
>  .Cm src ,
>  .Cm dst ,
> @@ -73,11 +77,13 @@ Possible directions are
>  .Cm addr3 ,
>  and
>  .Cm addr4 .
> -For example,
> -.Cm src foo ,
> -.Cm dst net 128.3 ,
> -.Cm src or dst port ftp-data .
> -If there is no dir qualifier,
> +E.g.,
> +.Dq src foo ,
> +.Dq dst net 128.3 ,
> +.Dq src or dst port ftp-data .
> +If there is no
> +.Ar dir
> +qualifier,
>  .Cm src or dst
>  is assumed.
>  The
> @@ -89,55 +95,83 @@ The
>  and
>  .Cm addr4
>  qualifiers are only valid for IEEE 802.11 Wireless LAN link layers.
> -For some link layers, such as SLIP and the "cooked" Linux capture mode
> -used for the "any" device and for some other device types, the
> +For null link layers (i.e., point-to-point protocols such as SLIP
> +.Pq Serial Line Internet Protocol
> +or the
> +.Xr pflog 4
> +header), the
>  .Cm inbound
>  and
>  .Cm outbound
>  qualifiers can be used to specify a desired direction.
> -.It proto
> +.It Ar proto
>  Proto qualifiers restrict the match to a particular protocol.
>  Possible
> -protos are:
> +protocols are:
> +.Cm ah ,
> +.Cm arp ,
> +.Cm atalk ,
> +.Cm decnet ,
> +.Cm esp ,
>  .Cm ether ,
>  .Cm fddi ,
> -.Cm tr ,
> -.Cm wlan ,
> +.Cm icmp ,
> +.Cm icmp6 ,
> +.Cm igmp ,
> +.Cm igrp ,
>  .Cm ip ,
>  .Cm ip6 ,
> -.Cm arp ,
> +.Cm lat ,
> +.Cm mopdl ,
> +.Cm moprc ,
> +.Cm pim ,
>  .Cm rarp ,
> -.Cm decnet ,
> +.Cm sca ,
> +.Cm stp ,
>  .Cm tcp ,
> +.Cm udp ,
>  and
> -.Cm udp .
> -For example,
> +.Cm wlan .
> +E.g.,
>  .Dq ether src foo ,
>  .Dq arp net 128.3 ,
>  .Dq tcp port 21 ,
>  and
>  .Dq wlan addr2 0:2:3:4:5:6 .
> -If there is no proto qualifier,
> +If there is no protocol qualifier,
>  all protocols consistent with the type are assumed.
> -For example,
> +E.g.,
>  .Dq src foo
>  means
> -.Dq (ip or arp or rarp) src foo
> -(except the latter is not legal syntax);
> +.Do
> +.Pq ip or arp or rarp
> +src foo
> +.Dc
> +.Pq except the latter is not legal syntax ;
>  .Dq net bar
>  means
> -.Dq (ip or arp or rarp) net bar ;
> +.Do
> +.Pq ip or arp or rarp
> +net bar
> +.Dc ;
>  and
>  .Dq port 53
>  means
> -.Dq (tcp or udp) port 53 .
> +.Do
> +.Pq TCP or UDP
> +port 53
> +.Dc .
>  .Pp
>  .Cm fddi
>  is actually an alias for
>  .Cm ether ;
>  the parser treats them identically as meaning
> -"the data link level used on the specified network interface".
> -FDDI headers contain Ethernet-like source and destination addresses,
> +.Qo
> +the data link level used on the specified network interface
> +.Qc .
> +FDDI
> +.Pq Fiber Distributed Data 

Re: timeout: Prettify man page and usage

2021-09-04 Thread Jason McIntyre
On Sat, Sep 04, 2021 at 02:14:47PM +0200, Ingo Schwarze wrote:
> 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.
> 
> >> 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 unusual cases.
> 
> > sure. but grep tripped me up, and it's always the page i think of with
> > long options. why did we leave --context in SYNOPSIS?
> 
> I admit the grep(1) case is slightly confusing, but it is explained
> here why it is somewhat special:
> 
>   https://cvsweb.openbsd.org/src/usr.bin/grep/grep.1#rev1.47
> 
> Yours,
>   Ingo
> 

hi ingo.

pretty damning that my ok is on that commit ;)
i'll try to remember...

jmc



Re: timeout: Prettify man page and usage

2021-09-03 Thread Jason McIntyre
On Fri, Sep 03, 2021 at 03:42:21PM +0200, Ingo Schwarze wrote:
> 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 unusual cases.
> 
> Yours,
>   Ingo

sure. but grep tripped me up, and it's always the page i think of with
long options. why did we leave --context in SYNOPSIS?

jmc



Re: mark getsubopt(3) as part of POSIX

2021-09-03 Thread Jason McIntyre
On Fri, Sep 03, 2021 at 02:40:34PM +0200, Theo Buehler wrote:
> Found this in my tree. Our version of getsubopt matches NetBSD's up to
> some DIAGASSERTs and they do mention POSIX in their manual, so I suspect
> we inherited the specified behavior. I copied the phrasing used for
> other functions, but haven't checked in detail.
> 

fine by me, but an ok from ingo would probably be better.
jmc

> Index: stdlib/getsubopt.3
> ===
> RCS file: /cvs/src/lib/libc/stdlib/getsubopt.3,v
> retrieving revision 1.14
> diff -u -p -r1.14 getsubopt.3
> --- stdlib/getsubopt.315 Nov 2014 14:41:02 -  1.14
> +++ stdlib/getsubopt.320 May 2021 04:11:54 -
> @@ -138,6 +138,11 @@ while ((ch = getopt(argc, argv, "ab:")) 
>  .Sh SEE ALSO
>  .Xr getopt 3 ,
>  .Xr strsep 3
> +.Sh STANDARDS
> +The
> +.Fn getsubopt
> +function conforms to
> +.St -p1003.1-2008 .
>  .Sh HISTORY
>  The
>  .Fn getsubopt
> 



Re: rm.1: remove extraneous word

2021-09-03 Thread Jason McIntyre
On Thu, Sep 02, 2021 at 11:10:54PM +0100, Jason McIntyre wrote:
> On Thu, Sep 02, 2021 at 02:28:54PM -0700, Evan Silberman wrote:
> > Speaking of the first sentence of rm(1):
> > 
> > Remove extraneous word from command description
> > 
> > "non-directory files" reads more naturally and means the same thing as
> > "non-directory type files".
> > 
> 
> true.
> 
> 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", which seems more natural.
> 
> regardless, rm can remove both directory entries/non-directory type
> files as well as directories. although by default it does not remove
> directories, i wonder if we could just say:
> 
>   The
>   .Nm
>   utility
>   attempts to remove any files specified on the command line.
> 
> and NAME could be:
> 
>   - rm - remove directory entries
>   + rm - remove files
> 
> but maybe that is unixical heresy?
> 
> jmc
> 

i cannot really make up my mind here. posix and other bsds all use
"remove directory entries" for NAME. i worry that my proposal would be
needless change, and a lessening of valid terminology. so i probably
reject my own proposal.

on the other hand, the phrase "non-directory type files" is pretty
awful. posix is clearer i think, sticking to "directory entries
specified by each file argument".we could also use this: "directory
entries specified on the command line". but that would feel like
deliberately avoiding the term "file", which is clear and simple.

just using "non-directory files" is also weird. i mean, you can very
much remove directory files.

jmc

> > diff --git a/bin/rm/rm.1 b/bin/rm/rm.1
> > index a2526a36392..1be2bf31913 100644
> > --- a/bin/rm/rm.1
> > +++ b/bin/rm/rm.1
> > @@ -46,7 +46,7 @@
> >  .Sh DESCRIPTION
> >  The
> >  .Nm
> > -utility attempts to remove the non-directory type files specified on the
> > +utility attempts to remove the non-directory files specified on the
> >  command line.
> >  If the permissions of the file do not permit writing, and the standard
> >  input device is a terminal, the user is prompted (on the standard error
> > 



Re: rm.1: remove extraneous word

2021-09-02 Thread Jason McIntyre
On Thu, Sep 02, 2021 at 02:28:54PM -0700, Evan Silberman wrote:
> Speaking of the first sentence of rm(1):
> 
> Remove extraneous word from command description
> 
> "non-directory files" reads more naturally and means the same thing as
> "non-directory type files".
> 

true.

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", which seems more natural.

regardless, rm can remove both directory entries/non-directory type
files as well as directories. although by default it does not remove
directories, i wonder if we could just say:

The
.Nm
utility
attempts to remove any files specified on the command line.

and NAME could be:

- rm - remove directory entries
+ rm - remove files

but maybe that is unixical heresy?

jmc

> diff --git a/bin/rm/rm.1 b/bin/rm/rm.1
> index a2526a36392..1be2bf31913 100644
> --- a/bin/rm/rm.1
> +++ b/bin/rm/rm.1
> @@ -46,7 +46,7 @@
>  .Sh DESCRIPTION
>  The
>  .Nm
> -utility attempts to remove the non-directory type files specified on the
> +utility attempts to remove the non-directory files specified on the
>  command line.
>  If the permissions of the file do not permit writing, and the standard
>  input device is a terminal, the user is prompted (on the standard error
> 



Re: timeout: Prettify man page and usage

2021-09-02 Thread Jason McIntyre
On Thu, Sep 02, 2021 at 10:41:32PM +0200, Leon Fischer wrote:
> >
> > yes, fair point. i also dislike excess markup. but i think in the first
> > sentence it is not excess, it is explanation. i mean "duration"is marked
> > up.
> >
> > so that first sentence should try to talk about all those arg elements,
> > and mark each of them up. later, you can try and avoid being excessive.
> >
> > The
> > .Nm
> > utility executes
> > .Ar command ,
> > with any
> > .Ar args ,
> > and kills it if it is still running after the specified
> > .Ar duration .
> >
> > sth like that?
> >
> > but i agree that you don;t want to keep continually marking it up.
> 
> If there's bikeshedding to be done, I'd argue for an existing standard.
> doas(1) doesn't markup "command" and doesn't mention "args". rm(1)
> doesn't markup "file".  It's already clear how they're meant to be used.
> 

i would argue that "file" is pretty much unambiguous, and in 10 zillion
pages, whereas "args" is not. all commands have args. this command has
args, and specifies another command which can have args.

i don;t understand why you are differentiating between "command" as not an
argument and "duration" as an argument. they are both arguments: either mark
them up or don;t. if you don't, you will be flying in the face of how
our manuals are written, but at least you will be doing it consistently/

the fact that you are not explaining "args" does not really justify
anything. why mention "args" at all? isn;t it clear that a timeout
command that didn;t accept commands with arguments wouldn't work?

yes doas is different. yes it does not mark up command in the first
sentence. it marks it up in the second sentence. like, big win.

jmc



Re: timeout: Prettify man page and usage

2021-09-02 Thread Jason McIntyre
On Thu, Sep 02, 2021 at 05:47:09PM +0200, Leon Fischer wrote:
> > > @@ -34,83 +35,74 @@
> > >  .Nd run a command with a time limit
> > >  .Sh SYNOPSIS
> > >  .Nm
> > > -.Op Fl Fl signal Ar sig | Fl s Ar sig
> > > -.Op Fl Fl preserve-status
> > > -.Op Fl Fl kill-after Ar time | Fl k Ar time
> > > -.Op Fl Fl foreground
> > > -.Ao Ar duration Ac
> > > -.Ao Ar command Ac
> > > -.Ao Ar args ... Ac
> > > +.Op Fl k Ar time
> > > +.Op Fl s Ar sig
> > > +.Op Fl -foreground
> > > +.Op Fl -preserve-status
> > > +.Ar duration
> > > +.Ar command
> > > +.Op Ar args
> >
> > why do you want to remove the long options from the synopsis?
> 
> I copied this practice from sort(1), patch(1), less(1) and openrsync(1).
> 

ooh, good spot.

> >
> > i do agree that it currently looks awful, but i think it's because of
> > how it's implemented: it has four flags, and two of them have no short
> > option equivalents. ouch! that does make it hard to propose a tidy
> > synopsis.
> >
> > still, i'm not sure axing the long options makes sense. it just make it
> > look like it's better implemented!
> 
> Does it make sense to include redundant information in a summary?
>
> >
> > i thought about seperating them, like we do with grep. i.e. list -ks
> > seperately, then again as long options. that's horrible too.
> 
> grep(1) is inconsistent with the other man pages I mentioned and one of
> the two sides should probably be changed to conform with the other.
> 
> >
> > having said all that, i guess i'm not totally against obscuring the fact
> > that -k and -s have long options. but i suspect other people will, and
> > that we'll get mails telling us we forgot to list the long options in
> > synopsis.
> 
> No mails so far for sort(1) and patch(1), which have been around
> forever.
> 

given your points and theo's, i'm ok with this then, i guess.

> >
> > >  .Sh DESCRIPTION
> > > +The
> > >  .Nm
> > > -starts the
> > > -.Ar command
> > > -with its
> > > -.Ar args .
> > > -If
> > > -.Ar command
> > > -is still running after
> > > +utility executes the given command.
> > > +If it is still running after
> > >  .Ar duration ,
> > >  it is killed.
> >
> > this is ok, but you probably want to mark up "command"
> 
> I took inspiration from the doas(1) man page, which only marks up
> "command" when referring to it as an argument.  timeout(1) looked
> strange before with every paragraph containing a marked up "command".
> 

yes, fair point. i also dislike excess markup. but i think in the first
sentence it is not excess, it is explanation. i mean "duration"is marked
up.

so that first sentence should try to talk about all those arg elements,
and mark each of them up. later, you can try and avoid being excessive.

The
.Nm
utility executes
.Ar command ,
with any
.Ar args ,
and kills it if it is still running after the specified
.Ar duration .

sth like that?

but i agree that you don;t want to keep continually marking it up.

> > > +.Pp
> > > +The options are as follows:
> > > +.Bl -tag -width Ds
> > > +.It Fl k Ar time , Fl -kill-after Ns = Ns Ar time
> > > +Send a second kill signal if the command is still running after
> > >  .Ar time
> > > -after the first signal was sent.
> > > +after the first signal is sent.
> >
> > "after time after". ouch. (i know it's not your phrasing)
> >
> > how about
> >
> > ...still running
> > .Ar time
> > seconds after
> 
> The problem is "time" doesn't have to be seconds; it can be "30m",
> "7d", etc.  The GNU man page says "still running after this long" but I
> think it should mention the argument.
> 
> Changed to "still running time after the first signal".
> 

fine. i think it's good to write the text from the "what happens by
default" viewpoint, and exceptions are described in the relevant places.
so we should talk about duration as if it is in seconds - because it is
unless you say otherwise, in which case you know what you are doing.

you could refer to "timeout" as a period, i suppose.

> 
> >
> > also i'm trying to understand what it means that the number can be a
> > "positive integer or real (decimal) number". what does this mean? it can
> > be n or n.n?
> 
> Yes.  I copied the phrasing from the FreeBSD man page.
> 
> >
> > i think it'd be helpful to say upfront plainly what a valid timeout
> > would be, and that it's in seconds, and then later talk about adding
> > suffixes.
> 
> Changed to "duration and time may contain a decimal fraction.  The value
> defaults to seconds unless an unit-specifying suffix is given."
> 

"unit-specifying suffix" does not sound great. maybe just "a specific
suffix" or "a time suffix"? or make your text match and use "unless a
unit symbol is given", or change the unit symbol text to match whatever
you use. then people will join dots.

> 
> >
> > > -.It s
> > > +.It Cm s
> > >  seconds
> > > -.It m
> > > +.It Cm m
> > >  minutes
> > > -.It h
> > > +.It Cm h
> > >  hours
> > > -.It d
> > > +.It Cm d
> > > 

Re: update to tcpdump(8)

2021-09-02 Thread Jason McIntyre
On Thu, Sep 02, 2021 at 04:27:41PM +0200, Denis Fondras wrote:
> Le Thu, Sep 02, 2021 at 07:49:25AM +0100, Jason McIntyre a ?crit :
> > why not just paste in the body of pcap-filter in then and we can try and
> > keep them in sync thereafter?
> > 
> 
> OK, I will do that. I am not confident it will stay in sync over time :D
> 

maybe not, but it would be a good start.
jmc



Re: update to tcpdump(8)

2021-09-02 Thread Jason McIntyre
On Thu, Sep 02, 2021 at 03:33:17AM -0600, Theo de Raadt wrote:
> Jason McIntyre  wrote:
> 
> > On Thu, Sep 02, 2021 at 12:44:56AM -0600, Theo de Raadt wrote:
> > > Jason McIntyre  wrote:
> > > 
> > > > then i guess i would propose doing exactly that: removing the bulk of
> > > > the text describing primitives and qualifiers and leave a pointer to
> > > > pcap-filter.3. we could leave a brief description of the main
> > > > qualifiers, and perhaps just a list of valid keywords for the other
> > > > primitives.
> > > 
> > > I think that will be very annoying.
> > > 
> > > When I want to use tcpdump, I don't want to go reading a manual page
> > > which isn't called tcpdump.  Why should people need to jump another step.
> > > 
> > > Why should the tcpdump option become just a stub about the getopt options.
> > > 
> > > I believe most people run 'man tcpdump' not to read about the getopt 
> > > options,
> > > but to remind themselves of the pcap grammar they are about to use.  
> > > Making
> > > them run the man command twice is inserting a distraction into the 
> > > process.
> > > 
> > > I recognize the tcpdump manual page doesn't describe the full grammer, but
> > > it is still useful as-is.
> > > 
> > 
> > why not just paste in the body of pcap-filter in then and we can try and
> > keep them in sync thereafter?
> 
> that might work
> 

a paste in would be simple, but i guess i'd want someone to
authoratively say that the text in pcap-filter is the correct one, or
vice versa. i.e. i'm not familiar with the gubbins.

tcpdump talks about proto ah and atalk, but pcap-filter does not.
pcap-filter talks about tr as an alias for ether, but tcpdump does not.
and so on.

perhaps it is not so simple.

jmc



Re: timeout: Prettify man page and usage

2021-09-02 Thread Jason McIntyre
On Thu, Sep 02, 2021 at 08:56:29AM +, Job Snijders wrote:
> On Thu, Sep 02, 2021 at 07:23:26AM +0100, Jason McIntyre wrote:
> > >  .Ar time
> > > -can be integer or decimal numbers.
> > > +are positive integer or real (decimal) numbers, with an optional
> > 
> > can you have a negative timeout?
> 
> Negative values are not permitted
> 
> $ timeout -- -1 /bin/ls
> timeout: invalid duration: Undefined error: 0
> 
> Kind regards,
> 
> Job
> 

sorry, i wasn;t totally clear: i understand that negative values are not
permitted. but do we have to say it? i mean, you couldn;t expect to run
a command with a negative timeout, right?

the whole phrasing about what the timeout is is very precise, but hard
to understand. i want to simplify it. so if no one could logically
expect a negative timeout to work, why say it?

i.e. the current man page does not say it. so i think the proposed
change is not good.

jmc



Re: update to tcpdump(8)

2021-09-02 Thread Jason McIntyre
On Thu, Sep 02, 2021 at 12:44:56AM -0600, Theo de Raadt wrote:
> Jason McIntyre  wrote:
> 
> > then i guess i would propose doing exactly that: removing the bulk of
> > the text describing primitives and qualifiers and leave a pointer to
> > pcap-filter.3. we could leave a brief description of the main
> > qualifiers, and perhaps just a list of valid keywords for the other
> > primitives.
> 
> I think that will be very annoying.
> 
> When I want to use tcpdump, I don't want to go reading a manual page
> which isn't called tcpdump.  Why should people need to jump another step.
> 
> Why should the tcpdump option become just a stub about the getopt options.
> 
> I believe most people run 'man tcpdump' not to read about the getopt options,
> but to remind themselves of the pcap grammar they are about to use.  Making
> them run the man command twice is inserting a distraction into the process.
> 
> I recognize the tcpdump manual page doesn't describe the full grammer, but
> it is still useful as-is.
> 

why not just paste in the body of pcap-filter in then and we can try and
keep them in sync thereafter?

jmc



Re: update to tcpdump(8)

2021-09-02 Thread Jason McIntyre
On Wed, Sep 01, 2021 at 08:28:14PM +0200, Denis Fondras wrote:
> Le Wed, Sep 01, 2021 at 06:42:54PM +0100, Jason McIntyre a ?crit :
> > On Wed, Sep 01, 2021 at 06:15:04PM +0200, Denis Fondras wrote:
> > > I was searching for the sampling command of tcpdump but could not find it 
> > > in the
> > > manual. In fact it is missing some primitives compared to pcap-filter 
> > > manual.
> > > 
> > 
> > hi.
> > 
> > it looks like there's a whole heap of duplication going on here. does
> > tcpdump support just a subset of the syntax in pcap-filter(3), or are
> > they exactly the same?
> > 
> > i wonder if we can whack all the tcpdump text, or just inline the exact
> > text of pcap-filter.3 if it really needs to be there (or vice-versa if
> > tcpdump.8 is more authorative).
> > 
> > or do they differ?
> > 
> 
> tcpdump uses libpcap to decode the filter so as far as I can tell, they are 
> the
> same.
> 
> I would find it good to have only a pointer to pcap-filter manual in tcpdump
> manual instead of the full list of primitives.
> 

then i guess i would propose doing exactly that: removing the bulk of
the text describing primitives and qualifiers and leave a pointer to
pcap-filter.3. we could leave a brief description of the main
qualifiers, and perhaps just a list of valid keywords for the other
primitives.

do you want to take a shot at that? then we can see whether it's an
improvement.

jmc



Re: timeout: Prettify man page and usage

2021-09-02 Thread Jason McIntyre
On Wed, Sep 01, 2021 at 09:29:35PM +0200, Leon Fischer wrote:
> Here's my thanks for importing timeout(1).
> 
> P.S. The wording could still be improved, especially the -k description.
> 

hi.

> Index: timeout.1
> ===
> RCS file: /cvs/src/usr.bin/timeout/timeout.1,v
> retrieving revision 1.1
> diff -u -p -r1.1 timeout.1
> --- timeout.1 1 Sep 2021 15:50:33 -   1.1
> +++ timeout.1 1 Sep 2021 19:19:55 -
> @@ -1,3 +1,4 @@
> +.\"  $OpenBSD$
>  .\"  $NetBSD: timeout.1,v 1.4 2016/10/13 06:22:26 dholland Exp $
>  .\"
>  .\" Copyright (c) 2014 Baptiste Daroussin 
> @@ -26,7 +27,7 @@
>  .\"
>  .\" $FreeBSD: head/usr.bin/timeout/timeout.1 268861 2014-07-18 22:56:59Z 
> bapt $
>  .\"
> -.Dd July 19, 2014
> +.Dd $Mdocdate$
>  .Dt TIMEOUT 1
>  .Os
>  .Sh NAME
> @@ -34,83 +35,74 @@
>  .Nd run a command with a time limit
>  .Sh SYNOPSIS
>  .Nm
> -.Op Fl Fl signal Ar sig | Fl s Ar sig
> -.Op Fl Fl preserve-status
> -.Op Fl Fl kill-after Ar time | Fl k Ar time
> -.Op Fl Fl foreground
> -.Ao Ar duration Ac
> -.Ao Ar command Ac
> -.Ao Ar args ... Ac
> +.Op Fl k Ar time
> +.Op Fl s Ar sig
> +.Op Fl -foreground
> +.Op Fl -preserve-status
> +.Ar duration
> +.Ar command
> +.Op Ar args

why do you want to remove the long options from the synopsis?

i do agree that it currently looks awful, but i think it's because of
how it's implemented: it has four flags, and two of them have no short
option equivalents. ouch! that does make it hard to propose a tidy
synopsis.

still, i'm not sure axing the long options makes sense. it just make it
look like it's better implemented!

i thought about seperating them, like we do with grep. i.e. list -ks
seperately, then again as long options. that's horrible too.

having said all that, i guess i'm not totally against obscuring the fact
that -k and -s have long options. but i suspect other people will, and
that we'll get mails telling us we forgot to list the long options in
synopsis.

>  .Sh DESCRIPTION
> +The
>  .Nm
> -starts the
> -.Ar command
> -with its
> -.Ar args .
> -If
> -.Ar command
> -is still running after
> +utility executes the given command.
> +If it is still running after
>  .Ar duration ,
>  it is killed.

this is ok, but you probably want to mark up "command"

> -By default,
> -.Dv SIGTERM
> -is sent.
> -.Bl -tag -width "-k time, --kill-after time"
> -.It Fl Fl preserve-status
> -Always exits with the same status as
> -.Ar command
> -even if it times out.
> -.It Fl Fl foreground
> -Do not propagate timeout to the
> -.Ar command
> -children.
> -.It Fl s Ar sig , Fl Fl signal Ar sig
> -Specify the signal to send on timeout.
> -By default,
> -.Dv SIGTERM
> -is sent.
> -.It Fl k Ar time , Fl Fl kill-after Ar time
> -Send a second kill signal if
> -.Ar command
> -is still running after
> +.Pp
> +The options are as follows:
> +.Bl -tag -width Ds
> +.It Fl k Ar time , Fl -kill-after Ns = Ns Ar time
> +Send a second kill signal if the command is still running after
>  .Ar time
> -after the first signal was sent.
> +after the first signal is sent.

"after time after". ouch. (i know it's not your phrasing)

how about

...still running
.Ar time
seconds after

> +.It Fl s Ar sig , Fl -signal Ns = Ns Ar sig
> +Specify the signal to send on timeout, instead of the default
> +.Dv SIGTERM .

i like that

> +.It Fl -foreground
> +Do not propagate timeout signal to children processes.

maybe *the* timeout signal

> +.It Fl -preserve-status
> +Always exit with the same status as
> +.Ar command
> +even if the timeout is reached.
>  .El
>  .Sh DURATION FORMAT
>  .Ar duration
>  and
>  .Ar time
> -can be integer or decimal numbers.
> +are positive integer or real (decimal) numbers, with an optional

can you have a negative timeout?

also i'm trying to understand what it means that the number can be a
"positive integer or real (decimal) number". what does this mean? it can
be n or n.n?

i think it'd be helpful to say upfront plainly what a valid timeout
would be, and that it's in seconds, and then later talk about adding
suffixes.

> +unit-specifying suffix.
>  Values without unit symbols are interpreted as seconds.
>  .Pp
>  Supported unit symbols are:
>  .Bl -tag -width indent -compact

this list will look better with a .Pp before the .Bl, and it is missing
"-offset". it should be:

Support unit symbols are:
.Pp
.Bl -tag -width Ds -offset indent -compact

> -.It s
> +.It Cm s
>  seconds
> -.It m
> +.It Cm m
>  minutes
> -.It h
> +.It Cm h
>  hours
> -.It d
> +.It Cm d
>  days
>  .El
>  .Sh EXIT STATUS
> -If the timeout was not reached, the exit status of
> +If the timeout is not reached, the exit status of
>  .Ar command
>  is returned.

in my opinion, the text read better using past tense. i don;t like these
changes.

>  .Pp
> -If the timeout was reached and
> -.Fl Fl preserve-status
> +If the timeout is reached and
> +.Fl -preserve-status
>  is set, the exit status of
>  .Ar 

Re: update to tcpdump(8)

2021-09-01 Thread Jason McIntyre
On Wed, Sep 01, 2021 at 06:15:04PM +0200, Denis Fondras wrote:
> I was searching for the sampling command of tcpdump but could not find it in 
> the
> manual. In fact it is missing some primitives compared to pcap-filter manual.
> 

hi.

it looks like there's a whole heap of duplication going on here. does
tcpdump support just a subset of the syntax in pcap-filter(3), or are
they exactly the same?

i wonder if we can whack all the tcpdump text, or just inline the exact
text of pcap-filter.3 if it really needs to be there (or vice-versa if
tcpdump.8 is more authorative).

or do they differ?

jmc

> Index: tcpdump.8
> ===
> RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.8,v
> retrieving revision 1.111
> diff -u -p -r1.111 tcpdump.8
> --- tcpdump.8 17 Aug 2020 06:29:29 -  1.111
> +++ tcpdump.8 1 Sep 2021 16:05:20 -
> @@ -583,10 +583,26 @@ for details).
>  .It Cm src net Ar net
>  True if the IP source address of the packet has a network number of
>  .Ar net .
> -.It Cm net Ar net
> -True if either the IP source or destination address of the packet
> -has a network number of
> -.Ar net .
> +.It Cm net Ar net Ns / Ns Ar len
> +True if the IPv4/v6 address matches
> +.Ar net
> +with a netmask
> +.Ar len
> +bits wide.
> +May be qualified with
> +.Cm src
> +or
> +.Cm dst .
> +.It Cm net Ar net Cm mask Ar netmask
> +True if the IPv4 address matches
> +.Ar net
> +with the specific
> +.Ar netmask .
> +May be qualified with
> +.Cm src
> +or
> +.Cm dst .
> +Note that this syntax is not valid for IPv6 networks.
>  .It Cm dst port Ar port
>  True if the packet is IP/TCP or IP/UDP and has a destination port value of
>  .Ar port .
> @@ -634,12 +650,15 @@ True if the packet has a length greater 
>  This is equivalent to:
>  .Pp
>  .D1 Cm len >= Ar length
> -.It Cm ip proto Ar proto
> -True if the packet is an IP packet (see
> +.It Cm sample Ar samplerate
> +True if the packet has been randomly selected or sampled at a rate of 1 per
> +.Ar samplerate .
> +.It Cm ip proto Ar protocol
> +True if the packet is an IPv4 packet (see
>  .Xr ip 4 )
>  of protocol type
> -.Ar proto .
> -.Ar proto
> +.Ar protocol .
> +.Ar protocol
>  can be a number or name from
>  .Xr protocols 5 ,
>  such as
> @@ -650,13 +669,18 @@ or
>  These identifiers are also keywords and must be escaped
>  using a backslash character
>  .Pq Sq \e .
> +Note that this primitive does not chase the protocol header chain.
> +.It Cm ip6 proto Ar protocol
> +True if the packet is an IPv6 packet of protocol type
> +.Ar protocol .
> +Note that this primitive does not chase the protocol header chain.
>  .It Cm ether broadcast
>  True if the packet is an Ethernet broadcast packet.
>  The
>  .Cm ether
>  keyword is optional.
>  .It Cm ip broadcast
> -True if the packet is an IP broadcast packet.
> +True if the packet is an IPv4 broadcast packet.
>  It checks for both the all-zeroes and all-ones broadcast conventions
>  and looks up the local subnet mask.
>  .It Cm ether multicast
> @@ -670,10 +694,12 @@ This is shorthand for
>  .Dc .
>  .It Cm ip multicast
>  True if the packet is an IP multicast packet.
> -.It Cm ether proto Ar proto
> +.It Cm ip6 multicast
> +True if the packet is an IPv6 multicast packet.
> +.It Cm ether proto Ar protocol
>  True if the packet is of ether type
> -.Ar proto .
> -.Ar proto
> +.Ar protocol .
> +.Ar protocol
>  can be a number or one of the names
>  .Cm ip ,
>  .Cm ip6 ,
> @@ -835,6 +861,53 @@ Valid directions are:
>  .Ar fromds ,
>  .Ar dstods ,
>  or a numeric value.
> +.It Cm vlan Op Ar vlan_id
> +True if the packet is an IEEE 802.1Q VLAN packet.
> +If
> +.Ar vlan_id
> +is specified, only true if the packet has the specified ID.
> +Note that the first
> +.Cm vlan
> +keyword encountered in
> +.Ar expression
> +changes the decoding offsets for the remainder of
> +.Ar expression
> +on the assumption that the packet is a VLAN packet.
> +This expression may be used more than once, to filter on VLAN hierarchies.
> +Each use of that expression increments the filter offsets by 4.
> +.Pp
> +For example,
> +to filter on VLAN 200 encapsulated within VLAN 100:
> +.Pp
> +.Dl vlan 100 && vlan 200
> +.Pp
> +To filter IPv4 protocols encapsulated in VLAN 300 encapsulated within any
> +higher order VLAN:
> +.Pp
> +.Dl vlan && vlan 300 && ip
> +.It mpls Op Ar label
> +True if the packet is an MPLS (Multi-Protocol Label Switching) packet.
> +If
> +.Ar label
> +is specified, only true if the packet has the specified label.
> +Note that the first
> +.Cm mpls
> +keyword encountered in
> +.Ar expression
> +changes the decoding offsets for the remainder of
> +.Ar expression
> +on the assumption that the packet is an MPLS packet.
> +This expression may be used more than once, to filter on MPLS labels.
> +Each use of that expression increments the filter offsets by 4.
> +.Pp
> +For example,
> +to filter on MPLS label 42 first and requires the next label to be 12:
> +.Pp
> +.Dl mpls 42 && 

Re: acpibtn.4: Mention sleep putton, lid status and machdep.{lid,pwr}action

2021-09-01 Thread Jason McIntyre
On Tue, Aug 31, 2021 at 11:51:37PM +, Klemens Nanni wrote:
> landry added the sensor back in 2013 and suspend via sleep button also works
> (at least on ThinkPads).
> 
> machdep.*action are super useful and I dislike grepping /etc/examples/
> for to read about them.
> 
> acpibtn(4) is the most prominent driver supporting, so documenting them
> there seems fine and finally pleases my muscle memory:
> 
>   $ man -k any=lidaction
>   acpibtn(4) - ACPI button
> 
> suspend/hibernate wording is taken from apm(8).
> sysctl value list style is taken from sysctl(2)'s KERN_POOL_DEBUG.
> 
> Feedback? OK?
> 

hi. i think this is a good change - it makes the page more helpful.
i have only one tweak, inline:

> Index: acpibtn.4
> ===
> RCS file: /cvs/src/share/man/man4/acpibtn.4,v
> retrieving revision 1.5
> diff -u -p -r1.5 acpibtn.4
> --- acpibtn.4 16 Jul 2013 16:05:48 -  1.5
> +++ acpibtn.4 31 Aug 2021 23:37:20 -
> @@ -25,17 +25,59 @@
>  .Sh DESCRIPTION
>  The
>  .Nm
> -driver is used to handle the event triggered when the user presses an ACPI
> -button.
> -Currently, the only event handled is the press of a power button which
> -causes the system to perform a regular system shutdown and power off the
> -machine if the
> +driver handles events triggered by ACPI buttons.
> +Currently, only power button, sleep button and lid status events are 
> supported.
> +.Pp
> +The power button event is handled according to the
> +.Va machdep.pwraction
> +.Xr sysctl 8 .
> +Valid values are:
> +.Pp
> +.Bl -tag -width 3n -offset indent -compact
> +.It 0
> +Do nothing.
> +.It 1
> +Perform a regular system shutdown and power off the machine if the
>  .Va hw.allowpowerdown
> +sysctl is set to 1.
> +.It 2
> +Put the system into suspend (deep sleep) state.
> +.El
> +.Pp
> +The sleep button event puts the system into suspend (deep sleep) state.
> +.Pp
> +The lid status event is handled according to the
> +.Va machdep.lidaction
> +sysctl.
> +Valid values are:
> +.Pp
> +.Bl -tag -width 3n -offset indent -compact
> +.It 0
> +Do nothing.
> +.It 1
> +Put the system into suspend (deep sleep) state.
> +.It 2
> +Put the system into hibernation.
> +System memory is saved to disk (swap space)
> +and the machine is powered down.
> +For machines supporting the
> +.Xr acpi 4
> +style hibernate functionality, on resume a full kernel
> +boot will occur, followed by the reading of the saved
> +memory image.
> +The image will then be unpacked and the system resumed
> +at the point immediately after the hibernation request.
> +.El
> +.Pp
> +The lid status is set up as sensor and can be monitored using

i think you should say "as a sensor".

jmc

>  .Xr sysctl 8
> -is set to 1.
> +or
> +.Xr sensorsd 8 .
>  .Sh SEE ALSO
>  .Xr acpi 4 ,
> -.Xr intro 4
> +.Xr intro 4 ,
> +.Xr sensorsd 8 ,
> +.Xr sysctl 8
>  .Sh HISTORY
>  The
>  .Nm
> 



Re: openssl(1): implement naccept

2021-08-29 Thread Jason McIntyre
On Sun, Aug 29, 2021 at 02:00:44PM +0200, Theo Buehler wrote:
> Terminate the s_server after n clients connected to it. This is
> occasionally useful, matches OpenSSL's behavior and should help
> simplifying regress/usr.bin/openssl/x509.
> 

hi.

> Index: openssl.1
> ===
> RCS file: /cvs/src/usr.bin/openssl/openssl.1,v
> retrieving revision 1.129
> diff -u -p -r1.129 openssl.1
> --- openssl.1 17 Mar 2021 18:08:32 -  1.129
> +++ openssl.1 28 Aug 2021 17:12:59 -
> @@ -4607,6 +4607,7 @@ will be used.
>  .Op Fl keymatexportlen Ar len
>  .Op Fl msg
>  .Op Fl mtu Ar mtu
> +.Op Fl naccept Ar arg

i guess "arg" should be "num".
also i think it needs to be added to sv_usage in s_server.c.

otherwise doc parts ok.

jmc

>  .Op Fl named_curve Ar arg
>  .Op Fl nbio
>  .Op Fl nbio_test
> @@ -4807,6 +4808,10 @@ Export len bytes of keying material (def
>  Show all protocol messages with hex dump.
>  .It Fl mtu Ar mtu
>  Set the link layer MTU.
> +.It Fl naccept Ar num
> +Terminate server after
> +.Ar num
> +connections.
>  .It Fl named_curve Ar arg
>  Specify the elliptic curve name to use for ephemeral ECDH keys.
>  This option is deprecated; use
> Index: s_apps.h
> ===
> RCS file: /cvs/src/usr.bin/openssl/s_apps.h,v
> retrieving revision 1.5
> diff -u -p -r1.5 s_apps.h
> --- s_apps.h  25 Apr 2018 07:12:33 -  1.5
> +++ s_apps.h  28 Aug 2021 17:12:59 -
> @@ -120,7 +120,7 @@ extern int verify_return_error;
>  
>  int do_server(int port, int type, int *ret,
>  int (*cb)(char *hostname, int s, unsigned char *context),
> -unsigned char *context);
> +unsigned char *context, int naccept);
>  #ifdef HEADER_X509_H
>  int verify_callback(int ok, X509_STORE_CTX *ctx);
>  #endif
> Index: s_server.c
> ===
> RCS file: /cvs/src/usr.bin/openssl/s_server.c,v
> retrieving revision 1.47
> diff -u -p -r1.47 s_server.c
> --- s_server.c17 Mar 2021 18:11:01 -  1.47
> +++ s_server.c28 Aug 2021 17:17:38 -
> @@ -267,6 +267,7 @@ static struct {
>   uint16_t min_version;
>   const SSL_METHOD *meth;
>   int msg;
> + int naccept;
>   char *named_curve;
>   int nbio;
>   int nbio_test;
> @@ -741,6 +742,13 @@ static const struct option s_server_opti
>   },
>  #endif
>   {
> + .name = "naccept",
> + .argname = "num",
> + .desc = "terminate after num connections",
> + .type = OPTION_ARG_INT,
> + .opt.value = _server_config.naccept
> + },
> + {
>   .name = "named_curve",
>   .argname = "arg",
>   .type = OPTION_ARG,
> @@ -1084,6 +1092,7 @@ s_server_main(int argc, char *argv[])
>   memset(_server_config, 0, sizeof(s_server_config));
>   s_server_config.keymatexportlen = 20;
>   s_server_config.meth = TLS_server_method();
> + s_server_config.naccept = -1;
>   s_server_config.port = PORT;
>   s_server_config.cert_file = TEST_CERT;
>   s_server_config.cert_file2 = TEST_CERT2;
> @@ -1465,10 +1474,12 @@ s_server_main(int argc, char *argv[])
>   (void) BIO_flush(bio_s_out);
>   if (s_server_config.www)
>   do_server(s_server_config.port, s_server_config.socket_type,
> - _socket, www_body, s_server_config.context);
> + _socket, www_body, s_server_config.context,
> + s_server_config.naccept);
>   else
>   do_server(s_server_config.port, s_server_config.socket_type,
> - _socket, sv_body, s_server_config.context);
> + _socket, sv_body, s_server_config.context,
> + s_server_config.naccept);
>   print_stats(bio_s_out, ctx);
>   ret = 0;
>   end:
> Index: s_socket.c
> ===
> RCS file: /cvs/src/usr.bin/openssl/s_socket.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 s_socket.c
> --- s_socket.c28 Jun 2019 13:35:02 -  1.11
> +++ s_socket.c28 Aug 2021 17:12:59 -
> @@ -132,7 +132,7 @@ init_client(int *sock, char *host, char 
>  int
>  do_server(int port, int type, int *ret,
>  int (*cb) (char *hostname, int s, unsigned char *context),
> -unsigned char *context)
> +unsigned char *context, int naccept)
>  {
>   int sock;
>   char *name = NULL;
> @@ -161,7 +161,9 @@ do_server(int port, int type, int *ret,
>   shutdown(sock, SHUT_RDWR);
>   close(sock);
>   }
> - if (i < 0) {
> + if (naccept != -1)
> + naccept--;
> + if (i < 0 || naccept == 0) {
>   shutdown(accept_socket, SHUT_RDWR);
>   close(accept_socket);
>   return (i);
> 



Re: fortune(6): Veni, vidi, vici

2021-08-23 Thread Jason McIntyre
On Mon, Aug 23, 2021 at 08:18:13PM +0200, Alessandro De Laurenzis wrote:
> Greetings,
> 
> I was reluctant to submit this patch, since I'm not a native English 
> speaker and this could be a wordplay joke, but if not, and it is really 
> citing the Latin phrase popularly attributed to Julius Caesar (see e.g. 
> [1], but there are plenty on the net, of course), the wrong order warps 
> the meaning.
> 
> Please consider the attached diff.
> 
> All the best
> 
> [1] https://en.wikipedia.org/wiki/Veni,_vidi,_vici
> 
> -- 
> Alessandro De Laurenzis
> [mailto:jus...@atlantide.mooo.com]
> Web: http://www.atlantide.mooo.com
> LinkedIn: http://it.linkedin.com/in/delaurenzis

> --- /usr/src/games/fortune/datfiles/fortunes2-o.orig  Thu Jul 13 04:45:56 2017
> +++ /usr/src/games/fortune/datfiles/fortunes2-o   Mon Aug 23 20:07:23 2021
> @@ -14251,8 +14251,8 @@
>  to a rival.  Husbands, good or bad, always have rivals.  Lovers, never.
>   -- Helen Lawrenson, "Esquire"
>  %
> -Vidi, vici, veni.
> -(I saw, I conquered, I came.)
> +Veni, vidi, vici.
> +(I came, I saw, I conquered.)
>  %
>  Viennese Oyster: Lady who can cross her feet behind her head, lying on her
>  back, of course.  When she has done so, you hold her tightly round each 
> instep


hi.

it is a joke, yes. there's at least one other joke of this type in the
database:

Veni, Vidi, VISA:
I came, I saw, I did a little shopping.

however i also just spotted the actual quote is there too, and appears
to have a typo!

jmc

Index: fortunes2
===
RCS file: /cvs/src/games/fortune/datfiles/fortunes2,v
retrieving revision 1.52
diff -u -p -r1.52 fortunes2
--- fortunes2   27 Sep 2019 20:44:22 -  1.52
+++ fortunes2   23 Aug 2021 20:36:05 -
@@ -41833,7 +41833,7 @@ Hagar's note: The first definition is mu
 only by malcontents, the envious, and disgruntled owners of waterfront
 property.
 %
-Vini, vidi, vici.
+Veni, vidi, vici.
 [I came, I saw, I conquered].
-- Gaius Julius Caesar
 %



Re: ucc(4): consumer control keyboard device driver

2021-08-17 Thread Jason McIntyre
On Tue, Aug 17, 2021 at 08:13:41PM +0200, Anton Lindqvist wrote:
> Hi,
> Here's a new driver for USB HID Consumer Control keyboards. Such
> keyboard is a pseudo device which is used to expose audio and
> application launch keys. My prime motivation is to get the volume mute,
> increment and decrement keys to just work on my keyboard without the
> need to use usbhidaction(1).
> 
> ucc(4) attaches a wskbd(4) keyboard "on top" making it appear like an
> ordinary keyboard, which also makes it possible to inject key
> press/release input. It supports both translating and raw mode making it
> compatible with the ordinary console and X11.
> 
> My keyboard for instance exposes 42 keys in its input report. I only
> care about the volume and audio related ones and therefore only added
> mappings for those. Additional mappings should be trivial to add if
> desired.
> 
> Testing would be much appreciated.
> 
> Comments? OK?
> 

hi.

the doc parts look good.
jmc

> diff --git share/man/man4/Makefile share/man/man4/Makefile
> index 6a0ecb20653..63b33660159 100644
> --- share/man/man4/Makefile
> +++ share/man/man4/Makefile
> @@ -84,7 +84,7 @@ MAN=aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \
>   tlphy.4 thmc.4 tpm.4 tpmr.4 tqphy.4 trm.4 trunk.4 tsl.4 tty.4 \
>   tun.4 tap.4 twe.4 \
>   txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \
> - ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \
> + ubsec.4 ucc.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \
>   udav.4 udcf.4 udl.4 udp.4 udsbr.4 \
>   uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uhidpp.4 \
>   uipaq.4 ujoy.4 uk.4 ukbd.4 \
> diff --git share/man/man4/ucc.4 share/man/man4/ucc.4
> new file mode 100644
> index 000..413c88aa6af
> --- /dev/null
> +++ share/man/man4/ucc.4
> @@ -0,0 +1,45 @@
> +.\"  $OpenBSD$
> +.\"
> +.\" Copyright (c) 2021 Anton Lindqvist 
> +.\"
> +.\" Permission to use, copy, modify, and distribute this software for any
> +.\" purpose with or without fee is hereby granted, provided that the above
> +.\" copyright notice and this permission notice appear in all copies.
> +.\"
> +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> +.\"
> +.Dd $Mdocdate$
> +.Dt UCC 4
> +.Os
> +.Sh NAME
> +.Nm ucc
> +.Nd Consumer Control keyboards
> +.Sh SYNOPSIS
> +.Cd "ucc* at uhidev?"
> +.Cd "wsbkd* at ucc? mux 1"
> +.Sh DESCRIPTION
> +The
> +.Nm
> +driver provides support for Consumer Control pseudo keyboards, often used to
> +expose audio and application launch keys.
> +.Sh SEE ALSO
> +.Xr intro 4 ,
> +.Xr uhidev 4 ,
> +.Xr usb 4 ,
> +.Xr wskbd 4
> +.Sh HISTORY
> +The
> +.Nm
> +driver first appeared in
> +.Ox 7.0 .
> +.Sh AUTHORS
> +The
> +.Nm
> +driver was written by
> +.An Anton Lindqvist Aq Mt an...@openbsd.org .
> diff --git share/man/man4/uhidev.4 share/man/man4/uhidev.4
> index 02252789a3f..d398c564bd5 100644
> --- share/man/man4/uhidev.4
> +++ share/man/man4/uhidev.4
> @@ -37,6 +37,7 @@
>  .Sh SYNOPSIS
>  .Cd "uhidev*  at uhub?"
>  .Cd "fido*at uhidev?"
> +.Cd "ucc* at uhidev?"
>  .Cd "ucycom*  at uhidev?"
>  .Cd "ugold*   at uhidev?"
>  .Cd "uhid*at uhidev?"
> @@ -72,6 +73,7 @@ only dispatches data to them based on the report id.
>  .Sh SEE ALSO
>  .Xr fido 4 ,
>  .Xr intro 4 ,
> +.Xr ucc 4 ,
>  .Xr ucycom 4 ,
>  .Xr ugold 4 ,
>  .Xr uhid 4 ,
> diff --git share/man/man4/usb.4 share/man/man4/usb.4
> index dad3d3a97d9..d159d8b27f3 100644
> --- share/man/man4/usb.4
> +++ share/man/man4/usb.4
> @@ -249,6 +249,8 @@ D-Link DSB-R100 USB radio device
>  FIDO/U2F security keys
>  .It Xr ubcmtp 4
>  Broadcom trackpad mouse
> +.It Xr ucc 4
> +USB Consumer Control keyboards
>  .It Xr ugold 4
>  TEMPer gold HID thermometer and hygrometer
>  .It Xr uhid 4
> diff --git sys/arch/alpha/conf/GENERIC sys/arch/alpha/conf/GENERIC
> index 8af652ce301..54d4a45cd4e 100644
> --- sys/arch/alpha/conf/GENERIC
> +++ sys/arch/alpha/conf/GENERIC
> @@ -107,6 +107,8 @@ uslhcom* at uhidev?   # Silicon Labs 
> CP2110 USB HID UART
>  ucom*at uslhcom?
>  uhid*at uhidev?  # USB generic HID support
>  fido*at uhidev?  # FIDO/U2F security key support
> +ucc* at uhidev?  # Consumer Control keyboards
> +wskbd*   at ucc? mux 1
>  ujoy*at uhidev?  # USB joystick/gamecontroller 
> support
>  uhidpp*  at uhidev?  # Logitech HID++ Devices
>  upd* at uhidev?

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

2021-08-16 Thread Jason McIntyre
On Mon, Aug 16, 2021 at 01:45:30PM +0200, Ingo Schwarze wrote:
> 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 qualification):
> 
>$ frob -f -u
>   usage: frob [-f | -u]
> 
> This is what "overrides earlier" means:
> 
>$ frob -f -u
>   output from successful unfrobnification
> 
>$ frob -u -f
>   output from successful frobnification
> 

for me, mututally exclusive means simply that you can;t use the options 
together.
it doesn;t specify how a program reacts:

- sometimes the program coughs when you use them together (spits out usage)
- sometimes it just uses the last match (so silently accepts both; first/last 
wins)

maybe others do not see it that way. i mean, i'm not saying i'm correct,
only that this is how i understand the concept.

> > i don;t find it as clear, and i don;t hugely like it, but i guess
> > it's just my preference.
> > 
> > i also dislike the sentence structure of "Overrides earlier -f."
> > although it's understandable, it reads like there's a word or phrase
> > missing.
> 
> Yes, it is an elliptic wording.
> 
> > Overrides earlier instances of -f. Overrides previous -f options.
> 
> Both are still elliptic.
> 
> The intended meaning of the ellipsis is:
> 
>   [This option] overrides [any] earlier -f [options].
> 

yes, i understand about elliptic wording. what i meant was that i felt
this form (i.e. elliptic) read badly.

> Should we prefer the non-elliptic wording?
> 

well, for me, yes. but i guess other people will prefer the shorter
text.

> > i just find it clearer when we just say -x and -y are mutually exclusive.
> 
> OK, let's spell this out in full.
> 
> I'm aware of two ways to document "mutually exclusive":
> 
>   -f   Frobnicate.  Mutually exclusive with -u.
>   -u   Unfrobnicate.  Mutually exclusive with -f.
> 
> Or:
> 
>   -f   Frobnicate.
>   -u   Unfrobnicate.
>   [...]
>   The options -f and -u are mutually exclusive.
> 
> I have no strong preference either way because if a user specifies both,
> they get the usage() message, so the error is likely to be discovered
> either way.
> 

well when you have 10 exclusive options (looking at you, ls(1)) then
adding the text to every option becomes unwieldy. that's why we did it
the second way. but when you just have a couple (much more common) then
it can be easier to read in your first example.

> 
> I'm aware of two ways to document "overrides":
> 
>   -f   Frobnicate.  Overrides earlier -u.
>   -u   Unfrobnicate.  Overrides earlier -f.
> 
> Or:
> 
>   -f   Frobnicate.
>   -u   Unfrobnicate.
>   [...]
>   The options -f and -u override each other [and the action
>   is determined by the last one specified].
> 
> I prefer the the former because the latter is easy to miss (in
> addition to being longer), and there is no error message to tell
> the user that *something* is going on.
> 
> 
> Some pages use
> 
>   The options -f and -u are mutually exclusive and override each other.
> 
> as a synonym for
> 
>   The options -f and -u override each other.
> 
> That may have caused your confusion.  Arguably, it might be better
> to avoid the somewhat redundant and potentially confusing wording
> "are mutually exclusive and override each other".  Do you agree?
> 
> Yours,
>   Ingo

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

maybe it is more helpful to think of "mutually exclusive" as "causes an
error", but i am not sure.

jmc



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

2021-08-16 Thread Jason McIntyre
On Mon, Aug 16, 2021 at 12:53:38PM +0200, Ingo Schwarze wrote:
> 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 same as just "lock -n",
> even though -t comes after -n.
> 
> But if options override *each other*, that means the last one wins
> unless otherwise stated.
> 
> A utility can also be designed such that some options override each
> other and the first one wins, but usually, i wouldn't consider that
> ideal UI design in a command line utility.  In configuration files,
> on the other hand, both "first one wins" and "last one wins" exist.
> For that reason, nothing much seems wrong with being explicit that
> the last one wins, where that is the case.
> 
> > and then not document this fact every time. or at least document
> > exceptions only?
> > 
> > ...and continue to document where options are mutually exclusive? 
> > 
> > also the text "overrides earlier" is unclear.
> 
> In which sense do you consider
> 
>   -f   Frobnicate.  Overrides earlier -u.
>   -l   [...]
>   -n   [...]
>   -u   Unfrobnicate.  Overrides earlier -f.
> 
> unclear?  Options exclusively appear on the command line, so i don't
> see how "earlier" or "later" could possibly refer to anything else
> than the position on the command line.
> 
> Note that this seems only loosely related to martijn@'s diff, which
> i think is undesirable for other, stronger reasons.
> 
> Yours,
>   Ingo

hi.

when i wrote my mail, i failed to understand that "overrides earlier"
was really just another way of saying "mutually exclusive". i don;t find
it as clear, and i don;t hugely like it, but i guess it's just my
preference.

i also dislike the sentence structure of "Overrides earlier -f."
although it's understandable, it reads like there's a word or phrase
missing. Overrides earlier instances of -f. Overrides previous -f
options.

i just find it clearer when we just say -x and -y are mutually exclusive.

jmc



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

2021-08-15 Thread Jason McIntyre
On Sun, Aug 15, 2021 at 05:42:13PM -0600, Theo de Raadt wrote:
> This conversation is strange, because we had a very similar argument
> recently about some other command (I forgot which one), about what
> policy should occur for repeated commands.
> 
> I think once we step outside a narrowly defined POSIX option argument
> scheme, we need to understand we are outside POSIX.  Meanwhile, there
> is this "sed and line 0" conversation flowing through my mailbox, where
> a strictly defined POSIX command's GNU extensions causes people trouble.
> 
> Is it really reasonable that we should strictly follow a non-applicable
> standard in such rarely used non-standard utilities, when
> strictly-standardized utilities so often have non-standard extensions
> which acutely poison the user expectations in more harmful ways (meaning,
> incorrect results IN SCRIPTS).
> 
> We can't push back against established facts in sed because it would break
> people's scripts somewhere, why do we need to push back against established
> facts for people who might use cal in this weird way in a script?
> 
> Beyond the theory of "lacking guidance, let's impose a POSIX rule after
> the fact", has there been any attempt to JUDGE if this will affect anyone
> in scripts?
> 

not by me, and that's a good point. i wouldn;t even know how to examine
such a thing.

from my point of view i supposed that last option winning was the
general way of things and it would be enough to have that presumed and
not documented, but obviously we would document commands where this does not
occur.

so for cal(1), i figured it unneccessary to document this fact. i guess
if it is a change in behaviour (i'm unsure whether that is the case)
then i guess we might have to document it.

jmc

> Jason McIntyre  wrote:
> 
> > On 15 August 2021 22:40:49 BST, Martijn van Duren 
> >  wrote:
> > >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
> > >> convention 12.2.11 is pertinent:
> > >> 
> > >>   The order of different options relative to one another should not
> > >>   matter, unless the options are documented as mutually-exclusive
> > >>   and such an option is documented to override any incompatible
> > >>   options preceding it.  If an option that has option-arguments is
> > >>   repeated, the option and option-argument combinations should be
> > >>   interpreted in the order specified on the command line.
> > >
> > >This is also violated by cal(1) (and maybe others, but this one came
> > >up first). Diff below should fix this.
> > >
> > >OK?
> > >
> > >martijn@
> > >
> > >Index: cal.1
> > >===
> > >RCS file: /cvs/src/usr.bin/cal/cal.1,v
> > >retrieving revision 1.31
> > >diff -u -p -r1.31 cal.1
> > >--- cal.1  27 Nov 2016 10:37:22 -  1.31
> > >+++ cal.1  15 Aug 2021 21:39:28 -
> > >@@ -53,11 +53,8 @@ The options are as follows:
> > > .Bl -tag -width Ds
> > > .It Fl j
> > > Display Julian dates (days one-based, numbered from January 1).
> > >-The options
> > >-.Fl j
> > >-and
> > >-.Fl w
> > >-are mutually exclusive.
> > >+Overrides earlier
> > >+.Fl w .
> > > .It Fl m
> > > Display weeks starting on Monday instead of Sunday.
> > > .It Fl w
> > >@@ -65,11 +62,8 @@ Display week numbers in the month displa
> > > If
> > > .Fl m
> > > is specified the ISO week format is assumed.
> > >-The options
> > >-.Fl j
> > >-and
> > >-.Fl w
> > >-are mutually exclusive.
> > >+Overrides earlier
> > >+.Fl j .
> > > .It Fl y
> > > Display a calendar for the current year.
> > > .El
> > >Index: cal.c
> > >===
> > >RCS file: /cvs/src/usr.bin/cal/cal.c,v
> > >retrieving revision 1.30
> > >diff -u -p -r1.30 cal.c
> > >--- cal.c  9 Oct 2015 01:37:06 -   1.30
> > >+++ cal.c  15 Aug 2021 21:39:28 -
> > >@@ -158,12 +158,14 @@ main(int argc, char *argv[])
> > >   switch(ch) {
> > >   case 'j':
> > >   julian = 1;
> > >+  wflag = 0;
> > >   break;
> > >   case 'm':
> > > 

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

2021-08-15 Thread Jason McIntyre
On 15 August 2021 22:40:49 BST, Martijn van Duren 
 wrote:
>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
>> convention 12.2.11 is pertinent:
>> 
>>   The order of different options relative to one another should not
>>   matter, unless the options are documented as mutually-exclusive
>>   and such an option is documented to override any incompatible
>>   options preceding it.  If an option that has option-arguments is
>>   repeated, the option and option-argument combinations should be
>>   interpreted in the order specified on the command line.
>
>This is also violated by cal(1) (and maybe others, but this one came
>up first). Diff below should fix this.
>
>OK?
>
>martijn@
>
>Index: cal.1
>===
>RCS file: /cvs/src/usr.bin/cal/cal.1,v
>retrieving revision 1.31
>diff -u -p -r1.31 cal.1
>--- cal.1  27 Nov 2016 10:37:22 -  1.31
>+++ cal.1  15 Aug 2021 21:39:28 -
>@@ -53,11 +53,8 @@ The options are as follows:
> .Bl -tag -width Ds
> .It Fl j
> Display Julian dates (days one-based, numbered from January 1).
>-The options
>-.Fl j
>-and
>-.Fl w
>-are mutually exclusive.
>+Overrides earlier
>+.Fl w .
> .It Fl m
> Display weeks starting on Monday instead of Sunday.
> .It Fl w
>@@ -65,11 +62,8 @@ Display week numbers in the month displa
> If
> .Fl m
> is specified the ISO week format is assumed.
>-The options
>-.Fl j
>-and
>-.Fl w
>-are mutually exclusive.
>+Overrides earlier
>+.Fl j .
> .It Fl y
> Display a calendar for the current year.
> .El
>Index: cal.c
>===
>RCS file: /cvs/src/usr.bin/cal/cal.c,v
>retrieving revision 1.30
>diff -u -p -r1.30 cal.c
>--- cal.c  9 Oct 2015 01:37:06 -   1.30
>+++ cal.c  15 Aug 2021 21:39:28 -
>@@ -158,12 +158,14 @@ main(int argc, char *argv[])
>   switch(ch) {
>   case 'j':
>   julian = 1;
>+  wflag = 0;
>   break;
>   case 'm':
>   mflag = 1;
>   break;
>   case 'w':
>   wflag = 1;
>+  julian = 0;
>   break;
>   case 'y':
>   yflag = 1;
>@@ -174,9 +176,6 @@ main(int argc, char *argv[])
>   }
>   argc -= optind;
>   argv += optind;
>-
>-  if (julian && wflag)
>-  usage();
> 
>   day_headings = DAY_HEADINGS_S;
>   sep1752 = sep1752s;
>
>

hi.

i don't like this approach, because i think the changes are confusing. 

can't we take a stance that where options override each other, the last one 
wins?  and then not document this fact every time. or at least document 
exceptions only?

...and continue to document where options are mutually exclusive? 

also the text "overrides earlier" is unclear.

jmc



Re: dhcpleased(8): ignore servers / parts of lease

2021-08-08 Thread Jason McIntyre
On Sun, Aug 08, 2021 at 12:37:54PM +0200, Florian Obser wrote:
> This implements ignoring of nameservers and / or routes in leases as
> well as completely ignoring servers (you cannot block rogue DHCP servers
> in pf because bpf sees packets before pf).
> 
> Various people voiced the need for these features.
> Tests, OKs?
> 
> diff --git dhcpleased.conf.5 dhcpleased.conf.5
> index 9e6846f899e..b856113bac1 100644
> --- dhcpleased.conf.5
> +++ dhcpleased.conf.5
> @@ -57,6 +57,17 @@ A list of interfaces to overwrite defaults:
>  .Ic interface
>  options are as follows:
>  .Bl -tag -width Ds
> +.It Ic ignore dns
> +Ignore nameservers from leases on this interface.
> +The default is to not ignore nameservers.
> +.It Ic ignore routes
> +Ignore routes from leases on this interface.
> +The default is to not ignore routes.
> +.It Ic ignore Ar server-ip
> +Ignore leases from
> +.Ar server-ip .
> +This option can be listed multiple times.
> +The default is to not ignore servers.

hi.

you probably want

.It Ic ignore Ar server-ip ...

then you can either remove the "multiple times" text to shorten the
text block, or leave it in to be explicit.

the diff reads fine.

jmc

>  .It Ic send client id Ar client-id
>  Send the dhcp client identifier option with a value of
>  .Ar client-id .



Re: time.3: miscellaneous cleanup and rewrites

2021-07-30 Thread Jason McIntyre
On Fri, Jul 30, 2021 at 01:01:21PM -0500, Scott Cheloha wrote:
> Next up, time.3.
> 
> As before, changes by section, with "I don't knows" at the end of the
> change list in each section.
> 

hi. comments inline:

> NAME
> 
> - get "the" time of day.
> 
> SYNOPSIS
> 
> - Not a fan of the "tloc" variable name.  Use "now" as we do in other
>   pages to reinforce the meaning of its contents.
> 
> DESCRIPTION
> 
> - Clean this up.  In particular, format the Epoch date like we do in
>   other pages.  We don't need two paragraphs, either.
> 
> - Mention that we call gettimeofday(2).  Not strictly necessary, but
>   useful for people tracing system calls to know what the library
>   is doing.
> 
> Part of me wants to tell the reader not to use time() to measure
> elapsed time.  Then again, time() is low-res so it isn't misused
> nearly as often as gettimeofday(2).
> 
> I'm also leaning toward omitting the full description of the UTC clock
> and its behavior.  Not completely sure.
> 
> RETURN VALUES
> 
> - There are no relevant error cases, remove them.
> 
>   The underlying system call, gettimeofday(2), will not fail in this
>   context unless the stack is corrupted, which we cannot account for
>   anyway.
> 
> - Just say that time() always succeeds.
> 
> I cribbed this bit from another page to put something in the Return
> Values section, but the return value is already described in the
> Description.
> 
> Maybe we don't need this section at all anymore?
> 
> STANDARDS
> 
> - This section is missing.  Our time() conforms to the latest
>   standard.
> 
> HISTORY
> 
> - Rework this a bit.
> 
> - Note the fate of the historical time() system call.
> 
> Index: time.3
> ===
> RCS file: /cvs/src/lib/libc/gen/time.3,v
> retrieving revision 1.16
> diff -u -p -r1.16 time.3
> --- time.329 Jan 2015 01:46:30 -  1.16
> +++ time.330 Jul 2021 17:59:37 -
> @@ -36,52 +36,54 @@
>  .Os
>  .Sh NAME
>  .Nm time
> -.Nd get time of day
> +.Nd get the time of day

i'm honestly unconvinced about this. it makes more sense in normal
english rules, but feels incorrect. for comparison, posix uses

time - get time

i think in this sense "time of day" is a thing, and does not require an
article. i don;t see a good reason to change it.

>  .Sh SYNOPSIS
>  .In time.h
>  .Ft time_t
> -.Fn time "time_t *tloc"
> +.Fn time "time_t *now"
>  .Sh DESCRIPTION
>  The
>  .Fn time
> -function returns the value of time in seconds since 0 hours, 0 minutes,
> -0 seconds, January 1, 1970, Coordinated Universal Time (UTC).
> +function returns the the number of seconds elapsed since
> +Jan 1 1970 00:00:00 UTC.
> +This value is also written to
> +.Fa now
> +unless
> +.Fa now
> +is
> +.Dv NULL .
>  .Pp
> -A copy of the time value may be saved to the area indicated by the
> -pointer
> -.Fa tloc .
> -If
> -.Fa tloc
> -is a null pointer, no value is stored.
> +This version of
> +.Fn time
> +is implemented with
> +.Xr gettimeofday 2 .
>  .Sh RETURN VALUES
> -Upon successful completion,
> +The
>  .Fn time
> -returns the value of time.
> -Otherwise a value of
> -.Po Fa time_t Pc Ns -1
> -is returned and the global variable
> -.Va errno
> -is set to indicate the error.
> -.Sh ERRORS
> -The following error codes may be set in
> -.Va errno :
> -.Bl -tag -width Er
> -.It Bq Er EFAULT
> -An argument address referenced invalid memory.
> -.El
> +function is always successful,
> +and no return value is reserved to indicate an error.
>  .Sh SEE ALSO
>  .Xr clock_gettime 2 ,
>  .Xr gettimeofday 2 ,
>  .Xr ctime 3
> +.Sh STANDARDS
> +The
> +.Fn time
> +function conforms to
> +.St -p1003.1-2008 .
>  .Sh HISTORY
>  A
>  .Fn time
>  system call first appeared in
> -.At v1
> -and used to return time in sixtieths of a second in 32 bits,
> -which was to guarantee a crisis every 2.26 years.
> -Since
> -.At v6 ,
> -.Fn time
> -scale was changed to seconds, extending the pre-crisis stagnation
> -period up to a total of 68 years.
> +.At v1 .
> +This version counted time in sixtieths of a second with a 32-bit return 
> value,

i think the text should be *that* version

otherwise reads fine.
jmc

> +ensuring an integer overflow crisis every 2.26 years.
> +In
> +.At v6
> +the granularity of the return value was reduced to whole seconds,
> +delaying the aforementioned crisis until 2038.
> +In
> +.Bx 4.1c
> +the function was moved out of the kernel into the C standard library and
> +reimplemented with
> +.Xr gettimeofday 2 .
> 



Re: gettimeofday.2: miscellaneous cleanup and rewrites

2021-07-30 Thread Jason McIntyre
On Fri, Jul 30, 2021 at 09:41:38AM -0500, Scott Cheloha wrote:
> Hi,
> 
> The Description section in this page has always bugged me.  The author
> chose to save space by merging the description of two different system
> calls into a single paragraph.  Then the rules and caveats for
> settimeofday() are off in a separate paragraph.  Meh.
> 
> I recently revised the clock_gettime.2 page and I have bits I want to
> crib from there to improve this page.  Then there are other things on
> the page that nag at me.
> 
> Anyway, here are the changes by section.  Any questions or
> uncertainties I have are appended after the list in each section.
> 

reads fine to me.
jmc

> NAME
> 
> - Explicitly note that this is the UTC time.
> 
> I like the sound of "get or set the time of day" better, but the
> phrase "time of day" feels a little imprecise.  Unsure.
> 
> SYNOPSIS
> 
> - I think the variable name "tp" is mediocre.  Change "tp" to "now",
>   just like we did in clock_gettime.2.  "now" helps reinforce what the
>   variable represents.
> 
> - While here change "tzp" to "tz".  If we have no "tp" we don't need
>   the trailing 'p' for consistency.
> 
> DESCRIPTION
> 
> - Talk about gettimeofday() first, in its own paragraph.  It is the most
>   important interface here and belongs right at the top.
> 
> - Then describe the UTC clock itself.  Call it "UTC," not "Greenwich
>   time".  Describe how the clock behaves, too.
> 
>   I think a discussion of the granularity of the clock is outside the
>   scope of this page.  Tick-based timecounters (i.e., those that are
>   only advanced during the clock interrupt) are exceedingly rare. The
>   time is almost always kept by a dedicated hardware counter.
> 
>   Explicitly discourage people from using gettimeofday() to measure
>   elapsed time.  Point them to clock_gettime(2).
> 
> - Then talk about settimeofday().  Merge the settimeofday() paragraph
>   with the paragraph describing its rules and caveats.
> 
>   I don't think we need to mention that adjtime(2) can still slow the
>   effective clock frequency when securelevel >= 2.  The adjustment is
>   capped at 5000ppm, which hardly cripples the system.  You can do way,
>   way more damage with the newer adjfreq(2) call, anyway, and I don't
>   want to mention both.
> 
>   I *do* think we ought to mention that settimeofday(2) cancels
>   whatever adjtime(2) was doing.  That is a side effect of the call
>   and we need to mention it explicitly.
> 
> - Update the timeval structure description to match the current code
>   in sys/time.h
> 
> - Last and very much least, the historical timezone parameter.
> 
>   Clarify that we no longer keep timezone information in the
>   kernel, not that we just don't track it at all.
> 
>   Use active voice when describing the consequences when tz is not
>   NULL.
> 
> I am a little uncertain about telling the reader not to use
> gettimeofday() to measure time right in the middle of the Description.
> That said, it's an extremely common mistake, and I don't think it
> should be appended in Caveats.
> 
> Thoughts?
> 
> SEE ALSO
> 
> - Reference timeradd(3).  We're working with timevals on this page.
> 
> ERRORS
> 
> - Simplify leading sentences.
> 
> - Use more active voice.
> 
> - Strictly speaking, you don't need to try to set the time to get
>   EPERM.  Any unprivileged process gets EPERM when it calls
>   settimeofday(), even if the first argument is NULL.  More accurate to
>   say that the caller wasn't root, not what the caller tried to do.
> 
> - Document the securelevel(7) EPERM error.
> 
> Should we document the other error, the UINT_MAX seconds cap?  See
> settime() in sys/kern/kern_time.c.  I'm leaning towards "no".
> 
> STANDARDS
> 
> - settimeofday() has never been standardized, but it's available
>   everywhere.  I think we should note this.  It's not unique to
>   us, or even to BSD.  Linux, Solaris, AIX, whatever, they all
>   have it.
> 
> HISTORY
> 
> I want to rework the first sentence here but I'm stumped at the
> moment.  I'll circle back to it.
> 
> CAVEATS
> 
> Should this warning be here?  Isn't this more relevant to a system
> administrator in the date(1) page?
> 
> It feels out of scope for a system call manpage to be making
> recommendations about rebooting the system after you use it.  A system
> administrator doesn't use the settimeofday(2) system call directly,
> nor are they necessarily even aware of the underlying system call at
> all.  They use a tool like date(1) to set the clock.
> 
> Thoughts?
> 
> --
> 
> Index: gettimeofday.2
> ===
> RCS file: /cvs/src/lib/libc/sys/gettimeofday.2,v
> retrieving revision 1.31
> diff -u -p -r1.31 gettimeofday.2
> --- gettimeofday.24 Sep 2019 14:27:55 -   1.31
> +++ gettimeofday.230 Jul 2021 14:37:46 -
> @@ -35,97 +35,121 @@
>  .Sh NAME
>  .Nm gettimeofday ,
>  .Nm settimeofday
> -.Nd get/set date and time
> +.Nd get or set the UTC time
>  

Re: tpmr manpage add veb reference

2021-07-27 Thread Jason McIntyre
On Tue, Jul 27, 2021 at 10:18:10PM +0200, Sebastian Benoit wrote:
> tpmr(4) connects only two ethernet ports with not much functionality, so the
> manpage is helpful by telling us bridge(4) as a more complete alternative.
> We now also have veb(4), so mention that as well.
> 
> ok?
> 
> diff --git share/man/man4/tpmr.4 share/man/man4/tpmr.4
> index ab9eba4cee3..de0b200d429 100644
> --- share/man/man4/tpmr.4
> +++ share/man/man4/tpmr.4
> @@ -43,7 +43,9 @@ configuration file for
>  .Pp
>  Other forms of Ethernet bridging are available using the
>  .Xr bridge 4
> -driver.
> +Ethernet bridge driver and the
> +.Xr veb 4
> +Virtual Ethernet Bridge device.
>  Link aggregation of Ethernet interfaces can be achieved
>  using the
>  .Xr aggr 4
> @@ -145,6 +147,7 @@ interfaces.
>  .Xr bridge 4 ,
>  .Xr pf 4 ,
>  .Xr trunk 4 ,
> +.Xr veb 4 ,
>  .Xr hostname.if 5 ,
>  .Xr ifconfig 8 ,
>  .Xr netstart 8
> 

morning.

so tpmr(4), which is a small page anyway, says:


 A TPMR is a simplified Ethernet bridge that provides
 a subset of the functionality as found in bridge(4).
and
 Other forms of Ethernet bridging are available using the
 bridge(4) driver.

that's in (the only) 9 lines of text in DESCRIPTION. maybe the first
paragraph could read like this:

DESCRIPTION
 The tpmr driver implements an 802.1Q (originally 802.1aj)
 Two-Port MAC Relay (TPMR).  A TPMR is a simplified Ethernet
 bridge with exactly two member ports, and it
 unconditionally relays Ethernet packets between those ports.

then you could use your changes to expand the reference to bridge and
veb.

jmc



Re: sleep.3: miscellaneous cleanup and rewrites

2021-07-25 Thread Jason McIntyre
On Sun, Jul 25, 2021 at 02:30:01PM -0500, Scott Cheloha wrote:
> On Sun, Jul 25, 2021 at 08:15:34AM +0100, Jason McIntyre wrote:
> > On Sat, Jul 24, 2021 at 10:39:49PM -0500, Scott Cheloha wrote:
> > > Okay, the nanosleep.2 changes are committed, let's do sleep.3 next.
> > 
> > hi.
> > 
> > the changes read fine to me. only one comment:
> > 
> > > [...]
> > > 
> > > STANDARDS
> > > 
> > > - Bump the relevant standard to POSIX.1-2001.  That version
> > >   incorporates details about threads, which our version respects.
> > > 
> > >   For sake of completeness, I will note that SUSv2 mentions threads
> > >   too:
> > > 
> > >   https://pubs.opengroup.org/onlinepubs/7908799/xsh/sleep.html
> > > 
> > >   SUSv2 is older than POSIX.1-2001.  Do we prefer the earlier
> > >   standard?
> > > 
> > 
> > no, we tend to reference the latest spec.
> 
> So, should I just say we conform to POSIX.1-2008?
> 

yes, assuming that you're happy that it's conformant.
jmc

> There were no changes to the sleep() spec in that edition relevant to
> our implementation.  If sleep() is based on nanosleep() the spec
> hasn't changed in any meaningful way since 2001.  All the changes
> since then are about the SIGALRM approach, which seems to be on its
> way out.
> 



Re: sleep.3: miscellaneous cleanup and rewrites

2021-07-25 Thread Jason McIntyre
On Sat, Jul 24, 2021 at 10:39:49PM -0500, Scott Cheloha wrote:
> Okay, the nanosleep.2 changes are committed, let's do sleep.3 next.
> 

hi.

the changes read fine to me. only one comment:

> Here's a changelist by section.  I have some questions in there at end
> of sections where I'm unsure about something.
> 
> NAME
> 
> - This is clunky.  Tighten it up.
> 
> - It's also wrong.  Remove reference to the process: sleep suspends
>   the calling thread.
> 
> DESCRIPTION
> 
> - Again, it suspends the thread, not the process.
> 
> - If we borrow language/style from nanosleep.2 we can condense this
>   first paragraph into a single sentence.
> 
> - In the second paragraph I don't think we need to talk about SIGALRM
>   explicitly.  It isn't relevant to our implementation.
> 
>   I think such comments belong in the Standards section.  See below.
> 
> - Probably worth mentioning the sole implication of an implementation
>   based on nanosleep(2) here instead of telling the reader to schlep
>   off to that page to get the details there.
> 
> I'm not positive about cutting the discussion of timers and SIGALARM
> here.  My thinking is: here in 2021, the fact that our sleep() doesn't
> touch the process timer or the signal mask doesn't seem significant
> enough to warrant inclusion.  I wonder if this detail confuses some
> readers ("why are they bringing this up?").
> 
> RETURN VALUES
> 
> - Tighten this up.
> 
> - Prefer a literal "0" for an integral return value.
> 
> Should we mention that sleep(3) can set errno?
> 
> If so, do we need to mention how to check whether it was interrupted
> by a signal?  It's similar to other libc syscall wrappers:
> 
>   errno = 0;
>   sleep(...);
>   if (errno != 0)
>   warn("sleep");
> 
> No, you can't just check if the return value is greater than 0.  If we
> get a signal but the scheduler doesn't choose to run us until after
> the timeout has elapsed we'll get 0 back but errno will be set.  No
> way to avoid this race.
> 
> ERRORS
> 
> Is this section missing?  Maybe just a nod to nanosleep(2), like:
> 
>   The sleep() function may fail for any of the reasons
>   given in nanosleep(2).
> 
> Something else?
> 
> SEE ALSO
> 
> - Add sigaction(2).  We mention SA_RESTART and signals in the
>   Description.
> 
> STANDARDS
> 
> - Bump the relevant standard to POSIX.1-2001.  That version
>   incorporates details about threads, which our version respects.
> 
>   For sake of completeness, I will note that SUSv2 mentions threads
>   too:
> 
>   https://pubs.opengroup.org/onlinepubs/7908799/xsh/sleep.html
> 
>   SUSv2 is older than POSIX.1-2001.  Do we prefer the earlier
>   standard?
> 

no, we tend to reference the latest spec.
jmc

> - Mention the two possible implementations.  Mention that they
>   are not the same and might behave differently.  Offer a
>   solution for portable applications.
> 
> For the portability paragraph I'm just spitballing.  No idea what the
> right language is here or what recommendations are appropriate.
> 
> In general, the nanosleep() spec is simple and the sleep() spec is
> complex due to some historical mishaps.  From a spec perspective,
> nanosleep(2) is the safer bet because you know what you're getting,
> warts and all.
> 
> However:
> 
> I honestly haven't looked very deeply into the specific behavioral
> differences between the two approaches, I'm just taking POSIX at their
> word.  We have an old-school implementation in CVS:
> 
> http://cvsweb.openbsd.org/src/lib/libc/gen/sleep.c?rev=1.6=text/x-cvsweb-markup
> 
> ... at a glance I can imagine how it might behave differently from the
> current approach:
> 
> http://cvsweb.openbsd.org/src/lib/libc/gen/sleep.c?rev=1.13=text/x-cvsweb-markup
> 
> I also don't know where you would find an alarm(3)-based approach
> anymore.  I caveat my recommendation with the "although the
> alarm(3)-based approach is increasingly rare" bit to acknowledge this,
> though still I feel like we ought to say something, just in case.
> 
> HISTORY
> 
> - I cannot find a sleep() system call in Research UNIX v2.
> 
>   I can find it in v3:
> 
>   
> https://github.com/dspinellis/unix-history-repo/blob/Research-V3/man/man2/sleep.2
> 
>   So, change ".At v2" to ".At v3".
> 
> I must admit I have a hard time tracking the changes in the Research
> UNIX code.  Shit moves around *constantly*.  So sleep() might indeed
> be in v2 and I'm just not seeing it.
> 
> --
> 
> Index: sleep.3
> ===
> RCS file: /cvs/src/lib/libc/gen/sleep.3,v
> retrieving revision 1.16
> diff -u -p -r1.16 sleep.3
> --- sleep.3   8 Feb 2020 01:09:57 -   1.16
> +++ sleep.3   25 Jul 2021 03:27:27 -
> @@ -32,7 +32,7 @@
>  .Os
>  .Sh NAME
>  .Nm sleep
> -.Nd suspend process execution for interval measured in seconds
> +.Nd suspend execution for a count of seconds
>  .Sh SYNOPSIS
>  .In unistd.h
>  .Ft unsigned int
> @@ -40,46 +40,57 @@
>  .Sh DESCRIPTION
>  

Re: cron(8): add '@' interval time specifier

2021-07-10 Thread Jason McIntyre
On Sat, Jul 10, 2021 at 02:07:53PM +, Job Snijders wrote:
> Hi all,
> 
> The below patch adds a new kind of time specifier: an interval (in
> minutes). When used, cron(8) will schedule the next instance of a job
> after the previous job has completed and a full interval has passed. 
> 
> A crontab(5) configured as following:
> 
> $ crontab -l
> @3 sleep 100
> 
> Will result in this schedule:
> 
> Jul 10 13:38:17 vurt cron[96937]: (CRON) STARTUP (V5.0)
> Jul 10 13:42:01 vurt cron[79385]: (job) CMD (sleep 100)
> Jul 10 13:47:01 vurt cron[3165]: (job) CMD (sleep 100)
> Jul 10 13:52:01 vurt cron[40539]: (job) CMD (sleep 100)
> Jul 10 13:57:01 vurt cron[84504]: (job) CMD (sleep 100)
> 
> A use case could be running rpki-client more frequently than once an
> hour:
> 
> @15 -n rpki-client && bgpctl reload
> 
> The above is equivalent to:
> 
> * * * * * -sn sleep 900 && rpki-client && bgpctl reload
> 
> I borrowed the idea from FreeBSD's cron [1]. A difference between the
> below changeset and the freebsd implementation is that they specify the
> interval in seconds, while the below specifies in minutes. I was able
> to leverage the 'singleton' infrastructure. And removed a comment that
> reads like a TODO nobody is going to do.
> 
> Thoughts?
> 
> Kind regards,
> 
> Job
> 

hi.

just to be clear - the point here is that you don;t know how long a job
takes to run, so you can't specify the interval in the normal way?

the doc changes look fine, but i have some suggestions:

> Index: crontab.5
> ===
> RCS file: /cvs/src/usr.sbin/cron/crontab.5,v
> retrieving revision 1.41
> diff -u -p -r1.41 crontab.5
> --- crontab.5 18 Apr 2020 17:11:40 -  1.41
> +++ crontab.5 10 Jul 2021 13:38:13 -
> @@ -265,7 +265,7 @@ For example,
>  would cause a command to be run at 4:30 am on the 1st and 15th of each
>  month, plus every Friday.
>  .Pp
> -Instead of the first five fields, one of eight special strings may appear:
> +Instead of the first five fields, one of nine special strings may appear:

instead of being specific about numbers, we could just say "one of these
special strings". then we don;t have to keep changing the text.

>  .Bl -column "@midnight" "meaning" -offset indent
>  .It Sy string Ta Sy meaning
>  .It @reboot Ta Run once, at startup.
> @@ -276,6 +276,14 @@ Instead of the first five fields, one of
>  .It @daily Ta Run every midnight (0 0 * * *).
>  .It @midnight Ta The same as @daily.
>  .It @hourly Ta Run every hour, on the hour (0 * * * *).
> +.It Pf @ Ar minutes Ta The

the field "minutes" could be confusing, because the other fields
are similar type (hourly, daily, etc) and literal, whereas this is
an argument name. would it be clearer to use sth like "n", a more
common arg name for an arbitrary number, which would also match
your text "followed by a numeric value"?

that's not a request, it's a question ;)

> +.Sq @
> +symbol followed by a numeric value has a special notion of running a job
> +after an interval specified in minutes has passed, and the previous
> +instance has completed.
> +The first run is scheduled at a full interval after
> +.Xr cron 8
> +started.

i hate how every other entry here is a succint one-liner, and this
addition is a block. i wonder if we could be super trim here, and
be more expansive using an example. i already feel from the text
that i don;t really understand when i might use this, so an example
might help.

for example:

...
@n  Run after previous job + "n" minutes have elapsed.
...
EXAMPLES
...
# the gories
#
#
@15 -n rpki-client && bgpctl reload

jmc

>  .El
>  .Sh ENVIRONMENT
>  .Bl -tag -width "LOGNAMEXXX"
> @@ -346,7 +354,9 @@ MAILTO=paul
>  5 4 * * sun echo "run at 5 after 4 every sunday"
>  
>  # run hourly at a random time within the first 30 minutes of the hour
> -0~30 * * * *   /usr/libexec/spamd-setup
> +0~30 * * * */usr/libexec/spamd-setup
> +
> +@10 sleep 180 && echo "starts every 13 minutes, implies -s"
>  .Ed
>  .Sh SEE ALSO
>  .Xr crontab 1 ,
> @@ -372,6 +382,8 @@ Random intervals are supported using the
>  character.
>  .It
>  Months or days of the week can be specified by name.
> +.It
> +Interval mode.
>  .It
>  Environment variables can be set in a crontab.
>  .It



Re: mandoc style warning about text lines > 80 bytes

2021-06-26 Thread Jason McIntyre
On Sat, Jun 26, 2021 at 07:20:52PM +0200, Ingo Schwarze wrote:
> 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
> >> such a warning... With those wrapped,
>  
> > yes, there is no feedback on long lines. although we try to keep the
> > source less than 80 width, there are some places where it is not
> > possible.
> > 
> > i'm not sure whether adding a warning would be helpful or disruptive.
> 
> Here is a patch implementing such a style warning, leaning very
> heavily into the direction of never producing false positives, that
> is, not warning about long lines
> 
>  - in no-fill mode (e.g., .Bd -literal, .EX, .nf and the like)
>  - that start with a dot (normal macro and request lines)
>or with a non-standard control character
>  - that start with a space character or with an escape sequence
>  - in tbl(7) context
>  - in eqn(7) context
>  - that do not contain a blank character before column 80
> 
> So, this certainly does not find all long lines that can be improved,
> but everything it finds ought to be trivial and worthwhile to fix.
> 
> There are less than twenty-five offenders below /usr/src/share/man/,
> and none of those are false positives.
> 
> However, i see over twenty-three thousand offending lines
> below /usr/share/man/, the vast majority in Perl manual pages
> and considerable amounts in other third-party stuff like GCC
> and binutils.
> The worst offenders we maintain ourselves are tmux(1) with 15
> offending lines, terminfo(5) with 11, mkhybrid(8) with 6, tic(1),
> magic(5), sysctl(2), cdio(1), and the rest with three or less
> offending lines each, maybe a few dozen offending files all told.
> 

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.

> I don't think such a patch would be disruptive.  I expect most of the
> third-party manuals it flags already have many other warnings.
> Our own stuff does not have large amounts of issues due to Jason's
> diligent manual work.
> 
> Does it help?  Maybe it could slightly reduce one aspect of Jason's
> workload and help developers who want to find their own glitches in
> this respect, in particular those usually working on terminals wider
> than 80 columns.
> 
> There is no need to chase all of these down, but the style warning
> might help when editing a page for other reasons.
> 
> What do you think?
>   Ingo

i have no strong opinions. it actually doesn;t really touch anything i
do - i never check pages for long lines, though i do shorten them if i'm
doing other stuff on a page. i guess the question is more if others
would find it handy to have it flagged, or disruptive.

on balance, i'd be fine with such an addition.

jmc

> 
> 
> P.S.
> The following script makes it easy to count violations:
> 
> mandoc -T lint */*.[1-9]* */*/*.[1-9]* | \
>   grep 'longer than' | \
>   cut -d : -f 2 | \
>   uniq -c | \
>   sort -nr
> 
> 
> Index: libmandoc.h
> ===
> RCS file: /cvs/src/usr.bin/mandoc/libmandoc.h,v
> retrieving revision 1.64
> diff -u -p -r1.64 libmandoc.h
> --- libmandoc.h   3 Apr 2020 11:34:19 -   1.64
> +++ libmandoc.h   26 Jun 2021 16:19:03 -
> @@ -73,7 +73,7 @@ void roff_reset(struct roff *);
>  void  roff_man_free(struct roff_man *);
>  struct roff_man  *roff_man_alloc(struct roff *, const char *, int);
>  void  roff_man_reset(struct roff_man *);
> -int   roff_parseln(struct roff *, int, struct buf *, int *);
> +int   roff_parseln(struct roff *, int, struct buf *, int *, size_t);
>  void  roff_userret(struct roff *);
>  void  roff_endparse(struct roff *);
>  void  roff_setreg(struct roff *, const char *, int, char);
> Index: mandoc.1
> ===
> RCS file: /cvs/src/usr.bin/mandoc/mandoc.1,v
> retrieving revision 1.175
> diff -u -p -r1.175 mandoc.1
> --- mandoc.1  2 Jun 2021 18:27:36 -   1.175
> +++ mandoc.1  26 Jun 2021 16:19:04 -
> @@ -1066,6 +1066,9 @@ An
>  request occurs even though the document already switched to no-fill mode
>  and did not switch back to fill mode yet.
>  It has no effect.
> +.It Sy "input text line longer than 80 bytes"
> +Consider breaking the input text line
> +at one of the blank characters 

Re: timeout.9: document kclock timeouts + a bunch of other changes

2021-06-24 Thread Jason McIntyre
On Thu, Jun 24, 2021 at 05:39:56PM -0500, Scott Cheloha wrote:
> On Thu, Jun 24, 2021 at 06:51:07AM +0100, Jason McIntyre wrote:
> > On Wed, Jun 23, 2021 at 06:57:00PM -0500, Scott Cheloha wrote:
> > > Hi,
> > > 
> > > I want to document kclock timeouts so others can use them.
> > 
> > morning. reads fine, except one issue:
> > 
> > [...]
> > 
> > > +.Bl -tag -width kclock
> > > +.It Fa kclock
> > > +The timeout is scheduled against the given
> > > +.Fa kclock,
> > 
> > you need a space between kclock and the comma
> 
> Huh, I'm a little surprised -Tlint doesn't flag that.
> 

it did! you must have just missed it somehow.

> Fixed.
> 
> Are there any other mdoc(7)-type stylistic anachronisms we can fix up?
> 

everything else looked ok.
jmc

> Index: share/man/man9/timeout.9
> ===
> RCS file: /cvs/src/share/man/man9/timeout.9,v
> retrieving revision 1.53
> diff -u -p -r1.53 timeout.9
> --- share/man/man9/timeout.9  11 May 2021 13:29:25 -  1.53
> +++ share/man/man9/timeout.9  24 Jun 2021 22:37:38 -
> @@ -44,7 +44,7 @@
>  .Nm timeout_triggered ,
>  .Nm TIMEOUT_INITIALIZER ,
>  .Nm TIMEOUT_INITIALIZER_FLAGS
> -.Nd execute a function after a specified period of time
> +.Nd execute a function in the future
>  .Sh SYNOPSIS
>  .In sys/types.h
>  .In sys/timeout.h
> @@ -55,12 +55,13 @@
>  .Fa "struct timeout *to"
>  .Fa "void (*fn)(void *)"
>  .Fa "void *arg"
> +.Fa "int kclock"
>  .Fa "int flags"
>  .Fc
>  .Ft void
>  .Fn timeout_set_proc "struct timeout *to" "void (*fn)(void *)" "void *arg"
>  .Ft int
> -.Fn timeout_add "struct timeout *to" "int ticks"
> +.Fn timeout_add "struct timeout *to" "int nticks"
>  .Ft int
>  .Fn timeout_del "struct timeout *to"
>  .Ft int
> @@ -83,174 +84,218 @@
>  .Fn timeout_add_usec "struct timeout *to" "int usec"
>  .Ft int
>  .Fn timeout_add_nsec "struct timeout *to" "int nsec"
> -.Fn TIMEOUT_INITIALIZER "void (*fn)(void *)" "void *arg"
> -.Fn TIMEOUT_INITIALIZER_FLAGS "void (*fn)(void *)" "void *arg" "int flags"
> +.Ft int
> +.Fn timeout_in_nsec "struct timeout *to" "uint64_t nsecs"
> +.Ft int
> +.Fn timeout_at_ts "struct timeout *to" "const struct timespec *abs"
> +.Fo TIMEOUT_INITIALIZER
> +.Fa "void (*fn)(void *)"
> +.Fa "void *arg"
> +.Fc
> +.Fo TIMEOUT_INITIALIZER_FLAGS
> +.Fa "void (*fn)(void *)"
> +.Fa "void *arg"
> +.Fa "int kclock"
> +.Fa "int flags"
> +.Fc
>  .Sh DESCRIPTION
>  The
>  .Nm timeout
> -API provides a mechanism to execute a function at a given time.
> -The granularity of the time is limited by the granularity of the
> -.Xr hardclock 9
> -timer which executes
> -.Xr hz 9
> -times a second.
> +API provides a mechanism to schedule a function for asynchronous
> +execution in the future.
>  .Pp
> -It is the responsibility of the caller to provide these functions with
> -pre-allocated timeout structures.
> +All state is encapsulated in a caller-allocated timeout structure
> +.Pq hereafter, a Qo timeout Qc .
> +A timeout must be initialized before it may be used as input to other
> +functions in the API.
>  .Pp
>  The
>  .Fn timeout_set
> -function prepares the timeout structure
> -.Fa to
> -to be used in future calls to
> -.Fn timeout_add
> -and
> -.Fn timeout_del .
> -The timeout will be prepared to call the function specified by the
> +function initializes the timeout
> +.Fa to .
> +When executed,
> +the timeout will call the function
>  .Fa fn
> -argument with a
> -.Fa void *
> -argument given in the
> +with
>  .Fa arg
> -argument.
> -Once initialized, the
> -.Fa to
> -structure can be used repeatedly in
> -.Fn timeout_add
> -and
> -.Fn timeout_del
> -and does not need to be reinitialized unless
> -the function called and/or its argument must change.
> +as its first parameter.
> +The timeout is implicitly scheduled against the
> +.Dv KCLOCK_NONE
> +clock and is not configured with any additional flags.
>  .Pp
>  The
>  .Fn timeout_set_flags
>  function is similar to
> -.Fn timeout_set
> -but it additionally accepts the bitwise OR of zero or more of the
> -following
> +.Fn timeout_set ,
> +except that it takes two additional parameters:
> +.Bl -tag -width kclock
> +.It Fa kclock
> +The timeout

Re: timeout.9: document kclock timeouts + a bunch of other changes

2021-06-23 Thread Jason McIntyre
On Wed, Jun 23, 2021 at 06:57:00PM -0500, Scott Cheloha wrote:
> Hi,
> 
> I want to document kclock timeouts so others can use them.
> 

morning. reads fine, except one issue:

> 
> Index: share/man/man9/timeout.9
> ===
> RCS file: /cvs/src/share/man/man9/timeout.9,v
> retrieving revision 1.53
> diff -u -p -r1.53 timeout.9
> --- share/man/man9/timeout.9  11 May 2021 13:29:25 -  1.53
> +++ share/man/man9/timeout.9  23 Jun 2021 23:39:04 -
> @@ -44,7 +44,7 @@
>  .Nm timeout_triggered ,
>  .Nm TIMEOUT_INITIALIZER ,
>  .Nm TIMEOUT_INITIALIZER_FLAGS
> -.Nd execute a function after a specified period of time
> +.Nd execute a function in the future
>  .Sh SYNOPSIS
>  .In sys/types.h
>  .In sys/timeout.h
> @@ -55,12 +55,13 @@
>  .Fa "struct timeout *to"
>  .Fa "void (*fn)(void *)"
>  .Fa "void *arg"
> +.Fa "int kclock"
>  .Fa "int flags"
>  .Fc
>  .Ft void
>  .Fn timeout_set_proc "struct timeout *to" "void (*fn)(void *)" "void *arg"
>  .Ft int
> -.Fn timeout_add "struct timeout *to" "int ticks"
> +.Fn timeout_add "struct timeout *to" "int nticks"
>  .Ft int
>  .Fn timeout_del "struct timeout *to"
>  .Ft int
> @@ -83,174 +84,218 @@
>  .Fn timeout_add_usec "struct timeout *to" "int usec"
>  .Ft int
>  .Fn timeout_add_nsec "struct timeout *to" "int nsec"
> -.Fn TIMEOUT_INITIALIZER "void (*fn)(void *)" "void *arg"
> -.Fn TIMEOUT_INITIALIZER_FLAGS "void (*fn)(void *)" "void *arg" "int flags"
> +.Ft int
> +.Fn timeout_in_nsec "struct timeout *to" "uint64_t nsecs"
> +.Ft int
> +.Fn timeout_at_ts "struct timeout *to" "const struct timespec *abs"
> +.Fo TIMEOUT_INITIALIZER
> +.Fa "void (*fn)(void *)"
> +.Fa "void *arg"
> +.Fc
> +.Fo TIMEOUT_INITIALIZER_FLAGS
> +.Fa "void (*fn)(void *)"
> +.Fa "void *arg"
> +.Fa "int kclock"
> +.Fa "int flags"
> +.Fc
>  .Sh DESCRIPTION
>  The
>  .Nm timeout
> -API provides a mechanism to execute a function at a given time.
> -The granularity of the time is limited by the granularity of the
> -.Xr hardclock 9
> -timer which executes
> -.Xr hz 9
> -times a second.
> +API provides a mechanism to schedule an arbitrary function for asynchronous
> +execution in the future.
>  .Pp
> -It is the responsibility of the caller to provide these functions with
> -pre-allocated timeout structures.
> +All state is encapsulated in a caller-allocated timeout structure
> +.Pq hereafter, a Qo timeout Qc .
> +A timeout must be initialized before it may be used as input to other
> +functions in the API.
>  .Pp
>  The
>  .Fn timeout_set
> -function prepares the timeout structure
> -.Fa to
> -to be used in future calls to
> -.Fn timeout_add
> -and
> -.Fn timeout_del .
> -The timeout will be prepared to call the function specified by the
> +function initializes the timeout
> +.Fa to .
> +When executed,
> +the timeout will call the function
>  .Fa fn
> -argument with a
> -.Fa void *
> -argument given in the
> +with
>  .Fa arg
> -argument.
> -Once initialized, the
> -.Fa to
> -structure can be used repeatedly in
> -.Fn timeout_add
> -and
> -.Fn timeout_del
> -and does not need to be reinitialized unless
> -the function called and/or its argument must change.
> +as its first parameter.
> +The timeout is implicitly scheduled against the
> +.Dv KCLOCK_NONE
> +clock and is not configured with any additional flags.
>  .Pp
>  The
>  .Fn timeout_set_flags
>  function is similar to
> -.Fn timeout_set
> -but it additionally accepts the bitwise OR of zero or more of the
> -following
> +.Fn timeout_set ,
> +except that it takes two additional parameters:
> +.Bl -tag -width kclock
> +.It Fa kclock
> +The timeout is scheduled against the given
> +.Fa kclock,

you need a space between kclock and the comma

jmc

> +which must be one of the following:
> +.Bl -tag -width KCLOCK_UPTIME
> +.It Dv KCLOCK_NONE
> +Low resolution tick-based clock.
> +The granularity of this clock is limited by the
> +.Xr hardclock 9 ,
> +which executes roughly
> +.Xr hz 9
> +times per second.
> +.It Dv KCLOCK_UPTIME
> +The uptime clock.
> +Counts the time elapsed since the system booted.
> +.El
> +.It Fa flags
> +The timeout's behavior may be configured with the bitwise OR of
> +zero or more of the following
>  .Fa flags :
> -.Bl -tag -width TIMEOUT_PROC -offset indent
> +.Bl -tag -width TIMEOUT_PROC
>  .It Dv TIMEOUT_PROC
> -Runs the timeout in a process context instead of the default
> +Execute the timeout in a process context instead of the default
>  .Dv IPL_SOFTCLOCK
>  interrupt context.
>  .El
> +.El
>  .Pp
>  The
>  .Fn timeout_set_proc
> -function is similar to
> +function is equivalent to
> +.Fn timeout_set ,
> +except that the given timeout is configured with the
> +.Dv TIMEOUT_PROC
> +flag.
> +.Pp
> +A timeout may also be initialized statically.
> +The
> +.Fn TIMEOUT_INITIALIZER
> +macro is equivalent to the
>  .Fn timeout_set
> -but it runs the timeout in a process context instead of the default
> -.Dv IPL_SOFTCLOCK
> -interrupt context.
> +function,
> +and the
> +.Fn 

Re: disklabel(8): reduce usage()

2021-06-22 Thread Jason McIntyre
On Tue, Jun 22, 2021 at 12:36:02PM -0600, Todd C. Miller wrote:
> On Tue, 22 Jun 2021 13:34:43 +0100, Jason McIntyre wrote:
> 
> > diff to reduce verbosity in disklabel(8) usage. before:
> 
> OK.  Should we also remove SEEALSO from sbin/disklabel/Makefile
> and distrib/special/disklabel/Makefile?
> 
>  - todd
> 

ah, now i see the point of SEEALSO! how about this?
(completely untested for distrib/special)

jmc

Index: distrib/special/disklabel/Makefile
===
RCS file: /cvs/src/distrib/special/disklabel/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- distrib/special/disklabel/Makefile  21 Jul 2020 13:56:09 -  1.11
+++ distrib/special/disklabel/Makefile  22 Jun 2021 20:09:55 -
@@ -25,25 +25,6 @@ manual.c:disklabel.cat8
echo '};'; echo 'const int manpage_sz = sizeof(manpage);') > manual.c
 .endif
 
-.if ${MACHINE} == "alpha"
-CFLAGS+= -DSEEALSO="\"installboot(8)\""
-.endif
-
-.if ${MACHINE} == "amd64" || ${MACHINE} == "i386" || \
-${MACHINE} == "octeon" || ${MACHINE} == "loongson" || \
-${MACHINE} == "armv7" || ${MACHINE} == "arm64" || \
-${MACHINE} == "landisk" || ${MACHINE} == "powerpc64"
-CFLAGS+= -DSEEALSO="\"fdisk(8), installboot(8)\""
-.endif
-
-.if ${MACHINE} == "macppc"
-CFLAGS+= -DSEEALSO="\"fdisk(8), pdisk(8), installboot(8)\""
-.endif
-
-.if ${MACHINE} == "sparc64"
-CFLAGS+= -DSEEALSO="\"installboot(8)\"" -DSUN_CYLCHECK -DSUN_AAT0
-.endif
-
 .ifdef NOPIC
 CFLAGS+= -DSTATICLINKING
 .endif
Index: sbin/disklabel/Makefile
===
RCS file: /cvs/src/sbin/disklabel/Makefile,v
retrieving revision 1.68
diff -u -p -r1.68 Makefile
--- sbin/disklabel/Makefile 21 Jul 2020 13:56:08 -  1.68
+++ sbin/disklabel/Makefile 22 Jun 2021 20:09:55 -
@@ -25,23 +25,4 @@ manual.c:disklabel.cat8
echo '};'; echo 'const int manpage_sz = sizeof(manpage);') > manual.c
 .endif
 
-.if ${MACHINE} == "alpha"
-CFLAGS+= -DSEEALSO="\"installboot(8)\""
-.endif
-
-.if ${MACHINE} == "amd64" || ${MACHINE} == "i386" || \
-${MACHINE} == "octeon" || ${MACHINE} == "loongson" || \
-${MACHINE} == "armv7" || ${MACHINE} == "arm64" || \
-${MACHINE} == "landisk" || ${MACHINE} == "powerpc64"
-CFLAGS+= -DSEEALSO="\"fdisk(8), installboot(8)\""
-.endif
-
-.if ${MACHINE} == "macppc"
-CFLAGS+= -DSEEALSO="\"fdisk(8), pdisk(8), installboot(8)\""
-.endif
-
-.if ${MACHINE} == "sparc64"
-CFLAGS+= -DSEEALSO="\"installboot(8)\"" -DSUN_CYLCHECK -DSUN_AAT0
-.endif
-
 .include 
Index: sbin/disklabel/disklabel.c
===
RCS file: /cvs/src/sbin/disklabel/disklabel.c,v
retrieving revision 1.236
diff -u -p -r1.236 disklabel.c
--- sbin/disklabel/disklabel.c  14 Nov 2020 20:53:31 -  1.236
+++ sbin/disklabel/disklabel.c  22 Jun 2021 20:09:55 -
@@ -1212,28 +1212,15 @@ void
 usage(void)
 {
fprintf(stderr,
-   "usage: disklabel[-Acdtv] [-h | -p unit] [-T file] 
disk\t(read)\n");
+   "usage: disklabel[-Acdtv] [-h | -p unit] [-T file] disk\n");
fprintf(stderr,
-   "   disklabel -w [-Acdnv] [-T file] disk disktype 
[packid]\t(write)\n");
+   "   disklabel -w [-Acdnv] [-T file] disk disktype [packid]\n");
fprintf(stderr,
-   "   disklabel -e [-Acdnv] [-T file] disk\t\t\t(edit)\n");
+   "   disklabel -e [-Acdnv] [-T file] disk\n");
fprintf(stderr,
-   "   disklabel -E [-Acdnv] [-F|-f file] [-T file] disk\t(simple 
editor)"
-   "\n");
+   "   disklabel -E [-Acdnv] [-F|-f file] [-T file] disk\n");
fprintf(stderr,
-   "   disklabel -R [-nv] [-F|-f file] disk 
protofile\t\t(restore)\n\n");
-   fprintf(stderr,
-   "`disk' may be of the form: sd0 or /dev/rsd0%c.\n", 'a'+RAW_PART);
-   fprintf(stderr,
-   "`disktype' is an entry from %s, see disktab(5) for more info.\n",
-   DISKTAB);
-   fprintf(stderr,
-   "`packid' is an identification string for the device.\n");
-   fprintf(stderr,
-   "`protofile' is the output from the read cmd form; -R is 
powerful.\n");
-#ifdef SEEALSO
-   fprintf(stderr,
-   "For procedures specific to this architecture see: %s\n", SEEALSO);
-#endif
+   "   disklabel -R [-nv] [-F|-f file] disk protofile\n");
+
exit(1);
 }



Re: tset(1): reduce usage()

2021-06-22 Thread Jason McIntyre
On Tue, Jun 22, 2021 at 03:22:34PM +, Klemens Nanni wrote:
> On Tue, Jun 22, 2021 at 03:57:08PM +0100, Jason McIntyre wrote:
> > On Tue, Jun 22, 2021 at 02:19:32PM +, Klemens Nanni wrote:
> > > On Tue, Jun 22, 2021 at 01:47:13PM +0100, Jason McIntyre wrote:
> > > > after:
> > > > 
> > > > $ /usr/obj/usr.bin/tset/tset -Z
> > > > tset: unknown option -- Z
> > > > usage: tset [-cIQqrsVw] [-] [-e ch] [-i ch] [-k ch] [-m mapping] 
> > > > [terminal]
> > > 
> > > OK kn
> > > 
> > 
> > thanks. i noticed sth else though:
> > 
> > $ reset -Z
> > reset: unknown option -- Z
> > usage: tset [-cIQqrsVw] [-] [-e ch] [-i ch] [-k ch] [-m mapping] [terminal]
> > 
> > can we change it so that when you run tset as reset, the usage name
> > matches? i thought it would do that already but see now it does not. it
> > uses a weird _nc_progname argument in usage, which i do not understand
> > at all.
> Right, this is using /usr/src/lib/libcurses/tinfo/access.c
> _nc_rootname() here.
> 
> > could it be easily fixed?
> I see no reason to not use getprogname(3) in usage(), with that our
> usage will always match the getopt(3) warning for `-Z'.
> 

would you mind tweaking my diff to do that, please? then commit with my
ok.

thanks!
jmc



Re: tset(1): reduce usage()

2021-06-22 Thread Jason McIntyre
On Tue, Jun 22, 2021 at 02:19:32PM +, Klemens Nanni wrote:
> On Tue, Jun 22, 2021 at 01:47:13PM +0100, Jason McIntyre wrote:
> > after:
> > 
> > $ /usr/obj/usr.bin/tset/tset -Z
> > tset: unknown option -- Z
> > usage: tset [-cIQqrsVw] [-] [-e ch] [-i ch] [-k ch] [-m mapping] [terminal]
> 
> OK kn
> 

thanks. i noticed sth else though:

$ reset -Z
reset: unknown option -- Z
usage: tset [-cIQqrsVw] [-] [-e ch] [-i ch] [-k ch] [-m mapping] [terminal]

can we change it so that when you run tset as reset, the usage name
matches? i thought it would do that already but see now it does not. it
uses a weird _nc_progname argument in usage, which i do not understand
at all.

could it be easily fixed?

thanks,
jmc

Index: tset.c
===
RCS file: /cvs/src/usr.bin/tset/tset.c,v
retrieving revision 1.41
diff -u -p -r1.41 tset.c
--- tset.c  28 Jun 2019 13:35:05 -  1.41
+++ tset.c  22 Jun 2021 14:56:35 -
@@ -1094,28 +1094,9 @@ obsolete(char **argv)
 static void
 usage(void)
 {
-static const char *tbl[] =
-{
-   ""
-   ,"Options:"
-   ,"  -c  set control characters"
-   ,"  -e ch   erase character"
-   ,"  -I  no initialization strings"
-   ,"  -i ch   interrupt character"
-   ,"  -k ch   kill character"
-   ,"  -m mapping  map identifier to type"
-   ,"  -Q  do not output control key settings"
-   ,"  -r  display term on stderr"
-   ,"  -s  output TERM set command"
-   ,"  -V  print curses-version"
-   ,"  -w  set window-size"
-};
-unsigned n;
-(void) fprintf(stderr, "Usage: %s [-cIQqrsVw] [-] "
-   "[-e ch] [-i ch] [-k ch] [-m mapping] [terminal]\n",
+(void) fprintf(stderr, "usage: %s [-cIQqrsVw] [-] "
+   "[-e ch] [-i ch] [-k ch] [-m mapping] [terminal]",
_nc_progname);
-for (n = 0; n < sizeof(tbl) / sizeof(tbl[0]); ++n)
-   fprintf(stderr, "%s\n", tbl[n]);
 
 exit_error();
 /* NOTREACHED */



Re: lex(1): reduce usage()

2021-06-22 Thread Jason McIntyre
On Tue, Jun 22, 2021 at 07:50:10AM -0600, Theo de Raadt wrote:
> Jason McIntyre  wrote:
> 
> > hi.
> > 
> > diff to reduce verbosity in flex/lex usage. before:
> 
> This seems better.  Rather than telling people to run --help, which is
> now usage(), just run usage().  Also usage() does not need to exit(),
> since all calls to usage() are followed by FLEX_EXIT().
> 
> [This is a crusty kind of old code from a time when people believed the
> simplest things required abstraction...]
> 
> Normally we don't maintain diffs to code from outside, but I think we carry
> a few diffs for lex already.
> 

please go ahead. i was reluctant to touch some of the more complex ones
anyway.

jmc

> Index: main.c
> ===
> RCS file: /cvs/src/usr.bin/lex/main.c,v
> retrieving revision 1.27
> diff -u -p -u -r1.27 main.c
> --- main.c21 Jan 2017 08:33:07 -  1.27
> +++ main.c22 Jun 2021 13:46:50 -
> @@ -977,14 +977,7 @@ flexinit(argc, argv)
>   while ((rv = scanopt(sopt, , )) != 0) {
>  
>   if (rv < 0) {
> - /*
> -  * Scanopt has already printed an option-specific
> -  * error message.
> -  */
> - fprintf(stderr,
> - _
> - ("Try `%s --help' for more information.\n"),
> - program_name);
> + usage();
>   FLEX_EXIT(1);
>   }
>   switch ((enum flexopt_flag_t) rv) {
> @@ -1740,71 +1733,12 @@ basename2(path, strip_ext)
>  }
>  
>  void
> -usage()
> +usage(void)
>  {
> - FILE *f = stdout;
> -
> - if (!did_outfilename) {
> - snprintf(outfile_path, sizeof(outfile_path), outfile_template,
> - prefix, C_plus_plus ? "cc" : "c");
> - outfilename = outfile_path;
> - }
> - fprintf(f, _("Usage: %s [OPTIONS] [FILE]...\n"), program_name);
> - fprintf(f,
> - _
> - ("Generates programs that perform pattern-matching on text.\n"
> - "\n" "Table Compression:\n"
> - "  -Ca, --align  trade off larger tables for better memory 
> alignment\n"
> - "  -Ce, --ecsconstruct equivalence classes\n"
> - "  -Cf   do not compress tables; use -f 
> representation\n"
> - "  -CF   do not compress tables; use -F 
> representation\n"
> - "  -Cm, --meta-ecs   construct meta-equivalence classes\n"
> - "  -Cr, --read   use read() instead of stdio for scanner 
> input\n"
> - "  -f, --fullgenerate fast, large scanner. Same as 
> -Cfr\n"
> - "  -F, --fastuse alternate table representation. Same 
> as -CFr\n"
> - "  -Cem  default compression (same as --ecs 
> --meta-ecs)\n"
> - "\n" "Debugging:\n"
> - "  -d, --debug enable debug mode in scanner\n"
> - "  -b, --backupwrite backing-up information to %s\n"
> - "  -p, --perf-report   write performance report to stderr\n"
> - "  -s, --nodefault suppress default rule to ECHO 
> unmatched text\n"
> - "  -T, --trace %s should run in trace mode\n"
> - "  -w, --nowarndo not generate warnings\n"
> - "  -v, --verbose   write summary of scanner statistics 
> to stdout\n"
> - "\n" "Files:\n"
> - "  -o, --outfile=FILE  specify output filename\n"
> - "  -S, --skel=FILE specify skeleton file\n"
> - "  -t, --stdoutwrite scanner on stdout instead of 
> %s\n"
> - "  --yyclass=NAME  name of C++ class\n"
> - "  --header-file=FILE   create a C header file in addition 
> to the scanner\n"
> - "  --tables-file[=FILE] write tables to FILE\n" "\n"
> - "Scanner behavior:\n"
> - "  -7, --7bit  generate 7-bit scanner\n"
> - "  -8, --8bit  generate 8-bit scanner\n"
> - "  -B, --batch generate batch scanner (opposite of 
> -I)\n&

Re: tls_load_file.3: tls_config_set_*_file() load files into memory

2021-06-22 Thread Jason McIntyre
On Tue, Jun 22, 2021 at 01:29:59PM +, Klemens Nanni wrote:
> On Tue, Jun 22, 2021 at 06:35:44AM +0100, Jason McIntyre wrote:
> > > -sets the files from which the public certificate, and private key will 
> > > be read.
> > > +loads two files from which the public certificate, and private key will 
> > > be read.
> > 
> > this is a weird place for a comma. i would remove it.
> > jmc
> 
> Agreed, but all the other sentences below have it as well so I left it
> to keep my diff simple.  I'm sure this manual can be polished further
> afterwards.
> 

that is because they are lists of more than two items. putting a comma
in a list with two items is wrong (well, that's a simplification, but
it's wrong in your diff).

jmc

> > >  .Pp
> > >  .Fn tls_config_set_keypair_mem
> > >  directly sets the public certificate, and private key from memory.
> > >  .Pp
> > >  .Fn tls_config_set_keypair_ocsp_file
> > > -sets the files from which the public certificate, private key, and 
> > > DER-encoded
> > > -OCSP staple will be read.
> > > +loads three files containing the public certificate, private key, and 
> > > DER-encoded
> > > +OCSP staple.
> > >  .Pp
> > >  .Fn tls_config_set_keypair_ocsp_mem
> > >  directly sets the public certificate, private key, and DER-encoded OCSP 
> > > staple
> > > 
> > 
> 



rdist(1): reduce usage()

2021-06-22 Thread Jason McIntyre
hi.

diff to reduce verbosity in rdist(1) usage. before:

$ /usr/bin/rdist -Z
rdist: unknown option -- Z
usage: rdist [-DFnV] [-A num] [-a num] [-c mini_distfile]
[-d var=value] [-f distfile] [-L remote_logopts] [-l local_logopts]
[-M maxproc] [-m host] [-o distopts] [-P rsh-path] [-p rdistd-path]
[-t timeout] [name ...]

The values for  are:

chknfs,chkreadonly,chksym,compare,defgroup,defowner,follow,history,ignlnks,nochkgroup,nochkmode,nochkowner,nodescend,noexec,numchkgroup,numchkowner,quiet,remove,savetargets,sparse,updateperm,verify,whole,younger

Where  is of form
=,,...:=,...
Valid  names: stdout file syslog notify
Valid  names: change info notice nerror ferror warning verbose all debug

after:

$ /usr/obj/usr.bin/rdist -Z
rdist: unknown option -- Z
usage: rdist [-DFnV] [-A num] [-a num] [-c mini_distfile] [-d var=value]
[-f distfile] [-L remote_logopts] [-l local_logopts] [-M maxproc]
[-m host] [-o distopts] [-P rsh-path] [-p rdistd-path] [-t timeout]
[name ...]

this one is more problematic. it uses two functions, getdistoptlist and
msgprusage, which i think are only used within usage. so i killed them
too.

ok?
jmc

Index: usr.bin/rdist/client.h
===
RCS file: /cvs/src/usr.bin/rdist/client.h,v
retrieving revision 1.3
diff -u -p -r1.3 client.h
--- usr.bin/rdist/client.h  30 Aug 2017 07:42:52 -  1.3
+++ usr.bin/rdist/client.h  22 Jun 2021 12:54:54 -
@@ -161,7 +161,6 @@ int install(char *, char *, int, int , o
 
 /* distopt.c */
 int parsedistopts(char *, opt_t *, int);
-char *getdistoptlist(void);
 char *getondistoptlist(opt_t);
 
 /* docmd.c */
Index: usr.bin/rdist/defs.h
===
RCS file: /cvs/src/usr.bin/rdist/defs.h,v
retrieving revision 1.38
diff -u -p -r1.38 defs.h
--- usr.bin/rdist/defs.h21 Sep 2018 19:00:45 -  1.38
+++ usr.bin/rdist/defs.h22 Jun 2021 12:54:54 -
@@ -206,7 +206,6 @@ char *xbasename(char *);
 char *searchpath(char *);
 
 /* message.c */
-void msgprusage(void);
 void msgprconfig(void);
 char *msgparseopts(char *, int);
 void checkhostname(void);
Index: usr.bin/rdist/distopt.c
===
RCS file: /cvs/src/usr.bin/rdist/distopt.c,v
retrieving revision 1.13
diff -u -p -r1.13 distopt.c
--- usr.bin/rdist/distopt.c 20 Jan 2015 09:00:16 -  1.13
+++ usr.bin/rdist/distopt.c 22 Jun 2021 12:54:54 -
@@ -134,27 +134,6 @@ parsedistopts(char *str, opt_t *optptr, 
 }
 
 /*
- * Get a list of the Distfile Option Entries.
- */
-char *
-getdistoptlist(void)
-{
-   int i;
-   static char buf[1024];
-
-   for (i = 0, buf[0] = CNULL; distoptinfo[i].do_name; ++i) {
-   if (buf[0] == CNULL)
-   (void) strlcpy(buf, distoptinfo[i].do_name, sizeof buf);
-   else {
-   (void) strlcat(buf, ",", sizeof buf);
-   (void) strlcat(buf, distoptinfo[i].do_name, sizeof buf);
-   }
-   }
-
-   return(buf);
-}
-
-/*
  * Get a list of the Distfile Option Entries for each enabled 
  * value in "opts".
  */
Index: usr.bin/rdist/message.c
===
RCS file: /cvs/src/usr.bin/rdist/message.c,v
retrieving revision 1.29
diff -u -p -r1.29 message.c
--- usr.bin/rdist/message.c 28 Jun 2019 05:35:35 -  1.29
+++ usr.bin/rdist/message.c 22 Jun 2021 12:54:54 -
@@ -118,30 +118,6 @@ static void _error(const char *);
 static void _fatalerr(const char *);
 
 /*
- * Print message logging usage message
- */
-void
-msgprusage(void)
-{
-   int i, x;
-
-   (void) fprintf(stderr, "\nWhere  is of form\n");
-   (void) fprintf(stderr, 
-   "\t=,,...:=,...\n");
-
-   (void) fprintf(stderr, "Valid  names:");
-
-   for (i = 0; msgfacility[i].mf_name; ++i)
-   (void) fprintf(stderr, " %s", msgfacility[i].mf_name);
-
-   (void) fprintf(stderr, "\nValid  names:");
-   for (x = 0; msgtypes[x].mt_name; ++x)
-   (void) fprintf(stderr, " %s", msgtypes[x].mt_name);
-
-   (void) fprintf(stderr, "\n");
-}
-
-/*
  * Print enabled message logging info
  */
 void
Index: usr.bin/rdist/rdist.c
===
RCS file: /cvs/src/usr.bin/rdist/rdist.c,v
retrieving revision 1.31
diff -u -p -r1.31 rdist.c
--- usr.bin/rdist/rdist.c   9 Jul 2017 14:04:50 -   1.31
+++ usr.bin/rdist/rdist.c   22 Jun 2021 12:54:54 -
@@ -337,19 +337,13 @@ usage(void)
extern char *__progname;
 
(void) fprintf(stderr,
-   "usage: %s [-DFnV] [-A num] [-a num] "
-   "[-c mini_distfile]\n"
-   "\t[-d var=value] [-f distfile] [-L remote_logopts] "
-   "[-l local_logopts]\n"
-   "\t[-M 

lex(1): reduce usage()

2021-06-22 Thread Jason McIntyre
hi.

diff to reduce verbosity in flex/lex usage. before:

$ /usr/bin/lex --help
Usage: lex [OPTIONS] [FILE]...
Generates programs that perform pattern-matching on text.

Table Compression:
  -Ca, --align  trade off larger tables for better memory alignment
  -Ce, --ecsconstruct equivalence classes
  -Cf   do not compress tables; use -f representation
  -CF   do not compress tables; use -F representation
  -Cm, --meta-ecs   construct meta-equivalence classes
  -Cr, --read   use read() instead of stdio for scanner input
  -f, --fullgenerate fast, large scanner. Same as -Cfr
  -F, --fastuse alternate table representation. Same as -CFr
  -Cem  default compression (same as --ecs --meta-ecs)

Debugging:
  -d, --debug enable debug mode in scanner
  -b, --backupwrite backing-up information to lex.backup
  -p, --perf-report   write performance report to stderr
  -s, --nodefault suppress default rule to ECHO unmatched text
  -T, --trace lex should run in trace mode
  -w, --nowarndo not generate warnings
  -v, --verbose   write summary of scanner statistics to stdout

Files:
  -o, --outfile=FILE  specify output filename
  -S, --skel=FILE specify skeleton file
  -t, --stdoutwrite scanner on stdout instead of lex.yy.c
  --yyclass=NAME  name of C++ class
  --header-file=FILE   create a C header file in addition to the scanner
  --tables-file[=FILE] write tables to FILE

Scanner behavior:
  -7, --7bit  generate 7-bit scanner
  -8, --8bit  generate 8-bit scanner
  -B, --batch generate batch scanner (opposite of -I)
  -i, --case-insensitive  ignore case in patterns
  -l, --lex-compatmaximal compatibility with original lex
  -X, --posix-compat  maximal compatibility with POSIX lex
  -I, --interactive   generate interactive scanner (opposite of -B)
  --yylineno  track line count in yylineno

Generated code:
  -+,  --c++   generate C++ scanner class
  -Dmacro[=defn]   #define macro defn  (default defn is '1')
  -L,  --nolinesuppress #line directives in scanner
  -P,  --prefix=STRING use STRING as prefix instead of "yy"
  -R,  --reentrant generate a reentrant C scanner
   --bison-bridge  scanner for bison pure parser.
   --bison-locations   include yylloc support.
   --stdinit   initialize yyin/yyout to stdin/stdout
   --noansi-definitions old-style function definitions
   --noansi-prototypes  empty parameter list in prototypes
   --nounistd  do not include 
   --noFUNCTIONdo not generate a particular FUNCTION

Miscellaneous:
  -n  do-nothing POSIX option
  -?
  -h, --help  produce this help message
  -V, --version   report lex version

after:

$ /usr/obj/usr.bin/lex/lex --help
usage: lex [-78BbFfhIiLlnpsTtVvw+?] [-C[aeFfmr]] [--help] [--version]
[-ooutput] [-Pprefix] [-Sskeleton] [file ...]

this one is more problematic as the usage is very different. i copied
over the structure from rdist, but did not declare "static void" at the
top as the compiler complained. i left it as "void". also inserted an
exit line at function end.

ok?
jmc

Index: usr.bin/lex/main.c
===
RCS file: /cvs/src/usr.bin/lex/main.c,v
retrieving revision 1.27
diff -u -p -r1.27 main.c
--- usr.bin/lex/main.c  21 Jan 2017 08:33:07 -  1.27
+++ usr.bin/lex/main.c  22 Jun 2021 12:51:48 -
@@ -1740,71 +1740,14 @@ basename2(path, strip_ext)
 }
 
 void
-usage()
+usage(void)
 {
-   FILE *f = stdout;
+   extern char *__progname;
 
-   if (!did_outfilename) {
-   snprintf(outfile_path, sizeof(outfile_path), outfile_template,
-   prefix, C_plus_plus ? "cc" : "c");
-   outfilename = outfile_path;
-   }
-   fprintf(f, _("Usage: %s [OPTIONS] [FILE]...\n"), program_name);
-   fprintf(f,
-   _
-   ("Generates programs that perform pattern-matching on text.\n"
-   "\n" "Table Compression:\n"
-   "  -Ca, --align  trade off larger tables for better memory 
alignment\n"
-   "  -Ce, --ecsconstruct equivalence classes\n"
-   "  -Cf   do not compress tables; use -f 
representation\n"
-   "  -CF   do not compress tables; use -F 
representation\n"
-   "  -Cm, --meta-ecs   construct meta-equivalence classes\n"
-   "  -Cr, --read   use read() instead of stdio for scanner 
input\n"
-   "  -f, --fullgenerate fast, large scanner. Same as 
-Cfr\n"
-   "  -F, --fastuse alternate table representation. Same 
as -CFr\n"
-   "  -Cem  default compression (same as --ecs 

locate(1): reduce usage()

2021-06-22 Thread Jason McIntyre
hi.

diff to reduce verbosity in locate(1) usage. before:

$ /usr/bin/locate -Z
locate: unknown option -- Z
usage: locate [-bciS] [-d database] [-l limit] pattern ...
default database: `/var/db/locate.database' or $LOCATE_PATH

after:

$ /usr/obj/usr.bin/locate/locate/locate -Z
locate: unknown option -- Z
usage: locate [-bciS] [-d database] [-l limit] pattern ...

ok?
jmc

Index: usr.bin/locate/locate/locate.c
===
RCS file: /cvs/src/usr.bin/locate/locate/locate.c,v
retrieving revision 1.33
diff -u -p -r1.33 locate.c
--- usr.bin/locate/locate/locate.c  17 Jan 2019 06:15:44 -  1.33
+++ usr.bin/locate/locate/locate.c  22 Jun 2021 12:49:13 -
@@ -252,8 +252,7 @@ usage(void)
 {
(void)fprintf(stderr, "usage: locate [-bciS] [-d database] ");
(void)fprintf(stderr, "[-l limit] pattern ...\n");
-   (void)fprintf(stderr, "default database: `%s' or $LOCATE_PATH\n",
-   _PATH_FCODES);
+
exit(1);
 }
 



tset(1): reduce usage()

2021-06-22 Thread Jason McIntyre
hi.

diff to reduce verbosity in tset(1) usage. before:

$ /usr/bin/tset -Z
tset: unknown option -- Z
Usage: tset [-cIQqrsVw] [-] [-e ch] [-i ch] [-k ch] [-m mapping] [terminal]

Options:
  -c  set control characters
  -e ch   erase character
  -I  no initialization strings
  -i ch   interrupt character
  -k ch   kill character
  -m mapping  map identifier to type
  -Q  do not output control key settings
  -r  display term on stderr
  -s  output TERM set command
  -V  print curses-version
  -w  set window-size

after:

$ /usr/obj/usr.bin/tset/tset -Z
tset: unknown option -- Z
usage: tset [-cIQqrsVw] [-] [-e ch] [-i ch] [-k ch] [-m mapping] [terminal]

ok?
jmc

Index: usr.bin/tset/tset.c
===
RCS file: /cvs/src/usr.bin/tset/tset.c,v
retrieving revision 1.41
diff -u -p -r1.41 tset.c
--- usr.bin/tset/tset.c 28 Jun 2019 13:35:05 -  1.41
+++ usr.bin/tset/tset.c 22 Jun 2021 12:46:16 -
@@ -1094,28 +1094,9 @@ obsolete(char **argv)
 static void
 usage(void)
 {
-static const char *tbl[] =
-{
-   ""
-   ,"Options:"
-   ,"  -c  set control characters"
-   ,"  -e ch   erase character"
-   ,"  -I  no initialization strings"
-   ,"  -i ch   interrupt character"
-   ,"  -k ch   kill character"
-   ,"  -m mapping  map identifier to type"
-   ,"  -Q  do not output control key settings"
-   ,"  -r  display term on stderr"
-   ,"  -s  output TERM set command"
-   ,"  -V  print curses-version"
-   ,"  -w  set window-size"
-};
-unsigned n;
-(void) fprintf(stderr, "Usage: %s [-cIQqrsVw] [-] "
-   "[-e ch] [-i ch] [-k ch] [-m mapping] [terminal]\n",
+(void) fprintf(stderr, "usage: %s [-cIQqrsVw] [-] "
+   "[-e ch] [-i ch] [-k ch] [-m mapping] [terminal]",
_nc_progname);
-for (n = 0; n < sizeof(tbl) / sizeof(tbl[0]); ++n)
-   fprintf(stderr, "%s\n", tbl[n]);
 
 exit_error();
 /* NOTREACHED */



ypmatch(1): reduce usage()

2021-06-22 Thread Jason McIntyre
hi.

diff to reduce verbosity in ypmatch(1) usage. before:

$ /usr/bin/ypmatch -Z
ypmatch: unknown option -- Z
usage: ypmatch [-kt] [-d domain] key ... mapname
   ypmatch -x
where
mapname may be either a mapname or a nickname for a map.
-k prints keys as well as values.
-t inhibits map nickname translation.
-x dumps the map nickname translation table.

after:

$ /usr/obj/usr.bin/ypmatch/ypmatch -Z
ypmatch: unknown option -- Z
usage: ypmatch [-kt] [-d domain] key ... mapname
   ypmatch -x

ok?
jmc

Index: usr.bin/ypmatch/ypmatch.c
===
RCS file: /cvs/src/usr.bin/ypmatch/ypmatch.c,v
retrieving revision 1.16
diff -u -p -r1.16 ypmatch.c
--- usr.bin/ypmatch/ypmatch.c   8 Feb 2015 23:40:35 -   1.16
+++ usr.bin/ypmatch/ypmatch.c   22 Jun 2021 12:44:03 -
@@ -61,12 +61,7 @@ usage(void)
fprintf(stderr,
"usage: ypmatch [-kt] [-d domain] key ... mapname\n"
"   ypmatch -x\n");
-   fprintf(stderr,
-   "where\n"
-   "\tmapname may be either a mapname or a nickname for a map.\n"
-   "\t-k prints keys as well as values.\n"
-   "\t-t inhibits map nickname translation.\n"
-   "\t-x dumps the map nickname translation table.\n");
+
exit(1);
 }
 



crontab(1): reduce usage()

2021-06-22 Thread Jason McIntyre
hi.

diff to reduce verbosity in crontab(1) usage. before:

$ /usr/bin/crontab -Z
crontab: unknown option -- Z
usage: crontab [-u user] file
   crontab [-e | -l | -r] [-u user]
(default operation is replace, per 1003.2)
-e  (edit user's crontab)
-l  (list user's crontab)
-r  (delete user's crontab)

after:

$ /usr/obj/usr.bin/crontab/crontab -Z
crontab: unknown option -- Z
usage: crontab [-u user] file
   crontab [-e | -l | -r] [-u user]

ok?
jmc

Index: crontab.c
===
RCS file: /cvs/src/usr.sbin/cron/crontab.c,v
retrieving revision 1.94
diff -u -p -r1.94 crontab.c
--- crontab.c   11 Feb 2020 12:42:02 -  1.94
+++ crontab.c   22 Jun 2021 12:41:42 -
@@ -70,11 +70,7 @@ usage(const char *msg)
warnx("usage error: %s", msg);
fprintf(stderr, "usage: %s [-u user] file\n", __progname);
fprintf(stderr, "   %s [-e | -l | -r] [-u user]\n", __progname);
-   fprintf(stderr,
-   "\t\t(default operation is replace, per 1003.2)\n"
-   "\t-e\t(edit user's crontab)\n"
-   "\t-l\t(list user's crontab)\n"
-   "\t-r\t(delete user's crontab)\n");
+
exit(EXIT_FAILURE);
 }
 



mkuboot(8): reduce usage()

2021-06-22 Thread Jason McIntyre
hi.

diff to reduce verbosity in mkuboot(8) usage. i don;t have the means to
build this one.

ok?
jmc

Index: mkuboot.c
===
RCS file: /cvs/src/usr.sbin/mkuboot/mkuboot.c,v
retrieving revision 1.10
diff -u -p -r1.10 mkuboot.c
--- mkuboot.c   1 Jun 2021 02:59:01 -   1.10
+++ mkuboot.c   22 Jun 2021 12:36:08 -
@@ -395,16 +395,6 @@ usage(void)
(void)fprintf(stderr,
"usage: %s [-a arch] [-e entry] [-l loadaddr] [-n name] [-o os] "
"[-t type] infile outfile\n", __progname);
-   (void)fprintf(stderr,
-   "arch is one of:");
-   for (mapptr = archmap; mapptr->arch; mapptr++)
-   (void)fprintf(stderr, " %s", mapptr->arch);
-   (void)fprintf(stderr, "\n");
-   (void)fprintf(stderr,
-   "os is one of:");
-   for (osmapptr = osmap; osmapptr->arch; osmapptr++)
-   (void)fprintf(stderr, " %s", osmapptr->arch);
-   (void)fprintf(stderr, "\n");

exit(1);
 }



disklabel(8): reduce usage()

2021-06-22 Thread Jason McIntyre
hi.

diff to reduce verbosity in disklabel(8) usage. before:

$ /sbin/disklabel -Z
disklabel: unknown option -- Z
usage: disklabel[-Acdtv] [-h | -p unit] [-T file] disk  (read)
   disklabel -w [-Acdnv] [-T file] disk disktype [packid]   (write)
   disklabel -e [-Acdnv] [-T file] disk (edit)
   disklabel -E [-Acdnv] [-F|-f file] [-T file] disk(simple editor)
   disklabel -R [-nv] [-F|-f file] disk protofile   (restore)

`disk' may be of the form: sd0 or /dev/rsd0c.
`disktype' is an entry from /etc/disktab, see disktab(5) for more info.
`packid' is an identification string for the device.
`protofile' is the output from the read cmd form; -R is powerful.
For procedures specific to this architecture see: fdisk(8), installboot(8)

after:

$ /usr/obj/sbin/disklabel/disklabel -Z
disklabel: unknown option -- Z
usage: disklabel[-Acdtv] [-h | -p unit] [-T file] disk
   disklabel -w [-Acdnv] [-T file] disk disktype [packid]
   disklabel -e [-Acdnv] [-T file] disk
   disklabel -E [-Acdnv] [-F|-f file] [-T file] disk
   disklabel -R [-nv] [-F|-f file] disk protofile

ok?
jmc

Index: sbin/disklabel/disklabel.c
===
RCS file: /cvs/src/sbin/disklabel/disklabel.c,v
retrieving revision 1.236
diff -u -p -r1.236 disklabel.c
--- sbin/disklabel/disklabel.c  14 Nov 2020 20:53:31 -  1.236
+++ sbin/disklabel/disklabel.c  22 Jun 2021 12:34:14 -
@@ -1212,28 +1212,15 @@ void
 usage(void)
 {
fprintf(stderr,
-   "usage: disklabel[-Acdtv] [-h | -p unit] [-T file] 
disk\t(read)\n");
+   "usage: disklabel[-Acdtv] [-h | -p unit] [-T file] disk\n");
fprintf(stderr,
-   "   disklabel -w [-Acdnv] [-T file] disk disktype 
[packid]\t(write)\n");
+   "   disklabel -w [-Acdnv] [-T file] disk disktype [packid]\n");
fprintf(stderr,
-   "   disklabel -e [-Acdnv] [-T file] disk\t\t\t(edit)\n");
+   "   disklabel -e [-Acdnv] [-T file] disk\n");
fprintf(stderr,
-   "   disklabel -E [-Acdnv] [-F|-f file] [-T file] disk\t(simple 
editor)"
-   "\n");
+   "   disklabel -E [-Acdnv] [-F|-f file] [-T file] disk\n");
fprintf(stderr,
-   "   disklabel -R [-nv] [-F|-f file] disk 
protofile\t\t(restore)\n\n");
-   fprintf(stderr,
-   "`disk' may be of the form: sd0 or /dev/rsd0%c.\n", 'a'+RAW_PART);
-   fprintf(stderr,
-   "`disktype' is an entry from %s, see disktab(5) for more info.\n",
-   DISKTAB);
-   fprintf(stderr,
-   "`packid' is an identification string for the device.\n");
-   fprintf(stderr,
-   "`protofile' is the output from the read cmd form; -R is 
powerful.\n");
-#ifdef SEEALSO
-   fprintf(stderr,
-   "For procedures specific to this architecture see: %s\n", SEEALSO);
-#endif
+   "   disklabel -R [-nv] [-F|-f file] disk protofile\n");
+
exit(1);
 }



scsi(8): reduce usage()

2021-06-22 Thread Jason McIntyre
hi.

diff to reduce verbosity in scsi(8) usage. before:

$ /sbin/scsi -Z
scsi: unknown option -- Z
Usage:

  scsi -f device -d debug_level# To set debug level
  scsi -f device -m page [-P pc]   # To read mode pages
  scsi -f device [-v] [-s seconds] -c cmd_fmt [arg0 ... argn] # A command...
 -o count out_fmt [arg0 ... argn]  #   EITHER (data out)
 -i count in_fmt   #   OR (data in)

"out_fmt" can be "-" to read output data from stdin;
"in_fmt" can be "-" to write input data to stdout;

If debugging is not compiled in the kernel, "-d" will have no effect

after:

$ /usr/obj/sbin/scsi/scsi -Z
scsi: unknown option -- Z
usage: scsi -f device -d debug_level
   scsi -f device -m page [-e] [-P pc]
   scsi -f device [-v] [-s seconds] -c cmd_fmt [arg ...] -o count out_fmt
[arg ...] -i count in_fmt [arg ...]

ok?
jmc

Index: sbin/scsi/scsi.c
===
RCS file: /cvs/src/sbin/scsi/scsi.c,v
retrieving revision 1.30
diff -u -p -r1.30 scsi.c
--- sbin/scsi/scsi.c7 Jun 2016 01:29:38 -   1.30
+++ sbin/scsi/scsi.c22 Jun 2021 12:27:10 -
@@ -84,20 +84,11 @@ static void
 usage(void)
 {
fprintf(stderr,
-"Usage:\n"
-"\n"
-"  scsi -f device -d debug_level# To set debug level\n"
-"  scsi -f device -m page [-P pc]   # To read mode pages\n"
-"  scsi -f device [-v] [-s seconds] -c cmd_fmt [arg0 ... argn] # A 
command...\n"
-" -o count out_fmt [arg0 ... argn]  #   EITHER (data out)\n"
-" -i count in_fmt   #   OR (data in)\n"
-"\n"
-"\"out_fmt\" can be \"-\" to read output data from stdin;\n"
-"\"in_fmt\" can be \"-\" to write input data to stdout;\n"
-"\n"
-"If debugging is not compiled in the kernel, \"-d\" will have no effect\n"
-
-);
+"usage: scsi -f device -d debug_level\n"
+"   scsi -f device -m page [-e] [-P pc]\n"
+"   scsi -f device [-v] [-s seconds] -c cmd_fmt [arg ...]"
+" -o count out_fmt\n"
+"[arg ...] -i count in_fmt [arg ...]\n");
 
exit (1);
 }



Re: tls_load_file.3: tls_config_set_*_file() load files into memory

2021-06-21 Thread Jason McIntyre
On Tue, Jun 22, 2021 at 04:48:39AM +0200, Theo Buehler wrote:
> > 
> > Feedback? OK?
> 
> You have two overlong lines as indicated below. I would have thought
> that mandoc -Tlint complains about that, but apparently it doesn't have
> such a warning... With those wrapped,
> 

yes, there is no feedback on long lines. although we try to keep the
source less than 80 width, there are some places where it is not
possible.

i'm not sure whether adding a warning would be helpful or disruptive.

jmc



Re: tls_load_file.3: tls_config_set_*_file() load files into memory

2021-06-21 Thread Jason McIntyre
On Mon, Jun 21, 2021 at 11:26:41PM +, Klemens Nanni wrote:
> 
> Thanks.  tls_config_add_*_file also load files into memory, but given
> this patch I think their usage of "add" in the manual is enough to infer
> that files will also be loaded and added, so no need to change those as
> well, I think.
> 
> This should be the complete diff.
> 
> Feedback? OK?
> 
> 
> Index: man/tls_load_file.3
> ===
> RCS file: /cvs/src/lib/libtls/man/tls_load_file.3,v
> retrieving revision 1.11
> diff -u -p -r1.11 tls_load_file.3
> --- man/tls_load_file.3   29 Nov 2018 14:24:23 -  1.11
> +++ man/tls_load_file.3   21 Jun 2021 23:24:58 -
> @@ -217,8 +217,7 @@ call, ensuring that the memory contents 
>  returns the path of the file that contains the default root certificates.
>  .Pp
>  .Fn tls_config_set_ca_file
> -sets the filename used to load a file
> -containing the root certificates.
> +loads a file containing the root certificates.
>  .Pp
>  .Fn tls_config_set_ca_path
>  sets the path (directory) which should be searched for root
> @@ -228,41 +227,39 @@ certificates.
>  sets the root certificates directly from memory.
>  .Pp
>  .Fn tls_config_set_cert_file
> -sets file from which the public certificate will be read.
> +loads a file containing the public certificate.
>  .Pp
>  .Fn tls_config_set_cert_mem
>  sets the public certificate directly from memory.
>  .Pp
>  .Fn tls_config_set_crl_file
> -sets the filename used to load a file containing the
> -Certificate Revocation List (CRL).
> +loads a file containing the Certificate Revocation List (CRL).
>  .Pp
>  .Fn tls_config_set_crl_mem
>  sets the CRL directly from memory.
>  .Pp
>  .Fn tls_config_set_key_file
> -sets the file from which the private key will be read.
> +loads a file containing the private key.
>  .Pp
>  .Fn tls_config_set_key_mem
>  directly sets the private key from memory.
>  .Pp
>  .Fn tls_config_set_ocsp_staple_file
> -sets a DER-encoded OCSP response to be stapled during the TLS handshake from
> -the specified file.
> +loads a file containing a DER-encoded OCSP response to be stapled during the 
> TLS handshake.
>  .Pp
>  .Fn tls_config_set_ocsp_staple_mem
>  sets a DER-encoded OCSP response to be stapled during the TLS handshake from
>  memory.
>  .Pp
>  .Fn tls_config_set_keypair_file
> -sets the files from which the public certificate, and private key will be 
> read.
> +loads two files from which the public certificate, and private key will be 
> read.

this is a weird place for a comma. i would remove it.
jmc

>  .Pp
>  .Fn tls_config_set_keypair_mem
>  directly sets the public certificate, and private key from memory.
>  .Pp
>  .Fn tls_config_set_keypair_ocsp_file
> -sets the files from which the public certificate, private key, and 
> DER-encoded
> -OCSP staple will be read.
> +loads three files containing the public certificate, private key, and 
> DER-encoded
> +OCSP staple.
>  .Pp
>  .Fn tls_config_set_keypair_ocsp_mem
>  directly sets the public certificate, private key, and DER-encoded OCSP 
> staple
> 



Re: alarm.3: misc. cleanup, rewriting

2021-06-18 Thread Jason McIntyre
On Fri, Jun 18, 2021 at 04:27:36PM -0500, Scott Cheloha wrote:
> 
> I've also added a CAVEATS section.
> 
> I've also tweaked the .Nd summary:
> 
> .Nd schedule SIGALRM delivery
> 
> Thoughts?
> 

reads ok to me. one possible tweak inline:

> Index: alarm.3
> ===
> RCS file: /cvs/src/lib/libc/gen/alarm.3,v
> retrieving revision 1.15
> diff -u -p -r1.15 alarm.3
> --- alarm.3   28 Jan 2016 22:11:39 -  1.15
> +++ alarm.3   18 Jun 2021 21:26:23 -
> @@ -32,7 +32,7 @@
>  .Os
>  .Sh NAME
>  .Nm alarm
> -.Nd set signal timer alarm
> +.Nd schedule SIGALRM delivery
>  .Sh SYNOPSIS
>  .In unistd.h
>  .Ft unsigned int
> @@ -45,32 +45,30 @@ This is a simplified interface to
>  .Pp
>  The
>  .Fn alarm
> -function waits a count of
> -.Ar seconds
> -before asserting the terminating signal
> -.Dv SIGALRM .
> -When the signal has successfully been caught,
> -.Fn alarm
> -returns the amount of time left on the clock.
> -The maximum number of
> -.Ar seconds
> -allowed
> -is 1.
> +function schedules the
> +.Dv SIGALRM
> +signal for delivery to the calling process after the given number of
> +.Fa seconds
> +have elapsed.
>  .Pp
> -If an alarm has been set with
> -.Fn alarm ,
> +If an alarm is already pending,
>  another call to
>  .Fn alarm
>  will supersede the prior call.
> -The request
> -.Fn alarm "0"
> -voids the current
> -alarm.
> +.Pp
> +If
> +.Fa seconds
> +is zero,
> +any pending alarm is cancelled.
>  .Sh RETURN VALUES
> -If the call succeeds, any time left remaining from a previous call is 
> returned.
> -If an error occurs, the value \-1 is returned, and a more precise
> -error code is placed in the global variable
> -.Va errno .
> +.Fn alarm
> +returns the number of seconds remaining until the pending alarm would have
> +expired.
> +If the alarm has already expired,
> +or the alarm was cancelled,

i would remove "or" from the sentence above.
jmc

> +or no alarm was ever scheduled,
> +.Fn alarm
> +returns zero.
>  .Sh SEE ALSO
>  .Xr setitimer 2 ,
>  .Xr sigaction 2 ,
> @@ -94,3 +92,15 @@ For
>  it was reimplemented as a wrapper around the
>  .Xr setitimer 2
>  system call.
> +.Sh CAVEATS
> +The
> +.Fn alarm
> +function is implemented with the per-process
> +.Dv ITIMER_REAL
> +timer described in
> +.Xr setitimer 2 .
> +Use of both
> +.Fn alarm
> +and
> +.Xr setitimer 2
> +in the same program may yield confusing behavior.



Re: fix isascii(3) manpage

2021-06-12 Thread Jason McIntyre
On Fri, Jun 11, 2021 at 09:56:20AM +, Miod Vallat wrote:
> All the is*() ctype.h functions take an int as argument, but valid
> values are only EOF, and the range of values of `unsigned char'.
> 
> All, but one: the XPG4 isascii(), which has no such restriction.
> Quoting https://pubs.opengroup.org/onlinepubs/9699919799/ :
> ``The isascii() function is defined on all integer values.''
> 
> Hence the following diff.
> 

fixed, thanks!
jmc

> Index: isascii.3
> ===
> RCS file: /OpenBSD/src/lib/libc/gen/isascii.3,v
> retrieving revision 1.13
> diff -u -p -r1.13 isascii.3
> --- isascii.3 17 Jul 2013 05:42:11 -  1.13
> +++ isascii.3 11 Jun 2021 09:54:13 -
> @@ -77,11 +77,3 @@ The
>  .Fn isascii
>  function first appeared in
>  .At v7 .
> -.Sh CAVEATS
> -The argument to
> -.Fn isascii
> -must be
> -.Dv EOF
> -or representable as an
> -.Li unsigned char ;
> -otherwise, the result is undefined.
> 



Re: Very little patch : ref getrtable in rdomain

2021-05-19 Thread Jason McIntyre
On Wed, May 19, 2021 at 10:55:11AM -0400, Sven F. wrote:
> Index: rdomain.4
> ===
> RCS file: /cvs/src/share/man/man4/rdomain.4,v
> retrieving revision 1.17
> diff -u -p -r1.17 rdomain.4
> --- rdomain.4   24 Sep 2020 11:05:32 -  1.17
> +++ rdomain.4   19 May 2021 14:51:37 -
> @@ -139,7 +139,8 @@ Delete rdomain 4 again:
>  .Xr route 4 ,
>  .Xr pf.conf 5 ,
>  .Xr ifconfig 8 ,
> -.Xr route 8
> +.Xr route 8,
> +.Xr getrtable 2
>  .Sh HISTORY
>  .Ox
>  support for
> 

hi.

i'll let others decide whether we expect users of rdomains/rtables to need to
read the programming pages. i suspect not.

note that your addition to SEE ALSO is wrong - there should be a
space between the section number and punctuation, and pages are
ordered by section first, so it'd be added after the entry to ps(1).
get used to running doc changes through "mandoc -Tlint" to pick up
such small fry...

jmc



Re: mention apmd(8) on afterboot(8)

2021-05-15 Thread Jason McIntyre
hi.

so i'm ok with this. two more points:

- i'd use a colon after "15%", not a full stop
- i'd remove the " check the man page" line and .Pp because it'd save space and 
we already Xr the page. up to you though.

jmc

On 15 May 2021 17:14:55 BST, Paco Esteban  wrote:
>Hi Jason,
>
>On Sat, 15 May 2021, Jason McIntyre wrote:
>
>> On Sat, May 15, 2021 at 12:27:53PM +0200, Paco Esteban wrote:
>> > Hi,
>> > 
>> > This adds a mention to apmd(8) on afterboot(8).  Original idea is
>from
>> > kmos@, crappy wording is mine (corrections/suggestions welcome).
>> > 
>> > ok to commit ?
>> > 
>> 
>> hi.
>> 
>> i guess i don;t object, but i'm not convinced this page needs such a
>> large block of text on power management. there is a "Daemons" section
>> which could just provide a nod to the relevant pages.
>
>I put it there after the Video stuff which is somewhat tailored to
>laptop users.  But I don't have a strong opinion on where to put it.
>
>The Daemons section only mentions intro(8) which does not have any
>mention of apmd(8) at all.
>
>As we already make mentions to things like Printers or Video there it
>does not feel weird to me.  But yeah, it could be shorter.  Maybe
>without the rcctl example lines and just point to the man page.
>
>In any case, mods below with your suggestions.
>
>> 
>> one note inline:
>> 
>> > diff b8464fd1ac0e783621fb415f793b0d73c4fb /usr/src
>> > blob - 8b4079f857da2aa79783848d450addba1e5831e6
>> > file + share/man/man8/afterboot.8
>> > --- share/man/man8/afterboot.8
>> > +++ share/man/man8/afterboot.8
>> > @@ -418,6 +418,23 @@ Normal recording can be enabled by adding the
>followin
>> >  kern.audio.record=1
>> >  kern.video.record=1
>> >  .Ed
>> > +.Ss Power management
>> > +The
>> > +.Xr apmd 8
>> > +daemon controls the Advanced Power Management (APM).
>> > +If your device's BIOS supports it, you can configure this daemon
>to act on
>> > +different events and adjust the performance of your device.
>> 
>> we tend to avoid 2nd person text like this. so it could be written
>like:
>> 
>>  If the BIOS supports it, the daemon can be configured to act on
>>  different events and adjust device performance.
>
>Right, that reads way better.
>I've included a modified version at the end with that form and a wee
>bit
>shorter.
>
>> 
>> jmc
>> 
>> > +In the following example
>> > +.Xr apmd 8
>> > +is configured to start on boot in automatic performance adjustment
>mode and
>> > +suspend the system if no AC is connected and the estimated battery
>life is
>> > +equal or below 15%.
>> > +.Bd -literal -offset indent
>> > +# rcctl set apmd status on
>> > +# rcctl set apmd flags -A -z 15
>> > +.Ed
>> > +.Pp
>> > +For more information check the man page.
>> >  .Ss Mail aliases
>> >  Edit
>> >  .Pa /etc/mail/aliases
>
>diff aeddc3fc1c2dc619781d7d37222447f40fb248a7 /usr/src
>blob - 8b4079f857da2aa79783848d450addba1e5831e6
>file + share/man/man8/afterboot.8
>--- share/man/man8/afterboot.8
>+++ share/man/man8/afterboot.8
>@@ -418,6 +418,19 @@ Normal recording can be enabled by adding the
>followin
> kern.audio.record=1
> kern.video.record=1
> .Ed
>+.Ss Power management
>+If the BIOS supports it,
>+.Xr apmd 8
>+can be configured to act on different events and adjust device
>performance.
>+In the following example it is configured to start on boot in
>automatic
>+performance adjustment mode and suspend the system if no AC is
>connected and
>+the estimated battery life is equal or below 15%.
>+.Bd -literal -offset indent
>+# rcctl set apmd status on
>+# rcctl set apmd flags -A -z 15
>+.Ed
>+.Pp
>+For more information check the man page.
> .Ss Mail aliases
> Edit
> .Pa /etc/mail/aliases



Re: mention apmd(8) on afterboot(8)

2021-05-15 Thread Jason McIntyre
On Sat, May 15, 2021 at 12:27:53PM +0200, Paco Esteban wrote:
> Hi,
> 
> This adds a mention to apmd(8) on afterboot(8).  Original idea is from
> kmos@, crappy wording is mine (corrections/suggestions welcome).
> 
> ok to commit ?
> 

hi.

i guess i don;t object, but i'm not convinced this page needs such a
large block of text on power management. there is a "Daemons" section
which could just provide a nod to the relevant pages.

one note inline:

> diff b8464fd1ac0e783621fb415f793b0d73c4fb /usr/src
> blob - 8b4079f857da2aa79783848d450addba1e5831e6
> file + share/man/man8/afterboot.8
> --- share/man/man8/afterboot.8
> +++ share/man/man8/afterboot.8
> @@ -418,6 +418,23 @@ Normal recording can be enabled by adding the followin
>  kern.audio.record=1
>  kern.video.record=1
>  .Ed
> +.Ss Power management
> +The
> +.Xr apmd 8
> +daemon controls the Advanced Power Management (APM).
> +If your device's BIOS supports it, you can configure this daemon to act on
> +different events and adjust the performance of your device.

we tend to avoid 2nd person text like this. so it could be written like:

If the BIOS supports it, the daemon can be configured to act on
different events and adjust device performance.

jmc

> +In the following example
> +.Xr apmd 8
> +is configured to start on boot in automatic performance adjustment mode and
> +suspend the system if no AC is connected and the estimated battery life is
> +equal or below 15%.
> +.Bd -literal -offset indent
> +# rcctl set apmd status on
> +# rcctl set apmd flags -A -z 15
> +.Ed
> +.Pp
> +For more information check the man page.
>  .Ss Mail aliases
>  Edit
>  .Pa /etc/mail/aliases
> 
> -- 
> Paco Esteban.
> 0x5818130B8A6DBC03
> 



Re: shell manpage tweaks wrt getopt

2021-05-01 Thread Jason McIntyre
On Sat, May 01, 2021 at 04:33:08PM +0200, Christian Weisgerber wrote:
> Jason McIntyre:
> 
> > - i'm ok with the getopt.1 and ksh.1 parts
> > - i'm not ok with the addition to sh.1
> > 
> > no one has really given a good reason why they think it should go into
> > sh.1. i've given a few why i think it should not.
> 
> My understanding is that sh.1 is a subset of ksh.1, describing the
> POSIX-standardized functionality.  Am I wrong?
> 

that's correct.

> ksh.1 has very little in the way of examples, but I think figuring
> out the correct getopts idiom is difficult enough to warrant an
> example.
> 
> The problem is that if I'm trying to write a portable shell script,
> I will refer to sh.1.  I will not check ksh.1 for examples.
> 
> But since you are the principal author of sh.1, I'm certainly
> deferring to your judgment.
> 

ok, your point is a good one too. i had been trying to keep sh(1) trim.
i think the general idea is if you need more of an explanation, it's in
ksh(1). but on balance i guess i'm ok with the addition to sh.1 too.

jmc



Re: shell manpage tweaks wrt getopt

2021-04-30 Thread Jason McIntyre
On Fri, Apr 30, 2021 at 04:42:12PM +0200, Marc Espie wrote:
> On Fri, Apr 30, 2021 at 03:28:42PM +0100, Jason McIntyre wrote:
> > my argument boils down to: sh(1) is small and has no examples. adding
> > them changes the (deliberate) nature of the page. ksh(1) is what you
> > read when you can;t get to sleep.
> > 
> > why is it wrong to add your example to ksh(1)? why would that leave the
> > reader disadvantaged?
> 
> I would also actually be fairly happy if we changed drastically the way
> sh(1) and ksh(1) look. To me, sh(1) should be the (more or less) standard
> shell documentation, AND ksh(1) should contain the differences/extensions.
> 
> Occasionally useful when you want to write scripts that are usable outside
> of OpenBSD with /bin/sh as a tagline.
> 
> Not very likely to happen.
> 

hi.

there's a few possibilities with what to do with sh.1 and ksh.1, but i
guess none of them are fully satisfactory.

i suspect if we picked out the parts in ksh.1 already covered by sh.1 it
would leave a not very helpful page. and it would take a lot of
picking...

jmc



Re: shell manpage tweaks wrt getopt

2021-04-30 Thread Jason McIntyre
On Fri, Apr 30, 2021 at 04:54:57PM +0200, Christian Weisgerber wrote:
> Marc Espie:
> 
> > Until a patch from naddy, I wasn't even aware of getopts in sh(1)
> 
> Let's start the discussion with this instead.
> 
> This puts the deprecation notice in getopt.1 in a prominent place,
> and uses the same snippet in sh.1 and ksh.1.
> 

morning.

- i'm ok with the getopt.1 and ksh.1 parts
- i'm not ok with the addition to sh.1

no one has really given a good reason why they think it should go into
sh.1. i've given a few why i think it should not.

jmc

> Index: bin/ksh/ksh.1
> ===
> RCS file: /cvs/src/bin/ksh/ksh.1,v
> retrieving revision 1.214
> diff -u -p -r1.214 ksh.1
> --- bin/ksh/ksh.1 11 Mar 2021 07:04:12 -  1.214
> +++ bin/ksh/ksh.1 30 Apr 2021 14:40:52 -
> @@ -3219,6 +3219,25 @@ resetting
>  .Ev OPTIND ,
>  may lead to unexpected results.
>  .Pp
> +The following code fragment shows how one might process the arguments
> +for a command that can take the option
> +.Fl a
> +and the option
> +.Fl o ,
> +which requires an argument.
> +.Bd -literal -offset indent
> +while getopts ao: name
> +do
> + case $name in
> + a)  flag=1 ;;
> + o)  oarg=$OPTARG ;;
> + ?)  echo "Usage: ..."; exit 2 ;;
> + esac
> +done
> +shift $(($OPTIND - 1))
> +echo "Non-option arguments: " "$@"
> +.Ed
> +.Pp
>  .It Xo
>  .Ic hash
>  .Op Fl r
> Index: bin/ksh/sh.1
> ===
> RCS file: /cvs/src/bin/ksh/sh.1,v
> retrieving revision 1.152
> diff -u -p -r1.152 sh.1
> --- bin/ksh/sh.1  22 May 2019 15:23:23 -  1.152
> +++ bin/ksh/sh.1  30 Apr 2021 14:45:22 -
> @@ -508,6 +508,25 @@ is a colon,
>  .Ev OPTARG
>  is set to the unsupported option,
>  otherwise an error message is displayed.
> +.Pp
> +The following code fragment shows how one might process the arguments
> +for a command that can take the option
> +.Fl a
> +and the option
> +.Fl o ,
> +which requires an argument.
> +.Bd -literal -offset indent
> +while getopts ao: name
> +do
> + case $name in
> + a)  flag=1 ;;
> + o)  oarg=$OPTARG ;;
> + ?)  echo "Usage: ..."; exit 2 ;;
> + esac
> +done
> +shift $(($OPTIND - 1))
> +echo "Non-option arguments: " "$@"
> +.Ed
>  .It Ic hash Op Fl r | Ar utility
>  Add
>  .Ar utility
> Index: usr.bin/getopt/getopt.1
> ===
> RCS file: /cvs/src/usr.bin/getopt/getopt.1,v
> retrieving revision 1.19
> diff -u -p -r1.19 getopt.1
> --- usr.bin/getopt/getopt.1   16 Mar 2018 16:58:26 -  1.19
> +++ usr.bin/getopt/getopt.1   30 Apr 2021 14:25:17 -
> @@ -14,6 +14,13 @@
>  .Ar optstring
>  .Va $*
>  .Sh DESCRIPTION
> +The
> +.Nm
> +utility cannot handle option arguments containing whitespace;
> +consider using the standard
> +.Ic getopts
> +shell built-in instead.
> +.Pp
>  .Nm
>  is used to break up options in command lines for easy parsing by
>  shell procedures, and to check for legal options.
> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 



Re: shell manpage tweaks wrt getopt

2021-04-30 Thread Jason McIntyre
On Fri, Apr 30, 2021 at 04:07:55PM +0200, Marc Espie wrote:
> On Fri, Apr 30, 2021 at 02:44:01PM +0100, Jason McIntyre wrote:
> > On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote:
> > > Until a patch from naddy, I wasn't even aware of getopts in sh(1)
> > > 
> > > Unless I made some mistakes, this translates the example in getopt(1)
> > > manpage.
> > > 
> > > It's likely some stronger wording might be adequate, I suspect some
> > > of the BUGS section in getopt(1) does not apply to the sh(1) built-in.
> > > 
> > 
> > hi marc.
> > 
> > is there a reason why you wanted the example in sh(1) and not ksh(1)?
> > 
> > i think the overall structure is that ksh(1) is the full monty, whereas
> > sh(1) is really a simplified reference to which bits you can use if you
> > want to keep things portable. to that end there aren;t really any
> > examples in sh(1). i felt that having a short page was more beneficial
> > in the long run (especially since we already have a full on ksh(1)
> > page).
> > 
> > having said that, getopts is one of those things that you really won;t
> > get from reading descriptive text. an example is definitely helpful. so
> > i'd not be dead against it in sh(1) if there's a good reason.
> > 
> > there's also the possibility that it may be more helpful to show it in
> > getopts(1) itself? i guess there are pros and cons there too.
> > 
> > jmc
> 
> getopts(1) is not a separate command. Having built-ins in their separate
> manpage would be a definitive departure from what we've always done.
> 

i'm not advocating that. ah i think i see the misunderstanding - when i
said it could "show it in getopts(1) itself" i meant getopt(1) of
course. i was not proposing we create a getopts(1) page! sorry about
that!

> Some linux distributions do have some of the built-ins in their own
> man pages so that they're easier to find, which makes all kind of sense
> to me, even though it's pedantically incorrect.  I think it would help,
> but you are going to ruffle all kinds of feathers.
> 

where a standalone command and sh builtin co-exist (like kill) we
tend to note in STANDARDS for that command that a shell version
exists.  in this case though, getopt(1) just references sh(1): we
couldn;t add a pointer to STANDARDS (since it doesn't have one) so
i think we just nudged SEE ALSO. it could be that we should be more
upfront in getopt(1) about the shell built-in getopts.

> 
> Also, getopts is POSIX. Documenting it in ksh   would send the wrong signal
> in my opinion (but if I replace getopt with getopts, am I still writing
> a standard shell script).
> 

well, getopts is already documented in ksh(1). along with all the other
builtins mandated by posix. so i can;t see how it would "send the wrong
signal".

my argument boils down to: sh(1) is small and has no examples. adding
them changes the (deliberate) nature of the page. ksh(1) is what you
read when you can;t get to sleep.

why is it wrong to add your example to ksh(1)? why would that leave the
reader disadvantaged?

> That said, we can easily lift the exact same paragraph in both manpages.
> 

i don;t like that idea. these pages are already big enough, and duplicate text
always, at some point, goes out of sync.

jmc



Re: shell manpage tweaks wrt getopt

2021-04-30 Thread Jason McIntyre
On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote:
> Until a patch from naddy, I wasn't even aware of getopts in sh(1)
> 
> Unless I made some mistakes, this translates the example in getopt(1)
> manpage.
> 
> It's likely some stronger wording might be adequate, I suspect some
> of the BUGS section in getopt(1) does not apply to the sh(1) built-in.
> 

hi marc.

is there a reason why you wanted the example in sh(1) and not ksh(1)?

i think the overall structure is that ksh(1) is the full monty, whereas
sh(1) is really a simplified reference to which bits you can use if you
want to keep things portable. to that end there aren;t really any
examples in sh(1). i felt that having a short page was more beneficial
in the long run (especially since we already have a full on ksh(1)
page).

having said that, getopts is one of those things that you really won;t
get from reading descriptive text. an example is definitely helpful. so
i'd not be dead against it in sh(1) if there's a good reason.

there's also the possibility that it may be more helpful to show it in
getopts(1) itself? i guess there are pros and cons there too.

jmc

> Index: bin/ksh/sh.1
> ===
> RCS file: /cvs/src/bin/ksh/sh.1,v
> retrieving revision 1.152
> diff -u -p -r1.152 sh.1
> --- bin/ksh/sh.1  22 May 2019 15:23:23 -  1.152
> +++ bin/ksh/sh.1  30 Apr 2021 09:51:42 -
> @@ -508,6 +508,26 @@ is a colon,
>  .Ev OPTARG
>  is set to the unsupported option,
>  otherwise an error message is displayed.
> +.Pp
> +The following example has identical functionality to the
> +example in
> +.Xr getopt 1 .
> +.Bd -literal -offset indent
> +while getopts abo: name
> +do
> + case "$name"
> + in
> + a|b)
> + flag="-$name";;
> + o)
> + oarg="$OPTARG";;
> + ?)
> + echo "Usage: ..."
> + exit 2
> + ;;
> + esac
> +done
> +.Ed
>  .It Ic hash Op Fl r | Ar utility
>  Add
>  .Ar utility
> Index: usr.bin/getopt/getopt.1
> ===
> RCS file: /cvs/src/usr.bin/getopt/getopt.1,v
> retrieving revision 1.19
> diff -u -p -r1.19 getopt.1
> --- usr.bin/getopt/getopt.1   16 Mar 2018 16:58:26 -  1.19
> +++ usr.bin/getopt/getopt.1   30 Apr 2021 09:51:42 -
> @@ -54,7 +54,7 @@ which requires an argument.
>  args=`getopt abo: $*`
>  if [ $? -ne 0 ]
>  then
> - echo 'Usage: ...'
> + echo "Usage: ..."
>   exit 2
>  fi
>  set -- $args
> @@ -79,6 +79,11 @@ cmd -a -o arg file file
>  cmd -oarg -a file file
>  cmd -a -oarg -- file file
>  .Ed
> +Note that
> +.Xr sh 1
> +offers the
> +.Ic getopts
> +built-in with a simpler usage.
>  .Sh DIAGNOSTICS
>  .Nm
>  prints an error message on the standard error output when it
> 



Re: Updates for elf(5)

2021-04-15 Thread Jason McIntyre
On Thu, Apr 01, 2021 at 03:29:54PM +0100, George Brown wrote:
> In revision 1.35 EI_BRAND was removed in conjunction with EI_OSABI and
> EI_ABIVERSION being added, but it looks like this has not been reflected
> in elf(5). The only place EI_BRAND appears in OpenBSD's current source
> tree is this man page, as such I think it's worth removing.
> 
> For a quick comparison to other systems FreeBSD still mentions EI_BRAND
> but NetBSD does not (and never appeared to document this in any man
> page). With regards to EI_OSABI and EI_ABIVERSION FreeBSD covers the
> defined values whereas NetBSD does not as they note only ELFOSABI_SYSV
> is used. On the other hand FreeBSD does indeed mark native binaries as
> ELFOSABI_FREEBSD. Further afield in Linux EI_BRAND was removed, EI_OSABI
> and EI_ABIVERSION defined values are covered similar to FreeBSD.
> 
> The diff below removes mention of EI_BRAND and uncomments the EI_OSABI
> and EI_ABIVERSION parts which appear to have been present since the
> initial appearance of this man page. In addition I've added the mention
> of the Modesto and OpenBSD EI_OSABI values as they are defined in
> sys/sys/exec_elf.h.
> 

a different diff has been committed by kettenis. thanks for your mail,
jmc

> diff --git a/share/man/man5/elf.5 b/share/man/man5/elf.5
> index 57b0bf0da4d..6ce92ef9bb4 100644
> --- a/share/man/man5/elf.5
> +++ b/share/man/man5/elf.5
> @@ -207,51 +207,56 @@ Invalid version.
>  .It Dv EV_CURRENT
>  Current version.
>  .El
> -.\" .It Dv EI_OSABI
> -.\" This byte identifies the operating system
> -.\" and ABI to which the object is targeted.
> -.\" Some fields in other ELF structures have flags
> -.\" and values that have platform specific meanings;
> -.\" the interpretation of those fields is determined by the value of this 
> byte.
> -.\" The following values are currently defined:
> -.\" .Pp
> -.\" .Bl -tag -width "ELFOSABI_STANDALONE" -compact
> -.\" .It Dv ELFOSABI_SYSV
> -.\" UNIX System V ABI.
> -.\" .It Dv ELFOSABI_HPUX
> -.\" HP-UX operating system ABI.
> -.\" .It Dv ELFOSABI_NETBSD
> -.\" .Nx
> -.\" operating system ABI.
> -.\" .It Dv ELFOSABI_LINUX
> -.\" GNU/Linux operating system ABI.
> -.\" .It Dv ELFOSABI_HURD
> -.\" GNU/Hurd operating system ABI.
> -.\" .It Dv ELFOSABI_86OPEN
> -.\" 86Open Common IA32 ABI.
> -.\" .It Dv ELFOSABI_SOLARIS
> -.\" Solaris operating system ABI.
> -.\" .It Dv ELFOSABI_MONTEREY
> -.\" Monterey project ABI.
> -.\" .It Dv ELFOSABI_IRIX
> -.\" IRIX operating system ABI.
> -.\" .It Dv ELFOSABI_FREEBSD
> -.\" .Fx
> -.\" operating system ABI.
> -.\" .It Dv ELFOSABI_TRU64
> -.\" TRU64 UNIX operating system ABI.
> -.\" .It Dv ELFOSABI_ARM
> -.\" ARM architecture ABI.
> -.\" .It Dv ELFOSABI_STANDALONE
> -.\" Stand-alone (embedded) ABI.
> -.\" .El
> -.\" .It Dv EI_ABIVERSION
> -.\" This byte identifies the version of the ABI
> -.\" to which the object is targeted.
> -.\" This field is used to distinguish among incompatible versions of an ABI.
> -.\" The interpretation of this version number
> -.\" is dependent on the ABI identified by the EI_OSABI field.
> -.\" Applications conforming to this specification use the value 0.
> +.It Dv EI_OSABI
> +This byte identifies the operating system
> +and ABI to which the object is targeted.
> +Some fields in other ELF structures have flags
> +and values that have platform specific meanings;
> +the interpretation of those fields is determined by the value of this byte.
> +The following values are currently defined:
> +.Pp
> +.Bl -tag -width "ELFOSABI_STANDALONE" -compact
> +.It Dv ELFOSABI_SYSV
> +UNIX System V ABI.
> +.It Dv ELFOSABI_HPUX
> +HP-UX operating system ABI.
> +.It Dv ELFOSABI_NETBSD
> +.Nx
> +operating system ABI.
> +.It Dv ELFOSABI_LINUX
> +GNU/Linux operating system ABI.
> +.It Dv ELFOSABI_HURD
> +GNU/Hurd operating system ABI.
> +.It Dv ELFOSABI_86OPEN
> +86Open Common IA32 ABI.
> +.It Dv ELFOSABI_SOLARIS
> +Solaris operating system ABI.
> +.It Dv ELFOSABI_MONTEREY
> +Monterey project ABI.
> +.It Dv ELFOSABI_IRIX
> +IRIX operating system ABI.
> +.It Dv ELFOSABI_FREEBSD
> +.Fx
> +operating system ABI.
> +.It Dv ELFOSABI_TRU64
> +TRU64 UNIX operating system ABI.
> +.It Dv ELFOSABI_MODESTO
> +Modesto operating system ABI.
> +.It Dv ELFOSABI_OPENBSD
> +.Ox
> +operating system ABI.
> +.It Dv ELFOSABI_ARM
> +ARM architecture ABI.
> +.It Dv ELFOSABI_STANDALONE
> +Stand-alone (embedded) ABI.
> +.El
> +.It Dv EI_ABIVERSION
> +This byte identifies the version of the ABI
> +to which the object is targeted.
> +This field is used to distinguish among incompatible versions of an ABI.
> +The interpretation of this version number
> +is dependent on the ABI identified by the EI_OSABI field.
> +Applications conforming to this specification use the value 0.
>  .It Dv EI_PAD
>  Start of padding.
>  These bytes are reserved and set to zero.
> @@ -259,8 +264,6 @@ Programs
>  which read them should ignore them.
>  The value for EI_PAD will change in
>  the future if currently unused bytes are given 

Re: ifconfig(8) add bpe(4)

2021-04-11 Thread Jason McIntyre
On Sun, Apr 11, 2021 at 04:48:40PM +0200, Marcus MERIGHI wrote:
> hello!
> 
> the description of bpe(4) is missing from ifconfig(8).
> my attempt with what I could gather from bpe(4) below.
> 
> marcus
> 

hi.

the sections are ordered alphabetically, so it should go first,
immediately before BRIDGE.

except for that, it reads fine to me.
jmc

> Index: ifconfig.8
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
> retrieving revision 1.371
> diff -u -p -u -r1.371 ifconfig.8
> --- ifconfig.819 Mar 2021 19:36:10 -  1.371
> +++ ifconfig.811 Apr 2021 14:41:08 -
> @@ -182,6 +182,7 @@ Create the specified network pseudo-devi
>  At least the following devices can be created on demand:
>  .Pp
>  .Xr aggr 4 ,
> +.Xr bpe 4 ,
>  .Xr bridge 4 ,
>  .Xr carp 4 ,
>  .Xr egre 4 ,
> @@ -2205,6 +2206,31 @@ Valid tag values are from 1 to 4094 incl
>  Clear the tag value.
>  Packets on a VLAN interface without a tag set will use a value of
>  0 in their headers.
> +.El
> +.Sh BPE
> +.nr nS 1
> +.Bk -words
> +.Nm ifconfig
> +.Ar bpe-interface
> +.Op Oo Fl Oc Ns Cm parent Ar parent-interface
> +.Op Ns Cm vnetid Ar vnetid-tag
> +.Ek
> +.nr nS 0
> +.Pp
> +The following options are available for
> +.Xr bpe 4
> +interfaces:
> +.Bl -tag -width Ds
> +.It Cm parent Ar parent-interface
> +Associate the BPE interface with the interface
> +.Ar parent-interface .
> +.It Cm -parent
> +Disassociate from the parent interface.
> +This breaks the link between the BPE interface and its parent.
> +.It Cm vnetid Ar vnetid-tag
> +Set the virtual network identifier tag value to
> +.Ar vnetid-tag .
> +This is a 24-bit value in the range 0 to 16777215.
>  .El
>  .Sh WIREGUARD
>  .nr nS 1
> 



Re: missing arg in esample renice man command ?

2021-04-06 Thread Jason McIntyre
On Tue, Apr 06, 2021 at 02:41:28PM -0400, Sven F. wrote:
> On Tue, Apr 6, 2021 at 2:29 PM Jason McIntyre  wrote:
> >
> > On Tue, Apr 06, 2021 at 01:42:51PM -0400, Sven F. wrote:
> > > Line 120 , in renice.8
> > >
> > > https://github.com/openbsd/src/blob/master/usr.bin/renice/renice.8#L120
> > >
> > > # renice -n +1 987 -u daemon root -p 32
> > >
> > > should be
> > >
> > > # renice -n +1 -g 987 -u daemon root -p 32 ?
> > >
> > >
> > > --- usr.bin/renice/renice.8.orig   2021-04-06 13:41:09.272347600 -0400
> > > +++ usr.bin/renice/renice.82021-04-06 13:41:45.089202200 -0400
> > > @@ -117,7 +117,7 @@
> > >  changes the priority of process IDs 987 and 32,
> > >  and all processes owned by users daemon and root:
> > >  .Bd -literal -offset indent
> > > -# renice -n +1 987 -u daemon root -p 32
> > > +# renice -n +1 -g 987 -u daemon root -p 32
> > >  .Ed
> > >  .Sh SEE ALSO
> > >  .Xr nice 1 ,
> > >
> >
> > hi.
> >
> > i don;t think the example is wrong. it says it alters the priority of
> > process IDs 987 and 32. and the man page notes:
> >
> >  If none of the -gpu options are specified, the default is
> >  to select by process ID.
> >
> > having said that, i do think the example is a really weird way to
> > specify IDs 987 and 32 and users daemon and root. and since it does give
> > both -u and -p, it might not be entirely obvious to link it back to the
> > text sating that -p is the default. it would be saner to do:
> >
> > # renice -n +1 -p 987 32 -u daemon root
> > or
> > # renice -n +1 987 32 -u daemon root
> >
> > (not tested!)
> >
> > both netbsd and freebsd have the same example that we currently have, so
> > they're probably pretty old. so not sure if it's worth changing. or leaving
> > as an exercise to the reader...
> >
> > jmc
> >
> 
> example is fine, i got confused doing more than one thing at a time
> bit confusing the 987 is not after the option like in SYNOPSIS
> 
> On a helping / clarity point of vue,changing
> `The following example changes the priority of process`
> by something like
> `The following raise the priority of process to allocate more
> resources to it by 1 `
> may be more helping to someone in a hurry
> 

i think it's fine as it is.
jmc



Re: missing arg in esample renice man command ?

2021-04-06 Thread Jason McIntyre
On Tue, Apr 06, 2021 at 01:42:51PM -0400, Sven F. wrote:
> Line 120 , in renice.8
> 
> https://github.com/openbsd/src/blob/master/usr.bin/renice/renice.8#L120
> 
> # renice -n +1 987 -u daemon root -p 32
> 
> should be
> 
> # renice -n +1 -g 987 -u daemon root -p 32 ?
> 
> 
> --- usr.bin/renice/renice.8.orig   2021-04-06 13:41:09.272347600 -0400
> +++ usr.bin/renice/renice.82021-04-06 13:41:45.089202200 -0400
> @@ -117,7 +117,7 @@
>  changes the priority of process IDs 987 and 32,
>  and all processes owned by users daemon and root:
>  .Bd -literal -offset indent
> -# renice -n +1 987 -u daemon root -p 32
> +# renice -n +1 -g 987 -u daemon root -p 32
>  .Ed
>  .Sh SEE ALSO
>  .Xr nice 1 ,
> 

hi.

i don;t think the example is wrong. it says it alters the priority of
process IDs 987 and 32. and the man page notes:

 If none of the -gpu options are specified, the default is
 to select by process ID.

having said that, i do think the example is a really weird way to
specify IDs 987 and 32 and users daemon and root. and since it does give
both -u and -p, it might not be entirely obvious to link it back to the
text sating that -p is the default. it would be saner to do:

# renice -n +1 -p 987 32 -u daemon root
or
# renice -n +1 987 32 -u daemon root

(not tested!)

both netbsd and freebsd have the same example that we currently have, so
they're probably pretty old. so not sure if it's worth changing. or leaving
as an exercise to the reader...

jmc



Re: httpd.conf grammar

2021-04-06 Thread Jason McIntyre
On Mon, Apr 05, 2021 at 11:05:45PM +0100, Raf Czlonka wrote:
> Hello,
> 
> Could this get committed before the freeze?
> 

hi. thanks for your mail. i'd thought i was oking a diff, and it's
obviously been left at that.

anyway i rereviewed it, and decided my suggestion to have the sentence
in one place, though good, was bad ;) the trouble is it interferes with
the same sentence in SERVERS, and i worry it would make it unclear.

so i committed a diff which:

- changed brackets to braces, per raf's suggestion
- shortened that text, per mine
- noted that fatcgi could take multiple options

jmc

> Cheers,
> 
> Raf
> 
> On Mon, Mar 22, 2021 at 02:20:42PM GMT, Jason McIntyre wrote:
> > On Mon, Mar 22, 2021 at 01:33:34PM +, Raf Czlonka wrote:
> > > On Mon, Mar 22, 2021 at 07:08:32AM GMT, Jason McIntyre wrote:
> > > > On Sun, Mar 21, 2021 at 10:58:02PM +, Raf Czlonka wrote:
> > > > > 
> > > > > Hi Laurie,
> > > > > 
> > > > > I'd simply use the existing wording, without getting into details.
> > > > > 
> > > > > While there, "braces" dominate the manual page, with a single
> > > > > occurrence of "brackets" so let's change that too, for consistency.
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Raf
> > > > > 
> > > 
> > > Hi Jason,
> > > 
> > > > hi. i could have sworn i recently discussed this documenting of multiple
> > > > options with someone else, but cannot find the mails. anyway, a couple
> > > > of points:
> > > > 
> > > > - "a block of options that is enclosed in curly braces" can be 
> > > > shortened to
> > > >   "a block of options enclosed in curly braces". up to you.
> > > 
> > > Yup.
> > > 
> > > > - if it is generally true that where multiple options can be given they
> > > >   are specified in the same way (curly braces) then it would be better
> > > >   just to say up front that this is the case, rather than repeating the
> > > >   text endlessly everywhere it's possible.
> > > 
> > > I did think about it as there's a lot of repetition:
> > > 
> > >   $ grep '^Multiple options' /usr/share/man/man5/httpd.conf.5
> > >   Multiple options may be specified within curly braces.
> > >   Multiple options may be specified within curly braces.
> > >   Multiple options may be specified within curly braces.
> > >   Multiple options may be specified within curly braces.
> > >   Multiple options may be specified within curly braces.
> > >   Multiple options may be specified within curly braces.
> > > 
> > > but wanted the diff to be as small as possible ;^)
> > > 
> > > > in other respects i'm fine with the diff.
> > > > jmc
> > > 
> > > How about this?
> > > 
> > > Cheers,
> > > 
> > > Raf
> > > 
> > 
> > yes, exactly what i'd hoped. ok by me.
> > jmc
> > 
> > > Index: usr.sbin/httpd/httpd.conf.5
> > > ===
> > > RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> > > retrieving revision 1.114
> > > diff -u -p -r1.114 httpd.conf.5
> > > --- usr.sbin/httpd/httpd.conf.5   29 Oct 2020 12:30:52 -  1.114
> > > +++ usr.sbin/httpd/httpd.conf.5   22 Mar 2021 13:24:58 -
> > > @@ -78,6 +78,8 @@ the comment is effective until the end o
> > >  Argument names not beginning with a letter, digit, or underscore
> > >  must be quoted.
> > >  .Pp
> > > +Multiple options may be specified within curly braces.
> > > +.Pp
> > >  Additional configuration files can be included with the
> > >  .Ic include
> > >  keyword, for example:
> > > @@ -155,7 +157,7 @@ see
> > >  .Xr patterns 7 .
> > >  .El
> > >  .Pp
> > > -Followed by a block of options that is enclosed in curly brackets:
> > > +Followed by a block of options enclosed in curly braces:
> > >  .Bl -tag -width Ds
> > >  .It Ic alias Ar name
> > >  Specify an additional alias
> > > @@ -238,7 +240,6 @@ option.
> > >  .El
> > >  .It Ic connection Ar option
> > >  Set the specified options and limits for HTTP connections.
> > > -Multiple options may be specified within curly braces.
> > >  Valid options are:
> > >  .Bl -tag -width Ds
>

Re: printf.9: document limited conversion specification syntax

2021-04-04 Thread Jason McIntyre
yep, better than mine. ok
jmc

On 4 April 2021 14:41:13 BST, Klemens Nanni  wrote:
>On Sun, Apr 04, 2021 at 07:17:27AM +0100, Jason McIntyre wrote:
>> On Sun, Apr 04, 2021 at 01:22:23AM +0200, Klemens Nanni wrote:
>> > @@ -119,6 +119,17 @@ send formatted strings to the ddb console, and
>are onl
>> >  Since each of these kernel functions is a variant of its user
>space
>> >  counterpart, this page describes only the differences between the
>user
>> >  space and kernel versions.
>> > +.Pp
>> > +The limited syntax of a conversion specification is:
>> 
>> hi. i'm fine with your diff, though cannot really judge the actual
>> content. but the "limited syntax" text is a bit ambiguous. you could
>> still expect from it that a full syntax version is supported.
>Right, I do imply that nothing more is supported;  this sentence is a
>cheap copy of printf(3)'s sentence
>
> The overall syntax of a conversion specification is:
>
>> maybe spell it out?
>> 
>>  printf(9) supports a subset of the conversion specification
>>  available to printf(3):
>> 
>> sth like that?
>Thanks, how about this?
>
>Only a subset of the user space conversion specification is available
>to
> the kernel version:
>
>   %[width][size]conversion
>
> Refer to printf(3) for functional details.
>
>
>
>Index: share/man/man9/printf.9
>===
>RCS file: /cvs/src/share/man/man9/printf.9,v
>retrieving revision 1.24
>diff -u -p -r1.24 printf.9
>--- share/man/man9/printf.97 Nov 2015 03:48:25 -   1.24
>+++ share/man/man9/printf.94 Apr 2021 13:39:02 -
>@@ -119,6 +119,18 @@ send formatted strings to the ddb consol
> Since each of these kernel functions is a variant of its user space
> counterpart, this page describes only the differences between the user
> space and kernel versions.
>+.Pp
>+Only a subset of the user space conversion specification is available
>to the
>+kernel version:
>+.Bd -filled -offset indent
>+.Sm off
>+.Cm %
>+.Op Ar width
>+.Op Ar size
>+.Ar conversion
>+.Sm on
>+.Ed
>+.Pp
> Refer to
> .Xr printf 3
> for functional details.



Re: Typos in ssh man pages

2021-04-04 Thread Jason McIntyre
On Sun, Apr 04, 2021 at 11:25:56AM +0200, Matthias Schmidt wrote:
> Hi,
> 
> in the recent commits to ssh(d)_config.5 two typos slipped in (looks like
> classic "switch vi to edit mode" typo :)).
> 
> Cheers
> 
>   Matthias
> 

fixed, thanks.
jmc

> 
> diff --git a/usr.bin/ssh/ssh_config.5 b/usr.bin/ssh/ssh_config.5
> index 5202196bce5..cf7391d9ce1 100644
> --- a/usr.bin/ssh/ssh_config.5
> +++ b/usr.bin/ssh/ssh_config.5
> @@ -373,7 +373,7 @@ by certificate authorities (CAs).
>  The default is:
>  .Bd -literal -offset indent
>  ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> -sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,i
> +sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,
>  rsa-sha2-512,rsa-sha2-256
>  .Ed
>  .Pp
> diff --git a/usr.bin/ssh/sshd_config.5 b/usr.bin/ssh/sshd_config.5
> index e2509bb865f..35e9e3fdabc 100644
> --- a/usr.bin/ssh/sshd_config.5
> +++ b/usr.bin/ssh/sshd_config.5
> @@ -379,7 +379,7 @@ by certificate authorities (CAs).
>  The default is:
>  .Bd -literal -offset indent
>  ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> -sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,i
> +sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,
>  rsa-sha2-512,rsa-sha2-256
>  .Ed
>  .Pp
> 



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

2021-04-04 Thread Jason McIntyre
On Sat, Apr 03, 2021 at 02:33:05AM +0200, Klemens Nanni wrote:
> It has always bothered me that linting manuals complained about missing
> manuals from packages despite their path being part of the default
> MANPATH:
> 
> No local man(1) config:
> 
>   $ echo $MANPATH
>   ksh: MANPATH: parameter not set
>   $ cat /etc/man.conf
>   cat: /etc/man.conf: No such file or directory
> 
> man(1) finds tog(1), but mandoc(1) does not:
> 
>   $ mandoc -T lint `man -w tog` | grep 'not found'
>   mandoc: /usr/local/man/man1/tog.1:35:6: STYLE: referenced manual not 
> found: Xr git-repository 5 (2 times)
>   mandoc: /usr/local/man/man1/tog.1:188:6: STYLE: referenced manual not 
> found: Xr got 1 (6 times)
> 
> Not having those STYLE "issues" also makes `mandoc -T lint' more useful
> for automatic regression/pre-commit/etc. checks in ports using it since
> even STYLE messages result in a non-zero exit status, i.e. `make test'
> for a totally fine manual would fail.
> 
> Using `-W warning' to omit STYLE message entirely is undesired because
> it silences other useful style hints as well and parsing output to work
> around all this is hackish at best.
> 
> So let's lint manuals with the default MANPATH instead of the limited
> base one.
> 
> Feedback? Objections? OK?
> 

i think we need to hear from ingo on this one. it was done deliberately,
but i cannot remember why.

jmc

> 
> Index: main.c
> ===
> RCS file: /cvs/src/usr.bin/mandoc/main.c,v
> retrieving revision 1.256
> diff -u -p -r1.256 main.c
> --- main.c19 Feb 2021 19:49:49 -  1.256
> +++ main.c3 Apr 2021 00:29:56 -
> @@ -962,7 +962,7 @@ check_xr(void)
>   size_t   sz;
>  
>   if (paths.sz == 0)
> - manpath_base();
> + manpath_default();
>  
>   for (xr = mandoc_xr_get(); xr != NULL; xr = xr->next) {
>   if (xr->line == -1)
> Index: manconf.h
> ===
> RCS file: /cvs/src/usr.bin/mandoc/manconf.h,v
> retrieving revision 1.9
> diff -u -p -r1.9 manconf.h
> --- manconf.h 21 Jul 2020 15:08:49 -  1.9
> +++ manconf.h 3 Apr 2021 00:29:57 -
> @@ -55,4 +55,4 @@ struct  manconf {
>  void  manconf_parse(struct manconf *, const char *, char *, char *);
>  int   manconf_output(struct manoutput *, const char *, int);
>  void  manconf_free(struct manconf *);
> -void  manpath_base(struct manpaths *);
> +void  manpath_default(struct manpaths *);
> Index: manpath.c
> ===
> RCS file: /cvs/src/usr.bin/mandoc/manpath.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 manpath.c
> --- manpath.c 27 Aug 2020 14:59:42 -  1.30
> +++ manpath.c 3 Apr 2021 00:30:46 -
> @@ -93,10 +93,9 @@ manconf_parse(struct manconf *conf, cons
>  }
>  
>  void
> -manpath_base(struct manpaths *dirs)
> +manpath_default(struct manpaths *dirs)
>  {
> - char path_base[] = MANPATH_BASE;
> - manpath_parseline(dirs, path_base, '\0');
> + manpath_parseline(dirs, MANPATH_DEFAULT, '\0');
>  }
>  
>  /*
> 



Re: printf.9: document limited conversion specification syntax

2021-04-04 Thread Jason McIntyre
On Sun, Apr 04, 2021 at 01:22:23AM +0200, Klemens Nanni wrote:
> print(9) says it only documents differences and points at printf(3) for
> identical/shared bits:
> 
>DESCRIPTION
>  [...]
> 
>  Since each of these kernel functions is a variant of its user space
>  counterpart, this page describes only the differences between the user
>  space and kernel versions. Refer to printf(3) for functional details.
> 
>FORMAT OPTIONS
>  The kernel functions don't support as many formatting specifiers as their
>  user space counterparts.  In addition to the floating point formatting
>  specifiers, the following integer type specifiers are not supported:
> 
>  %hhArgument of char type.  This format specifier is accepted by the
> kernel but will be handled as %h.
> 
>  %j Argument of intmax_t or uintmax_t type.
> 
>  %t Argument of ptrdiff_t type.
> 
>  The kernel functions support some additional formatting specifiers:
> 
>  %b Bit field expansion.  [...]
> 
> 
> So reading this, I get the impression that print(3)'s entire conversion
> specifications syntax is supported (merely with a few less `conversion'
> specifiers):
> 
>   %[argno$][flags][width][.precision][size]conversion
> 
> but printf(9) supports much fewer specifiers, afaict amounting to
> 
>   %[width][size]conversion
> 
> That's fine, but code using printf(3) syntax might actually compile
> without warnings (like this example did for me) and be useless afterall:
> 
> + printf("%1$s: node %2$x:\n"
> + "  mclk_rate is %3$u (0x%3$x)\n",
> + __func__, sc->sc_node, mclk_rate);
> 
> Apr  4 00:32:29 pine64 /bsd:   mclk_rate is   $u (0x  $x)
> 
> 
> I don't fancy expanding syntax or adding checks to the kernel's printf.c
> but documenting it seems needed.
> 
> Feedback? Objections? OK?
> 
> diff 5b147494c5d594d5ec97ca57686c9e3527b87e29 /usr/src
> blob - c31fb0cb42e9af426c42306a54339ec7f7f375a7
> file + share/man/man9/printf.9
> --- share/man/man9/printf.9
> +++ share/man/man9/printf.9
> @@ -119,6 +119,17 @@ send formatted strings to the ddb console, and are onl
>  Since each of these kernel functions is a variant of its user space
>  counterpart, this page describes only the differences between the user
>  space and kernel versions.
> +.Pp
> +The limited syntax of a conversion specification is:

hi. i'm fine with your diff, though cannot really judge the actual
content. but the "limited syntax" text is a bit ambiguous. you could
still expect from it that a full syntax version is supported.

maybe spell it out?

printf(9) supports a subset of the conversion specification
available to printf(3):

sth like that?
jmc

> +.Bd -filled -offset indent
> +.Sm off
> +.Cm %
> +.Op Ar width
> +.Op Ar size
> +.Ar conversion
> +.Sm on
> +.Ed
> +.Pp
>  Refer to
>  .Xr printf 3
>  for functional details.
> 



Re: Mention -N to shutdown(2) network socket after EOF in man nc(1)

2021-03-31 Thread Jason McIntyre
On Tue, Mar 30, 2021 at 02:48:17AM +0200, Robert Scheck wrote:
> Jakub Jelen reported at Fedora that "nc -l 8080" (terminal #1) and "echo
> XXX | nc localhost 8080" (terminal #2) keeps hanging both client and server
> after reading the EOF, even the last sentence of "CLIENT/SERVER MODEL" in
> the man page of nc(1) says "The connection may be terminated using an EOF
> (???^D???)."
> 
> Based on Freenode #openbsd IRC the observed behaviour is correct but the
> man page should be updated, so my proposal is posted below. As I'm not sure
> if -N should be added to 'server' and 'client' side, I've cloned the "DATA
> TRANSFER" section, which covers the 'client' side only. Feel free to adjust
> my proposal as necessary.
> 
> 
> Thanks,
>   Robert
> 

hi.

thanks for your diff. it has been committed, with a small wording
change.

jmc

> --- nc.1  2020-02-12 14:46:36.831500390 + 1.95
> +++ nc.1  2021-03-30 02:22:34.545148296 +0200
> @@ -414,7 +414,7 @@
>  .Pq or a second machine ,
>  connect to the machine and port being listened on:
>  .Pp
> -.Dl $ nc 127.0.0.1 1234
> +.Dl $ nc -N 127.0.0.1 1234
>  .Pp
>  There should now be a connection between the ports.
>  Anything typed at the second console will be concatenated to the first,
> @@ -427,7 +427,10 @@
>  .Sq client .
>  The connection may be terminated using an
>  .Dv EOF
> -.Pq Sq ^D .
> +.Pq Sq ^D
> +if the
> +.Fl N
> +flag was given.
>  .Sh DATA TRANSFER
>  The example in the previous section can be expanded to build a
>  basic data transfer model.
> 



Re: httpd.conf grammar

2021-03-22 Thread Jason McIntyre
On Mon, Mar 22, 2021 at 01:33:34PM +, Raf Czlonka wrote:
> On Mon, Mar 22, 2021 at 07:08:32AM GMT, Jason McIntyre wrote:
> > On Sun, Mar 21, 2021 at 10:58:02PM +, Raf Czlonka wrote:
> > > 
> > > Hi Laurie,
> > > 
> > > I'd simply use the existing wording, without getting into details.
> > > 
> > > While there, "braces" dominate the manual page, with a single
> > > occurrence of "brackets" so let's change that too, for consistency.
> > > 
> > > Regards,
> > > 
> > > Raf
> > > 
> 
> Hi Jason,
> 
> > hi. i could have sworn i recently discussed this documenting of multiple
> > options with someone else, but cannot find the mails. anyway, a couple
> > of points:
> > 
> > - "a block of options that is enclosed in curly braces" can be shortened to
> >   "a block of options enclosed in curly braces". up to you.
> 
> Yup.
> 
> > - if it is generally true that where multiple options can be given they
> >   are specified in the same way (curly braces) then it would be better
> >   just to say up front that this is the case, rather than repeating the
> >   text endlessly everywhere it's possible.
> 
> I did think about it as there's a lot of repetition:
> 
>   $ grep '^Multiple options' /usr/share/man/man5/httpd.conf.5
>   Multiple options may be specified within curly braces.
>   Multiple options may be specified within curly braces.
>   Multiple options may be specified within curly braces.
>   Multiple options may be specified within curly braces.
>   Multiple options may be specified within curly braces.
>   Multiple options may be specified within curly braces.
> 
> but wanted the diff to be as small as possible ;^)
> 
> > in other respects i'm fine with the diff.
> > jmc
> 
> How about this?
> 
> Cheers,
> 
> Raf
> 

yes, exactly what i'd hoped. ok by me.
jmc

> Index: usr.sbin/httpd/httpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> retrieving revision 1.114
> diff -u -p -r1.114 httpd.conf.5
> --- usr.sbin/httpd/httpd.conf.5   29 Oct 2020 12:30:52 -  1.114
> +++ usr.sbin/httpd/httpd.conf.5   22 Mar 2021 13:24:58 -
> @@ -78,6 +78,8 @@ the comment is effective until the end o
>  Argument names not beginning with a letter, digit, or underscore
>  must be quoted.
>  .Pp
> +Multiple options may be specified within curly braces.
> +.Pp
>  Additional configuration files can be included with the
>  .Ic include
>  keyword, for example:
> @@ -155,7 +157,7 @@ see
>  .Xr patterns 7 .
>  .El
>  .Pp
> -Followed by a block of options that is enclosed in curly brackets:
> +Followed by a block of options enclosed in curly braces:
>  .Bl -tag -width Ds
>  .It Ic alias Ar name
>  Specify an additional alias
> @@ -238,7 +240,6 @@ option.
>  .El
>  .It Ic connection Ar option
>  Set the specified options and limits for HTTP connections.
> -Multiple options may be specified within curly braces.
>  Valid options are:
>  .Bl -tag -width Ds
>  .It Ic max request body Ar number
> @@ -265,7 +266,6 @@ Set the default media type for the speci
>  overwriting the global setting.
>  .It Ic directory Ar option
>  Set the specified options when serving or accessing directories.
> -Multiple options may be specified within curly braces.
>  Valid options are:
>  .Bl -tag -width Ds
>  .It Oo Ic no Oc Ic auto index
> @@ -451,7 +451,6 @@ but can be changed per server or locatio
>  Use the
>  .Ic no log
>  directive to disable logging of any requests.
> -Multiple options may be specified within curly braces.
>  Valid options are:
>  .Bl -tag -width Ds
>  .It Ic access Ar name
> @@ -509,7 +508,6 @@ Disable any previous
>  in a location.
>  .It Ic request Ar option
>  Configure the options for the request path.
> -Multiple options may be specified within curly braces.
>  Valid options are:
>  .Bl -tag -width Ds
>  .It Oo Ic no Oc Ic rewrite Ar path
> @@ -547,7 +545,6 @@ Enable or disable the specified TCP/IP o
>  and
>  .Xr ip 4
>  for more information about the options.
> -Multiple options may be specified within curly braces.
>  Valid options are:
>  .Bl -tag -width Ds
>  .It Ic backlog Ar number
> @@ -577,7 +574,6 @@ This will affect the TCP window size.
>  .It Ic tls Ar option
>  Set the TLS configuration for the server.
>  These options are only used if TLS has been enabled via the listen directive.
> -Multiple options may be specified within curly braces.
>  Valid options are:
>  .Bl -tag -width Ds
>  .It Ic certificate Ar file
> 



Re: httpd.conf grammar

2021-03-22 Thread Jason McIntyre
On Sun, Mar 21, 2021 at 10:58:02PM +, Raf Czlonka wrote:
> 
> Hi Laurie,
> 
> I'd simply use the existing wording, without getting into details.
> 
> While there, "braces" dominate the manual page, with a single
> occurrence of "brackets" so let's change that too, for consistency.
> 
> Regards,
> 
> Raf
> 

hi. i could have sworn i recently discussed this documenting of multiple
options with someone else, but cannot find the mails. anyway, a couple
of points:

- "a block of options that is enclosed in curly braces" can be shortened to
  "a block of options enclosed in curly braces". up to you.

- if it is generally true that where multiple options can be given they
  are specified in the same way (curly braces) then it would be better
  just to say up front that this is the case, rather than repeating the
  text endlessly everywhere it's possible.

in other respects i'm fine with the diff.
jmc

> Index: usr.sbin/httpd/httpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> retrieving revision 1.114
> diff -u -p -r1.114 httpd.conf.5
> --- usr.sbin/httpd/httpd.conf.5   29 Oct 2020 12:30:52 -  1.114
> +++ usr.sbin/httpd/httpd.conf.5   21 Mar 2021 22:56:53 -
> @@ -155,7 +155,7 @@ see
>  .Xr patterns 7 .
>  .El
>  .Pp
> -Followed by a block of options that is enclosed in curly brackets:
> +Followed by a block of options that is enclosed in curly braces:
>  .Bl -tag -width Ds
>  .It Ic alias Ar name
>  Specify an additional alias
> @@ -282,6 +282,7 @@ will neither display nor generate a dire
>  .El
>  .It Oo Ic no Oc Ic fastcgi Oo Ar option Oc
>  Enable FastCGI instead of serving files.
> +Multiple options may be specified within curly braces.
>  Valid options are:
>  .Bl -tag -width Ds
>  .It Ic socket Oo Cm tcp Oc Ar socket Oo Ar port Oc
> 



Re: apm, apmd: ship manual pages on powerpc64

2021-03-21 Thread Jason McIntyre
On Sat, Mar 20, 2021 at 07:29:11PM -0600, Theo de Raadt wrote:
> There is a pattern we've followed in the past, that when a manpage applies
> to more than 2 (or 3?) architectures, then we simply make it MI.
> 
> So MANSUBDIR would get deleted, and then the sets would be updated.
> 
> People with old systems will retain the old files, but I think man(1)
> selects the MI ones over the MD ones (I think we have no override capability).
> 

man chooses the MD page over the MI page, i think. from man(1):

Machine specific areas are searched before general areas.

so you'd get the old page unless you deleted it. i don;t know if you can
override that.

jmc

> Klemens Nanni  wrote:
> 
> > It looks like an oversight when those were hooked up, but I don't have
> > access to that platform to test myself.
> > 
> > Feedback? OK?
> > 
> > Index: usr.sbin/apm/Makefile
> > ===
> > RCS file: /cvs/src/usr.sbin/apm/Makefile,v
> > retrieving revision 1.19
> > diff -u -p -r1.19 Makefile
> > --- usr.sbin/apm/Makefile   15 Jul 2020 22:46:52 -  1.19
> > +++ usr.sbin/apm/Makefile   20 Mar 2021 20:57:23 -
> > @@ -19,6 +19,6 @@ NOPROG=yes
> >  .endif
> >  
> >  MAN=   apm.8
> > -MANSUBDIR=arm64 amd64 i386 loongson macppc sparc64
> > +MANSUBDIR=arm64 amd64 i386 loongson macppc sparc64 powerpc64
> >  
> >  .include 
> > Index: usr.sbin/apmd/Makefile
> > ===
> > RCS file: /cvs/src/usr.sbin/apmd/Makefile,v
> > retrieving revision 1.15
> > diff -u -p -r1.15 Makefile
> > --- usr.sbin/apmd/Makefile  15 Jul 2020 22:46:52 -  1.15
> > +++ usr.sbin/apmd/Makefile  20 Mar 2021 21:00:37 -
> > @@ -13,6 +13,6 @@ NOPROG=yes
> >  .endif
> >  
> >  MAN=   apmd.8
> > -MANSUBDIR= arm64 amd64 i386 loongson macppc sparc64
> > +MANSUBDIR= arm64 amd64 i386 loongson macppc sparc64 powerpc64
> >  
> >  .include 
> > Index: distrib/sets/lists/man/mi
> > ===
> > RCS file: /cvs/src/distrib/sets/lists/man/mi,v
> > retrieving revision 1.1616
> > diff -u -p -r1.1616 mi
> > --- distrib/sets/lists/man/mi   1 Mar 2021 23:26:59 -   1.1616
> > +++ distrib/sets/lists/man/mi   20 Mar 2021 21:00:15 -
> > @@ -2511,6 +2511,8 @@
> >  ./usr/share/man/man8/pkg_check.8
> >  ./usr/share/man/man8/portmap.8
> >  ./usr/share/man/man8/powerpc64/MAKEDEV.8
> > +./usr/share/man/man8/powerpc64/apm.8
> > +./usr/share/man/man8/powerpc64/apmd.8
> >  ./usr/share/man/man8/powerpc64/eeprom.8
> >  ./usr/share/man/man8/pppd.8
> >  ./usr/share/man/man8/pppstats.8
> > 
> 



Re: wg(4): add history section

2021-03-14 Thread Jason McIntyre
On Sat, Mar 13, 2021 at 10:47:30PM +0200, Maxim Vuets wrote:
> Documented in which release wg(4) has been added
> (as per ).
> 
> Index: share/man/man4/wg.4
> ===
> RCS file: /cvs/src/share/man/man4/wg.4,v
> retrieving revision 1.9
> diff -u -r1.9 wg.4
> --- share/man/man4/wg.4   27 Nov 2020 15:08:22 -  1.9
> +++ share/man/man4/wg.4   13 Mar 2021 18:37:17 -
> @@ -208,6 +208,11 @@
>  .%T WireGuard whitepaper
>  .%U https://www.wireguard.com/papers/wireguard.pdf
>  .Re
> +.Sh HISTORY
> +The
> +.Nm
> +driver first appeared in
> +.Ox 6.8 .
>  .Sh AUTHORS
>  .An -nosplit
>  The
> 

committed, thanks.
jmc



Re: Clarifications about ELF(5)

2021-02-27 Thread Jason McIntyre
On Sat, Feb 27, 2021 at 07:26:42PM +, George Brown wrote:
> > hi. diff committed, with one change: we did not add "must" (just removed
> > "usually").
> >
> > jmc
> 
> Thanks Jason. Though browsing cvsweb it seems the commit did include the
> "must" not sure if the decision changed after sending your mail or the
> wrong diff got applied?
> 

thanks, i totally messed up my commit. i've fixed that now. sorry that i
also didn;t credit you as the author of the diff!

thanks for your diff and the follow up.
jmc



Re: Clarifications about ELF(5)

2021-02-27 Thread Jason McIntyre
On Sat, Feb 27, 2021 at 12:24:33PM +, George Brown wrote:
> Binaries without a .note.openbsd.ident section fail to execute. This
> note section is mentioned in the ELF man page as follows.
> 
> > .note  This section holds information in the note section format
> >described below.  This section is of type SHT_NOTE.  No
> >attribute types are used.  OpenBSD native executables usually
> >contain a .note.openbsd.ident section to identify themselves,
> >for the kernel to bypass any compatibility ELF binary emula-
> >tion tests when loading the file.
> 
> The use of the word "usually" makes this read ambiguously to me. In that
> it's not clear if this note is present and/or required in all binaries.
> 
> Examining binaries on my system it seems this note is indeed always
> present and from practise does seem to be required (removing it from
> binaries with objcopy -R causes execution to fail). The mention of
> "emulation" made we wonder if perhaps this was referring to the old
> compat_linux layer. Reviewing the history it seems this part of the man
> page is largely unchanged from it's import in V 1.1 which pre-dates the
> removal of compat_linux.
> 
> Is this indeed a remnant? If so should an update with firmer wording be
> made, perhaps something like the following? Though I'm not really sure
> what in the underlying implantation this note represents in a post
> compat_linux removal world?
> 
> diff --git a/share/man/man5/elf.5 b/share/man/man5/elf.5
> index d22279f6738..aece235de6b 100644
> --- a/share/man/man5/elf.5
> +++ b/share/man/man5/elf.5
> @@ -1026,10 +1026,9 @@ This section is of type
>  .Dv SHT_NOTE .
>  No attribute types are used.
>  .Ox
> -native executables usually contain a
> +native executables must contain a
>  .Sy .note.openbsd.ident
> -section to identify themselves, for the kernel to bypass any compatibility
> -ELF binary emulation tests when loading the file.
> +section to identify themselves.
>  .It .plt
>  This section holds the procedure linkage table.
>  This section is of type
> 

hi. diff committed, with one change: we did not add "must" (just removed
"usually").

jmc



Re: ober_get_string.3: s/byte/character

2021-02-22 Thread Jason McIntyre
On Mon, Feb 22, 2021 at 11:12:32PM +0100, Martijn van Duren wrote:
> As pointed out by claudio@, it makes more sense to talk about characters
> for fmt instead of bytes.
> 
> The .Bl line already was >80 columns, but I don't know how to remedy
> this situation, so this diff makes that a little worse.
> 

hi.

you can just use a "\", but i think it makes the source look worse, so i
would just leave it as-is (especially since, as you say, the 80 point is
already passed).

there is trailing whitespace at eol 74, so please zap that when/if you
commit.

one comment inline about the Bl line:

> martijn@
> 
> Index: ober_get_string.3
> ===
> RCS file: /cvs/src/lib/libutil/ober_get_string.3,v
> retrieving revision 1.4
> diff -u -p -r1.4 ober_get_string.3
> --- ober_get_string.3 22 Feb 2021 17:15:02 -  1.4
> +++ ober_get_string.3 22 Feb 2021 22:08:32 -
> @@ -87,15 +87,15 @@ to return a valid
>  .Fn ober_scanf_elements
>  retrieves the values from zero or more elements starting at
>  .Fa root .
> -For each byte in
> +For each character in
>  .Fa fmt ,
>  arguments of the types given in the following table are consumed
>  and passed to the function listed, processing one
>  .Vt ber_element
> -per byte.
> -The following bytes are valid:
> -.Bl -column -offset indent bytes ober_get_enumerated() "1: struct 
> ber_element **"
> -.It Sy byte Ta Sy function Ta Sy arguments
> +per character.
> +The following characters are valid:
> +.Bl -column -offset indent characters ober_get_enumerated() "1: struct 
> ber_element **"

i would rewrite this as:

.Bl -column "( or {" "ober_get_enumerated()" "1: struct ber_element **" 
-offset indent

it just seems clearer to specify the column widths after the "-column"
marker, and finish with the offset.

column lists are horrible.

jmc

> +.It Sy character Ta Sy function Ta Sy arguments
>  .It $ Ta see below  Ta 0
>  .It B Ta Fn ober_get_bitstring  Ta 2: Vt void ** , size_t *
>  .It b Ta Fn ober_get_booleanTa 1: Vt int *
> 
> 



Re: OpenSMTPD docs: forward.5

2021-02-13 Thread Jason McIntyre
On Sat, Feb 13, 2021 at 09:47:41PM +, Larry Hynes wrote:
> Jason McIntyre  wrote:
> > On Fri, Feb 12, 2021 at 03:15:47PM +, Larry Hynes wrote:
> > > 
> > > Index: forward.5
> > > ===
> > > RCS file: /cvs/src/usr.sbin/smtpd/forward.5,v
> > > retrieving revision 1.9
> > > diff -u -p -r1.9 forward.5
> > > --- forward.5 13 Mar 2015 22:41:54 -  1.9
> > > +++ forward.5 12 Feb 2021 15:14:44 -
> > > @@ -49,10 +49,10 @@ group or world-writable;
> > >  if the home directory is group writeable;
> > >  or if the file is not owned by the user.
> > >  .Pp
> > > -Users should avoid editing directly the
> > > +Users should avoid editing the
> > >  .Nm .forward
> > > -file to prevent delivery failures from occurring if a message
> > > -arrives while the file is not fully written.
> > > +file directly, to prevent delivery failures from occurring if
> > > +a message arrives while the file is not fully written.
> > >  The best option is to use a temporary file and use the
> > >  .Xr mv 1
> > >  command to atomically overwrite the former
> > > 
> > 
> > fixed, thanks.
> > jmc
> 
> I meant to note that 'mandoc -Tlint' gives the following gripe about
> forward.5:
> 
>   forward.5:40:13: STYLE: no blank before trailing delimiter:
>   Pq :include:
> 
> It can be "fixed" by escaping the closing ':' at EOL with '\&' but I
> don't know if that's correct (or worth it).
> 

the idea is to catch punctuation not separated by whitespace, such as:

Such as
.Ar foo:

but in this case the argument to Pq is correct.

it's better to have it as a false positive (i think) than to mangle the
source to avoid the warning.

jmc



Re: OpenSMTPD docs: smtp.1

2021-02-13 Thread Jason McIntyre
On Fri, Feb 12, 2021 at 05:35:07PM +, Larry Hynes wrote:
> Note: the command 'smtp -h' only returns usage. Usage exits with '1'
> (I assume this is to satisfy the default case in switch (ch) in
> main()), even when called from the correct use of the '-h' flag,
> which I don't think is correct.
> 
> Index: smtp.1
> ===
> RCS file: /cvs/src/usr.sbin/smtpd/smtp.1,v
> retrieving revision 1.8
> diff -u -p -r1.8 smtp.1
> --- smtp.121 Dec 2020 11:48:38 -  1.8
> +++ smtp.112 Feb 2021 17:30:55 -
> @@ -58,7 +58,7 @@ Default to the current username.
>  .It Fl H Ar helo
>  Define the hostname to advertise (HELO) when establishing the SMTP session.
>  .It Fl h
> -Display version and usage.
> +Display usage.
>  .It Fl n
>  Do not actually execute a transaction,
>  just try to establish an SMTP session and quit.
> 

taken.

i think that's the last of your current diffs - thanks for the
submissions.

jmc



Re: OpenSMTPD docs: table.5

2021-02-13 Thread Jason McIntyre
On Fri, Feb 12, 2021 at 03:30:11PM +, Larry Hynes wrote:
> 
> Index: table.5
> ===
> RCS file: /cvs/src/usr.sbin/smtpd/table.5,v
> retrieving revision 1.11
> diff -u -p -r1.11 table.5
> --- table.5   11 Aug 2019 13:00:57 -  1.11
> +++ table.5   12 Feb 2021 15:29:25 -
> @@ -52,7 +52,7 @@ value3
>  .Ed
>  .Pp
>  A mapping will be written with each key and value on a line,
> -whitespaces separating both columns:
> +whitespace separating both columns:
>  .Bd -literal -offset indent
>  key1 value1
>  key2 value2
> @@ -90,7 +90,7 @@ user3   otheru...@example.com
>  .Ed
>  .Pp
>  In a virtual domain context, the key is either a user part, a full email
> -address or a catch all, following selection rules described in
> +address or a catch-all, following selection rules described in

taken, since makemap.8 uses the same spelling

>  .Xr smtpd.conf 5 ,
>  and the value is one or many recipients as described in
>  .Xr aliases 5 :
> @@ -164,7 +164,7 @@ They can only be used in the following c
>  When used as a "from source", the address of a client is compared to the list
>  of addresses in the table until a match is found.
>  .Pp
> -A netaddr table can contain exact addresses or netmasks, and looks as follow:
> +A netaddr table can contain exact addresses or netmasks, as follows:
>  .Bd -literal -offset indent
>  192.168.1.1
>  ::1
> @@ -172,7 +172,7 @@ ipv6:::1
>  192.168.1.0/24
>  .Ed
>  .Ss Userinfo tables
> -User info tables are used in rule context to specify an alternate user base,
> +Userinfo tables are used in a rule context to specify an alternate userbase,

taken

>  mapping virtual users to local system users by UID, GID and home directory.
>  .Pp
>  .D1 Ic action Ar name method Cm userbase Pf < Ar table Ns >
> @@ -234,15 +234,15 @@ user@*.domain
>  .Ed
>  .Ss Addrname tables
>  Addrname tables are used to map IP addresses to hostnames.
> -They can be used in both listen context and relay context:
> +They can be used in both listen and relay contexts:
>  .Bd -unfilled -offset indent
>  .Ic listen on Ar interface Cm hostnames Pf < Ar table Ns >
>  .Ic action Ar name Cm relay helo\-src Pf < Ar table Ns >
>  .Ed
>  .Pp
> -In listen context, the table is used to look up the server name to advertise
> +In a listen context, the table is used to look up the server name to 
> advertise
>  depending on the local address of the socket on which a connection is 
> accepted.
> -In relay context, the table is used to determine the hostname for the HELO
> +In a relay context, the table is used to determine the hostname for the HELO
>  sequence of the SMTP protocol, depending on the local address used for the
>  outgoing connection.
>  .Pp
> 

changes not commented on not committed.
jmc



  1   2   3   4   5   6   7   8   9   10   >