Re: [PATCH 1/3] Add missing clear(1) man page

[Jason McIntyre]

thanks, have committed this.
jmc

On Wed, Apr 24, 2024 at 02:09:13AM +0200, Piotr Durlej wrote:
> ---
>  usr.bin/tput/Makefile |   1 +
>  usr.bin/tput/clear.1  | 163 ++
>  2 files changed, 164 insertions(+)
>  create mode 100644 usr.bin/tput/clear.1
> 
> diff --git a/usr.bin/tput/Makefile b/usr.bin/tput/Makefile
> index 7b261e36c7f..c966ab1acee 100644
> --- a/usr.bin/tput/Makefile
> +++ b/usr.bin/tput/Makefile
> @@ -11,6 +11,7 @@ TIC= ${.CURDIR}/../tic
>  CFLAGS+= -I${CURSES} -I${TIC} -I${.CURDIR} -I.
>  .PATH:  ${TIC}
>  CLEANFILES+= termsort.h
> +MAN+=clear.1
>  
>  termsort.h: ${TIC}/MKtermsort.sh
>   sh ${TIC}/MKtermsort.sh awk ${CURSES}/Caps > ${.TARGET}
> diff --git a/usr.bin/tput/clear.1 b/usr.bin/tput/clear.1
> new file mode 100644
> index 000..c5184de779c
> --- /dev/null
> +++ b/usr.bin/tput/clear.1
> @@ -0,0 +1,163 @@
> +.\"***
> +.\" Copyright 2018-2021,2022 Thomas E. Dickey
> *
> +.\" Copyright 1998-2016,2017 Free Software Foundation, Inc.  
> *
> +.\"  
> *
> +.\" Permission is hereby granted, free of charge, to any person obtaining a  
> *
> +.\" copy of this software and associated documentation files (the
> *
> +.\" "Software"), to deal in the Software without restriction, including  
> *
> +.\" without limitation the rights to use, copy, modify, merge, publish,  
> *
> +.\" distribute, distribute with modifications, sublicense, and/or sell   
> *
> +.\" copies of the Software, and to permit persons to whom the Software is
> *
> +.\" furnished to do so, subject to the following conditions: 
> *
> +.\"  
> *
> +.\" The above copyright notice and this permission notice shall be included  
> *
> +.\" in all copies or substantial portions of the Software.   
> *
> +.\"  
> *
> +.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS  
> *
> +.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF   
> *
> +.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.   
> *
> +.\" IN NO EVENT SHALL THE ABOVE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,   
> *
> +.\" DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> *
> +.\" OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
> *
> +.\" THE USE OR OTHER DEALINGS IN THE SOFTWARE.   
> *
> +.\"  
> *
> +.\" Except as contained in this notice, the name(s) of the above copyright   
> *
> +.\" holders shall not be used in advertising or otherwise to promote the 
> *
> +.\" sale, use or other dealings in this Software without prior written   
> *
> +.\" authorization.   
> *
> +.\"***
> +.\"
> +.\" $Id: clear.1,v 1.27 2022/02/12 20:07:29 tom Exp $
> +.TH clear 1 ""
> +.\" these would be fallbacks for DS/DE,
> +.\" but groff changed the meaning of the macros.
> +.de NS
> +.ie n  .sp
> +.el.sp .5
> +.ie n  .in +4
> +.el.in +2
> +.nf
> +.ft C\" Courier
> +..
> +.de NE
> +.fi
> +.ft R
> +.ie n  .in -4
> +.el.in -2
> +..
> +.ie \n(.g .ds `` \(lq
> +.el   .ds `` ``
> +.ie \n(.g .ds '' \(rq
> +.el   .ds '' ''
> +.de bP
> +.ie n  .IP \(bu 4
> +.el.IP \(bu 2
> +..
> +.ds n 5
> +.SH NAME
> +\fBclear\fP \- clear the terminal screen
> +.SH SYNOPSIS
> +\fBclear\fR [\fB\-T\fItype\fR] [\fB\-V\fR] [\fB\-x\fR]
> +.br
> +.SH DESCRIPTION
> +\fBclear\fP clears your terminal's screen if this is possible,
> +including the terminal's scrollback buffer
> +(if the extended \*(``E3\*('' capability is defined).
> +\fBclear\fP looks in the environment for the terminal type
> +given by the environment variable \fBTERM\fP,
> +and then in the
> +\fBterminfo\fP database to determine how to clear the screen.
> +.PP
> +\fBclear\fP writes to the standard output.
> +You can redirect the standard output to a file (which prevents
> +\fBclear\fP from actually clearing the screen),
> +and later \fBcat\fP the file to the screen, clearing it at that point.
> +.SH OPTIONS
> +.PP
> +.TP 5
> +.B \-T \fItype\fP
> +indicates the \fItype\fP of terminal.
> +Normally this option is
> +unnecessary, because the default is taken from the environment
> +variable \fBTERM\fP.
> +If \fB\-T\fP is specified, then the shell
> +variables \fBLINES\fP and \fBCOLUMNS\fP will also be ignored.
> +.TP
> +.B \-V
> +reports the version of ncurses which was used in this program, and exits.
> +The 

Re: [PATCH] Remove the no longer supported ! command from less.hlp

[Jason McIntyre]

On Sun, Apr 21, 2024 at 08:14:54PM +0200, Piotr Durlej wrote:
> ---
>  less.hlp | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/less.hlp b/less.hlp
> index 2bc53df..f89f87b 100644
> --- a/less.hlp
> +++ b/less.hlp
> @@ -96,7 +96,6 @@
>___<_n_a_m_e_> Display the setting of an option, by name.
>+_c_m_d Execute the less cmd each time a new file is 
> examined.
>  
> -  !_c_o_m_m_a_n_d Execute the shell command with $SHELL.
>|XX_c_o_m_m_a_n_dPipe file between current pos & mark 
> XX to shell command.
>vEdit the current file with $VISUAL or $EDITOR.
>VPrint version number of "less".
> -- 
> 2.44.0
> 

fixed, thanks.
jmc

Re: touchpad sometimes stops working

[Jason McIntyre]

On Fri, Mar 01, 2024 at 09:52:51AM +0100, o...@omarpolo.com wrote:
> >Synopsis:touchpad sometimes stops working
> >Category:amd64
> >Environment:
>   System  : OpenBSD 7.4
>   Details : OpenBSD 7.4-current (GENERIC.MP) #1689: Thu Feb 15 
> 18:32:43 MST 2024
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   Sometimes the touchpad stops working.  It doesn't respond to
>   finger movements nor to clicks with the buttons.
>   So far it happened only while I was moving the mouse, i.e. it
>   stops working midway a single "swipe".
> 
>   When it happens, the rest of the machine seems working (music
>   still plays, I can control the window manager with the
>   keyboard, network is still working, etc...).
>   Nothing is reported in /var/log/messages.
> 
>   Machine doesn't suspend, and after an hibernation[0] cycle
>   the mouse is still stuck, a reboot (shutdown -r) seems to be
>   required.
> 
>   [0]: fwiw in order to hibernate I have to stop X11, otherwise
>   the machine doesn't resurrect from sleep.
> 
>   My /etc/wsconsctl.conf contains only
> 
>   mouse.tp.tapping=1
> 
>   and if it matters I have a nonstandard /etc/kbdtype
>   (us.swapctrlcaps.dvorak.)  Otherwise, no other wscons
>   settings.
> 
> >How-To-Repeat:
>   Seems to happen randomly.  It could happen in a row or not
>   happen for a day.
> >Fix:
>   No idea.
> 
> 

hi.

this sounds very similar to an issue i have (long standing) with my
laptop. essentially the pointer stops working (if i remember, it
actually disappears, but i could be wrong). sometimes very quickly,
sometimes it runs for hours without issue. but it always happens.

about the time i noticed it, i did bug some developers, but we could
never find a fix. i do have a workaround though, which you could try. it
appears to be an issue with ihidev. i use this diff:

Index: dev/i2c/ihidev.c
===
RCS file: /cvs/src/sys/dev/i2c/ihidev.c,v
retrieving revision 1.29
diff -u -p -r1.29 ihidev.c
--- dev/i2c/ihidev.c12 Aug 2023 10:03:05 -  1.29
+++ dev/i2c/ihidev.c1 Mar 2024 11:56:47 -
@@ -38,7 +38,7 @@
 #define DPRINTF(x)
 #endif
 
-#define SLOW_POLL_MS   200
+#define SLOW_POLL_MS   100
 #define FAST_POLL_MS   10
 
 /* 7.2 */
@@ -116,7 +116,7 @@ ihidev_attach(struct device *parent, str
printf(", failed fetching initial HID descriptor\n");
return;
}
-
+/*
if (ia->ia_intr) {
printf(" %s", iic_intr_string(sc->sc_tag, ia->ia_intr));
 
@@ -125,7 +125,7 @@ ihidev_attach(struct device *parent, str
if (sc->sc_ih == NULL)
printf(", can't establish interrupt");
}
-
+*/
if (ia->ia_poll || !sc->sc_ih) {
printf(" (polling)");
sc->sc_poll = 1;

in my dmesg, i get a line like this:

ihidev0 at iic0 addr 0x2c (polling), vendor 0x4f3 product 0x3147, 
DELL0A1E

notice "polling" where before it said gpio9.

the effect of putting it in polling mode makes the pointer feel very
sluggish (which is why i think i changed the value of SLOW_POLL_MS,
which isn;t strictly neccessary. i also started using the synaptics(4)
driver, since it makes it easier to make the pointer more responsive.

anyway, you could try the patch and see if it helps. it would at least
be useful to see if it's the same issue. please report here if it does
or does not help/

i'm afraid i don;t have a proper fix though.
dmesg from my -current laptop below.

jmc

OpenBSD 7.5 (GENERIC.MP) #54: Thu Feb 29 19:59:17 GMT 2024
j...@manila.kerhand.co.uk:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7894605824 (7528MB)
avail mem = 7634567168 (7280MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xca706000 (77 entries)
bios0: vendor Dell Inc. version "1.14.0" date 12/12/2023
bios0: Dell Inc. Inspiron 5505
efi0 at bios0: UEFI 2.7
efi0: Dell Inc. rev 0x10f00
acpi0 at bios0: ACPI 5.0Undefined scope: \\_SB_.PCI0.LPC0.EC0_

acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP UEFI SSDT IVRS SSDT SSDT TPM2 MSDM ASF! BOOT HPET APIC 
MCFG SLIC SSDT WSMT VFCT SSDT SSDT CRAT CDIT SSDT SSDT SSDT SSDT SSDT FPDT SSDT 
SSDT SSDT SSDT SSDT SSDT SSDT SSDT BGRT
acpi0: wakeup devices GP17(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 4700U with Radeon Graphics, 2000.00 MHz, 17-60-01, patch 
08600106
cpu0: 

Re: Typo in if_bge.c

[Jason McIntyre]

On Sat, Feb 10, 2024 at 07:05:01PM +0200, Andrius V wrote:
> Multiple typos were fixed in this file in the past, but one slipped away.
> 

fixed, thanks.
jmc

> diff --git a/sys/dev/pci/if_bge.c b/sys/dev/pci/if_bge.c
> index 8dc020150c7..4ad031a5ec9 100644
> --- a/sys/dev/pci/if_bge.c
> +++ b/sys/dev/pci/if_bge.c
> @@ -2099,7 +2099,7 @@ bge_blockinit(struct bge_softc *sc)
>  * The BD ring replenish thresholds control how often the
>  * hardware fetches new BD's from the producer rings in host
>  * memory.  Setting the value too low on a busy system can
> -* starve the hardware and recue the throughput.
> +* starve the hardware and reduce the throughput.
>  *
>  * Set the BD ring replenish thresholds. The recommended
>  * values are 1/8th the number of descriptors allocated to
> 

Re: man 7z - wrong file path in section Switches

[Jason McIntyre]

On Tue, Jun 27, 2023 at 09:45:37PM +0300, kodcode wrote:
> Hello,
> 
> in `man 7z` in section SWITCHES it states:
> 
> -m{Parameters}
>   Set Compression Method (see
>   /usr/local/share/doc/p7zip/DOC/MANUAL/switches/method.htm for a
>   list of methods)
> 
> The correct path to the file method.htm is:
> /usr/local/share/doc/p7zip/DOC/MANUAL/cmdline/switches/method.htm
> 
> Regards.
> kodcode
> 

hi.

7z comes from the p7zip port, i think. port man pages will sometimes
have incorrect paths, because i think the fuss to maintain local changes
like that is not worth it. you could try contacting the port maintainer
to see if they are happy with that or want to change it. i think p7zip
is just listed under po...@openbsd.org, so if no one gives you a more
concrete answer here, you could try mailing that list.

jmc

Re: 404 running syspatch on armv7

[Jason McIntyre]

On Sun, Mar 12, 2023 at 01:50:41PM +0100, Sebastian Benoit wrote:
> kod code(kodc...@gmx.com) on 2023.03.11 21:52:14 +0100:
> > I got the wrong impression from 'man afterboot' where it states
> > that syspatches can be installed with syspatch(8).
> 
> let's make it a bit clearer then, diff below.
> 
> ok?
>  
> > > Sent: Saturday, March 11, 2023 at 10:41 PM
> > > From: "Peter Hessler" 
> > > To: "kod code" 
> > > Cc: bugs@openbsd.org
> > > Subject: Re: 404 running syspatch on armv7
> > >
> > > On 2023 Mar 11 (Sat) at 20:33:28 +0100 (+0100), kod code wrote:
> > > :syspatch: Error retrieving 
> > > http://cdn.openbsd.org/pub/OpenBSD/syspatch/7.2/armv7/SHA256.sig: 404 Not 
> > > Found
> > > 
> > > That is correct, we do not build syspatches for armv7.
> > > 
> 
> 
> Index: afterboot.8
> ===
> RCS file: /cvs/src/share/man/man8/afterboot.8,v
> retrieving revision 1.173
> diff -u -p -r1.173 afterboot.8
> --- afterboot.8   23 Dec 2022 07:37:21 -  1.173
> +++ afterboot.8   12 Mar 2023 12:48:50 -
> @@ -68,8 +68,9 @@ files in
>  By the time that you have installed your system, it is possible that
>  bugs in the release have been found.
>  Security or reliability fixes can be found at
> -.Lk https://www.openbsd.org/errata.html ,
> -and can be installed using
> +.Lk https://www.openbsd.org/errata.html .
> +For some hardware platforms binary updates are made available and can be
> +installed using
>  .Xr syspatch 8 .
>  .Ss Login
>  Log in on the console, or over the network using
> 

hi. no opinion on the addition, but i think your sentence would sound
better the other way round:

Binary updates are made available for some architectures
and can be installed using syspatch(8).

(or platforms, or whatever)

jmc

Re: Error in vi(1) manpage

[Jason McIntyre]

go ahead. it matches vi.ref anyway. i was waiting on confirmation from millert 
since i never use this stuff.

jmc

On 29 January 2023 08:19:43 GMT, Otto Moerbeek  wrote:
>On Sat, Jan 28, 2023 at 07:55:57PM +0100, Tomáš Rippl  wrote:
>
>> System: OpenBSD 7.2
>> Architecture: OpenBSD.amd64
>> Machine: amd64
>> 
>> >Description
>> There is a bug in vi(1) manpage in VI TEXT INPUT COMMANDS section.
>> ^ is said to "Erase all of the autoindent characters, and reset 
>> the autoindent level."
>> Actually, it does not reset the autoindent level.
>> 0 is said to "Erase all of the autoindent characters."
>> Actually, it also resets the autoindent level.
>> It seems that the sentence part that mentions the autoindent level reset 
>> should be moved from ^ to 0
>
>Yes  I think you are right.
>
>   -Otto
>
>
>Index: docs/USD.doc/vi.man/vi.1
>===
>RCS file: /home/cvs/src/usr.bin/vi/docs/USD.doc/vi.man/vi.1,v
>retrieving revision 1.82
>diff -u -p -r1.82 vi.1
>--- docs/USD.doc/vi.man/vi.1   22 Apr 2022 21:09:48 -  1.82
>+++ docs/USD.doc/vi.man/vi.1   29 Jan 2023 08:18:19 -
>@@ -1593,10 +1593,10 @@ Erase to the previous
> column boundary.
> .Pp
> .It Cm ^ Ns Aq Cm control-D
>-Erase all of the autoindent characters, and reset the autoindent level.
>+Erase all of the autoindent characters.
> .Pp
> .It Cm 0 Ns Aq Cm control-D
>-Erase all of the autoindent characters.
>+Erase all of the autoindent characters, and reset the autoindent level.
> .Pp
> .It Aq Cm control-T
> Insert sufficient
>

Re: misleading error message in cal

[Jason McIntyre]

On Tue, Jan 24, 2023 at 09:39:05PM -0300, Lucas de Sena wrote:
> > hi.
> > 
> > the trouble is, openbsd supports a single month name argument to cal(1):
> > 
> > $ cal jan
> > 
> > the ability is non-standard, but is documented as such.
> > 
> > so our SYNOPSIS is correct and this proposal, as far as i can see,
> > incorrect.
> > 
> > jmc
> 
> Indeed, my proposed SYNOPSIS ignores the month name exception.
> Sorry for that.
> 
> On the proposed patch for cal.c; do you think that it is correct
> and that the issue on the misleading error message is valid?
> 

that one's not my department. sorry.
jmc

Re: misleading error message in cal

[Jason McIntyre]

On Tue, Jan 24, 2023 at 07:13:49AM -0300, Lucas de Sena wrote:
> On 2023-01-24, Lucas de Sena wrote:
> > (nitpick)
> 
> While I'm at it, here's a patch for the SYNOPSIS section of the manual:
> 
> 
> Index: usr.bin/cal/cal.1
> ===
> RCS file: /cvs/src/usr.bin/cal/cal.1,v
> retrieving revision 1.32
> diff -u -p -r1.32 cal.1
> --- usr.bin/cal/cal.1 31 Mar 2022 17:27:24 -  1.32
> +++ usr.bin/cal/cal.1 24 Jan 2023 10:09:46 -
> @@ -42,8 +42,10 @@
>  .Sh SYNOPSIS
>  .Nm cal
>  .Op Fl jmwy
> +.Oo
>  .Op Ar month
> -.Op Ar year
> +.Ar year
> +.Oc
>  .Sh DESCRIPTION
>  .Nm
>  displays a simple calendar.
> 

hi.

the trouble is, openbsd supports a single month name argument to cal(1):

$ cal jan

the ability is non-standard, but is documented as such.

so our SYNOPSIS is correct and this proposal, as far as i can see,
incorrect.

jmc

Re: mail(1) "save" command straying from POSIX for missing filename

[Jason McIntyre]

On Sun, Dec 18, 2022 at 03:50:51PM -0600, Brian Conway wrote:
> On Sun, Dec 18, 2022, at 3:29 PM, Jason McIntyre wrote:
> > On Fri, Dec 16, 2022 at 02:21:41AM +, Tim Chase wrote:
> >> According to the POSIX definitions for mail(1) & mailx(1), the
> >> (s)ave command should save to "mbox" if the filename is not specified
> >> 
> >> > Save the specified messages in the file named by the pathname
> >> > file, or the mbox if the file argument is omitted
> >> 
> >> (newer spec)
> >> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mailx.html#tag_20_75_13_33
> >> 
> >> > s [file]
> >> >  Save the message in the named file (mbox is default).
> >> 
> >> (older spec)
> >> https://pubs.opengroup.org/onlinepubs/7908799/xcu/mail.html#tag_001_014_1339
> >> 
> >> 
> >> 
> >> However, when exercising this functionality, mail(1) on OpenBSD
> >> (also tested on FreeBSD where the same issue manifests[1]) doesn't
> >> support this:
> >> 
> >>   demo$ echo test | mail -s "test" demo # send self a message
> >>   demo$ mail
> >>   Mail version 8.1 6/6/93.  Type ? for help.
> >>   "/var/mail/demo": 1 message 1 new
> >>   >N  1 d...@localhost.my.do  Thu Dec 15 19:34  19/775   "test"
> >>   & s
> >>   No file specified.
> >> 
> >> While I'm not positive on the solution, I think it involves tweaking
> >> the save1() function in src/usr.bin/mail/cmd2.c such that instead
> >> of failing if it can't snarf(), it should set `file` to "mbox" or
> >> "&" so that expand() points to the mbox as required by POSIX.
> >> 
> >> -tkc
> >> 
> >> [1]
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268402
> >> 
> >
> > hi.
> >
> > currently mail(1) has these entries in FILES:
> >
> > FILES
> >  /var/mail/* post office (unless overridden
> >  by the MAIL environment
> >  variable)
> >  ~/mbox  user's old mail
> >
> > isn;t it the case that openbsd uses mailboxes in /var/mail by default,
> > instead of ~/mbox, as displayed?
> 
> I believe those FILES entries are correct. A pristine install of OpenBSD will 
> have Theo's welcome email waiting in /var/mail/root . Running `mail`, reading 
> it, and then quitting (q) without any use of `s` will deposit the "user's old 
> mail" in /root/mbox.
> 
> Brian
> 

ah. i misunderstood the meaning of "old mail", since i don;t use ~/mbox.
i thought it was a compat thing.

so it won;t be me who decides, but either a code change or a note
describing the altered behaviour.

jmc

Re: mail(1) "save" command straying from POSIX for missing filename

[Jason McIntyre]

On Fri, Dec 16, 2022 at 02:21:41AM +, Tim Chase wrote:
> According to the POSIX definitions for mail(1) & mailx(1), the
> (s)ave command should save to "mbox" if the filename is not specified
> 
> > Save the specified messages in the file named by the pathname
> > file, or the mbox if the file argument is omitted
> 
> (newer spec)
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mailx.html#tag_20_75_13_33
> 
> > s [file]
> >  Save the message in the named file (mbox is default).
> 
> (older spec)
> https://pubs.opengroup.org/onlinepubs/7908799/xcu/mail.html#tag_001_014_1339
> 
> 
> 
> However, when exercising this functionality, mail(1) on OpenBSD
> (also tested on FreeBSD where the same issue manifests[1]) doesn't
> support this:
> 
>   demo$ echo test | mail -s "test" demo # send self a message
>   demo$ mail
>   Mail version 8.1 6/6/93.  Type ? for help.
>   "/var/mail/demo": 1 message 1 new
>   >N  1 d...@localhost.my.do  Thu Dec 15 19:34  19/775   "test"
>   & s
>   No file specified.
> 
> While I'm not positive on the solution, I think it involves tweaking
> the save1() function in src/usr.bin/mail/cmd2.c such that instead
> of failing if it can't snarf(), it should set `file` to "mbox" or
> "&" so that expand() points to the mbox as required by POSIX.
> 
> -tkc
> 
> [1]
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268402
> 

hi.

currently mail(1) has these entries in FILES:

FILES
 /var/mail/* post office (unless overridden
 by the MAIL environment
 variable)
 ~/mbox  user's old mail

isn;t it the case that openbsd uses mailboxes in /var/mail by default,
instead of ~/mbox, as displayed?

it seems that mail(1) is really out of date regarding default mail spool
entries, but i may well have misunderstood the situation. once it's
clear, i can see if we need a code fix (out of my hands) or doc fix.

jmc

Re: [patch] 7.2 Calendar bug with Advent

[Jason McIntyre]

hi richard.

i was not rejecting your diff. it is there for the relevant developers to take 
or leave, as they see fit.

there is no point in having two entries either way. it is not a case of anyone 
having to shut up, nor of users having to work anything out.

jmc

On 13 December 2022 15:05:07 GMT, Richard Narron  wrote:
>On Tue, 13 Dec 2022, Jason McIntyre wrote:
>
>> On Mon, Dec 05, 2022 at 01:29:26PM -0800, Richard Narron wrote:
>> > Here is an new version of the 5 patches with changes to two files:
>> >
>> > calendars/calendar.christian
>> > advent.c
>> >
>> > The file, calendar.christian, Advent entries are changed
>> > from:
>> >
>> >   11/SunLast  First Sunday of Advent (4th Sunday before Christmas)
>> >   12/SunFirst First Sunday of Advent (4th Sunday before Christmas)
>> >
>> > to:
>> >
>> >   Advent  First Sunday of Advent (4th Sunday before Christmas)
>> >
>>
>> for now i have removed "11/SunLast". that should give us at least a
>> couple of years to deliberate this diff.
>>
>> unless someone picks it up, i will gently remind fans of
>> calendar.christain of its description in calendar(1):
>>
>>   calendar.christianChristian holidays (should be updated
>> yearly by the local system
>> administrator so that roving holidays
>> are set correctly for the current
>> year).
>
>The fact that there are two Advent entries in the calendar.christian table
>and the man page mentioning "fixing" the calendar.christian table reminds
>me of an old lightbulb joke:
>
>
>How many hardware engineers does it take to change a lightbulb?
>None: "We'll fix it in software."
>
>How many software engineers does it take to change a lightbulb?
>None: "We'll document it in the manual."
>
>How many tech writers does it take to change a lightbulb?
>None: "The user can work it out."
>---
>
>If you are not going to use the code you might as well leave both
>Advent entries 11/SunLast and 12/SunFirst alone because one of them will
>be correct and one will be wrong.
>
>I took a different approach from "We'll document it in the manual" and
>"The user can work it out".
>
>I shut up and coded.
>
>Richard Narron

Re: [patch] 7.2 Calendar bug with Advent

[Jason McIntyre]

On Mon, Dec 05, 2022 at 01:29:26PM -0800, Richard Narron wrote:
> Here is an new version of the 5 patches with changes to two files:
> 
> calendars/calendar.christian
> advent.c
> 
> The file, calendar.christian, Advent entries are changed
> from:
> 
>   11/SunLast  First Sunday of Advent (4th Sunday before Christmas)
>   12/SunFirst First Sunday of Advent (4th Sunday before Christmas)
> 
> to:
> 
>   Advent  First Sunday of Advent (4th Sunday before Christmas)
> 

for now i have removed "11/SunLast". that should give us at least a
couple of years to deliberate this diff.

unless someone picks it up, i will gently remind fans of
calendar.christain of its description in calendar(1):

 calendar.christianChristian holidays (should be updated
   yearly by the local system
   administrator so that roving holidays
   are set correctly for the current
   year).

jmc

> The file, advent.c, the calculation is changed from:
> 
>   /* find 4 weeks (28 days) before the Sunday before Christmas */
>   yearday = yearday - 28;
> 
> to:
> 
>   /* If  Christmas is not Sunday subtract 3 weeks otherwise subtract 4 */
>   if ( dayofweek > 0 )
>   yearday = yearday - 21;
>   else
>   yearday = yearday - 28;
> 
> Here are all 5 of the patch files:
> 
> --- calendar-7.2/calendars/calendar.christian.orig1998-11-07 
> 20:38:00.0 -0800
> +++ calendar-7.2/calendars/calendar.christian 2022-12-05 08:49:24.668905247 
> -0800
> @@ -21,8 +21,7 @@
>  Easter+56Trinity Sunday (7 days after Pentecost)
>  Easter+60Corpus Christi (11 days after Pentecost)
>  10/18Feast Day of St. Luke
> -11/SunLast   First Sunday of Advent (4th Sunday before Christmas)
> -12/SunFirst  First Sunday of Advent (4th Sunday before Christmas)
> +Advent   First Sunday of Advent (4th Sunday before Christmas)
>  12/06St. Nicholas' Day
>  12/25Christmas
> 
> --- calendar-7.2/Makefile.orig2016-09-10 23:40:57.0 -0700
> +++ calendar-7.2/Makefile 2022-12-02 17:28:49.720561727 -0800
> @@ -1,7 +1,7 @@
>  #$OpenBSD: Makefile,v 1.11 2016/09/11 06:40:57 natano Exp $
> 
>  PROG=calendar
> -SRCS=   calendar.c io.c day.c pesach.c ostern.c paskha.c
> +SRCS=   calendar.c io.c day.c pesach.c ostern.c paskha.c advent.c
>  INTER=   de_DE.UTF-8 hr_HR.UTF-8 ru_RU.UTF-8 fr_FR.UTF-8
> 
>  beforeinstall:
> 
> --- calendar-7.2/calendar.h.orig  2022-12-02 12:24:15.858386699 -0800
> +++ calendar-7.2/calendar.h   2022-12-02 13:21:12.184331976 -0800
> @@ -80,6 +80,7 @@ int  getmonth(char *);
>  int   pesach(int);
>  int   easter(int);
>  int   paskha(int);
> +int   advent(int);
>  void  insert(struct event **, struct event *);
>  struct match *isnow(char *, int);
>  FILE *opencal(void);
> @@ -113,12 +114,14 @@ extern int f_Setday;/* calendar invoked
>  #define EASTERNAMELEN (sizeof(EASTER) - 1)
>  #define PASKHA "paskha"
>  #define PASKHALEN (sizeof(PASKHA) - 1)
> +#define ADVENT "advent"
> +#define ADVENTLEN (sizeof(ADVENT) - 1)
> 
>  /* calendars */
>  extern enum calendars { GREGORIAN = 0, JULIAN, LUNAR } calendar;
>  extern u_long julian;
> 
> -#define NUMEV 3  /* Total number of such special events */
> +#define NUMEV 4  /* Total number of such special events */
>  extern struct specialev spev[NUMEV];
> 
>  /* For calendar -a, specify a maximum time (in seconds) to spend parsing
> 
> --- calendar-7.2/day.c.orig   2019-08-12 13:03:28.0 -0700
> +++ calendar-7.2/day.c2022-12-02 13:25:46.483327583 -0800
> @@ -143,6 +143,9 @@ setnnames(void)
>   spev[2].name = strdup(PASKHA);
>   spev[2].nlen = PASKHALEN;
>   spev[2].getev = paskha;
> + spev[3].name = strdup(ADVENT);
> + spev[3].nlen = ADVENTLEN;
> + spev[3].getev = advent;
>   for (i = 0; i < NUMEV; i++) {
>   if (spev[i].name == NULL)
>   err(1, NULL);
> 
> --- calendar-7.2/advent.c.orig2022-12-05 08:40:50.753913479 -0800
> +++ calendar-7.2/advent.c 2022-12-05 08:56:11.084898737 -0800
> @@ -0,0 +1,50 @@
> +/*
> + * Copyright (C) 2022 by Richard Narron , California
> + *
> + * 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 

Re: [patch] 7.2 Calendar bug with Advent

[Jason McIntyre]

On Sun, Dec 04, 2022 at 08:02:36AM -0800, Richard Narron wrote:
> Advent is the Sunday that is 4 weeks before the Sunday before Christmas.
> 
> In OpenBSD 7.2, I configured the .calendar/calendar to
> 
> #include #include 
> 
> And this month (December 2022) the calendar message wrongly shows
> Advent on December 4:
> 
>   Dec 04* First Sunday of Advent (4th Sunday before Christmas)
> 
> Advent was actually on November 27, 2022...
> 
> The bug is because of these lines in calendar.christian:
> 
>   11/SunLast  First Sunday of Advent (4th Sunday before Christmas)
>   12/SunFirst First Sunday of Advent (4th Sunday before Christmas)
> 
> Sometimes Advent starts on the third Sunday of November, not always
> the last Sunday of November.
> 
> The "First Sunday of Advent" never occurs in December and only occurs
> in November.
> 
> So these lines need to be changed...
> 
> My idea is to replace these two lines using a new "special event"
> called "Advent":
> 
>   Advent  First Sunday of Advent (4th Sunday before Christmas)
>   Advent+7Second Sunday of Advent (3rd Sunday before Christmas)
>   Advent+14   Third Sunday of Advent (2nd Sunday before Christmas)
>   Advent+21   Fourth Sunday of Advent (Sunday before Christmas)
> 
> Here are 5 patches to the 7.2 /usr/src/usr.bin/calendar files:
> 

hi.

i can;t comment on your code or whether such a soution is preferred,
but i can point you to calendar(1) itself:

 calendar.christianChristian holidays (should be updated
   yearly by the local system
   administrator so that roving holidays
   are set correctly for the current
   year).

so the idea is the system admin sets it. though maybe there are better
solutions now...

anyway it looks like somehow we have an extra entry for advent, and we
should just have one. i won;t attempt an edit at the minute in case
there is any follow up.

jmc

Re: src/usr.bin/mg/{README,mg.1}: Document lack of UTF-8 support more prominently, add missing word.

[Jason McIntyre]

On Fri, Mar 04, 2022 at 05:04:59PM +, Pau Amma wrote:
> Specifically:
> 

hi.

> - In README, mention it in "Known limitations".

i'll leave that for mg people to decide

> - In mg.1, add "command" before "to alternate" in "Use the 
> backup-to-home-directory to alternate between these two locations."

that seems reasonable

> - In mg.1, move the last line, "Multi-byte character sets, such as 
> UTF-8, are not supported.", to the start of the CAVEATS section, and 
> maybe rename that section to "BUGS" or something stronger, as "CAVEATS" 
> doesn't look strong enough for this to me.
> 

additions to CAVEATS and BUGS tend to get added to the end. there is
no order of importance intended. so i'd say we should not move it (lest
we be lobbied by angry umlaut users). further, the distinction between
what constitutes a caveat and a bug is often blurry. i see no need to
change the section here, or to treat the multi-byte issue seperately
(unless you can demonstrate that this is consistently done differently
elsewhere).

> No time for a patch for now, but I may submit one time permitting unless 
> someone beats me to it.
> 

the polite thing to do would be to wait until you have time, do the
work, and submit a patch.

thanks,
jmc

> -- 
> #StandWithUkrainians
> English: he/him/his (singular they/them/their/theirs OK)
> French: il/le/lui (iel/iel and ielle/ielle OK)
> Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila)
> 

Re: minor correction to patch.1

[Jason McIntyre]

On Tue, Nov 09, 2021 at 07:01:43AM -0500, Josh Grosse wrote:
> The -i option can only be used once. Current logic is to error with
> "  too many file arguments" if the number of uses reaches MAXFILEC,
> set to 2 in both common.h and patch.c.

fixed, thanks.
jmc

> diff --git a/usr.bin/patch/patch.1 b/usr.bin/patch/patch.1
> index 8d915b87287..1aa66bf8c1b 100644
> --- a/usr.bin/patch/patch.1
> +++ b/usr.bin/patch/patch.1
> @@ -168,7 +168,6 @@ for that.
>  .Xc
>  Causes the next argument to be interpreted as the input file name
>  (i.e. a patchfile).
> -This option may be specified multiple times.
>  .It Fl l , Fl Fl ignore-whitespace
>  Causes the pattern matching to be done loosely, in case the tabs and
>  spaces have been munged in your input file.

Re: Another socket bug, documentation this time (with patch).

[Jason McIntyre]

On Thu, Oct 07, 2021 at 10:04:55AM +0100, cho...@jtan.com wrote:
> [gs]etsockopt(2) points out that SO_TYPE, SO_DOMAIN, SO_PROTOCOL
> and SO_ERROR are read-only but does not include SO_PEERCRED in that
> list. Also in the initial big list at the top of the page, SO_PEERCRED
> is not singled out as get only.
> 
> This patch shuffles the lines around to put SO_PEERCRED with its peers.
> 
> Matthew
> 

fixed, thanks.
jmc

> Index: lib/libc/sys/getsockopt.2
> ===
> RCS file: /src/datum/openbsd/cvs/src/lib/libc/sys/getsockopt.2,v
> retrieving revision 1.57
> diff -u -p -r1.57 getsockopt.2
> --- lib/libc/sys/getsockopt.2 4 Feb 2021 18:51:01 -   1.57
> +++ lib/libc/sys/getsockopt.2 7 Oct 2021 09:00:21 -
> @@ -162,8 +162,6 @@ set timeout value for output
>  set timeout value for input
>  .It Dv SO_TIMESTAMP
>  enables reception of a timestamp with datagrams
> -.It Dv SO_PEERCRED
> -get the credentials from other side of connection
>  .It Dv SO_RTABLE
>  set the routing table used for route lookups
>  .It Dv SO_SPLICE
> @@ -178,6 +176,8 @@ get and clear error on the socket (get o
>  get the domain of the socket (get only)
>  .It Dv SO_PROTOCOL
>  get the protocol of the socket (get only)
> +.It Dv SO_PEERCRED
> +get the credentials from other side of connection (get only)
>  .El
>  .Pp
>  .Dv SO_DEBUG
> @@ -349,20 +349,6 @@ cmsg_level = SOL_SOCKET
>  cmsg_type = SCM_TIMESTAMP
>  .Ed
>  .Pp
> -.Dv SO_PEERCRED
> -fetches the
> -.Va struct sockpeercred
> -credentials from the other side of the connection
> -(currently only possible on
> -.Dv AF_UNIX
> -sockets).
> -These credentials are from the time that
> -.Xr bind 2 ,
> -.Xr connect 2
> -or
> -.Xr socketpair 2
> -were called.
> -.Pp
>  The
>  .Dv SO_RTABLE
>  option gets or sets the routing table which will be used by the socket
> @@ -459,9 +445,10 @@ is set, overwrite kernel memory after se
>  Finally,
>  .Dv SO_TYPE ,
>  .Dv SO_DOMAIN ,
> -.Dv SO_PROTOCOL
> -and
> +.Dv SO_PROTOCOL ,
>  .Dv SO_ERROR
> +and
> +.Dv SO_PEERCRED
>  are options used only with
>  .Fn getsockopt .
>  .Dv SO_TYPE
> @@ -478,6 +465,19 @@ returns the protocol of the socket such 
>  returns any pending error on the socket and clears the error status.
>  It may be used to check for asynchronous errors on connected
>  datagram sockets or for other asynchronous errors.
> +.Dv SO_PEERCRED
> +fetches the
> +.Va struct sockpeercred
> +credentials from the other side of the connection
> +(currently only possible on
> +.Dv AF_UNIX
> +sockets).
> +These credentials are from the time that
> +.Xr bind 2 ,
> +.Xr connect 2
> +or
> +.Xr socketpair 2
> +were called.
>  .Sh RETURN VALUES
>  .Rv -std
>  .Sh ERRORS
> 

Re: `toe` reference in man 7 term

[Jason McIntyre]

On Thu, Sep 09, 2021 at 07:11:16PM +1000, Jonathan Gray wrote:
> On Thu, Sep 09, 2021 at 09:34:51AM +0100, Laurence Tratt wrote:
> > `man 7 term` contains the following:
> > 
> >   Terminal type descriptions are stored as files of capability data
> >   underneath /usr/share/terminfo.  To browse a list of all terminal names
> >   recognized by the system, do
> > 
> >toe | more
> > 
> > However, I cannot see a `toe` command on any of my OpenBSD boxes, nor does
> > it seem to be a shell builtin, nor can I see any meaningful references in
> > src/ other than in the man page source file.
> > 
> > It's quite probable that I'm being an idiot, and that I should know how to
> > run `toe`, but perhaps this reference in the man page is out of date?
> 
> It is part of ncurses we don't build or have in the tree.
> 

i don;t mind removing it, but generally we have curses docs warts and
all. maybe nicm has an opinion on whether it's worth changing.

jmc

> Index: term.7
> ===
> RCS file: /cvs/src/lib/libcurses/term.7,v
> retrieving revision 1.9
> diff -u -p -r1.9 term.7
> --- term.73 Dec 2015 11:29:55 -   1.9
> +++ term.79 Sep 2021 09:10:14 -
> @@ -66,11 +66,8 @@ custom entry incorporating options (such
>  which you wish to override the system default type for your line.
>  .PP
>  Terminal type descriptions are stored as files of capability data underneath
> -\*d.  To browse a list of all terminal names recognized by the system, do
> -.sp
> - toe | more
> -.sp
> -from your shell.  These capability files are in a binary format optimized for
> +\*d.
> +These capability files are in a binary format optimized for
>  retrieval speed (unlike the old text-based \fBtermcap\fR format they 
> replace);
>  to examine an entry, you must use the \fBinfocmp\fR(1) command.
>  Invoke it as follows:
> 

Re: Maverick word in the sort(1) manpage

[Jason McIntyre]

On Mon, Sep 06, 2021 at 04:12:19PM +0200, Marc Espie wrote:
> On Sat, Sep 04, 2021 at 09:28:14PM +0200, Ingo Schwarze wrote:
> > Hi Wilfried,
> > 
> > wilfried.mei...@gmail.com wrote on Sat, Sep 04, 2021 at 08:20:59PM +0200:
> > 
> > > Synopsis: Maverick word in the sort(1) manpage
> > > Category: documentation
> > [...]
> > > There is a superfluous word in the description of the --random-source
> > > option of the sort(1) manpage. The second sentence contains
> > > "will use produce" which probably should just be "will produce".
> > 
> > Committed, thanks for reporting.
> > 
> > While there, i also deleted the word "will".  Manuals usually do not
> > need future tense, except in unusual situations.
> > 
> > Yours,
> >   Ingo
> > 
> > 
> > The paragraph now reads:
> > 
> >--random-source=filename
> >For random sort, the contents of filename are used as the source
> >of the `seed' data for the hash function.  Two invocations of
> >random sort with the same seed data produce the same result if
> >the input is also identical.  By default, the arc4random_buf(3)
> >function is used instead.
> > 
> > 
> Hum... I've looked around at my own manpages. Actually, careful use of 
> tenses tend to make documentation feel slightly less "dry" in a lot of
> cases, thus actually making it MORE readable in the end.
> 
> I'm not sure removing that specific "will" is a good idea. It's not future
> tense.  It's (whatever it's called in English ?) that modal that says that 
> this WILL predictably happen (instead  of SHOULD or MAY) thus adding 
> welcome emphasis instead of just saying things dryly like you do.
> 

hi.

there is an element of preference in these choices, that's true. but i
am confident many people (native and non-native) find it easier to read
without modals, and with fewer words. i totaly back ingo's change in
this bit of text. that's not to lessen your preference, i just think
it's a good rule of thumb for us to keep text simple and clear. modals
really wreck people's heads.

jmc

Re: Missing comma in ssh_config(5)

[Jason McIntyre]

On Sun, Apr 04, 2021 at 01:24:48AM +0900, ? wrote:
> see attachment (or search for "IdentityFile KnownHostsCommand" without the 
> quotes)
> 

fixed, thanks.
jmc

Re: smtpd.conf(5) formatting fix (lmtp)

[Jason McIntyre]

On Thu, Jan 21, 2021 at 03:17:43PM -0800, lyn...@orthanc.ca wrote:
> >Synopsis:smtpd.conf(5) format bug
> >Category:user
> >Environment:
>   System  : OpenBSD 6.8
>   Details : OpenBSD 6.8 (GENERIC) #97: Sun Oct  4 18:00:46 MDT 2020
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   smtpd.conf(5) lmtp action description formats 'rcpt-to'
>   keyword as a variable substitution.
> >How-To-Repeat:
>   man smtpd.conf
> >Fix:
> 

fixed, thanks.
jmc

> --- smtpd.conf.5  2021/01/21 23:09:14 1.1
> +++ smtpd.conf.5  2021/01/21 23:10:10
> @@ -118,13 +118,13 @@
>  .It Cm forward-only
>  Only accept the message if the recipient results in a remote address
>  after the processing of aliases or forward file.
> -.It Cm lmtp Ar destination Op Ar rcpt-to
> +.It Cm lmtp Ar destination Op Cm rcpt-to
>  Deliver the message to an LMTP server at
>  .Ar destination .
>  The location may be expressed as host:port or as a UNIX socket.
>  .Pp
>  Optionally,
> -.Ar rcpt-to
> +.Cm rcpt-to
>  might be specified to use the
>  recipient email address (after expansion) instead of the
>  local user in the LMTP session as RCPT TO.
> 
> 
> dmesg:
> OpenBSD 6.8 (GENERIC) #97: Sun Oct  4 18:00:46 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> real mem = 4278059008 (4079MB)
> avail mem = 4133466112 (3941MB)
> random: boothowto does not indicate good seed
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf62b0 (11 entries)
> bios0: vendor SeaBIOS version "Ubuntu-1.8.2-1ubuntu1.1" date 04/01/2014
> bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> acpi0 at bios0: ACPI 1.0
> acpi0: sleep states S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC HPET
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel Xeon E312xx (Sandy Bridge), 2600.42 MHz, 06-2a-01
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,VMX,SSSE3,CX16,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,ARAT,XSAVEOPT,MELTDOWN
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
> 64b/line 16-way L2 cache
> cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 1000MHz
> cpu at mainbus0: not configured
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
> acpihpet0 at acpi0: 1 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> "ACPI0006" at acpi0 not configured
> acpipci0 at acpi0 PCI0
> acpicmos0 at acpi0
> "PNP0A06" at acpi0 not configured
> "PNP0A06" at acpi0 not configured
> "PNP0A06" at acpi0 not configured
> acpicpu0 at acpi0: C1(@1 halt!)
> cpu0: using IvyBridge MDS workaround
> pvbus0 at mainbus0: KVM
> pvclock0 at pvbus0
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
> wired to compatibility, channel 1 wired to compatibility
> atapiscsi0 at pciide0 channel 0 drive 1
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0:  removable
> cd0(pciide0:0:1): using PIO mode 4, DMA mode 2
> pciide0: channel 1 disabled (no drives)
> uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
> piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9
> iic0 at piixpm0
> vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
> vio0 at virtio0: address 52:54:00:99:00:5c
> virtio0: msix shared
> virtio1 at pci0 dev 4 function 0 "Qumranet Virtio SCSI" rev 0x00
> vioscsi0 at virtio1: qsize 128
> scsibus2 at vioscsi0: 255 targets
> sd0 at scsibus2 targ 0 lun 0: 
> sd0: 81920MB, 512 bytes/sector, 167772160 sectors, thin
> sd1 at scsibus2 targ 0 lun 1: 
> sd1: 204800MB, 512 bytes/sector, 419430400 sectors, thin
> virtio1: msix per-VQ
> virtio2 at pci0 dev 5 function 0 "Qumranet Virtio Memory Balloon" rev 0x00
> viomb0 at virtio2
> virtio2: apic 0 int 10
> virtio3 at pci0 dev 6 function 0 "Qumranet Virtio RNG" rev 0x00
> viornd0 at virtio3
> virtio3: apic 0 int 10
> isa0 at pcib0
> isadma0 at isa0
> fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)

Re: calendars: David Bowie died on 2016-01-10, not -11.

[Jason McIntyre]

On Fri, Jan 08, 2021 at 08:09:59PM +0100, Steffen Nurpmeso wrote:
> Two days after his 69th birthday.
> 

fixed, thanks.
jmc

Re: about password length and man page

[Jason McIntyre]

On Sun, Dec 13, 2020 at 05:58:08PM +, Brian Kelk wrote:
> Hi.
> 
> The man page for passwd says that the length of a password must be
> less than a specified value. Less than or equal to would make more
> sense, surely?
> 
> Brian Kelk
> 

hi.

i'm kind of having to guess what exactly you are referring to. for
example, there are two passwd pages. a diff would have saved some
guesswork.

anyway, i guess you are referring to this:

 The new password should be at least six characters long and
 not purely alphabetic.  Its total length must be less than
 _PASSWORD_LEN (currently 128 characters).

are you suggesting that the current text is incorrect (i.e. a 128
character password is valid), or just that the phrasing is not to
your liking (and therefore that we should also adjust the documented
value to 127)?

i think i spent way more time writing this mail than you ;(

jmc

Re: games/atc/atc.6: swapped descriptions of unmarked and ignored planes

[Jason McIntyre]

On Sat, Dec 05, 2020 at 05:26:10PM +, r...@rptv.info wrote:
> >Synopsis:  games/atc/atc.6: swapped descriptions of unmarked and ignored 
> >planes
> >Category:  documentation
> >Environment:
> System  : OpenBSD 6.8
> Details : OpenBSD 6.8 (GENERIC.MP) #1: Tue Nov  3 09:06:04 MST 
> 2020
>  
> r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> The first paragraph of section "MARKING, UNMARKING AND IGNORING" in 
> the man page of atc(6) states
>   that "[...]. An unmarked plane [...] will remain this way until a mark 
> command has been issued.
>   [...]". This is not totally correct for unmarked planes, but it is 
> correct for ignored planes.
> 
> On the other hand, the second paragraph of the same section states 
> that "An ignored plane [...]
> will automatically switch to marked status when a delayed command has 
> been processed. [...]". This
> is not true for ignored planes, but it is true for unmarked planes.
> 
> It seems that the descriptions of unmarked planes (in the first 
> paragraph) and ignored planes (in
> the second paragraph) are swapped.
> >How-To-Repeat:
> 
> >Fix:
> The following patch file should fix it.
> 
> Regards,
> 
> Rafa.
> 
> 
> Index: games/atc/atc.6
> ===
> RCS file: /cvs/src/games/atc/atc.6,v
> retrieving revision 1.23
> diff -u -p -u -r1.23 atc.6
> --- games/atc/atc.6 7 Mar 2016 12:07:55 -   1.23
> +++ games/atc/atc.6 5 Dec 2020 15:32:17 -
> @@ -423,7 +423,7 @@ A plane may also be either
>  or
>  .Em ignored .
>  An
> -.Em unmarked
> +.Em ignored
>  plane is drawn in unhighlighted mode, and a line of dashes is displayed in
>  the command field of the information area.
>  The plane will remain this way until a mark command has been issued.
> @@ -432,8 +432,8 @@ but the command line will return to a li
>  is completed.
>  .Pp
>  An
> -.Em ignored
> -plane is treated the same as an unmarked plane, except that it will
> +.Em unmarked
> +plane is treated the same as an ignored plane, except that it will
>  automatically switch to
>  .Em marked
>  status when a delayed command has been processed.

fixed, thanks!
jmc

Re: iwx driver not working in current

[Jason McIntyre]

On Fri, Oct 09, 2020 at 11:24:17AM +0200, Stefan Sperling wrote:
> On Thu, Oct 08, 2020 at 05:05:29PM +0200, 
> nicola.dellu...@delluomo-morettin.com wrote:
> > >Synopsis:  after upgrade to latest snapshot iwx driver is not working at 
> > >all.  
> > >Category:  system
> > >Environment:
> > System  : OpenBSD 6.8
> > Details : OpenBSD 6.8-current (GENERIC.MP) #99: Wed Oct  7 22:24:13 
> > MDT 2020
> >  
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > after upgrading to the latest snapshot, iwx driver is not working at 
> > all. Reported error is:
> > fatal firmware error: iwx0: could not remove MAC context (error 35)
> > >How-To-Repeat:
> > upgrade to current #99 and boot.
> > >Fix:
> > unknown
> 
> Nothing was changed in this driver in quite a while.
> Can this problem be reproduced with later snapshots?
> 

this one working fine with #102 amd64 GENERIC.MP:

iwx0 at pci2 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix

jmc

Re: smtpctl spf walk ignores some records

[Jason McIntyre]

On Mon, Sep 14, 2020 at 09:49:30AM +0200, Giovanni Bechis wrote:
> On 9/14/20 9:32 AM, Martijn van Duren wrote:
> > On Mon, 2020-09-14 at 08:12 +0100, Stuart Henderson wrote:
> >> On 2020/09/13 22:48, Giovanni Bechis wrote:
> >>> "smtpctl spf walk" doesn't work as it should because it breaks when it 
> >>> finds
> >>> macros as defined in RFC 7208.
> >>>
> >>> $ echo ryanair.com | smtpctl spf walk
> >>> gives no output while dig reply is:
> >>> $ dig txt ryanair.com | grep spf
> >>> ryanair.com.17  IN  TXT "v=spf1 
> >>> include:ryanair.com._nspf.vali.email 
> >>> include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email ~all"
> >>
> >> "spf walk" should return a warning or an error in these cases.
> > 
> > Was already working on that. How about the diff below?
> > 
> > $ echo ryanair.com | ./smtpctl/obj/smtpctl spf walk
> > smtpctl: lookup_record: %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email contains 
> > macros and can't be resolved
> >>
> >>> Is it worth mentioning in smtpctl in CAVEATS section or somewhere else ?
> >>
> >> Maybe in caveats, but if it's there it should be referenced in the
> >> description of "spf walk" too, to make it easier to find.
> >>
> >> Text something like this?
> >>
> >> "SPF records may contain macros which cannot be included in a static list
> >> and must be resolved dynamically at connection time.
> >> spf walk cannot provide full results in these cases."
> > 
> > Text reads fine to me. Added to diff below.
> > While here I also changed the # to $ so not to give people the
> > impression it should be run as root.
> > 
> > OK?
> > 
> ok giovanni@, thanks.
>  Giovanni
> 
> > martijn@
> > 
> > Index: spfwalk.c
> > ===
> > RCS file: /cvs/src/usr.sbin/smtpd/spfwalk.c,v
> > retrieving revision 1.17
> > diff -u -p -r1.17 spfwalk.c
> > --- spfwalk.c   15 Mar 2020 16:34:57 -  1.17
> > +++ spfwalk.c   14 Sep 2020 07:31:03 -
> > @@ -118,6 +118,11 @@ lookup_record(int type, const char *reco
> > struct asr_query *as;
> > struct target *ntgt;
> >  
> > +   if (strchr(record, '%') != NULL) {
> > +   warnx("%s: %s contains macros and can't be resolved", __func__,
> > +   record);
> > +   return;
> > +   }
> > as = res_query_async(record, C_IN, type, NULL);
> > if (as == NULL)
> > err(1, "res_query_async");
> > Index: smtpctl.8
> > ===
> > RCS file: /cvs/src/usr.sbin/smtpd/smtpctl.8,v
> > retrieving revision 1.64
> > diff -u -p -r1.64 smtpctl.8
> > --- smtpctl.8   18 Sep 2018 06:21:45 -  1.64
> > +++ smtpctl.8   14 Sep 2020 07:31:03 -
> > @@ -247,8 +247,12 @@ Shows if MTA, MDA and SMTP systems are c
> >  Recursively look up SPF records for the domains read from stdin.
> >  For example:
> >  .Bd -literal -offset indent
> > -# smtpctl spf walk < domains.txt
> > +$ smtpctl spf walk < domains.txt
> >  .Ed
> > +.Pp
> > +SPF records may contain macros which cannot be included in a static list 
> > and
> > +must be resolved dynamically at connection time.
> > +spf walk cannot provide full results in these cases.
> >  .It Cm trace Ar subsystem
> >  Enables real-time tracing of
> >  .Ar subsystem .
> > 
> 

ok from me too. but i think you should probably mark up "spf walk" in
the last line of added text.

jmc

Re: man.openbsd.org/smtpd.conf: "regex" is missing

[Jason McIntyre]

On Thu, Aug 27, 2020 at 09:35:41AM +0100, Jason McIntyre wrote:
> On Thu, Aug 27, 2020 at 01:51:58PM +0900, Heddi Nabbisen [ ?? ?? ] 
> wrote:
> > 
> > Dear OpenBSD developers
> > 
> > Hello.
> > I found a mistake in smtpd.conf(5) man page.
> > 
> > [ Webpage ]
> > 
> > https://man.openbsd.org/smtpd.conf
> > 
> > [ Section ]
> > 
> > DESCRIPTION
> > - match options action name
> > -- [!] from auth user | 
> > 
> > [ Description ]
> > 
> > There are duplicate headers. Perhaps, according to the descriptions, the 
> > latter should be:
> > "[!] from auth regex user | ".
> > 
> > -- 
> > Best regards,
> > Heddi Nabbisen [ ?? ?? ]
> > 
> 
> hi.
> 
> it does indeed look like the "regex" keyword has been omitted. i'll try
> and chase up an ok.
> 
> jmc

fixed now. thanks for the mail.
jmc

Re: man.openbsd.org/smtpd.conf: "regex" is missing

[Jason McIntyre]

On Thu, Aug 27, 2020 at 01:51:58PM +0900, Heddi Nabbisen [ ?? ?? ] 
wrote:
> 
> Dear OpenBSD developers
> 
> Hello.
> I found a mistake in smtpd.conf(5) man page.
> 
> [ Webpage ]
> 
> https://man.openbsd.org/smtpd.conf
> 
> [ Section ]
> 
> DESCRIPTION
> - match options action name
> -- [!] from auth user | 
> 
> [ Description ]
> 
> There are duplicate headers. Perhaps, according to the descriptions, the 
> latter should be:
> "[!] from auth regex user | ".
> 
> -- 
> Best regards,
> Heddi Nabbisen [ ?? ?? ]
> 

hi.

it does indeed look like the "regex" keyword has been omitted. i'll try
and chase up an ok.

jmc

Re: suggestion to change wording in man 4 tpmr

[Jason McIntyre]

On Sun, Aug 23, 2020 at 10:16:19PM +, Uwe Werler wrote:
> Hi,
> 
> I suggest to change the wording in man 4 tpmr to avoid repetition.
> 
> Uwe
> 
> Index: tpmr.4
> ===
> RCS file: /cvs/src/share/man/man4/tpmr.4,v
> retrieving revision 1.7
> diff -u -p -r1.7 tpmr.4
> --- tpmr.4  5 Aug 2020 14:55:40 -   1.7
> +++ tpmr.4  23 Aug 2020 22:11:29 -
> @@ -44,7 +44,7 @@ configuration file for
>  Other forms of Ethernet bridging are available using the
>  .Xr bridge 4
>  driver.
> -Other forms of aggregation of Ethernet interfaces are available
> +Link aggregation of Ethernet interfaces can be achieved
>  using the
>  .Xr aggr 4
>  and
> 

hi.

your diff changes the meaning: currently the page suggests tpmr is capable of
(a form of) link aggregation, and aggr and trunk can be used as alternatives.

with your changes, it suggests tpmr is not capable of (a form of) link
aggregation.

i don;t know whether that's correct or not. but the diff does not just
"avoid repitition".

jmc

Re: some typos in man 4 tpmr

[Jason McIntyre]

On Sun, Aug 23, 2020 at 09:57:09PM +, Uwe Werler wrote:
> Hi,
> 
> spotted some typos:
> 

hi.

> Index: tpmr.4
> ===
> RCS file: /cvs/src/share/man/man4/tpmr.4,v
> retrieving revision 1.7
> diff -u -p -r1.7 tpmr.4
> --- tpmr.4  5 Aug 2020 14:55:40 -   1.7
> +++ tpmr.4  23 Aug 2020 21:29:27 -
> @@ -25,13 +25,13 @@
>  .Sh DESCRIPTION
>  The
>  .Nm
> -driver implements an 802.1Q (originally 802.1aj) Two-Port MAC Relay
> +driver implements a 802.1Q (originally 802.1aj) Two-Port MAC Relay

"an 8" is correct

>  (TPMR).
>  A TPMR is a simplified Ethernet bridge that provides a subset of
>  the functionality as found in
>  .Xr bridge 4 .
> -A TPMR has exactly two member ports, and unconditionally relays

it reads better with the comma, i'd say

> -Ethernet packets between the them.

but i fixed this one.

thanks,
jmc

> +A TPMR has exactly two member ports and unconditionally relays
> +Ethernet packets between them.
>  .Pp
>  .Nm
>  interfaces can be created at runtime using the
> cvs server: I know nothing about tpmr.4.orig
> 
> -- 
> 
> With kind regards / Me? bestu kve?ju / Mit freundlichen Gr??en
> 
> Uwe Werler
> 

Re: uaudio device works on usb2 port; fails on usb3 port

[Jason McIntyre]

On Fri, Aug 07, 2020 at 01:08:17PM +0200, Marcus Glocker wrote:
> On Fri, 7 Aug 2020 12:31:39 +0200
> Alexandre Ratchov  wrote:
> 
> > On Fri, Aug 07, 2020 at 10:08:25AM +0100, Patrick Harper wrote:
> > > I think asynchronous transfers don't work with xhci right now,
> > > which appears to be how your DAC works. If you can disable USB 3.0
> > > in the BIOS/UEFI setup program it should work. 
> 
> xhci(4) does support isochronous transfers.
> 
> > This device is usb1.1, it uses control and isochronous transfers that
> > xhci supports. Strangely, even certain control transfers fail with
> > this particular device.
> 
> Hmm weired.  I'm still puzzled by the lsusb output which seem to miss
> most of the uaudio device descritpor.  Could that be the reason?
> 
> jmc:
> Can you please provide usbdevs -v output and then only output of lsusb
> for that specific uaudio device from the ehci and from the xhci machine?
> 
>   # usbdevs -v
>   ...
>   # lsusb
>   ...
>   # lsusb -d : -vvv
>   ...
> 
> I would like compare if the lsusb output differs between ehci and xhci.
> 

hi.

details below. first the machine that the device works on:

# usbdevs -v
Controller /dev/usb0:
addr 01: 8086: Intel, EHCI root hub
 high speed, self powered, config 1, rev 1.00
 driver: uhub0
addr 02: 8087:0024 Intel, Rate Matching Hub
 high speed, self powered, config 1, rev 0.00
 driver: uhub2
Controller /dev/usb1:
addr 01: 8086: Intel, EHCI root hub
 high speed, self powered, config 1, rev 1.00
 driver: uhub1
addr 02: 8087:0024 Intel, Rate Matching Hub
 high speed, self powered, config 1, rev 0.00
 driver: uhub3
addr 03: 0a5c:5800 Broadcom Corp, 5880
 full speed, power 100 mA, unconfigured, rev 1.01, iSerial 
0123456789ABCD
 driver: ugen0
addr 04: 04d8:f0bf Cyrus Audio, Cyrus soundKey
 full speed, power 50 mA, config 1, rev 1.00, iSerial 001116
 driver: uaudio0
 driver: uhidev0
# lsusb
Bus 000 Device 001: ID 8086: Intel Corp. 
Bus 000 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 8086: Intel Corp. 
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 0a5c:5800 Broadcom Corp. BCM5880 Secure Applications 
Processor
Bus 001 Device 004: ID 04d8:f0bf Microchip Technology, Inc. 
Bus 001 Device 004: ID 04d8:f0bf Microchip Technology, Inc. 
Bus 000 Device 001: ID 8086: Intel Corp. 
Bus 000 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 8086: Intel Corp. 
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 0a5c:5800 Broadcom Corp. BCM5880 Secure Applications 
Processor
Bus 001 Device 004: ID 04d8:f0bf Microchip Technology, Inc. 
# lsusb -d 04d8:f0bf -vvv
Bus 001 Device 004: ID 04d8:f0bf Microchip Technology, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x04d8 Microchip Technology, Inc.
  idProduct  0xf0bf 
  bcdDevice1.00
  iManufacturer   1 Cyrus Audio
  iProduct2 Cyrus soundKey
  iSerial 4 001116
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  221
bNumInterfaces  3
bConfigurationValue 1
iConfiguration  3 Main Configuration
bmAttributes 0x80
  (Bus Powered)
MaxPower   50mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass 1 Audio
  bInterfaceSubClass  1 Control Device
  bInterfaceProtocol  0 
  iInterface  0 
  AudioControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  1 (HEADER)
bcdADC   1.00
wTotalLength   40
bInCollection   1
baInterfaceNr( 0)   1
  AudioControl Interface Descriptor:
bLength12
bDescriptorType36
bDescriptorSubtype  2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType  0x0101 USB Streaming
bAssocTerminal  0
bNrChannels 2
wChannelConfig 0x0003
  Left Front (L)
  Right Front (R)
iChannelNames   0 
iTerminal   0 
  AudioControl Interface Descriptor:
bLength10
bDescriptorType36
bDescriptorSubtype  6 

Re: uaudio device works on usb2 port; fails on usb3 port

[Jason McIntyre]

On Thu, Aug 06, 2020 at 09:51:54AM +0200, Marcus Glocker wrote:
> On Wed, 5 Aug 2020 15:35:41 +0100
> Jason McIntyre  wrote:
> 
> > hi.
> > 
> > i have a usb hardware dac which shows up as uaudio.  i've discovered
> > that it works when plugged into a usb2 port, but not usb3. i've
> > verified it fails to work on two different machines with usb3 ports.
> > all machines are running current amd64.
> > 
> > the soundcard is recognised, but i get this on a usb2 port (which
> > works):
> > 
> > uhidev0: iclass 3/0
> > uhid0 at uhidev0: input=64, output=64, feature=0
> > 
> > and this on a usb3 port:
> > 
> > uhidev0: no report descriptor
> > 
> > i've inlined below dmesg and "lsusb -vvv" for the working machine and
> > one of the ones that doesn;t work (with the device plugged in).
> > 
> > ratchov examined the audio device (from afar) and concluded nothing
> > looked amiss with it. mpi suggested it may be "a timing issue related
> > to the sequence to probe new devices".
> > 
> > jmc
> 
> Somehow your output of lsusb -vvv doesn't seem to contain the full
> output of the uaudio device.  I don't know whether it has been cut-off
> during copy/paste or if lsusb had problems to parse the uaudio device.
> 
> Anyway, I'm just making a very wild guess out in the blue, untested;
> Can you give this diff a spin on the USB3 machine?
> 
> 
> Index: sys/dev/usb/xhci.c
> ===
> RCS file: /cvs/src/sys/dev/usb/xhci.c,v
> retrieving revision 1.119
> diff -u -p -u -p -r1.119 xhci.c
> --- sys/dev/usb/xhci.c31 Jul 2020 19:27:57 -  1.119
> +++ sys/dev/usb/xhci.c6 Aug 2020 07:16:31 -
> @@ -2196,6 +2196,18 @@ usb_device_descriptor_t xhci_devd = {
>   1   /* # of configurations */
>  };
>  
> +usb_device_qualifier_t xhci_odevd = {
> + USB_DEVICE_DESCRIPTOR_SIZE,
> + UDESC_DEVICE_QUALIFIER, /* type */
> + {0x00, 0x02},   /* USB version */
> + UDCLASS_HUB,/* class */
> + UDSUBCLASS_HUB, /* subclass */
> + UDPROTO_FSHUB,  /* protocol */
> + 64, /* max packet */
> + 1,  /* # of configurations */
> + 0
> +};
> +
>  const usb_config_descriptor_t xhci_confd = {
>   USB_CONFIG_DESCRIPTOR_SIZE,
>   UDESC_CONFIG,
> @@ -2417,6 +2429,14 @@ xhci_root_ctrl_start(struct usbd_xfer *x
>   totlen = l = min(len, USB_DEVICE_DESCRIPTOR_SIZE);
>   USETW(xhci_devd.idVendor, sc->sc_id_vendor);
>   memcpy(buf, _devd, l);
> + break;
> + case UDESC_DEVICE_QUALIFIER:
> + if ((value & 0xff) != 0) {
> + err = USBD_IOERROR;
> + goto ret;
> + }
> + totlen = l = min(len, USB_DEVICE_DESCRIPTOR_SIZE);
> + memcpy(buf, _odevd, l);
>   break;
>   /*
>* We can't really operate at another speed, but the spec says

i've inlined lsusb -vvv again with the device plugged in. that's running with
your diff on the machine that doesn;t work. no change in behaviour with your
diff i.e. still doesn;t work.

jmc

$ ls usb -vvv
Bus 000 Device 001: ID 1022: Shinko Shoji Co., Ltd 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize0 9
  idVendor   0x1022 Shinko Shoji Co., Ltd
  idProduct  0x 
  bcdDevice1.00
  iManufacturer   1 AMD
  iProduct2 xHCI root hub
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes

uaudio device works on usb2 port; fails on usb3 port

[Jason McIntyre]

hi.

i have a usb hardware dac which shows up as uaudio.  i've discovered
that it works when plugged into a usb2 port, but not usb3. i've
verified it fails to work on two different machines with usb3 ports.
all machines are running current amd64.

the soundcard is recognised, but i get this on a usb2 port (which
works):

uhidev0: iclass 3/0
uhid0 at uhidev0: input=64, output=64, feature=0

and this on a usb3 port:

uhidev0: no report descriptor

i've inlined below dmesg and "lsusb -vvv" for the working machine and
one of the ones that doesn;t work (with the device plugged in).

ratchov examined the audio device (from afar) and concluded nothing
looked amiss with it. mpi suggested it may be "a timing issue related
to the sequence to probe new devices".

jmc

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

working machine:

Couldn't get configuration descriptor 0, some information will be missing
Couldn't get configuration descriptor 0, some information will be missing

Bus 000 Device 001: ID 8086: Intel Corp. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize064
  idVendor   0x8086 Intel Corp.
  idProduct  0x 
  bcdDevice1.00
  iManufacturer   1 Intel
  iProduct2 EHCI root hub
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  12
Hub Descriptor:
  bLength  10
  bDescriptorType  41
  nNbrPorts 2
  wHubCharacteristic 0x0002
No power switching (usb 1.0)
Ganged overcurrent protection
TT think time 8 FS bits
  bPwrOn2PwrGood  200 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  DeviceRemovable0x00
  PortPwrCtrlMask0x00
 Hub Port Status:
   Port 1: .0503 highspeed power enable connect
   Port 2: .0500 highspeed power
Device Status: 0x0001
  Self Powered

Bus 000 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize064
  idVendor   0x8087 Intel Corp.
  idProduct  0x0024 Integrated Rate Matching Hub
  bcdDevice0.00
  iManufacturer   0 
  iProduct0 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0001  1x 1 bytes
bInterval  12
Hub Descriptor:
  bLength   9
  bDescriptorType  41
  nNbrPorts 6
  wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
TT think time 8 FS bits
  bPwrOn2PwrGood   50 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  DeviceRemovable0x00
  

Re: send without tab! netstat address family and interface, well-known protocols

[Jason McIntyre]

On Sat, Jul 18, 2020 at 08:11:15PM +, marfabastewart wrote:
> > > > netstat -p only works for the protocols hard-coded in the protox 
> > > > struct in
> > > > /usr/src/usr.bin/netstat/main.c
> > > >
> 
> > > >
> > > > For the protocol problem, I see the call to getprotoent but
> > > > no call to getprotobyname in the name2protox function in
> > > > /usr/src/usr.b/in/netstat/main.c
> > > >
> > >
> >
> > so, philip guenther did all the hard work: it seems the text additions
> > were made 21 years ago with ip6 support, but the code was never added.
> > so the current SYNOPSIS was (and still is) correct: -f is not used with
> > -I. the text in -I describing -f was wrong, and i've just removed it.
> >
> > thanks for your mail,
> > jmc
> 
> Hi, thank you very much for your quick reply.
> It also appears that netstat isn't checking /etc/protcols
> when the -p option is called:
> 
> $netstat -an -p rdp
> netstat: rdp: unknown protocol
> 
> although rdp is in /etc/protocols.
> 

well, netstat(1) does not claim to read /etc/protocols, only
that some well known protocols may be listed there:

 Some protocol names and aliases are listed in the
 file /etc/protocols.

> In contrast, other protocols in struct protx
> do get a different response:
> 
> $netstat -an -p icmp
> netstat: no protocol handler for protocol icmp
> 
> Although I admit I don't know enough to know
> whether it would make sense to generate statistics
> for icmp.
> 

i'm not sure whether the combination makes sense. looking at SYNOPSIS,
it does suggest it should work. but if you run "-an" without -p it will
show you what protocols are supported for that usage (not icmp).

you want -s for stats:

$ netstat -s -p icmp

> Of course other protocols like tcp do work without
> problems.
> 

so we could easily add a list of the supported protocol names to -p. i
guess most people will know what makes sense, and if you try "netstat -p
bob" and it errors out, you'll know it isn;t supported. so i'm unsure
whether it's worth adding such a list. personally i think it probably
should...

jmc

Re: send without tab! netstat address family and interface, well-known protocols

[Jason McIntyre]

On Sat, Jul 18, 2020 at 05:37:40PM +0100, Jason McIntyre wrote:
> On Sat, Jul 18, 2020 at 03:17:05PM +, marfabastewart wrote:
> > I apologize!!! I have my mail client set to use plaintext
> > so I didn't think tabs woud be a problem. I'm
> > re-posting with just spaces.
> > 
> > Synopsis:netstat address family and interface, well-known protocols
> > Category:user
> > Environment:
> > System  : OpenBSD 6.7
> > Details : OpenBSD 6.7-current (GENERIC.MP) #351: Wed Jul 15 
> > 16:57:00 MDT 2020
> >  
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > Description:
> > netstat doesn't limit output to address family when used with -I, and 
> > protocol list problem
> > How-To-Repeat:
> > netstat -f inet -s -I lo0
> > or
> > netstat -s -f inet -I lo0
> > netstat -f inet -I lo0
> > 
> > Any interface can be used instead of lo0.
> > Netstat shows ipv6 information also although man netstat says
> > If the -f address_family option (with the -s option) is present,
> > show per-interface statistics on the given interface for the
> > specified address_family.
> > 
> > (It does, but doesn't limit output to the specified address_family.)
> > 
> > netstat -p only works for the protocols hard-coded in the protox struct 
> > in
> > /usr/src/usr.bin/netstat/main.c
> > 
> > Fix:
> > I'm not too well-versed in C (as perhaps my questions make clear)
> > but happy to try to offer patches if someone would suggest
> > the general direction of changes to make (and if the whole problem is 
> > not EBKAC).
> > 
> > I note that netstat -f inet works but adding the -I doesn't seem to 
> > work.
> > Is it because if iflag is set, we call intpr:
> > if (iflag) {
> > intpr(interval, repeatcount);
> > exit(0);
> > }
> > in lines 295-296 in /usr/src/usr.bin/netstat/main.c?
> > 
> > For the protocol problem, I see the call to getprotoent but
> > no call to getprotobyname in the name2protox function in
> > /usr/src/usr.b/in/netstat/main.c
> > 
> > 
> 
> hi.
> 
> at the very least, there is a doc bug here. before the last change to
> netstat.1, we showed -I and -f being compatible, in SYNOPSIS. in the
> most recent change to netstat.1, i removed that after some help from
> guenther in trying to track down what actually works. the -f text in the
> description of -I remained.
> 
> i will try to work out whether it's a doc fix or a code fix (i.e. bug
> those who know).
> 
> jmc

so, philip guenther did all the hard work: it seems the text additions
were made 21 years ago with ip6 support, but the code was never added.
so the current SYNOPSIS was (and still is) correct: -f is not used with
-I. the text in -I describing -f was wrong, and i've just removed it.

thanks for your mail,
jmc

Re: send without tab! netstat address family and interface, well-known protocols

[Jason McIntyre]

On Sat, Jul 18, 2020 at 03:17:05PM +, marfabastewart wrote:
> I apologize!!! I have my mail client set to use plaintext
> so I didn't think tabs woud be a problem. I'm
> re-posting with just spaces.
> 
> Synopsis:netstat address family and interface, well-known protocols
> Category:user
> Environment:
> System  : OpenBSD 6.7
> Details : OpenBSD 6.7-current (GENERIC.MP) #351: Wed Jul 15 16:57:00 
> MDT 2020
>  
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> Description:
> netstat doesn't limit output to address family when used with -I, and 
> protocol list problem
> How-To-Repeat:
> netstat -f inet -s -I lo0
> or
> netstat -s -f inet -I lo0
> netstat -f inet -I lo0
> 
> Any interface can be used instead of lo0.
> Netstat shows ipv6 information also although man netstat says
> If the -f address_family option (with the -s option) is present,
> show per-interface statistics on the given interface for the
> specified address_family.
> 
> (It does, but doesn't limit output to the specified address_family.)
> 
> netstat -p only works for the protocols hard-coded in the protox struct in
> /usr/src/usr.bin/netstat/main.c
> 
> Fix:
> I'm not too well-versed in C (as perhaps my questions make clear)
> but happy to try to offer patches if someone would suggest
> the general direction of changes to make (and if the whole problem is not 
> EBKAC).
> 
> I note that netstat -f inet works but adding the -I doesn't seem to work.
> Is it because if iflag is set, we call intpr:
> if (iflag) {
> intpr(interval, repeatcount);
> exit(0);
> }
> in lines 295-296 in /usr/src/usr.bin/netstat/main.c?
> 
> For the protocol problem, I see the call to getprotoent but
> no call to getprotobyname in the name2protox function in
> /usr/src/usr.b/in/netstat/main.c
> 
> 

hi.

at the very least, there is a doc bug here. before the last change to
netstat.1, we showed -I and -f being compatible, in SYNOPSIS. in the
most recent change to netstat.1, i removed that after some help from
guenther in trying to track down what actually works. the -f text in the
description of -I remained.

i will try to work out whether it's a doc fix or a code fix (i.e. bug
those who know).

jmc

Re: typo in sysctl.2

[Jason McIntyre]

On Wed, Mar 11, 2020 at 08:06:18AM +, Bryan Stenson wrote:
> Index: lib/libc/sys/sysctl.2
> ===
> RCS file: /cvs/src/lib/libc/sys/sysctl.2,v
> retrieving revision 1.37
> diff -u -p -u -r1.37 sysctl.2
> --- lib/libc/sys/sysctl.2   24 Jan 2020 15:17:16 -  1.37
> +++ lib/libc/sys/sysctl.2   11 Mar 2020 08:02:51 -
> @@ -2126,7 +2126,7 @@ hashes.
>  .It Dv FFS_DIRHASH_MEM Pq Va vfs.ffs.dirhash_mem
>  The amount of memory currently used by all directory hashes.
>  .It Dv FFS_MAX_SOFTDEPS Pq Va vfs.ffs.max_softdeps
> -Maximum strcuctures before slowdowns.
> +Maximum structures before slowdowns.
>  .It Dv FFS_SD_BLK_LIMIT_HIT Pq Va vfs.ffs.sd_blk_limit_hit
>  Number of times block slowdown imposed.
>  .It Dv FFS_SD_BLK_LIMIT_PUSH Pq Va vfs.ffs.sd_blk_limit_push
> 

fixed, thanks.
jmc

Re: small update to man smtpd.conf

[Jason McIntyre]

On Thu, Dec 05, 2019 at 11:36:28AM -0600, myportslist20190...@nym.hush.com 
wrote:
> Synopsis: small update to man smtpd.conf to include from local syntax
> Category: documentation
> Environment:
>   System  : OpenBSD 6.6
>   Details : OpenBSD 6.6-current (GENERIC.MP) #509: Tue Dec  3 
> 19:03:47 MST 2019
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> Description:
>   man smtpd.conf doesn't yet include the new "from local" syntax in 
> EXAMPLES section
>   The man page is not wrong. However, I think "from local" can be 
> included in 
>   the section about forwarding email to other servers. I've tested it
>   with several servers.
> 
>   I don't know if this next bit should also be in the man page, but in
>   order to get forwarding to work, I fill in the well-known aliases
>   on the sending machine with a different domain than the actual 
>   hostname. For example, the server that sends email may have
>   foo.my.local in /etc/myname, but I fill in root@fictional.domain
>   in the well-known aliases in /etc/mail/aliases. The receiving
>   server of course needs a match statement for that fictional domain.
> 
> How-To-Repeat:
>   man smtpd.conf
> Fix:

fixed, thanks.
jmc

> Index: usr.sbin/smtpd/smtpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v
> retrieving revision 1.236
> diff -u -p -u -r1.236 smtpd.conf.5
> --- usr.sbin/smtpd/smtpd.conf.5   5 Dec 2019 14:49:35 -   1.236
> +++ usr.sbin/smtpd/smtpd.conf.5   5 Dec 2019 17:12:34 -
> @@ -1151,8 +1151,8 @@ action "local_mail" mbox alias 
>  action "outbound" relay host smtp+tls://b...@smtp.example.com \e
>   auth 
>  
> -match for local action "local_mail"
> -match for any action "outbound"
> +match from local for local action "local_mail"
> +match from local for any action "outbound"
>  .Ed
>  .Pp
>  In this second example,
> 
> 
> 
> 
> 

Re: [patch] Minor documentation tweak in ksh(1)

[Jason McIntyre]

On Sun, Nov 24, 2019 at 06:26:25PM +, Jason McIntyre wrote:
> > 
> > --- /usr/src/bin/ksh/ksh.1  Sat Oct  5 11:03:46 2019
> > +++ /tmp/ksh.1  Sun Nov 24 05:29:03 2019
> > @@ -1341,7 +1341,7 @@
> >  .Ev CDPATH
> >  is set and does not contain
> >  .Sq \&.
> > -or contains an empty path, the current directory is not searched.
> > +or an empty path, the current directory is not searched.
> 
> 
> hmm. this sentence is horrible, i admit. there are too many negatives.
> i think your change is correct though.
> 
> >  Also, the
> >  .Ic cd
> >  built-in command will display the resulting directory when a match is found
> > @@ -2866,7 +2866,9 @@
> >  .Ar dir .
> >  A
> >  .Dv NULL
> > -path means the current directory.
> > +path or
> > +.Ql .\&
> > +means the current directory.
> 
> i think this is correct too.
> 
> >  If
> >  .Ar dir
> >  is found in any component of the
> > 
> 
> any (developer) oks for this?
> 
> jmc

ok, i committed your changes. thanks for the mail,
jmc

Re: [patch] Minor documentation tweak in ksh(1)

[Jason McIntyre]

On Sun, Nov 24, 2019 at 03:36:08AM +, cho...@jtan.com wrote:
> The description of ksh(1)'s handling of CDPATH is not quite complete
> and, worse, contradictory in the two locations it's mentioned. sh(1)
> barely touches on it but is Not Wrong so I've left it alone.
> 

hi.

this is what posix says:

A colon-separated list of pathnames that refer to directories.
The cd utility shall use this list in its attempt to change the
directory, as described in the DESCRIPTION. An empty string in
place of a directory pathname represents the current directory.
If CDPATH is not set, it shall be treated as if it were an empty
string.

in my (admittedly biased) opinion, sh(1) accurately describes this,
rather than "barely touches on it":

Colon separated list of directories used by the cd command. If
unset or empty, the current working directory is used.

> (FWIW I also checked the CDPATH scanning code and actually poked
> at a real shell so I've confirmed that this is how it actually works)
> 
> Matthew
> 
> --- /usr/src/bin/ksh/ksh.1  Sat Oct  5 11:03:46 2019
> +++ /tmp/ksh.1  Sun Nov 24 05:29:03 2019
> @@ -1341,7 +1341,7 @@
>  .Ev CDPATH
>  is set and does not contain
>  .Sq \&.
> -or contains an empty path, the current directory is not searched.
> +or an empty path, the current directory is not searched.


hmm. this sentence is horrible, i admit. there are too many negatives.
i think your change is correct though.

>  Also, the
>  .Ic cd
>  built-in command will display the resulting directory when a match is found
> @@ -2866,7 +2866,9 @@
>  .Ar dir .
>  A
>  .Dv NULL
> -path means the current directory.
> +path or
> +.Ql .\&
> +means the current directory.

i think this is correct too.

>  If
>  .Ar dir
>  is found in any component of the
> 

any (developer) oks for this?

jmc

Re: Small error in chflags man page

[Jason McIntyre]

On Tue, Nov 05, 2019 at 04:43:59AM +0100, Jonathan Drews wrote:
> To: bugs@openbsd.org
> Subject: Small error in chflags man page
> From: Jonathan
> Cc: cleetus
> Reply-To: easyfashioncloth...@gmx.com>Synopsis:  chflags man page has an
> error
> >Category:  Documentation
> >Environment:
> System  : OpenBSD 6.6
> Details : OpenBSD 6.6 (GENERIC.MP) #1: Sun Oct 27 16:19:23 MDT 2019
>  clee...@leo.cats.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> The man page for chflags says to prepend "no" to one of the 
> flags. To unset the nodump flag you would then do:
> $chlags nonodump file.txt
> However this does not work. 
> >How-To-Repeat:
> leo$ ls -lohd mp3/
> drwxr-xr-x  15 cleetus  cleetus  uchg,nodump  512B May  6 14:33 mp3/
> leo$ chflags -R nonodump mp3/
> chflags: invalid flag: nonodump
> leo$ chflags -R dump mp3/
> leo$ ls -lohd mp3/
> drwxr-xr-x  15 cleetus  cleetus  uchg  512B May  6 14:33 mp3/
> leo$>Fix:
> The man page should say: Putting the letters no before a flag name causes
> the flag to
> be turned off except in the case of the nodump flag. To turn
> off nodump, use dump. Do not use nonodump.
> EXAMPLE:
> chflags dump somefile.txt

morning.

i think part of this is just learning curve. if you think about it,
there's enough info there to work it out.

the question would be more whether specifying "dump" actually does
anything other than achieve what already happens if you don;t specify
"nodump".

other than that, i think there's enough there to work it out.

jmc

Re: incorrect book reference in ksh.1

[Jason McIntyre]

On Mon, Jun 24, 2019 at 04:28:02PM +0200, Ingo Schwarze wrote:
> Hi,
> 
> Andras Farkas wrote on Sat, Jun 22, 2019 at 02:54:01PM -0400:
> 
> > In ksh.1, in the See Also section, this book is referenced:
> > Morris Bolsky and David Korn, The KornShell Command and Programming
> > Language, 2nd Edition, Prentice Hall, 1995, ISBN 0131827006.
> > However, the book with that ISBN number has a different name, as
> > attested to here:
> > https://dl.acm.org/citation.cfm?id=545704=flat
> > and by looking up the ISBN on Google and Amazon. (I also own the book
> > with this ISBN number, and can confirm those sources _are_ correct)
> > So if this book is to be referenced, the title given should be:
> > The New KornShell Command and Programming Language
> > The reference to it being a second edition then becomes optional, and
> > fine either way.
> > 
> > However, it may be worthwhile reverting the reference to be to the
> > first edition of the book:
> > https://dl.acm.org/citation.cfm?id=77009=flat
> > The 2nd edition is about ksh93, while the first edition is about
> > ksh88.  The ksh clone in OpenBSD is not a ksh93 clone.
> > 
> > Relevant diff where this change occurred:
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/ksh/ksh.1.diff?r1=1.150=1.151
> 
> Since jmc@ asked me to handle this, i committed the following patch.
> 
> Thanks for reporting,
>   Ingo
> 

much obliged!
jmc

> 
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   schwa...@cvs.openbsd.org2019/06/24 08:22:39
> 
> Modified files:
>   bin/ksh: ksh.1 
> 
> Log message:
> Partial revert of rev. 1.151:
> Reference the First Edition (1989) of Bolsky/Korn which is about ksh88,
> the shell the OpenBSD ksh(1) descends from (via pdksh).
> The Second Edition (1995) of the book is about ksh93 which we don't provide.
> Pointed out by Andras Farkas on bugs@.
> 
> 
> Index: ksh.1
> ===
> RCS file: /cvs/src/bin/ksh/ksh.1,v
> retrieving revision 1.205
> retrieving revision 1.206
> diff -u -r1.205 -r1.206
> --- ksh.1 21 Jun 2019 10:49:17 -  1.205
> +++ ksh.1 24 Jun 2019 14:22:39 -  1.206
> @@ -5545,10 +5545,12 @@
>  .Rs
>  .%A Morris Bolsky
>  .%A David Korn
> -.%B The KornShell Command and Programming Language, 2nd Edition
> -.%D 1995
> +.%B The KornShell Command and Programming Language
> +.%D First Edition 1989
>  .%I Prentice Hall
> -.%O ISBN 0131827006
> +.%O ISBN 0135169720
> +.\" The second edition of the above book (1995) is about ksh93,
> +.\" but the OpenBSD ksh is a decendant from ksh88 via pdksh.
>  .Re
>  .Rs
>  .%A Stephen G. Kochan

Re: man page possible correction for ports, bsd.port.mk

[Jason McIntyre]

On Wed, Jun 12, 2019 at 09:08:29AM -0500, myportslist20190...@nym.hush.com 
wrote:
> 1. man ports: In the Using a Read-Only Ports Tree section of man ports, I 
> believe
> it should read  PLIST_REPOSITORY instead of PLIST_DB.
> 
> (To support the change from PLIST_DB to PLIST_REPOSITORY,
> please note that man bsd.port.mk says PLIST_DB is deprecated. Also,
> make fix-permissions won't change permission if PLIST_DB is set
> in /etc/mk.conf, but it does work if PLIST_REPOSITORY is set.)
> 
> 2. man bsd.port.mk: in the PORTS_PRIVSEP section, where one adds
> these commands to doas.conf: /usr/bin/touch, /usr/sbin/pkg_add, and
> /usr/sbin/pkg_delete, I think an additional line is needed:
> 
> permit nopass setenv { TERM } solene cmd /usr/bin/env
> 
> (To support this addtion, please see these lines in 
> /usr/ports/infrastructure/mk/bsd.port.mk:
> SETENV ?= /usr/bin/env -i
> and
> ===> Installing . . . @${SUDO} ${SETENV}  . . .)
> 
> These are in snapshots 6.5-current #19 Wed Jun 12 01:15:09 MDT 2019
> 
> 

morning.

could you mail a diff, please? you will probably have a better chance of
feedback that way.

jmc

Re: dangling SEE ALSO references and some peculiarities in man pages

[Jason McIntyre]

On Tue, Apr 30, 2019 at 12:16:10AM +0200, Marc Espie wrote:
> On Sun, Apr 28, 2019 at 02:16:23PM -0500, Tim Chase wrote:
> > Dangling SEE ALSO references to man-pages that don't exist:
> > 
> > dig(1) references missing named(8) and dnssec-keygen(8)
> > host(1) references missing named(8)
> > nslookup(1) references missing named(8)
> > info(5) references missing emacs(1)
> > info(5) references missing tex(1)
> > texinfo(5) references missing emacs(1)
> > texinfo(5) references missing tex(1)
> > readline(3) references missing bash(1)
> 
> Now, all of these DO exist, in the ports tree.
> 
> Question: should the base system manpages be self-contained 100%, or is
> it better to also point people to optional software that may or may not
> be installed ?..
> 

i hate it when we Xr outside base, but sometimes it just makes sense.

> I believe there's no 100% correct answer.
> 

i agree.

jmc

> For instance, info mode in emacs and the relationship between .texi 
> and the TeX formatter are tight enough that I believe those references 
> are innocuous.
> 

Re: dangling SEE ALSO references and some peculiarities in man pages

[Jason McIntyre]

On Sun, Apr 28, 2019 at 02:16:23PM -0500, Tim Chase wrote:
> Digging through cross-references in man-pages, I encountered a couple
> dangling references and some other peculiarities.
> 

hi.

because we sometimes install 3rd party pages, there is a small amount of
Xr that doesn;t match up. the effort to clean it up is probably not
worth it.

> 
> Dangling SEE ALSO references to man-pages that don't exist:
> 
> dig(1) references missing named(8) and dnssec-keygen(8)
> host(1) references missing named(8)
> nslookup(1) references missing named(8)

that's all from bind

> info(5) references missing emacs(1)
> info(5) references missing tex(1)
> texinfo(5) references missing emacs(1)
> texinfo(5) references missing tex(1)

boy do i wish we could kill the info crap.

> default_colors(3) references missing ded(1)
> curs_inopts(3) references missing termio(7)

curses

> readline(3) references missing bash(1)
> 

gnu readline (check the "ouput" typo)

basically, upstream will not see these as issues, and maintaing local
changes are often more pain that gain.

> Peculiarities:
> 
> The man pages for form(3) and menu(3) have multiple SEE ALSO sections
> which struck me as a bit odd/confusing.  
> 
>

i've never noticed that. you could check if the latest curses still has
this - if they do, they are quite receptive to diffs. if not, we could
ask someone like nicm about fixing this locally.

> It all started with looking at texinfo(5) and noticing that tex(1)
> didn't exist in the man-pages, so I tossed together a dirty little
> Python script to attempt to check for other missing cross-references.
> The script still produces a little bit of noise in the output that I
> cleaned up for this email, but it made pretty quick work of finding
> some missing links.  If anybody wants the .py file, you're welcome to
> it.
> 

better still, run any changes you make to man pages like this:

$ mandoc -Tlint page.1

it will report trailing Xr and a whole host of other things. you can sit
back and have a cuppa!

jmc

Re: small bgplgsh.8 mistake

[Jason McIntyre]

On Thu, Mar 14, 2019 at 10:22:05PM +0100, Pierre Emeriaud wrote:
> Hello,
> 
> bgplgsh.8 shows an invocation to adduser with full path to bgplgsh,
> which is wrong:
> 
> lg# echo /usr/bin/bgplgsh >> /etc/shells
> 
> lg# adduser -shell /usr/bin/bgplgsh -batch rviews
> Shell ``/usr/bin/bgplgsh'' is undefined, use ``csh''
> Added user ``rviews''
> 
> lg# getent passwd rviews
> rviews:*:1004:999::/home/rviews:/bin/csh   <<<
> 
> lg# userdel rviews
> 
> lg# adduser -shell bgplgsh -batch rviews
> Added user ``rviews''
> 
> lg# getent passwd rviews
> rviews:*:1004:999::/home/rviews:/usr/bin/bgplgsh
> 
> on a related note, adduser(8) in interactive mode doesn't call
> shell_default_valid(), so it defaults to sh if invalid:
> lg# adduser -shell /usr/bin/bgplgsh rviews
> [...]
> Enter shell bgplgsh csh ksh nologin sh [/usr/bin/bgplgsh]: <<< accept
> default here
> [...]
> Added user ``rviews''
> 
> lg# getent passwd rviews
> rviews:*:1004:999:cli looking glass user:/home/rviews: <<< no shell
> (not sure if that qualifies as a bug though - quite stupid in the
> first place to invoke adduser as such).
> 
> regards
> 
> --- bgplgsh.8   10 Sep 2015 15:16:44 -  1.11
> +++ bgplgsh.8   14 Mar 2019 21:20:21 -
> @@ -53,7 +53,7 @@ See
>  .Xr adduser 8
>  for more information about system user management.
>  .Bd -literal -offset indent
> -# adduser -shell /usr/bin/bgplgsh -batch bgplg
> +# adduser -shell bgplgsh -batch bgplg
>  # passwd bgplg
>  .Ed
>  .It
> 

fixed, thanks.
jmc

Re: Wording re. permissions on ~/.ssh/config differs between ssh(1) and ssh_config(5)

[Jason McIntyre]

On Sat, Feb 16, 2019 at 12:49:07PM +0100, Andreas Kusalananda K?h?ri wrote:
> In ssh_config(5):
> 
>  ~/.ssh/config
>  This is the per-user configuration file.  The format of this file
>  is described above.  This file is used by the SSH client.
>  Because of the potential for abuse, this file must have strict
>  permissions: read/write for the user, and not accessible by
>  others.
> 
> "not accessible"
> 
> In ssh(1):
> 
>  ~/.ssh/config
>  This is the per-user configuration file.  The file format and
>  configuration options are described in ssh_config(5).  Because of
>  the potential for abuse, this file must have strict permissions:
>  read/write for the user, and not writable by others.
> 
> "not writable"
> 
> 
> It would be better (IMHO) to mention explicit permissions, e.g. 600 (but
> only if this is what the actual code of ssh is checking for, obviously).
> 
> Also, not being accessible could be seen as a consequence of ~/.ssh not
> being accessible, which, if one disregarded the ssh(1) manual, could
> possibly be interpreted as meaning having the file writable by others is
> okay.
> 
> In any case, they should probably say the same thing.
> 
> -- 
> Andreas Kusalananda K??h??ri,
> National Bioinformatics Infrastructure Sweden (NBIS),
> Uppsala University, Sweden.
> 

morning.

the description "not writable" got updated in ssh.1, but looks like we
overlooked ssh_config.5. i've just bumped it to read the same/

thanks,
jmc

Re: Trivial documentation patch

[Jason McIntyre]

On Sun, Jan 06, 2019 at 03:30:10PM +0200, cho...@jtan.com wrote:
> A grammatical error in login.conf(5):
> 

fixed, thanks.
jmc

> --- login.conf.5?rev=1.64   Sun Jan  6 15:27:44 2019
> +++ login.conf.5Sun Jan  6 15:28:10 2019
> @@ -104,7 +104,7 @@
>  .Pp
>  .It auth Ta list Ta Dv passwd Ta
>  Allowed authentication styles.
> -The first value is the default styles.
> +The first value is the default style.
>  .\"
>  .Pp
>  .It auth- Ns Ar type Ta list Ta "" Ta
> 
> 
> Matthew
> 

Re: sed(1) not branching to the end of the script

[Jason McIntyre]

On Fri, Dec 07, 2018 at 06:23:35PM +0100, Ingo Schwarze wrote:
> Hi Martijn,
> 
> Martijn van Duren wrote on Thu, Dec 06, 2018 at 07:07:14AM +0100:
> > On 12/5/18 7:24 PM, Ingo Schwarze wrote:
> 
> >> putting the minimal useful example in the place of longer quotations:
> >> 
> >>$ printf "A\nB\n" | gsed '1b;='
> >>   A
> >>   2
> >>   B
> >>$ printf "A\nB\n" | sed '1b;='  
> >>   sed: 1: "1b;=": undefined label ''
> 
> >> Martijn van Duren wrote on Wed, Dec 05, 2018 at 09:24:05AM +0100:
> 
> >>> Note that the label should consist of "portable filename
> >>> character set" characters, so adding the semicolon support doesn't break
> >>> compatibility too bad. Although it is a violation, not an extension on
> >>> unspecified behaviour (only unspecified behaviour is for is for
> >>> s/../../w).
> 
> >> Why do you think it is a violation?
> 
> > Because POSIX goes out of its way to make it not obvious:
> > Editing commands other than {...}, a, b, c, i, r, t, w, :, and # can be 
> > followed by a , optional  characters, and another 
> > editing command. However, when an s editing command is used with the w  
> > flag, following it with another command in this manner produces 
> > undefined results.
> > 
> > They begin by a negation which can use a semicolon and then they follow
> > by explicitly stating where undefined behaviour lies. So assuming that
> > not including in "can" equals "may still", and assuming that the
> > undefined results section is a non-exhaustive list, or an exclusive for
> > the inverse group mentioned at the star, may result in undefined
> > behaviour. But combine the obscure language with the fact that there's a
> > profound reason to not use a semicolon in 6 out of the 10 exclude group
> > makes me wonder if it's not a violation why they went out of their way
> > to place them in the same list as a, c, i, r, w, #.
> 
> Ah.  I think when reading a standard, one must carefully look what it
> actually says, not jump to conclusions from how that is said.  Even when
> logically unambiguous, the wording may sometimes sound confusing.
> And sometimes, what is prescribed is unambiguous, but something else
> would seem to make more sense.
> 
> No doubt it says what a semicolon is supposed to do after the
> commands not listed.  No doubt it says that "s///w filename;something"
> results in undefined behaviour - by the way, "undefined" is stronger
> than "unspecified".  But i don't see that it says anywhere
> what "b label;something" is supposed to do - so that is left
> unspecified, and operating systems are free to implement and
> document an extension.
> 
> By the way, we do have a case here of the specification looking
> slightly ill-designed: "s///w filename;something" is explicitly
> marked as undefined, whereas the even simpler "w filename;something"
> is merely left unspecified.  But fortunately, we are not planning
> to change the behaviour of "[s///]w filename;something", so we don't
> need to worry about that right now.
> 
> 
> All that said, i see a few problems with the manual page, so here is
> a patch to fix it.
> 
> The information in the CAVEATS section is misplaced.  The purpose
> of that section is to warn about typical programming mistakes, not
> to explain what our implementation does nor to explain what the
> standard requires.  Besides, it is wrong, semicolons *can* be used
> after "b" and "t" with our implementation.  Finally, the current
> wording can mislead people to think this might be forbidden:
> 
>   $ echo "A\nB" | sed '=;r suffix.txt'
> 
> 
> So move the information about "a", "c", "i", "r", and "w" to the
> DESCRIPTION.  I don't think it belongs into the second paragraph
> from the top; even though that is where ";" is introduced, that
> place would be way too prominent.  Below "SED FUNCTIONS", where
> other special properties of groups of functions are also explained,
> seems about right.
> 
> Move the information about "b", "t", and ":" to STANDARDS where it
> belongs.  That commands in general can be separated with ";" was
> already said at the very top of the page.
> 
> I don't think anything more needs to be said about "#".
> We already have:
> 
> The '#' and the remainder of the line are ignored (treated as a
> comment), with the single exception that if the first two
> characters in the file are '#n', the default output is
> [...]
> 
> It's kind of obvious the remainder of the line may contain ';'
> and it will be ignored.
> 
> While here, avoid "permitted" - were aren't planning to send anybody
> to jail for sed(1) abuse.
> 
> OK?
>   Ingo
> 

hi.

it reads ok to me. but just to note - there is nothing wrong with the
way "permitted" is used in that text.

jmc

> 
> Index: sed.1
> ===
> RCS file: /cvs/src/usr.bin/sed/sed.1,v
> retrieving revision 1.57
> diff -u -r1.57 sed.1
> --- sed.1 14 Nov 2018 10:59:33 -  1.57
> +++ sed.1 7 Dec 2018 16:48:14 -
> 

Re: bgpd action pftable doesn't work as expected in -current

[Jason McIntyre]

On Tue, Nov 06, 2018 at 03:54:15PM +0200, Gregory Edigarov wrote:
> Hello, just noticed that.
> 
> in pf.conf:
> 
> table bgp-spamd-block persists
> 
> 
> in bgpd.conf
> 
> spamdAS="65066"
> AS 65077
> fib-update no?? # Mandatory, to not update the local routing table
> #log updates
> 
> group "spamd-bgp" {
>  ?? remote-as $spamdAS
>  ?? multihop 64
>  ?? export none # Do not send Route Server any information
> 
>  ?? # us.bgp-spamd.net
>  ?? neighbor 64.142.121.62
> 
>  ?? # eu.bgp-spamd.net
>  ?? neighbor 217.31.80.170
> 
>  ?? # IPv6 eu.bgp-spamd.net
>  ?? # neighbor 2a00:15a8:0:100:0:d91f:50aa:1
> }
> 
> match from group spamd-bgp community $spamdAS:666?? set pftable 
> "bgp-spamd-block"
> 
> bgpd is running
> 
> some time later:
> 
> lbld12# bgpctl sh
> Neighbor AS?? MsgRcvd?? MsgSent?? 
> OutQ Up/Down 
> State/PrfRcvd
> 217.31.80.170 65066 78 
> 20 0 00:08:53?? 38256
> 64.142.121.62 65066 76 
> 20 0 00:08:53?? 38256
> 
> i.e. it receives the prefixes ok, but:
> 
> lbld12# pfctl -Tsh -t bgp-spamd-block | wc -l
>   0
> 

hi.

during 6.3 - 6.4 there were some big changes in bgpd. you should
probably read through the upgrade notes for them. i suspect what's
causing you problems is that bgpd now denies to/from any by default. so
probably you need to allow the spamd group:

allow from group spamd-bgp

i don;t know if it's possible to do the match/allow bits with one rule
or not.

jmc

Re: sysctl(2) man page typo correction

[Jason McIntyre]

On Tue, Nov 06, 2018 at 12:25:56PM +0100, Piotr Durlej wrote:
> --- lib/libc/sys/sysctl.2.old   Tue Nov  6 10:08:56 2018
> +++ lib/libc/sys/sysctl.2   Tue Nov  6 10:09:03 2018
> @@ -256,7 +256,7 @@
>   .It Dv FS_POSIX_SETUID Ta "integer" Ta "yes"
>   .El
>   .Bl -tag -width "123456"
> -.It Dv FS_POSIX_SETUID Pq Va fx.posix.setuid
> +.It Dv FS_POSIX_SETUID Pq Va fs.posix.setuid
>   When this variable is set, ownership changes on a file will cause
>   the
>   .Va S_ISUID
> 

hi.

otto just fixed this, i think.
jmc

Re: sh's man page's description about its diff w ksh is very ambiguous & deserves being clarified?

[Jason McIntyre]

On Wed, Oct 31, 2018 at 03:10:35PM +, Joseph Mayer wrote:
> (Topic moved from misc@ https://marc.info/?t=15409118202=1=2
> as it's a question about whether it's a bug:)
> 
> 
> sh's man page (http://man.openbsd.org/sh#DESCRIPTION) says:
> 
> "This version of sh is actually ksh in disguise. As such, it also
> supports the features described in ksh(1). This manual page describes
> only the parts relevant to a POSIX compliant sh."
> 
> When I read that originally, I perceived it as that "sh" and "ksh"
> normally would have equivalent behavior - which also seems logical
> given that their binaries are byte-equivalent.
> 
> The meaning I gather from the sentence is that sh and ksh are
> equivalent and that instead the man pages will describe different
> functionalities that are actually available in both.
> 
> Can that phrase in sh's man page be tweaked so that my misunderstanding
> no longer is possible?
> 
> Do you find my misunderstanding a reasonable reading?
> 
> Joseph
> 

morning.

you may have a point, i agree. our sh is really ksh, but when run as sh
it has a few differences. i think it is mainly the case that there is
some functionality not supported when run as sh.

previously the sh page was the same as the ksh page, but with some of
this functionality trimmed out. i'm not sure where we would stop at
attempting to describe how the shells runs. do we need a list of
differences, or is it enough to say they differ in small ways?

when you say "Can that phrase ... be tweaked", i guess i would ask you:
can you provide a diff so that your "misunderstanding is no longer
possible"? it doesn;t have to be a diff - just give me the text you
think is missing.

personally i'd prefer to avoid trying to get into this discussion. you
should just use ksh(1) as the reference page for what the shell can do,
and sh(1) if you want to limit yourself to those aspects described by
posix.

jmc

Re: typo in switchd.conf.5

[Jason McIntyre]

On Tue, Oct 30, 2018 at 12:21:45AM -0700, Bryan Stenson wrote:
> Here's a small typo I noticed while reading/learning...
> 
> Thanks for the amazing work.
> 
> Bryan
> 

fixed, thanks.
jmc

> 
> Index: usr.sbin/switchd/switchd.conf.5
> 
> ===
> 
> RCS file: /cvs/src/usr.sbin/switchd/switchd.conf.5,v
> 
> retrieving revision 1.7
> 
> diff -u -r1.7 switchd.conf.5
> 
> --- usr.sbin/switchd/switchd.conf.5 18 Jun 2018 06:04:25 - 1.7
> 
> +++ usr.sbin/switchd/switchd.conf.5 30 Oct 2018 07:17:48 -
> 
> @@ -32,7 +32,7 @@
> 
>  files is divided into the following main sections:
> 
>  .Bl -tag -width 
> 
>  .It Sy Macros
> 
> -User-defined variables may be defined and user later, simplifying the
> 
> +User-defined variables may be defined and used later, simplifying the
> 
>  configuration file.
> 
>  .It Sy Global Configuration
> 
>  Global runtime settings for

Re: slowcgi -u user option does not change socket ownership

[Jason McIntyre]

On Wed, Aug 01, 2018 at 12:57:18PM +0200, Florian Obser wrote:
> On Tue, Jul 31, 2018 at 06:39:18PM -0500, Andrew Daugherity wrote:
> [...] 
> > Related: in the same section of code (at the end of my diff actually,
> > as context), I noticed that when -u is used, the chroot path is set to
> > the target user's home directory instead of /var/www.  I found this
> > surprising, so I added a manpage diff to my patchset:
> > 
> > --- slowcgi.8 2017-10-17 17:47:58.0 -0500
> > +++ slowcgi.8 2018-07-26 13:34:06.459779115 -0500
> > @@ -78,7 +78,9 @@
> >  .It Fl u Ar user
> >  Drop privileges to
> >  .Ar user
> > -instead of default user www.
> > +instead of the default www, and chroot to that user's home directory,
> > +unless you specify otherwise with
> > +.Ar -p .
> >  .El
> >  .Sh SEE ALSO
> >  .Xr httpd 8
> > 
> > Perhaps that's a bit too wordy and only the first line is needed, I dunno.
> 
> How about this? jmc?
> 
> diff --git slowcgi.8 slowcgi.8
> index 52bded7eee6..117228403b4 100644
> --- slowcgi.8
> +++ slowcgi.8
> @@ -79,6 +79,12 @@ Create and bind to alternative local socket at
>  Drop privileges to
>  .Ar user
>  instead of default user www.
> +.Nm
> +will
> +.Xr chroot 8
> +to
> +the home directory of
> +.Ar user .

reads ok. you could shorten it to:

... user www
and
.Xr chroot 8
...

>  .El
>  .Sh SEE ALSO
>  .Xr httpd 8
> 
> Jmc: Btw, why are we using the section 8 man page in Xr, technically
> slowcgi uses chroot(2).
> 

we tend to try and use userland refs in userland docs. however if it
makes more sense to reference chroot(2), by all means do so (whichever
will be the most use to the target reader).

jmc

Re: afterboot.8 nitpick

[Jason McIntyre]

On Sat, Jun 16, 2018 at 11:56:44AM +0100, Jason McIntyre wrote:
> On Fri, Jun 15, 2018 at 11:38:27AM +0100, Pedro Caetano wrote:
> > Hi bugs@
> > 
> > I spent some time reading afterboot.8 and noticed a few discrepancies with
> > reality.
> > Output from netstat(1) and from ifconfig(8) itself has changed lately.
> > 
> > I wasn't able to validate the correct output from the ppp(4), but based my
> > patch on gre(4) which i guess is similar enough.
> > 
> > Thank you for your time working on your project!
> > 
> > Best regards,
> > Pedro Caetano
> > 
> 
> morning.
> 
> the trouble with making changes like this is that we're playing catchup.
> i don;t think the actual output being in sync is going to make much
> difference to the afterboot(8) reader. in fact i am tempted to say it
> would make more sense to squash all the example output in that section -
> it doesn;t tell you anything anyway.
> 
> if anyone can think of reasons why it is helpful, we could update it i
> suppose. but, does anyone? if not i will squash it.
> 
> jmc
> 

no feedback, so below is my proposed diff.
jmc

Index: afterboot.8
===
RCS file: /cvs/src/share/man/man8/afterboot.8,v
retrieving revision 1.160
diff -u -r1.160 afterboot.8
--- afterboot.8 7 Sep 2017 13:08:39 -   1.160
+++ afterboot.8 17 Jun 2018 19:55:31 -
@@ -152,7 +152,7 @@
 You will also need to edit the
 .Pa /etc/myname
 file to have it stick around for the next reboot.
-.Ss Verify network interface configuration
+.Ss Verify network interface configuration and routing tables
 The first thing to do is an
 .Ic ifconfig -a
 to see if the network interfaces are properly configured.
@@ -171,65 +171,17 @@
 man page for more information on the format of
 .Pa /etc/hostname. Ns Ar interface
 files.
-The loopback interface will look something like:
-.Bd -literal -offset indent
-lo0: flags=8009 mtu 32972
-   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
-   inet6 ::1 prefixlen 128
-   inet 127.0.0.1 netmask 0xff00
-.Ed
-.Pp
-an Ethernet interface something like:
-.Bd -literal -offset indent
-em0: flags=9863
-   inet 192.168.4.52 netmask 0xff00 broadcast 192.168.4.255
-   inet6 fe80::5ef0:f0f0%em0 prefixlen 64 scopeid 0x1
-.Ed
-.Pp
-and a PPP interface something like:
-.Bd -literal -offset indent
-ppp0: flags=8051
-inet 203.3.131.108 --> 198.181.0.253 netmask 0x
-.Ed
 .Pp
 See
 .Xr netstart 8
 for instructions on configuring multicast routing.
-.Pp
 See
 .Xr hostname.if 5
 for instructions on configuring interfaces with DHCP.
-.Ss Check routing tables
-Issue a
+.Pp
+Routing tables can be viewed by issuing a
 .Ic netstat -rn
 command.
-The output will look something like:
-.Bd -literal -offset indent
-Routing tables
-
-Internet:
-DestinationGateway   Flags  Refs Use  Mtu  Interface
-default192.168.4.254 UGS  0 11098028-  em0
-127127.0.0.1 UGRS 00-  lo0
-127.0.0.1  127.0.0.1 UH   3   24-  lo0
-192.168.4  link#1UC   00-  em0
-192.168.4.52   8:0:20:73:b8:4a   UHL  1 6707-  em0
-192.168.4.254  0:60:3e:99:67:ea  UHL  10-  em0
-
-Internet6:
-DestinationGateway   Flags  Refs  Use Mtu  Interface
-::/96  ::1   UGRS 0 0   32972  lo0 =>
-::1::1   UH   4 0   32972  lo0
-:::0.0.0.0/96  ::1   UGRS 0 0   32972  lo0
-fc80::/10  ::1   UGRS 0 0   32972  lo0
-fe80::/10  ::1   UGRS 0 0   32972  lo0
-fe80::%em0/64  link#1UC   0 01500  em0
-fe80::%lo0/64  fe80::1%lo0   U0 0   32972  lo0
-ff01::/32  ::1   U0 0   32972  lo0
-ff02::%em0/32  link#1UC   0 01500  em0
-ff02::%lo0/32  fe80::1%lo0   UC   0 0   32972  lo0
-.Ed
-.Pp
 The default gateway address is stored in the
 .Pa /etc/mygate
 file.

Re: ddb(4): p[rint] man page example vs. result.

[Jason McIntyre]

On Wed, May 16, 2018 at 12:41:01PM +0300, Artturi Alm wrote:
> On Wed, May 09, 2018 at 11:35:42AM +0200, Martin Pieuchot wrote:
> > On 09/05/18(Wed) 12:13, Artturi Alm wrote:
> > > On Wed, May 09, 2018 at 10:23:41AM +0200, Martin Pieuchot wrote:
> > > > On 09/05/18(Wed) 07:48, Artturi Alm wrote:
> > > > > On Tue, May 08, 2018 at 01:44:39AM +0300, Artturi Alm wrote:
> > > > 
> > > > 
> > > > No bug are irrelevant to fix.  But working with you is hard, really
> > > > hard.  You never explain what the problem is.  Reading your email is
> > > > an exercise in frustration because you can do some good work but you
> > > > fail to communicate.
> > > > 
> > > > > > (manual "copypaste"):
> > > > > > nc2k4hp# sysctl ddb.trigger=1
> > > > > > Stopped at  db_enter+0x4:   popl%ebp
> > > > > > ddb{0}> print/x "eax = " $eax "\necx = " $ecx "\n"
> > > > > > 3
> > > > > > ddb{0}> c
> > > > > > ddb.trigger: 0 -> 1
> > > > > > 
> > > > > > so, for reasons yet unknown to me, p[rint] doesn't seem to work at 
> > > > > > all
> > > > > > like described in the man page, tested on i386.
> > > > 
> > > > What do no work?  What does the man page describe?  Do you expect us to
> > > > read the man page, then look at your mail again, then try to understand
> > > > what is not working? 
> > > > 
> > > 
> > > For example,
> > > 
> > >   print/x "eax = " $eax "\necx = " $ecx "\n"
> > > 
> > > will print something like this:
> > > 
> > >   eax = xx
> > >   ecx = yy
> > > 
> > > Now I did install 5.0 into a VM, and there the result for above example
> > > would of have been just "Ambiguous", and I'm guessing now that this
> > > has not been working as in the example since import.
> > > My fix is limited to producing output just like in the example, but
> > > input requires more, as it needs escapes for everything not a-z,A-Z,0-9.
> > > 
> > > > > > Should it work? I hope it would.
> > > > 
> > > > What should work?  Why do you hope?  Maybe the manpage should be fixed?
> > > > 
> > > 
> > > Multiple [addr] arguments to p[rint], including support for strings,
> > > and i hope so because i would find it useful while testing/writing/porting
> > > drivers. Maybe, I do like "show struct", and have more than just
> > > the filtering diff for it, but it doesn't really work for the ad hoc
> > > usecases p[rint] seems so excellent for.
> > > 
> > > > > Does feel like waste of time to go any further fixing this, if this is
> > > > > yet another bug too irrelevant for anyone to ack for, so _any_ input
> > > > > here would be great.
> > > > 
> > > > Like I said, no bug are irrelevant but if the one finding the bug, you
> > > > in that case, is not willing to properly explain the problem, then
> > > > better not send an email at all ;)
> > > 
> > > Will try in the future.
> > 
> > Thanks for the explanation!
> > 
> > > haven't tested the diff below yet, but compared to previous, it should
> > > have working /modifierS.
> > 
> > IMHO we should just amend the man page and keep ddb(4) code simple. 
> 
> Np., initial diff to castrate it to reality below, and jmc@ CC'd.
> 
> Unsure about the wording of the "If no modifier is ..." sentence towards
> end, atleast "the last one specified" when there can be only one specified
> does sound weird to me, maybe replacing 'previous' with 'last'?
> 
> Anyway I'm done with this, due broken english and all:)
> 
> -Artturi
> 
> 
> diff --git share/man/man4/ddb.4 share/man/man4/ddb.4
> index 02ff2fd78a6..69402f0c776 100644
> --- share/man/man4/ddb.4
> +++ share/man/man4/ddb.4
> @@ -278,9 +278,9 @@ plus the size of the data examined.
>  .It Xo
>  .Ic p Ns Op Ic rint
>  .Op Cm /axzodurc
> -.Op Ar addr Op Ar addr ...
> +.Op Ar addr
>  .Xc
> -Print each
> +Print
>  .Ar addr
>  according to the modifier character.
>  The valid modifiers are a subset of those from the
> @@ -290,20 +290,15 @@ If no modifier is specified, the last one specified in a
>  previous use of
>  .Ic print
>  is used.
> -The
> -.Ar addr
> -argument
> -can be a string, and it is printed as a literal.
>  .Pp
>  For example,
>  .Bd -literal -offset indent
> -print/x "eax = " $eax "\enecx = " $ecx "\en"
> +print/x $eax
>  .Ed
>  .Pp
>  will print something like this:
>  .Bd -literal -offset indent
> -eax = xx
> -ecx = yy
> +xx
>  .Ed
>  .\" 
>  .It Xo

fixed, thanks.
jmc

Re: -soii not documented in hostname.if(5)

[Jason McIntyre]

On Tue, Apr 03, 2018 at 01:17:06PM +0200, Harald Dunkel wrote:
> Hi folks,
> 
> according to the upgrade guide I added "-soii" to hostname.re1.
> It seems to work as expected, but it is not documented in
> hostname.if(5).
> 
> Would you mind to add this option to the man page?
> 
> Except for changing the link local IPv6 addresses the upgrade
> to 6.3 worked very well. No surprises, AFAICTBN.
> 
> I highly appreciate your work on OpenBSD.
> 
> 
> Regards
> Harri
> 

hi.

sorry i'm a bit late to the party. did everything get cleared up? soii
is documented in ifconfig(8), as expected, and linked to from
hostname.if(5). it is not needed to be explicitly documented in
hostname.if(5). hope that's all clear.

jmc

Re: Add "dummy" man page for the X dummy driver? ("void" kbd driver has a man page.)

[Jason McIntyre]

On Thu, Mar 29, 2018 at 11:17:33AM -0400, Tinker wrote:
> Hi,
> 
> The dummy X graphics driver may be slightly outdated but it exists and
> works.
> 
> The keyboard and mouse driver void(4) does have a man page, and is
> referenced in x.org(5)'s SEE ALSO section.
> 
> Shouldn't "dummy" have a man page and be referenced in x.org(5)'s SEE
> ALSO section also?
> 

isn;t that a question for the X project?
jmc

> 
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-video-dummy/
> 
> https://marc.info/?t=15187399242=1=2
> https://marc.info/?t=15223071333=1=2
> https://marc.info/?l=openbsd-misc=152233592922216=2
> 
> http://man.openbsd.org/void.4
> 
> http://man.openbsd.org/xorg.conf.5#SEE_ALSO
> 
> Tinker
> 

Re: setlocale() bugs

[Jason McIntyre]

On Tue, Mar 20, 2018 at 03:54:00PM +0100, Ingo Schwarze wrote:
> Hi Stefan,
> 
> Stefan Sperling wrote on Tue, Mar 20, 2018 at 10:09:39AM +0100:
> > On Tue, Mar 20, 2018 at 02:42:31AM +0100, Ingo Schwarze wrote:
> 
> >> So here is a rewrite of our setlocale(3) manual page.  No idea why
> >> i didn't do that earlier, there are lots of obvious issues with that
> >> manual page.
> 
> > Thanks, I've read through it and it looks good.
> 
> Thanks for checking.
> 
> > I think we explicitly allow LC_MESSAGES to be set to any
> > value which is accepted by LC_CTYPE, for compatibility with
> > natural language support in ports. Maybe mention that as well?
> 
> My text was intended to imply that, but i admit it wasn't all
> that clear.  Patch updated to make the point explicit in the
> following way, with no other changes:
> 
>   On OpenBSD, the only useful value for the category is LC_CTYPE.  It sets
>   the locale used for character encoding, character classification, and
>   case conversion.  For compatibility with natural language support in
>   packages(7), all other categories - LC_COLLATE, LC_MESSAGES, LC_MONETARY,
>   LC_NUMERIC, and LC_TIME - can be set and retrieved, too, but their values
>   are ignored by the OpenBSD C library.  A category of LC_ALL sets the
>   entire locale generically.
> 
> Yours,
>   Ingo
> 

reads fine to me.
jmc

> 
> Index: setlocale.3
> ===
> RCS file: /cvs/src/lib/libc/locale/setlocale.3,v
> retrieving revision 1.19
> diff -u -r1.19 setlocale.3
> --- setlocale.3   21 Sep 2015 14:46:59 -  1.19
> +++ setlocale.3   20 Mar 2018 14:50:09 -
> @@ -39,7 +39,7 @@
>  .Sh NAME
>  .Nm setlocale ,
>  .Nm localeconv
> -.Nd natural language formatting for C
> +.Nd select character encoding
>  .Sh SYNOPSIS
>  .In locale.h
>  .Ft char *
> @@ -49,78 +49,74 @@
>  .Sh DESCRIPTION
>  The
>  .Fn setlocale
> -function sets the C library's notion
> -of natural language formatting style
> -for particular sets of routines.
> -Each such style is called a
> -.Dq locale
> -and is invoked using an appropriate name passed as a C string.
> -The
> -.Fn localeconv
> -routine returns the current locale's parameters
> -for formatting numbers.
> +function selects the given
> +.Fa locale
> +for the current process.
> +The locale modifies the behaviour of some functions in the C library
> +with respect to the character encoding, and on other operating systems
> +also with respect to some language and cultural conventions.
> +For more information about locales in general, see the
> +.Xr locale 1
> +manual page.
>  .Pp
> -The
> -.Fn setlocale
> -function recognizes several categories of routines.
> -These are the categories and the sets of routines they select:
> -.Bl -tag -width LC_MONETARY
> -.It Dv LC_ALL
> -Set the entire locale generically.
> -.It Dv LC_COLLATE
> -Set a locale for string collation routines.
> -This controls alphabetic ordering in
> -.Xr strcoll 3
> -and
> -.Xr strxfrm 3 .
> -.It Dv LC_CTYPE
> -Set a locale for the functions declared in
> -.In ctype.h
> -and
> -.In wctype.h .
> -This controls recognition of upper and lower case,
> -alphabetic or non-alphabetic characters, and so on.
> -.It Dv LC_MESSAGES
> -Set a locale for message strings.
> -Controls the behaviour of
> -.Xr catopen 3
> -and internationalization tools.
> -.It Dv LC_MONETARY
> -Set a locale for formatting monetary values;
> -this affects the
> -.Fn localeconv
> -function.
> -.It Dv LC_NUMERIC
> -Set a locale for formatting numbers.
> -This controls the formatting of decimal points
> -in input and output of floating point numbers
> -in functions such as
> -.Xr printf 3
> +On
> +.Ox ,
> +the only useful value for the
> +.Fa category
> +is
> +.Dv LC_CTYPE .
> +It sets the locale used for character encoding, character classification,
> +and case conversion.
> +For compatibility with natural language support in
> +.Xr packages 7 ,
> +all other categories \(em
> +.Dv LC_COLLATE ,
> +.Dv LC_MESSAGES ,
> +.Dv LC_MONETARY ,
> +.Dv LC_NUMERIC ,
>  and
> -.Xr scanf 3 ,
> -as well as values returned by
> -.Fn localeconv .
> -.It Dv LC_TIME
> -Set a locale for formatting dates and times using the
> -.Xr strftime 3
> -function.
> -.El
> +.Dv LC_TIME
> +\(em can be set and retrieved, too, but their values are ignored by the
> +.Ox
> +C library.
> +A category of
> +.Dv LC_ALL
> +sets the entire locale generically.
>  .Pp
> -Only three locales are defined by default,
> -the empty string
> -.Qq
> -which denotes the native environment, and the
> -.Qq C
> -and
> -.Qq POSIX
> -locales, which denote the C language environment.
> -A
> +The syntax and semantics of the
> +.Fa locale
> +argument are not standardized and vary among operating systems.
> +On
> +.Ox ,
> +if the
>  .Fa locale
> -argument of
> -.Dv NULL
> -causes
> +string ends with
> +.Qq ".UTF-8" ,
> +the UTF-8 locale is selected; otherwise, the C/POSIX/ASCII locale
> +is selected.
> +If the
> +.Fa locale
> 

Re: gpioctl.8: "0x01" given as an example flag, and parsed w/strtonum.

[Jason McIntyre]

On Fri, Mar 09, 2018 at 09:08:15AM +0200, Artturi Alm wrote:
> Hi,
> 
> i don't see how that would work, so before anyone fixes gpioctl to
> accept base 16, maybe diff below to fix the man page instead..?
> (came up while adding more [flags] usage to the man page.)
> 
> -Artturi
> 

fixed, thanks.
jmc

> 
> diff --git usr.sbin/gpioctl/gpioctl.8 usr.sbin/gpioctl/gpioctl.8
> index 0b91a2ce4b6..25d0d302ae3 100644
> --- usr.sbin/gpioctl/gpioctl.8
> +++ usr.sbin/gpioctl/gpioctl.8
> @@ -143,7 +143,7 @@ invert output
>  When attaching an I2C device,
>  if the
>  .Ar flag
> -argument is set to 0x01,
> +argument is set to 1,
>  the order of the SDA and SCL signals is reversed
>  (see
>  .Xr gpioiic 4 ) .
> 

Re: (Minor, in the unbound man pages, "SEE ALSO" refs don't hyperlink)

[Jason McIntyre]

On Tue, Feb 27, 2018 at 02:01:30AM -0500, Tinker wrote:
> The links in the unbound documentation e.g. 
> http://man.openbsd.org/unbound#SEE_ALSO do not share format with the other 
> OpenBSD docs http://man.openbsd.org/cat#SEE_ALSO , so that the references not 
> are hyperlinks in the web version.
> 
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/unbound/doc/
> 
> Normally OpenBSD man pages link by .Xr and the unbound man pages don't.
> 
> Tinker
> 

morning.

you could petition the unbound project to convert their pages to mdoc
format. better still, convert them yourself and submit those.

jmc

Re: Document "machine video" command in the boot(8) man page (offered in 6.2 EFI BOOTX64)

[Jason McIntyre]

On Sat, Feb 10, 2018 at 02:23:35AM -0500, Tinker wrote:
> Hi,
> 
> The "OpenBSD/amd64 BOOTX64 3.35" EFI boot console bundled with OpenBSD 6.2 
> offers the "video" subcommand to the "machine" command.
> 
> Please add it to boot(8).
> 
> (The command is not offered by 6.2's MBR boot console.)
> 
> Interaction:
> 
>  boot> help
>  commands: # boot echo env help ls machine reboot set stty time
>  machine: diskinfo memory video exit poweroff
>  boot> machine video
>  Mode 0: 80 x 25
>  Mode 1: 80 x 50
>  Mode 2: 100 x 31
>  Mode 3: 80 x 26
>  
>  Current mode = 2
> 
> And running machine video with an integer argument changes the resolution to 
> the respective setting.
> 
> Thanks,
> Tinker
> 

documented, for some value of documented. next time, a diff would be
nice ;)

jmc

Re: amd64/machdep knob: forceukb forcing wrong encoding.

[Jason McIntyre]

On Sun, Feb 04, 2018 at 11:28:31AM +0200, Artturi Alm wrote:
> Hi,
> 
> machdep.forceukbd=1 feels broken to me, as i use "sv", and it doesn't respect
> /etc/kbdtype.
> caused nothing but my time being (not-so-well-)wasted, because i forgot having
> just added forceukbd=1 && this 'quirk' being undocumented. so maybe a docbug.
> 
> just wanted to make a note of this somewhere, sry4noise..
> -Artturi
> 

morning.

i ran into this this week too. i think it is a bug in its behaviour, not
a doc bug.

jmc

Re: is vic driver supported from OpenBSD 3.9 ?

[Jason McIntyre]

On Sun, Dec 31, 2017 at 11:48:04AM +0100, Jiri Navratil wrote:
> Hello,
> 
> May I propose to extend VIC(4) man page
> https://man.openbsd.org/vic.4
> 
> with this line
> 
> The vic driver first appeared in OpenBSD 3.9. 
> 
> See
> https://man.openbsd.org/OpenBSD-3.8/vic.4
> vs
> https://man.openbsd.org/OpenBSD-3.9/vic.4
> 
> Best regards,
> Ji??
> 
> -- 
> Jiri Navratil, https://kouc.navratil.cz, +420 222 767 131
> 

done.
jmc

Re: PF - Getting Started docs suggestion

[Jason McIntyre]

On Sun, Nov 05, 2017 at 12:11:57AM -0700, Jonathan Berger wrote:
> On this page:
> https://www.openbsd.org/faq/pf/config.html
> 
> I would suggest changing:
> > also manually activate and deactivate
> 
> to
> also manually enable and disable
> 
> 
> This would match the language in the man page and also help readers
> understand the -e and -d flags.
> 
> Jonathan

hi.

i agree that "enable" and "disable" is a better choice. however there is
an issue with your proposal: the text after that you quote does say:

These would enable and disable pf.

so the mnemonic is there. if we make your change there is duplication.
that suggests we need a small rewrite i guess. for example:

You can also manually enable and disable PF by using the
pfctl(8) options -e and -d, respectively.  Note that it doesn;t
...

however i'm loathe to touch html.

tj? tb?

jmc

Re: expand(1) manual documents non-existant "-a" option

[Jason McIntyre]

On Thu, Oct 19, 2017 at 09:20:25PM +0200, Andreas Kusalananda K?h?ri wrote:
> >Synopsis:expand(1) manual documents non-existant "-a" option
> >Category:documentation
> >Environment:
>   System  : OpenBSD 6.2
>   Details : OpenBSD 6.2 (GENERIC.MP) #0: Thu Oct 12 19:53:18 CEST 2017
>
> r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> 
> The documentation of the expand(1) utility contains references to an
> option "-a":
> 
>  -aBy default, only leading blanks and tabs are reconverted to maximal
>strings of tabs.  If the -a option is given, tabs are inserted
>whenever they would compress the resultant file by replacing two or
>more characters.
> 
> However, this option is not implemented:
> 
>   while ((c = getopt (argc, argv, "t:")) != -1) {
>   switch (c) {
>   case 't':
>   getstops(optarg);
>   break;
>   case '?':
>   default:
>   usage();
>   /* NOTREACHED */
>   }
>   }
> 
> 
> >How-To-Repeat:
> 
> Type "man expand", read.
> 
> Then:
> 
>   $ expand -a somefile
>   expand: unknown option -- a
>   usage: expand [-t tablist] [file ...]
> 
> 
> >Fix:
> 
> The "-a" option is not part of the POSIX spec for this utility,
> and there's no dead code in expand.c that implments it.  I would
> therefore suggest just removing the mentioning of "-a" from expand.1.
> Alternatively, implement the option according to the manual.
> 

hi.

the manual page documents both expand and unexpand. guess which one
support -a ;)

jmc

Re: sftp(1) Received message too long when sshrc sends to stdout

[Jason McIntyre]

On Mon, Oct 16, 2017 at 12:31:00PM +0300, Lars Nood??n wrote:
> Apologies for the non-bug.  I misread the manual page as a combined
> result of skimming visually and use of search with a / which is case
> sensitive.  I found the right section after starting at the beginning
> and reading through in sequence.  I would propose the following
> modification to make searching and skimming easier for sshrc.
> 
> /Lars
> 
> Index: src/usr.bin/ssh/sshd.8
> ===
> RCS file: /cvs/src/usr.bin/ssh/sshd.8,v
> retrieving revision 1.291
> diff -u -p -u -r1.291 sshd.8
> --- src/usr.bin/ssh/sshd.8  24 Jun 2017 06:28:50 -  1.291
> +++ src/usr.bin/ssh/sshd.8  16 Oct 2017 09:22:12 -
> @@ -345,12 +345,15 @@ system password database.
>  .El
>  .Sh SSHRC
>  If the file
> -.Pa ~/.ssh/rc
> +.Pa /etc/ssh/sshrc
>  exists,
>  .Xr sh 1
>  runs it after reading the
>  environment files but before starting the user's shell or command.
> -It must not produce any output on stdout; stderr must be used
> +Otherwise, if the file
> +.Pa ~/.ssh/rc
> +exists, it will be run instead.
> +Neither may produce any output on stdout; stderr must be used
>  instead.
>  If X11 forwarding is in use, it will receive the "proto cookie" pair in
>  its standard input (and
> 

hi.

both LOGIN PROCESS and SSHRC document that first ~/ssh/rc gets read.
if that file does not exist it tries to read /etc/ssh/sshrc.

i imagine that is correct (and your diff is wrong).

jmc

Re: ksh.1: two typos

[Jason McIntyre]

On Fri, Aug 18, 2017 at 05:32:21PM -0500, Scott Cheloha wrote:
> > On Aug 18, 2017, at 1:18 AM, Jason McIntyre <j...@kerhand.co.uk> wrote:
> > 
> > [...]
> > 
> >> --
> >> Scott Cheloha
> >> 
> >> Index: bin/ksh/ksh.1
> >> ===
> >> RCS file: /cvs/src/bin/ksh/ksh.1,v
> >> retrieving revision 1.192
> >> diff -u -p -r1.192 ksh.1
> >> --- bin/ksh/ksh.1  11 Aug 2017 23:10:55 -  1.192
> >> +++ bin/ksh/ksh.1  18 Aug 2017 00:19:35 -
> >> @@ -1614,16 +1614,15 @@ in
> >> .Ev PS1 .
> >> .It Li \e#
> >> The current command number.
> >> -This could be different to the current history number,
> >> -if
> >> +This may differ from the current history number if
> > 
> > what's there now is ok, and what you propose is ok. so the difference is
> > really taste. in cases like that, i don;t think changing the text is
> > worth it, unless you can see a clear improvement.
> > 
> > as to your point about to -> from, "different to" is in use. my
> > student dictonary notes that "In British English, people sometimes say
> > that one thing is different to another. Some people consider this use to
> > be incorrect". but then the reverse is seemingly true of "different
> > than".
> > 
> > i would just leave it.
> 
> Alrighty.
> 
> >> .Ev HISTFILE
> >> contains a history list from a previous session.
> >> .It Li \e$
> >> -The default prompt i.e.\&
> >> -.Sq # \&
> >> +The default prompt character i.e.\&
> >> +.Sq #\&
> >> if the effective UID is 0,
> >> otherwise
> >> -.Sq $ \& .
> >> +.Sq $\& .
> >> Since the shell interprets
> >> .Sq $
> >> as a special character within double quotes,
> >> 
> > 
> > i haven;t tested the space issue, but if it's correct i guess it needs
> > fixing. however in that case the "\&" escaping is not needed.
> 
> 
> Here's a tweaked diff:
> 

committed, thanks.
jmc

> Index: bin/ksh/ksh.1
> ===
> RCS file: /cvs/src/bin/ksh/ksh.1,v
> retrieving revision 1.192
> diff -u -p -r1.192 ksh.1
> --- bin/ksh/ksh.1 11 Aug 2017 23:10:55 -  1.192
> +++ bin/ksh/ksh.1 18 Aug 2017 22:31:13 -
> @@ -1619,11 +1619,11 @@ if
>  .Ev HISTFILE
>  contains a history list from a previous session.
>  .It Li \e$
> -The default prompt i.e.\&
> -.Sq # \&
> +The default prompt character i.e.\&
> +.Sq #
>  if the effective UID is 0,
>  otherwise
> -.Sq $ \& .
> +.Sq $ .
>  Since the shell interprets
>  .Sq $
>  as a special character within double quotes,
> 

Re: mandoc -Tlint and Mdocdate

[Jason McIntyre]

On Fri, Jun 23, 2017 at 07:24:31PM +0200, Ingo Schwarze wrote:
> Hi Jason,
> 
> Jason McIntyre wrote on Thu, Jun 22, 2017 at 07:31:49AM +0100:
> > On Thu, Jun 22, 2017 at 01:18:05AM +0200, Ingo Schwarze wrote:
> >> Jason McIntyre wrote on Wed, Jun 21, 2017 at 11:10:55PM +0100:
> 
> >>> i'm not entirely convinced... are there likely to be other style
> >>> warnings that apply to our base manuals but not "portable"?
> >>> if there's a list of things then maybe it makes sense.
> 
> >> Quite likely in the future:
> >> [ ... 4 examples deleted ... ]
> 
> > fair enough then, if you think it's worth doing.
> > but aren't you worried that you're gonna end up with all
> > operating systems/interested parties wanting their own flags?
> 
> Not worried, no.  I'm not expecting that many, a handful at most,
> and even a dozen would be less of a maintenance burden than many
> of the switch/case features contained in the mdoc(7) language itself.
> 
>  - illumos, definitely.
>  - FreeBSD, maybe.  I have no indication yet that they may want
>to use the feature, but it would fit their culture.
>  - Debian, possibly.  If there is something that they can tweak,
>they usually tweak it.  If there is not, they tweak it anyway.
>But i guess it will take several years before they find out.
>They don't move all that fast, you know.
> 
>  - Alpine, Void, Arch, Slackware, Crux Linux:
>Very unlikely.  They tend to refrain from customization, and
>from creatung unnecessary maintenance workload for themselves,
>whenever they can.
> 
>  - DragonFly, Minix, MacOS X:
>Very unlikely.  These projects look like abandonware to me.
> 
> No other project is actively using mandoc at this point.
> It also runs on IBM AIX and Oracle Solaris, and there are many
> unofficial, outdated ports for major Linux distros, but none of
> these will request their own -Tlint customizations.
> 
> Yours,
>   Ingo
> 

evening.

thanks for answering my questions. so i have no objections.

jmc

Re: mandoc -Tlint and Mdocdate

[Jason McIntyre]

On Thu, Jun 22, 2017 at 01:18:05AM +0200, Ingo Schwarze wrote:
> Hi Jason,
> 
> Jason McIntyre wrote on Wed, Jun 21, 2017 at 11:10:55PM +0100:
> > On Wed, Jun 21, 2017 at 05:22:12PM +0200, Ingo Schwarze wrote:
> 
> >> As there is no fully satisfactory option, i propose the patch below.
> >> It add the "-W portable" command line option, which is a variant of
> >> "-W style" hiding messages that only apply to base system manuals.
> 
> > i'm not entirely convinced... are there likely to be other style
> > warnings that apply to our base manuals but not "portable"?
> > if there's a list of things then maybe it makes sense.
> 
> Quite likely in the future:
> 
>  - In base, we only want sections 1-9 and 3p.
>In third-party software, sections like "n" (for TCL)
>or "3f" (for Fortran) may be legitimate.
> 
>  - In base, we have a fixed list of architectures that we want
>to check the third .Dt argument against.
>In portable software, architectures that do not exist in OpenBSD
>may be legitimate.
> 
>  - In base, we probably want to warn about standard .Sh sections
>that we don't use in OpenBSD (like LIBRARY).
>In portable software, a LIBRARY section may be legitimate, if
>the software is also targetting systems like FreeBSD, NetBSD,
>or Linux where that section is in widespread use (and actually
>somewhat useful because they either have such a vast swamp of
>libraries in base, or no clear distinction between base and
>ports at all).
> 
>  - In base, we always want to warn in case the .Os macro has any
>argument whatsoever.
>In portable software, an .Os argument may be deliberate.
> 

fair enough then, if you think it's worth doing. but aren't you worried that
you're gonna end up with all operating systems/interested parties wanting
their own flags?

jmc

Re: mandoc -Tlint and Mdocdate

[Jason McIntyre]

On Wed, Jun 21, 2017 at 05:22:12PM +0200, Ingo Schwarze wrote:
> Hi Sebastien and Jeremie,
> 
> Sebastien Marie wrote on Wed, Jun 21, 2017 at 12:26:14PM +0200:
> > On Wed, Jun 21, 2017 at 11:39:53AM +0200, Jeremie Courreges-Anglas wrote:
> >> Sebastien Marie  writes:
> 
> >>> But mandoc -Tlint complains about missing Mdocdate.
> >>> $ mandoc -Tlint sysclean.8
> >>> mandoc: sysclean.8:17:5: STYLE: Mdocdate missing: Dd June
> 
> >> With another project, I get this warning about Dd, plus a message
> >> about a missing RCS Id.
> 
> > ah, I don't have this one. But after checking, my man page has a
> > $OpenBSD$ tag inside it... it should come from the mdoc.template I
> > used to start writing the file. :)
> > If I remove it, I have the same STYLE warning.
> 
> You currently have the following options:
> 
>  1. Ignore the two style messages.
> As jmc@ rightly observed, and as the mandoc(1) manual says
> below DIAGNOSTICS, a style recommendation is not an error,
> and style messages are occasionally false positives.
> Both of these messages occur at most once per page.
> 
> Of course, having to ignore a message is not fully satisfactory,
> and keeping false positives down to a minimum *is* among my
> goals, even for style recommendations.
> 
>  2. Put a dummy .\" $OpenBSD$ line and a manually maintained
> .Dd $Mdocdate Month day year$ line into the file even though
> your VCS won't expand it.
> 
> That is icky, working around an issue in a non-intuitive way
> instead of solving the root cause, so i can't really recommend it.
> 
>  3. Use "mandoc -Ios= -Tlint" for checking pages that are supposed
> to be portable.
> 
> That is not fully satisfactory because it disables *all* operating
> system specific style messages.  It is likely that you do want to
> follow OpenBSD style in general, just not those parts that apply
> to the base system only.
> 
>  4. Put something like ".Os ratpoison" into the manual page.
> 
> I clearly recommend against that.  It not only suppers from
> the same problem as option 3 of disabling more than intended;
> it also results in an inconsistent user experience with the
> bottom line of manual pages (admittedly a minor point, though).
> 
>  5. Use "mandoc -Tlint -Wwarning" for these projects.
> 
> I clearly recommend against that.  It disables even more than
> option 3, namely, all style recommendations, most of which are
> just as useful for portable projects as for base system manuals.
> 
> As there is no fully satisfactory option, i propose the patch below.
> It add the "-W portable" command line option, which is a variant of
> "-W style" hiding messages that only apply to base system manuals.
> 

evening.

i'm not entirely convinced... are there likely to be other style
warnings that apply to our base manuals but not "portable"? if there's a
list of things then maybe it makes sense.

otherwise i wonder if we can;t try and make things clearer (style
warning is not a mistake) and leave things for a bit longer to see
whether STYLE by default is too much.

jmc

> In general, i don't like adding knobs.  But when the choice is
> between having innocent people harassed with false positives and
> between providing a knob for saying which checks you want, in a way
> that is actually needed in practice, then i prefer the knob to the
> harassment.
> 
> OK for the patch below?
> 
> > According to mandoc man page, -Wwarning will avoid all styles warning.
> > Here the complete list (taken from mandoc.h):
> 
> The list of messages is also in the mandoc(1) manual, with an
> explanation of each message.
> 
> Yours,
>   Ingo
> 
> 
> Index: main.c
> ===
> RCS file: /cvs/src/usr.bin/mandoc/main.c,v
> retrieving revision 1.195
> diff -u -p -r1.195 main.c
> --- main.c3 Jun 2017 12:16:19 -   1.195
> +++ main.c21 Jun 2017 15:09:46 -
> @@ -68,8 +68,8 @@ enumoutt {
>  
>  struct   curparse {
>   struct mparse*mp;
> - enum mandoclevel  wlevel;   /* ignore messages below this */
>   int   wstop;/* stop after a file with a warning */
> + enum mandocerrmmin; /* ignore messages below this */
>   enum outt outtype;  /* which output to use */
>   void *outdata;  /* data for output */
>   struct manoutput *outopts;  /* output options */
> @@ -159,7 +159,7 @@ main(int argc, char *argv[])
>  
>   memset(, 0, sizeof(struct curparse));
>   curp.outtype = OUTT_LOCALE;
> - curp.wlevel  = MANDOCLEVEL_BADARG;
> + curp.mmin = MANDOCERR_MAX;
>   curp.outopts = 
>   options = MPARSE_SO | MPARSE_UTF8 | MPARSE_LATIN1;
>   defos = NULL;
> @@ -416,7 +416,7 @@ main(int argc, char *argv[])
>   moptions(, auxpaths);
>  
>   mchars_alloc();
> - curp.mp = mparse_alloc(options, 

Re: mandoc -Tlint and Mdocdate

[Jason McIntyre]

On Wed, Jun 21, 2017 at 09:04:19AM +0200, Sebastien Marie wrote:
> Hi,
> 
> With latest commits on mandoc (particulary mdoc_validate.c r1.252), I
> have a problem with mandoc -Tlint regarding Dd macro.
> 
> Some days ago, I started to validate the man page of sysclean using
> mandoc -Tlint.
> 
> sysclean is a tool designed for OpenBSD, and maintained externally in a
> git repository.
> 
> The current preambule for sysclean.8 (in master) is :
> 
> .Dd June 18, 2017
> .Dt SYSCLEAN 8
> .Os
> 

morning.

presumably because you have a blank Os field, mandoc will look
elesewhere and is concluding that this is openbsd. maybe you can use a
dummy value, but wait for ingo's reply, as he will better know the
criteria for Os matching, and what a good way to do this is.

note that this is just flagging this as "STYLE": the old style Dd does
work (hence just ignoring the message may be the best choice). but it's
not "not respecting the specification".

jmc

> According to mdoc(7), there are valids:
> 
>Document preamble and NAME section macros
>  Dd   document date: $Mdocdate$ | month day, year
>  Dt   document title: TITLE section [arch]
>  Os   operating system version: [system [version]]
> 
> But mandoc -Tlint complains about missing Mdocdate.
> 
> $ mandoc -Tlint sysclean.8
> mandoc: sysclean.8:17:5: STYLE: Mdocdate missing: Dd June
> 
> The current check requires Dd to be in "Mdocdate" format if the Os is
> OpenBSD. It seems to me it doesn't respect the specification, which
> allow Dd to be a plain date (month day, year).
> 
> Due to the fact I am not using CVS for this project, I couldn't use
> $Mdocdate$ keyword (and have the date isn't automatically filled).
> 
> Alternatively, I could maintain manually Dd as "$Mdocdate: month day year $",
> but it seems a limitation for me, so I prefer reported it.
> 
> Thanks.
> -- 
> Sebastien Marie
> 

Re: pledge.2: missed rename: request -> promises

[Jason McIntyre]

On Sun, Jun 11, 2017 at 11:00:11AM -0500, Scott Cheloha wrote:
> Hi,
> 
> The pledge(2) "request" parameter is now called "promises".
> 
> --
> Scott Cheloha
> 

fixed, thanks.
jmc

> Index: lib/libc/sys/pledge.2
> ===
> RCS file: /cvs/src/lib/libc/sys/pledge.2,v
> retrieving revision 1.43
> diff -u -p -r1.43 pledge.2
> --- lib/libc/sys/pledge.2   7 Jun 2017 20:53:59 -   1.43
> +++ lib/libc/sys/pledge.2   11 Jun 2017 15:32:33 -
> @@ -573,7 +573,7 @@ or one of its elements, or
>  .Fa promises
>  points outside the process's allocated address space.
>  .It Bq Er EINVAL
> -.Ar request
> +.Ar promises
>  is malformed or contains invalid keywords.
>  .It Bq Er ENAMETOOLONG
>  An element of
> 

Re: usb(4) man page in curret: Please add "/RTL8153 ... /Gigabit" to the ure(4) entry.

[Jason McIntyre]

On Wed, Mar 22, 2017 at 06:00:09AM +, Tinker wrote:
> The ure(4) man page in current ( http://man.openbsd.org/ure.4 ) says that
> its for the "RealTek RTL8152/RTL8153 10/100/Gigabit USB Ethernet device".
> 
> The usb(4) man page in current ( http://man.openbsd.org/usb.4 ) says
> "RealTek RTL8152 10/100 USB Ethernet device" however.
> 
> This must be a tiny glitch as ure(4) in 6.0 only supported 100mbps,
> http://man.openbsd.org/OpenBSD-6.0/ure.4 .
> 
> Please add "/RTL8153 ... /Gigabit" to the ure(4) entry in the usb(4) man
> page.
> 

fixed, thanks.
jmc

Re: Seeming inconsistencies regarding ulimit between getrlimit(2), sh(1), POSIX.1-2008

[Jason McIntyre]

On Wed, Mar 15, 2017 at 06:46:54PM -0500, Scott Cheloha wrote:
> Hi,
> 
> getrlimit(2) says:
> 
> > Because this information is stored in the per-process information, this
> > system call must be executed directly by the shell if it is to affect all
> > future processes created by the shell; limit is thus a built-in command
> > to csh(1) and ulimit is the sh(1) equivalent.
> 
> sh(1) hasn't mentioned ulimit since jmc@ rewrote it for revision
> 1.101.
> 
> POSIX.1-2008 says ulimit is an XSI option here:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ulimit.html
> 
> sh(1) talks about how it is mostly POSIX.1-2008 compliant in its
> STANDARDS section.  You can use ulimit from /bin/sh, with or without
> POSIX mode.
> 
> ksh(1) defines ulimit in all its splendor, with its considerable
> capabilities (relative to the POSIX.1-2008 spec), but does not
> mention anything about POSIX, XSI, etc.
> 
> I think the simplest correction is to just change getrlimit(2)
> to say "ksh" instead of "sh" (trivial patch below), so that the
> documentation in the system itself is consistent... but elsewhere
> in the manpages XSI extensions are marked and such, so I don't
> know what else, if anything, should be changed.
> 
> Something just seems off, hence bugs@.
> 
> Thoughts?
> 

the confusion is that there's obviously been an update to posix (that i
didn;t know about) since i wrote sh(1). you are quoting from the 2016
edition, and sh(1) was based on the 2013 edition. from a quick scan, the
builtins hash, type, and unalias have all been added to the builtins.

so the fix is i have to update sh(1). and maybe some other man pages.
thanks for the mail,

jmc

> --
> Scott Cheloha
> 
> Index: getrlimit.2
> ===
> RCS file: /cvs/src/lib/libc/sys/getrlimit.2,v
> retrieving revision 1.27
> diff -u -p -r1.27 getrlimit.2
> --- getrlimit.2 7 Oct 2016 15:48:55 -   1.27
> +++ getrlimit.2 15 Mar 2017 23:00:25 -
> @@ -148,7 +148,7 @@ is thus a built-in command to
>  and
>  .Ic ulimit
>  is the
> -.Xr sh 1
> +.Xr ksh 1
>  equivalent.
>  .Pp
>  The system refuses to extend the data or stack space when the limits
> @@ -206,7 +206,7 @@ and the caller is not the superuser.
>  .El
>  .Sh SEE ALSO
>  .Xr csh 1 ,
> -.Xr sh 1 ,
> +.Xr ksh 1 ,
>  .Xr quotactl 2 ,
>  .Xr sigaction 2 ,
>  .Xr sigaltstack 2 ,

Re: mount(2) man page missing Dv for MNT_WXALLOWED

[Jason McIntyre]

On Mon, Feb 27, 2017 at 05:07:13PM +0100, Bruno Flueckiger wrote:
> Hi,
> 
> I've read the man page mount(2) in Firefox today. The formating
> of MNT_WXALLOWED looks different than the formatting of the other
> flags. This is only visible in a graphical browswer, on my terminal I
> cannot see any difference.
> 
> The patch below adds Dv to .It, making it look the same as the other
> flags.
> 
> Cheers,
> Bruno
> 

fixed, thanks.
jmc

> 
> Index: lib/libc/sys/mount.2
> ===
> RCS file: /cvs/src/lib/libc/sys/mount.2,v
> retrieving revision 1.46
> diff -u -p -r1.46 mount.2
> --- lib/libc/sys/mount.2  27 May 2016 19:45:04 -  1.46
> +++ lib/libc/sys/mount.2  27 Feb 2017 15:48:09 -
> @@ -95,7 +95,7 @@ All I/O to the filesystem should be done
>  Use soft dependencies.
>  Applies to FFS filesystems only (see 'softdep' in
>  .Xr mount 8 ) .
> -.It MNT_WXALLOWED
> +.It Dv MNT_WXALLOWED
>  Processes that ask for memory to be made writeable plus executable
>  using the
>  .Xr mmap 2
> 

Re: dhclient(8) man page typo: "is" should be "are"

[Jason McIntyre]

On Fri, Feb 03, 2017 at 03:45:32AM +0800, Tinker wrote:
> Hi,
> 
> http://man.openbsd.org/dhclient.8 says:
> 
> "It does this only when one or both of the options domain-name and
> domain-name-servers is present".
> 
> To the best of my grammar awareness, it should rather be "are present".
> 
> Tinker
> 

fixed, thanks.
jmc

Re: Possible typo in manpage http://man.openbsd.org/OpenBSD-current/man3p/Getopt::Std.3p

[Jason McIntyre]

On Mon, Jan 23, 2017 at 04:57:12PM +0100, Harald Hellmuth wrote:
> Dear Team,
> 
> i wonder if this in Getopt::Std(3p) is a typo:
> 
> Use of "getopts()" is not recommended.
>   ^
> 
> Because the same manpage at perldoc.perl.org states:
> 
>  Use of getopt() is not recommended.
> 
> Sincerly
> 
> Harald Hellmuth
> 

it does look like an error. the perl docs are 3rd party: you should
check whether the latest version has an issue and report it to them.

jmc

Re: wcscpy.3 mentions nonexistent EXAMPLES section in strcpy.3

[Jason McIntyre]

On Fri, Nov 11, 2016 at 09:10:50PM -0600, Scott Cheloha wrote:
> Hi,
> 
> The end of lib/libc/string/wcscpy.3 reads:
> 
>   CAVEATS 
>   Using the functions wcscpy() and wcsncpy() is very error-prone 
> with
>   respect to buffer overflows; see the EXAMPLES section in 
> strcpy(3) for 
>   correct usage. Using wcslcpy(3) is a better choice in most 
> cases.
> 
> But lib/libc/string/strcpy.3 has no EXAMPLES section.
> 
> Seen on OpenBSD 6.0 AMD64 (installed from the CD media), still present in CVS.
> 
> Cheers,
> Scott Cheloha

morning.

a few years ago the strcpy.3 page got split in order to create the
strncpy.3 page. the EXAMPLES section went to that page, so i'm guessing
that's where the reference should lie. it's a tough kind of thing to
check when you make such changes.

diff below. i'll commit it shortly if i don;t hear otherwise.
jmc

Index: wcscpy.3
===
RCS file: /cvs/src/lib/libc/string/wcscpy.3,v
retrieving revision 1.4
diff -u -r1.4 wcscpy.3
--- wcscpy.325 Sep 2013 21:49:31 -  1.4
+++ wcscpy.312 Nov 2016 07:58:15 -
@@ -122,7 +122,7 @@
 .Fn wcsncpy
 is very error-prone with respect to buffer overflows;
 see the EXAMPLES section in
-.Xr strcpy 3
+.Xr strncpy 3
 for correct usage.
 Using
 .Xr wcslcpy 3

Re: documentation incomplete; mount(8) man page; 5.9/6.0

[Jason McIntyre]

On Sat, Aug 27, 2016 at 05:33:19PM +, Manuel Jose Blanca Molinos wrote:
> 
> The mount command supports the options -o ro (for read only) and -o rw (for 
> read write), However this is not indicated in the manual page. In addition, 
> there are currently two examples on the page where the -o rw option appears 
> although there is no reference to this -o option before (this makes this 
> section a bit confusing).I think that would be enough to add in the man page 
> that, -o ro is a synonym for the -r option (and also for -o rdonly) and that 
> -o rw??is a synonym for the -w option.
> 
> Sorry I can not send a patch myself (I'm new to OpenBSD and still need more 
> experience).
> Manuel Blanca
>  
>  

tedu just fixed this, but one more note: we don;t document "rw" because
the list in mount(8) documents the options required to change default
behaviour (note the "no" prefix blurb).

so the default is rw, so the list now (correctly) describes "norw"
rather than "rw".

it is easy to be caught by this, admittedly...

jmc

Re: minor wording in man release.8

[Jason McIntyre]

On Fri, Jul 22, 2016 at 06:45:35PM +0200, Tim Kuijsten wrote:
> Index: release.8
> ===
> RCS file: /cvs/src/share/man/man8/release.8,v
> retrieving revision 1.70
> diff -u -p -r1.70 release.8
> --- release.8   31 Jul 2015 11:30:12 -  1.70
> +++ release.8   22 Jul 2016 16:43:58 -
> @@ -101,7 +101,8 @@ $ cd PORTSPATH && cvs up -r TAG -Pd
>  .Pp
>  Replace
>  .Va XSRCDIR
> -with the path to your X Window System sources.
> +with the path to your X Window System sources, typically
> +.Pa /usr/xenocara .
>  Replace
>  .Va PORTSPATH
>  with the path to your ports tree sources, typically
> 

i think this is reasonable. we do already document it in this file, but
the organisation is not so great. but if we do this, it allows us to
skip a bit of text earlier in the page.

hence i propose the diff below.
jmc

Index: release.8
===
RCS file: /cvs/src/share/man/man8/release.8,v
retrieving revision 1.73
diff -u -r1.73 release.8
--- release.8   26 Jun 2016 15:17:43 -  1.73
+++ release.8   22 Jul 2016 21:24:24 -
@@ -40,13 +40,7 @@
 .Pp
 The following sections describe each of the required steps in detail.
 .Pp
-Commands to be run as a user with write permissions on the source and
-ports trees
-.Pf ( Pa /usr/src
-and
-.Pa /usr/ports
-respectively)
-are preceded by a dollar sign
+Commands to be run as a user are preceded by a dollar sign
 .Pq Sq $ .
 Commands that must be run as the superuser are preceded by a hash mark
 .Pq Sq # .
@@ -101,7 +95,8 @@
 .Pp
 Replace
 .Va XSRCDIR
-with the path to your X Window System sources.
+with the path to your X Window System sources, typically
+.Pa /usr/xenocara .
 Replace
 .Va PORTSPATH
 with the path to your ports tree sources, typically

Re: Patch ssh-keygen manual: -c flag works for keys stored in the new format (-o)

[Jason McIntyre]

On Sat, May 28, 2016 at 10:22:32PM -0400, Yonas Yanfa wrote:
> Hi,
> 
> Keys stored in the new format (-o) can have their comments modified, along
> with RSA1 keys. I've attached a patch to mention this.
> 
> Cheers,
> Yonas
> 

fixed, thanks, though i altered the wording a little.
jmc

Index: ssh-keygen.1
===
RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.1,v
retrieving revision 1.132
diff -u -r1.132 ssh-keygen.1
--- ssh-keygen.13 May 2016 18:38:12 -   1.132
+++ ssh-keygen.116 Jun 2016 06:09:39 -
@@ -207,7 +207,7 @@
 If the passphrase is lost or forgotten, a new key must be generated
 and the corresponding public key copied to other machines.
 .Pp
-For RSA1 keys,
+For RSA1 keys and keys stored in the newer OpenSSH format,
 there is also a comment field in the key file that is only for
 convenience to the user to help identify the key.
 The comment can tell what the key is for, or whatever is useful.
@@ -264,7 +264,8 @@
 Provides a new comment.
 .It Fl c
 Requests changing the comment in the private and public key files.
-This operation is only supported for RSA1 keys.
+This operation is only supported for RSA1 keys and keys stored in the
+newer OpenSSH format.
 The program will prompt for the file containing the private keys, for
 the passphrase if the key has one, and for the new comment.
 .It Fl D Ar pkcs11

Re: Grammar fix for httpd.8

[Jason McIntyre]

On Fri, Jun 10, 2016 at 11:43:18AM +0300, Nick Permyakov wrote:
> Or maybe "Specifying multiple -v options increases the verbosity".
> 

i just went with your diff. note that vmd(8) had exactly the same issue,
so i fixed them both.

jmc

> Index: src/usr.sbin/httpd/httpd.8
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.8,v
> retrieving revision 1.51
> diff -u -p -u -r1.51 httpd.8
> --- src/usr.sbin/httpd/httpd.826 Mar 2015 19:16:57 -1.51
> +++ src/usr.sbin/httpd/httpd.810 Jun 2016 08:34:52 -
> @@ -65,7 +65,7 @@ Check that the configuration is valid, b
> ??Verbose mode.
> ??Multiple
> ??.Fl v
> -options increases the verbosity.
> +options increase the verbosity.
> ??.El
> ??.Sh FILES
> ??.Bl -tag -width "/etc/ssl/private/server.key" -compact

Re: Error in sh man page

[Jason McIntyre]

On Wed, May 04, 2016 at 06:01:10AM +, Andras Farkas wrote:
> In the man page for sh in OpenBSD 5.9 (originally installed as 5.8 and
> then upgraded), in the section COMMAND HISTORY AND COMMAND LINE
> EDITING there is an error.
> 
> The man page mentions [count]b twice.
> The second mention of it should be [count]B
> This is evident not only through actually testing these commands, but
> through comparison with the previous commands listed in the man page.
> 
> Thank you for reading this email!
> 

right. fixed now. many thanks,
jmc

Re: Wrong documentation of chmod(2) wrt. S_ISVTX on non-directories

[Jason McIntyre]

On Wed, Jan 27, 2016 at 08:24:09PM +0100, f...@fuz.su wrote:
> The manual page chmod(2) states about the chmod() system call:
> 
> If mode ISVTX (the sticky bit) is set on a file, it is ignored.
> 
> However, attempting to set S_ISVTX on a plain file, the system call
> fails with EFTYPE unless the user is the super user in which case it
> succeeds in setting the S_ISVTX bit.  The same behaviour occurs on
> FreeBSD.  It is however not documented on OpenBSD.  I consider this
> to be a documentation bug.  Please fix the documentation.
> 
> Yours sincerely,
> Robert Clausecker
> 

freebsd's man page says something pretty similar to what our page says,
though it's more verbose.

i think you should mail us a diff and some info to back it up. or hope
someone more knowledgeable replies to this thread ;)

jmc

Re: Minor text reference error in isakmpd.policy(5)

[Jason McIntyre]

On Mon, Jan 11, 2016 at 01:33:05AM -0800, Julian Hsiao wrote:
> Sorry, found another one:
> 

fixed, thanks.
jmc

> Index: isakmpd.policy.5
> ===
> RCS file: /cvs/src/sbin/isakmpd/isakmpd.policy.5,v
> retrieving revision 1.47
> diff -u -p -r1.47 isakmpd.policy.5
> --- isakmpd.policy.5  8 Jan 2016 07:43:38 -   1.47
> +++ isakmpd.policy.5  11 Jan 2016 09:32:15 -
> @@ -329,7 +329,7 @@ authentication.
> .It ah_key_length, esp_key_length
> The number of key bits to be used by the authentication and encryption
> algorithms respectively (for variable key-size algorithms).
> -.It ah_key_rounds, esp_key length
> +.It ah_key_rounds, esp_key_rounds
> The number of rounds of the authentication and encryption algorithms
> respectively (for variable round algorithms).
> .It ah_life_kbytes, esp_life_kbytes, comp_life_kbytes
> 
> 

Re: Minor text reference error in isakmpd.policy(5)

[Jason McIntyre]

On Thu, Jan 07, 2016 at 08:53:44PM -0800, Julian Hsiao wrote:
> In isakmpd.policy.5, the snippet on line 309 ~ 310
> 
> "[...] see the pfs attribute above [...]"
>  ^
> should be
> 
> "[...] see the pfs attribute below [...]"
>  ^
> 
> since the description for pfs attribute starts at line 415.
> 

fixed, thanks.
jmc

Re: fortune(6) attribute

[Jason McIntyre]

On Mon, Dec 28, 2015 at 12:39:01AM +, Andy Finkel wrote:
> 
> 
> David Coppa  gmail.com> writes:
> 
> > 
> > On Sun, Dec 7, 2014 at 9:47 AM, Jason McIntyre  
> kerhand.co.uk> wrote:
> > > On Sat, Dec 06, 2014 at 09:26:39AM +0001, Jason McIntyre wrote:
> > >> hi! chasing down netbsd pr 49451:
> > >>
> > >>   http://marc.info/?l=netbsd-bugs=14121109930
> > >>
> > >> they've basically added an attribute to the following quote:
> > >>
> > >>   Any sufficiently advanced technology is indistinguishable 
> from a rigged
> > >>   demo.
> > >>   -- Andy Finkel, Commodore-Amiga Inc.
> > >>
> > >> the trouble is when i put it in a search engine i get just as many 
> (more
> > >> maybe) hits for a guy called james klass.
> > >>
> > >> anyone have anything definitive? of course, this may explain why 
> there's
> > >> currently no attribute ;)
> 
> Hi:
> 
> I just happened to see this (I was showing early comp.sys.amiga and was 
> doing searches on my old postings)...
> 
> Anyway, I believe I originated this one around 1987;  that's the 
> earliest Google Groups shows me using it in my .signature file.
> 
> https://groups.google.com/forum/#!search/comp.sys.amiga$20any$20sufficie
> ntly$20advanced$20technology$20is$20indistinguishable$20from$20a$20rigge
> d$20demo/comp.sys.amiga/lNxuoj-TZcc/cEmtR14pjJcJ
> 
> Thanks,
> 
> Andy
> 

i'd forgotten all about this one. just fixed it - thanks for confirming!
jmc

> 
> 
> 
> 
> 
> > >>
> > >
> > > no feedback, so i don;t intend to add any attribute. i did zap the
> > > duplicate entry though.
> > 
> > Well... James Klass (http://en.wikipedia.org/wiki/James_Klass) passed
> > away in 2009.
> > 
> > But Andy Finkel is on Twitter (  aflyingcat) so, maybe, we could 
> talk
> > about this with him in person...
> > 
> > Ciao,
> > David
> > 
> 
> 
> 
> 

Re: /usr.bin/calendar - Picasso was born on Oct 25

[Jason McIntyre]

On Mon, Oct 05, 2015 at 07:04:53AM -0700, Richard wrote:
> Hello,
> 
>   Pablo Picasso was born on October 25 not on October 5.
> 
>   Please change /usr/src/usr.bin/calendar/calendars/calendar.birthday
> 
>   See the FreeBSD bug report:
> 
>   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=116952
> 

fixed, thanks.
jmc

Re: man release still refers to sudo in -current

[Jason McIntyre]

On Thu, Jul 09, 2015 at 07:00:30PM +1200, Peter Kane wrote:
 Hello
 
 Just a note to mention that man release in -current still refers to
 sudo in a number of places.
 
 Peter
 

we decided to leave the references to sudo for now. we'll adjust them
and tidy up the references once there's a replacement.

jmc

Re: Add example to ifconfig(8) for wireless monitor mode

[Jason McIntyre]

On Sun, Feb 01, 2015 at 06:37:28AM +0100, Bradain Foley wrote:
Description:
It would be helpful to add an example of how to put a wireless card
into monitor (rfmon) mode. The man pages for various wireless cards 
   
(such as athn(4), urtwn(4)) mention monitor mode but not how to set 
it.
I scoured ifconfig(8) and device man pages for days without finding 
a hint. Finally I resorted to writing a C program with libpcap to 
turn on monitor mode. Only then did I notice in ifconfig output 
that monitor mode is related to mediaopt.
There is a hint in ifconfig(8) already to look at output from:
# ifconfig interface media 
but it was too oblique for me to appreciate the connection.
Fix:
Here is a patch.
   
   I agree with this idea because searching ifconifg(8) for 'monitor'
   currently yields nothing.
  
   rfmon is a bit of an obscure acronym I think.
   Saying just monitor mode is sufficient.
   
+Refer to the interface's driver-specific man page to see if
+the card supports monitor mode:
   
   The above seems unnecessary. Most drivers support monitor mode. If I'm
   grepping correctly the only ones that don't are atu(4), atw(4), and 
   rsu(4).
   
  
 Thank you Stefan and Jason for the helpful suggestions. 
 An updated patch incorporating feedback. Is this ok?
 

fixed, thanks.
jmc

 --- src/sbin/ifconfig/ifconfig.8.orig Fri Jan 30 04:00:54 2015
 +++ src/sbin/ifconfig/ifconfig.8  Sat Jan 31 19:20:25 2015
 @@ -1565,9 +1565,9 @@
  .Pp
  .Dl # ifconfig gif1 create
  .Pp
 -Scan for wireless networks using bwi0:
 +Put the athn0 wireless interface into monitor mode.
  .Pp
 -.Dl # ifconfig bwi0 scan
 +.Dl # ifconfig athn0 mediaopt monitor
  .Sh DIAGNOSTICS
  Messages indicating the specified interface does not exist, the
  requested address is unknown, or the user is not privileged and
 

Re: Add example to ifconfig(8) for wireless monitor mode

[Jason McIntyre]

On Thu, Jan 29, 2015 at 12:19:26PM +0100, Stefan Sperling wrote:
 On Thu, Jan 29, 2015 at 09:02:52AM +0100, Bradain Foley wrote:
  Synopsis:  Add example to ifconfig(8) for wireless monitor mode
  Category:  documentation
  Environment:
  System  : OpenBSD 5.6
  Details : OpenBSD 5.6 (GENERIC) #310: Fri Aug  8 00:14:24 MDT 2014
   
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
  
  Architecture: OpenBSD.amd64
  Machine : amd64
  Description:
  It would be helpful to add an example of how to put a wireless card
  into monitor (rfmon) mode. The man pages for various wireless cards 
 
  (such as athn(4), urtwn(4)) mention monitor mode but not how to set 
  it.
  I scoured ifconfig(8) and device man pages for days without finding 
  a hint. Finally I resorted to writing a C program with libpcap to 
  turn on monitor mode. Only then did I notice in ifconfig output 
  that monitor mode is related to mediaopt.
  There is a hint in ifconfig(8) already to look at output from:
  # ifconfig interface media 
  but it was too oblique for me to appreciate the connection.
  Fix:
  Here is a patch.
 
 I agree with this idea because searching ifconifg(8) for 'monitor'
 currently yields nothing.
 

well, ifconfig is already a big page. you could argue the text is wrong
if it's missing important detail. still i'm inclined to agree with the
diff because we already have a wireless example in ifconfig(8), how to
scan, which is largely redundant, since the wireless pages also have it.

i propose we swap examples.

  --- src/sbin/ifconfig/ifconfig.8.orig   Fri Jan 30 04:00:54 2015
  +++ src/sbin/ifconfig/ifconfig.8Fri Jan 30 04:47:19 2015
  @@ -1568,6 +1568,12 @@
   Scan for wireless networks using bwi0:
   .Pp
   .Dl # ifconfig bwi0 scan
  +.Pp
  +Put the athn0 wireless interface into monitor (rfmon) mode.
 
 rfmon is a bit of an obscure acronym I think.
 Saying just monitor mode is sufficient.
 
  +Refer to the interface's driver-specific man page to see if
  +the card supports monitor mode:
 
 The above seems unnecessary. Most drivers support monitor mode. If I'm
 grepping correctly the only ones that don't are atu(4), atw(4), and rsu(4).
 
  +.Pp
  +.Dl # ifconfig athn0 mediaopt monitor
   .Sh DIAGNOSTICS
   Messages indicating the specified interface does not exist, the
   requested address is unknown, or the user is not privileged and
 

i totally agree with both points above.

jmc

Re: documentation: ipsec man page reference about manual SAs incorrect

[Jason McIntyre]

On Wed, Jan 28, 2015 at 07:52:58PM -0500, Paul Gorman wrote:
 The OpenBSD 5.6 ipsec man page says:
 
 Further information on manual SA establishment is described in
 ipsecctl(8).
 
 ipsecctl(8) does not mention manual SA establishment. Manual SAs are
 instead covered in ipsec.conf(5).

fixed, thanks.
jmc

Re: documentation error in man page

[Jason McIntyre]

On Tue, Jan 13, 2015 at 11:23:08AM +, Stuart Henderson wrote:
 On 2015/01/13 07:08, Jason McIntyre wrote:
  On Sun, Jan 11, 2015 at 12:13:09AM -0700, Shane Manjarres wrote:
   http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/unbound.conf.5?query=unbound%2econfsec=5
   
   uncounf.conf(5)
   
   
   In Openbsd the default directory for unbound.conf file is 
   /var/unbound/etc/
   
   but in the man page in the example it shows the directory as /etc/unbound/
   
   I believe this to be an error in the documentation.
   
   
   
  
  it does look like the example is geared towards an /etc-based
  configuration. but since unbound is 3rd party, i'm not sure if it's this
  way by accident or that it's troublesome to change.
  
  since it's an example, it may just be that there's no need to change it
  - an example is an example, right?
  
  anyone want to comment?
 
 I think that for OpenBSD manuals, we could probably just get rid of
 that EXAMPLE section, we already provide a default configuration file
 which is directly usable for a local resolver and isn't too complex,
 and the filenames and instructions aren't useful for the way we've
 set it up.
 
 OK?
 

ok by me. your fix has the benefit of removing another issue, which was
the section header is EXAMPLE, not EXAMPLES, and the section is in a
crazy place.

jmc

 Index: doc/unbound.conf.5.in
 ===
 RCS file: /cvs/src/usr.sbin/unbound/doc/unbound.conf.5.in,v
 retrieving revision 1.1.1.7
 diff -u -p -r1.1.1.7 unbound.conf.5.in
 --- doc/unbound.conf.5.in 11 Dec 2014 16:18:03 -  1.1.1.7
 +++ doc/unbound.conf.5.in 13 Jan 2015 11:22:04 -
 @@ -25,42 +25,6 @@ ignored as is whitespace at the beginnin
  The utility 
  \fIunbound\-checkconf\fR(8)
  can be used to check unbound.conf prior to usage.
 -.SH EXAMPLE
 -An example config file is shown below. Copy this to /etc/unbound/unbound.conf
 -and start the server with:
 -.P
 -.nf
 - $ unbound \-c /etc/unbound/unbound.conf 
 -.fi
 -.P
 -Most settings are the defaults. Stop the server with:
 -.P
 -.nf
 - $ kill `cat /etc/unbound/unbound.pid`
 -.fi
 -.P
 -Below is a minimal config file. The source distribution contains an extensive
 -example.conf file with all the options.
 -.P
 -.nf
 -# unbound.conf(5) config file for unbound(8).
 -server:
 - directory: /etc/unbound
 - username: unbound
 - # make sure unbound can access entropy from inside the chroot.
 - # e.g. on linux the use these commands (on BSD, devfs(8) is used):
 - #  mount \-\-bind \-n /dev/random /etc/unbound/dev/random
 - # and  mount \-\-bind \-n /dev/log /etc/unbound/dev/log
 - chroot: /etc/unbound
 - # logfile: /etc/unbound/unbound.log  #uncomment to use logfile.
 - pidfile: /etc/unbound/unbound.pid
 - # verbosity: 1  # uncomment and increase to get more logging.
 - # listen on all interfaces, answer queries from the local subnet.
 - interface: 0.0.0.0
 - interface: ::0
 - access\-control: 10.0.0.0/8 allow
 - access\-control: 2001:DB8::/64 allow
 -.fi
  .SH FILE FORMAT
  There must be whitespace between keywords. Attribute keywords end with a 
 colon ':'. An attribute
  is followed by its containing attributes, or a value.
 

Re: documentation error in man page

[Jason McIntyre]

On Sun, Jan 11, 2015 at 12:13:09AM -0700, Shane Manjarres wrote:
 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/unbound.conf.5?query=unbound%2econfsec=5
 
 uncounf.conf(5)
 
 
 In Openbsd the default directory for unbound.conf file is /var/unbound/etc/
 
 but in the man page in the example it shows the directory as /etc/unbound/
 
 I believe this to be an error in the documentation.
 
 
 

it does look like the example is geared towards an /etc-based
configuration. but since unbound is 3rd party, i'm not sure if it's this
way by accident or that it's troublesome to change.

since it's an example, it may just be that there's no need to change it
- an example is an example, right?

anyone want to comment?

jmc

Re: [PATCH] monopoly game, typo in community chest card

[Jason McIntyre]

On Sun, Dec 28, 2014 at 08:30:20PM +0100, Krzysztof Warzecha wrote:
 Hello,
 
 I think there is typo in community chest card in monopoly game
 (OpenBSD 5.6). The card in question says:
 
 Advance to the nearest Utility.
 If unowned, you may buy it from the bank.
 If owned, throw dice and pay oner a total of ten times
 the amount thrown.
 
 I think it should be pay owner a total of ... instead of  pay oner
 a total of 
 
 English is not my native language and this may just be some kind of
 exotic / rare expression that I've not encoutered yet. If that's the
 case, then sorry for the noise.
 
 
 Typo has been found by Daria Suchecka. I've attached patch.
 
 -- 
 Krzysztof Warzecha

we have monopoly? wow, this system just keeps getting better...
it is a typo, and i've just fixed it.

thanks for the mail,
jmc

 From 2a65ac39debae6ba13cfa4bc2eead5e30f312cf3 Mon Sep 17 00:00:00 2001
 From: Krzysztof Warzecha kwarzec...@gmail.com
 Date: Sun, 28 Dec 2014 19:30:44 +0100
 Subject: [PATCH] monopoly game, typo in community chest card
 
 ---
  games/monop/cards.inp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/games/monop/cards.inp b/games/monop/cards.inp
 index 4b6aa81..32524ee 100644
 --- a/games/monop/cards.inp
 +++ b/games/monop/cards.inp
 @@ -69,7 +69,7 @@ If Railroad is unowned you may buy it from the bank
  MU
  Advance to the nearest Utility.
  If unowned, you may buy it from the bank.
 -If owned, throw dice and pay oner a total of ten times
 +If owned, throw dice and pay owner a total of ten times
  the amount thrown.
  %%
  MB3
 -- 
 2.1.3
 

Re: documentation: daily(8)

[Jason McIntyre]

On Fri, Dec 12, 2014 at 06:50:41PM -0700, flesheno...@gmail.com wrote:
 Synopsis:daily(8) is inaccurate regarding /altroot
 Category:documentation
 Environment:
   System  : OpenBSD 5.6
   Details : OpenBSD 5.6 (GENERIC) #310: Fri Aug  8 00:14:24 MDT 2014

 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 Description:
 Regarding root filesystem backup, the daily(8) man page says The mount
 directory /altroot must exist, ...  This is not accurate.  All the other
 specified requirements are indeed necessary for proper functioning, but
 an /altroot directory is not required.  The backup takes place just fine
 without it.
 How-To-Repeat:
 Configure things as specified, then run 'mv /etc/altroot /etc/altroot.not ;
 sh /etc/daily' and you will see that the backup happens just fine.
 Fix:
 Modify the documentation to be consistent with the script's actual
 functioning, or modify the script to actually require the existence of
 an /altroot directory.
 

/altroot or /etc/altroot?
jmc

fortune(6) attribute

[Jason McIntyre]

hi! chasing down netbsd pr 49451:

http://marc.info/?l=netbsd-bugsm=14121109930

they've basically added an attribute to the following quote:

Any sufficiently advanced technology is indistinguishable from a rigged
demo.
-- Andy Finkel, Commodore-Amiga Inc.

the trouble is when i put it in a search engine i get just as many (more
maybe) hits for a guy called james klass.

anyone have anything definitive? of course, this may explain why there's
currently no attribute ;)

full pr below.

jmc

ps the actual quote is duplicated in fortunes2 too, so i'll kill it from
their once i sort this out.

Number: 49451
Category:   misc
Synopsis:   Add attribution to a quote in 
/cvsroot/src/games/fortune/datfiles/fortunes
Confidential:   no
Severity:   non-critical
Priority:   low
Responsible:misc-bug-people
State:  open
Class:  change-request
Submitter-Id:   net
Arrival-Date:   Fri Dec 05 14:45:00 + 2014
Originator: Ben Gergely
Release:1.56/cvsroot/src/games/fortune/datfiles/fortunes
Organization:
Environment:
NetBSD 7.99.1 macppc
Description:


Any sufficiently advanced technology is indistinguishable from a rigged
demo.

is not attributed to Andy Finkel
How-To-Repeat:
grep -H -A 3 Any sufficiently advanced technology is indistinguishable from a 
rigged src/games/fortune/datfiles/fortunes
Fix:
--- fortunes.orig   2014-12-05 14:17:55.0 +
+++ fortunes2014-12-05 14:19:22.0 +
@@ -1489,6 +1489,7 @@
 %
 Any sufficiently advanced technology is indistinguishable from a rigged
 demo.
+   -- Andy Finkel, Commodore-Amiga Inc.
 %
 Any sufficiently advanced technology is indistinguishable from magic.
-- Arthur C. Clarke

Re: error in man page find(1)

[Jason McIntyre]

On Thu, Dec 04, 2014 at 03:55:08AM -0500, Ted Unangst wrote:
 On Thu, Dec 04, 2014 at 07:40, Jason McIntyre wrote:
  On Thu, Dec 04, 2014 at 12:03:01AM +0100, Ingo Schwarze wrote:
  Hi Ted,
 
  Ted Unangst wrote on Wed, Dec 03, 2014 at 05:41:41PM -0500:
 
   Here's a revised diff against current. It just notes that the
   extension spellings are such.
 
  I'm OK with that, discouraging gratuitiously non-standard syntax
  makes a lot of sense.
 
  
  when find(1) was imported into openbsd (or when openbsd itself was
  imported), it came with the syntax -and and -or. that was in
  1995, some 19 years ago.  beyond that, well you'd be much better
  qualified to tell me the history of it.
  
  so how have you gone from that to gratuitiously non-standard syntax?
  if it has existed for 19 years (and before that), in this context it is
  completely standard syntax.
 
 I'll note that the -a and -o syntax was also supported since the
 initial import. It merely wasn't documented. All we're doing here is
 fixing a bug.
 

the bug is fixed. we're now really discussing whether the man page for
find(1) should sideline -and and -or in favour of -a and -o.

 In this case there is a real standard (as opposed to just
 historic practice) describing the utility.
 
 http://pubs.opengroup.org/onlinepubs/009695399/utilities/find.html
 

really.

  i'll ask again: are we deprecating this syntax to such an extent that we
  are actively asking people not to use it and, if so, why?
 
 I think so. I like the following rules.
 
 1. Prefer the better alternative.
 
 2. When alternatives are equal, prefer the officially standardized
 alternative.
 

right. so our examples use the portable format.

 The BSD syntax under discussion here is certainly traditional, but
 it's also gratuitous. It's not better. It doesn't let me do
 something new and different, like the -print0 extension, that's actually
 useful.
 
 From the perspective of an implementor, I find it very annoying trying
 to deal with all the de facto standards and variations that arise
 when people do not write their code and scripts to conform to the
 standard. This is like all those shell scripts that start with
 #!/bin/bash even though they run under plain sh just fine. I would not
 wish to further inflict that on others.
 

none of that really has any bearing on the man page. it just means you,
tedu, would like people to write portable code.

for people wishing to use find(1) portably, they should read the notes
in STANDARDS and/or the relevant standards, and decide whether to use
non-portable extensions or not. for people who don;t care, they can use
whatever components of find they want.

so i think we should document it normally (i.e. no change required) or we
mark it as deprecated. but not say oh by the way, we support this too. 
and i honestly don;t see the gain in doing that.

jmc

Re: error in man page find(1)

[Jason McIntyre]

On Thu, Dec 04, 2014 at 03:19:41PM +0001, Jason McIntyre wrote:
 On Thu, Dec 04, 2014 at 03:55:08AM -0500, Ted Unangst wrote:
  On Thu, Dec 04, 2014 at 07:40, Jason McIntyre wrote:
   On Thu, Dec 04, 2014 at 12:03:01AM +0100, Ingo Schwarze wrote:
   Hi Ted,
  
   Ted Unangst wrote on Wed, Dec 03, 2014 at 05:41:41PM -0500:
  
Here's a revised diff against current. It just notes that the
extension spellings are such.
  
   I'm OK with that, discouraging gratuitiously non-standard syntax
   makes a lot of sense.
  
   
   when find(1) was imported into openbsd (or when openbsd itself was
   imported), it came with the syntax -and and -or. that was in
   1995, some 19 years ago.  beyond that, well you'd be much better
   qualified to tell me the history of it.
   
   so how have you gone from that to gratuitiously non-standard syntax?
   if it has existed for 19 years (and before that), in this context it is
   completely standard syntax.
  
  I'll note that the -a and -o syntax was also supported since the
  initial import. It merely wasn't documented. All we're doing here is
  fixing a bug.
  
 
 the bug is fixed. we're now really discussing whether the man page for
 find(1) should sideline -and and -or in favour of -a and -o.
 

just for the record, free/net/dragon do not document -a and -o, so maybe
we can pass diffs upstream after deciding what we're doing. freebsd does
mention that -o and -a were implemented as posix compliances, but only
in STANDARDS.

i've no idea really if there is a reference linux page, but the first
one i found online documents both notations, more or less in the way i
have (though they've listed them as separate items, not as one).

jmc