Re: Small diff for 73.html

[Andras Farkas]

Oops!  Thank you for the explanation.

On Thu, Apr 27, 2023 at 3:37 PM Jonathan Gray  wrote:
>
> On Thu, Apr 27, 2023 at 03:24:06PM -0900, Andras Farkas wrote:
> > Small diff for 73.html: fixes incorrect link to amdgpu man page.
>
> amdgpu(4) is the xorg driver, it is intentionally drm.4
>
> >
> > SHA512 (73diff) =
> > b3a2afb78744cddfaa148d1bfcd825af376dc4e168e12116e49f1f16614cdc108f001b8fd592eb884e7fcf6e342da527fb437dba991fc583fbc85ef9f98b85e3
> >
> > Index: 73.html
> > ===
> > RCS file: /cvs/www/73.html,v
> > retrieving revision 1.61
> > diff -u -p -r1.61 73.html
> > --- 73.html 20 Apr 2023 14:17:41 - 1.61
> > +++ 73.html 28 Apr 2023 00:21:04 -
> > @@ -173,7 +173,7 @@ to 7.3.
> >
> >Updated https://man.openbsd.org/drm.4;>drm(4)
> >to Linux 6.1.15
> > -  https://man.openbsd.org/drm.4;>amdgpu(4): Added
> > +  https://man.openbsd.org/amdgpu.4;>amdgpu(4): Added
> >support for Ryzen 7000 "Raphael", Ryzen 7020 series "Mendocino",
> >Ryzen 7045 series "Dragon Range",
> >Radeon RX 7900 XT/XTX "Navi 31",
> >
> > Also attached to avoid potential mangling.
>
>

Small diff for 73.html

[Andras Farkas]

Small diff for 73.html: fixes incorrect link to amdgpu man page.

SHA512 (73diff) =
b3a2afb78744cddfaa148d1bfcd825af376dc4e168e12116e49f1f16614cdc108f001b8fd592eb884e7fcf6e342da527fb437dba991fc583fbc85ef9f98b85e3

Index: 73.html
===
RCS file: /cvs/www/73.html,v
retrieving revision 1.61
diff -u -p -r1.61 73.html
--- 73.html 20 Apr 2023 14:17:41 - 1.61
+++ 73.html 28 Apr 2023 00:21:04 -
@@ -173,7 +173,7 @@ to 7.3.
   
   Updated https://man.openbsd.org/drm.4;>drm(4)
   to Linux 6.1.15
-  https://man.openbsd.org/drm.4;>amdgpu(4): Added
+  https://man.openbsd.org/amdgpu.4;>amdgpu(4): Added
   support for Ryzen 7000 "Raphael", Ryzen 7020 series "Mendocino",
   Ryzen 7045 series "Dragon Range",
   Radeon RX 7900 XT/XTX "Navi 31",

Also attached to avoid potential mangling.


73diff
Description: Binary data

Re: Patch for 71.html

[Andras Farkas]

On Thu, Jul 14, 2022 at 11:53 PM Theo Buehler  wrote:
> > Removes two extraneous ` (backtick) characters.
> > Applies quoting around URLs used as the values of href attributes.
> > (the / (slash) character needs to be quoted in attributes)
>
> Committed, thanks. I don't think the / needs to be quoted, but I took
> that part anyway for consistency with the rest of the page.

Glad to help.

> From 
> https://html.spec.whatwg.org/multipage/introduction.html#intro-early-example
>
>   The attribute value can remain unquoted if it doesn't contain ASCII
>   whitespace or any of " ' ` = < or >.

Oh!  You're right.  HTML5 is more lenient than previous versions.

Patch for 71.html

[Andras Farkas]

This patch does two things to fix
https://www.openbsd.org/71.html

Removes two extraneous ` (backtick) characters.
Applies quoting around URLs used as the values of href attributes.
(the / (slash) character needs to be quoted in attributes)

SHA256 (71htmldiff) =
36290198de8c1232e750eeadc8b0b63237043c39ae891603c0ef85796637fc99


71htmldiff
Description: Binary data

diff to fix invalid HTML on 70.html

[Andras Farkas]

UL elements can't have plain text in them, text needs to be within LI elements.

SHA256 (70htmldiff) =
7838ec828825694efaeb527bd4a08413eb0de1ab39819e08764d076acf6df8ff
Diff attached.


70htmldiff
Description: Binary data

Re: Adding -p to pr(1)

[Andras Farkas]

Ping.
I'm hoping someone can review the diff adding -p to pr(1).

On Fri, Dec 11, 2020 at 9:54 PM Andras Farkas  wrote:
>
> Hi!
>
> After seeing the diff for cat -n earlier today, and just browsing Unix
> stuff on my own, I noticed OpenBSD's pr(1) command has no -p option
> despite pr.1 stating:
> > The pr utility is compliant with the IEEE Std 1003.1-2008 ("POSIX.1") 
> > specification.
> https://man.openbsd.org/pr.1
> This part of the man page was added in this diff:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/pr/pr.1.diff?r1=1.16=1.17
> https://github.com/openbsd/src/commit/7c5a075bb35c9874ed6ed8040f78870dae704a20
> and was never correct.  -p has been a mandatory (it's neither XSI nor
> optional) part of POSIX since 2001.
> It's also not merely a SysVism or POSIXism, as -p exists in Unix 8th
> and 10th editions:
> http://man.cat-v.org/unix_8th/1/pr
> http://man.cat-v.org/unix_10th/1/pr
>
> In case the -p option is not desired, I have a small diff attached
> (no-p.txt) that fixes the man page, and fixes a typo in pr.c
> But I also have a bigger diff (pr-p.txt) adding -p to pr.
> It's inspired by the FreeBSD and NetBSD diffs, but mostly the NetBSD one:
> https://github.com/freebsd/freebsd/commit/cace3f9d081619c267182e7e1c926cafabc283e2
> https://svnweb.freebsd.org/base?view=revision=93481
> https://github.com/NetBSD/src/commit/a19c45064f8d362783a3e36c2820544bc05d644a
> http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/pr/pr.c
>
> I did not touch -f or -F, though those can easily be changed later if desired.
> I also did not touch -n and its numbering limit.
> Implementation note: while POSIX says a "", i.e.
> '\r', should be waited for, FreeBSD, NetBSD, OpenSolaris, and Unix
> 10th edition wait for '\n' and I followed them rather than POSIX.  It
> would be easy to make pr wait for either '\n' or '\r' though.
>
> I don't know whether to add a new date or name to the
> copyright/license text at the top.  A whole new flag was added, but
> it's adapted from another implementation.
> I mostly imitated pr's pre-existing non-style(9) style, except for
> using proper style(9) inside the new prpause() function.
>
> Thanks for reading!

Re: Adding -p to pr(1)

[Andras Farkas]

On Sun, Dec 13, 2020 at 4:44 PM Jason McIntyre  wrote:
> On Sun, Dec 13, 2020 at 04:30:06PM -0500, Andras Farkas wrote:
> > Was the diff I sent adding -p support not good?  Or is -p just
> > something undesired in general?  Just trying to understand and learn
> > from this.
> >
> > > i also took the typo fix for pr.c.
> > Thanks!
> >
>
> hi.
>
> i don't code or use pr myself, so i'm a poor judge of that part of your
> diff. i didn;t hear any feedback about a desire to add it, so i decided
> to fix the man page with the view that it'd be trivial to undo that part
> if at some stage we want pr to have the -p option.
Thanks so much for explaining! :D  That makes sense.

> perhaps other people will comment on those aspects.
Alright.

Re: Adding -p to pr(1)

[Andras Farkas]

On Sun, Dec 13, 2020 at 10:40 AM Jason McIntyre  wrote:
> hi.
>
> it's an oversight on my part - the posix page for pr renders poorly on
> lynx, and -p is difficult to spot. i have added a note to say that -p is
> unsupported. if anyone chooses to add support, we can easily fix it.
I see!
Was the diff I sent adding -p support not good?  Or is -p just
something undesired in general?  Just trying to understand and learn
from this.

> i also took the typo fix for pr.c.
Thanks!

Re: Adding -p to pr(1)

[Andras Farkas]

On Fri, Dec 11, 2020 at 10:23 PM Andras Farkas
 wrote:
> Also, I think the line:
> ttyinf = stdin;
> is almost certainly unnecessary.  But I'd like someone else more
> versed in programming to confirm this.  I don't think ttyinf's value
> of stdin is ever used, as it gets set next to /dev/tty

I now see the purpose of it.  If stdin is already the tty then
/dev/tty doesn't need to be opened (a second time)
My patch needs no modification as for ttyinf then.

Re: Adding -p to pr(1)

[Andras Farkas]

Also, I think the line:
ttyinf = stdin;
is almost certainly unnecessary.  But I'd like someone else more
versed in programming to confirm this.  I don't think ttyinf's value
of stdin is ever used, as it gets set next to /dev/tty

On Fri, Dec 11, 2020 at 9:54 PM Andras Farkas  wrote:
>
> Hi!
>
> After seeing the diff for cat -n earlier today, and just browsing Unix
> stuff on my own, I noticed OpenBSD's pr(1) command has no -p option
> despite pr.1 stating:
> > The pr utility is compliant with the IEEE Std 1003.1-2008 ("POSIX.1") 
> > specification.
> https://man.openbsd.org/pr.1
> This part of the man page was added in this diff:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/pr/pr.1.diff?r1=1.16=1.17
> https://github.com/openbsd/src/commit/7c5a075bb35c9874ed6ed8040f78870dae704a20
> and was never correct.  -p has been a mandatory (it's neither XSI nor
> optional) part of POSIX since 2001.
> It's also not merely a SysVism or POSIXism, as -p exists in Unix 8th
> and 10th editions:
> http://man.cat-v.org/unix_8th/1/pr
> http://man.cat-v.org/unix_10th/1/pr
>
> In case the -p option is not desired, I have a small diff attached
> (no-p.txt) that fixes the man page, and fixes a typo in pr.c
> But I also have a bigger diff (pr-p.txt) adding -p to pr.
> It's inspired by the FreeBSD and NetBSD diffs, but mostly the NetBSD one:
> https://github.com/freebsd/freebsd/commit/cace3f9d081619c267182e7e1c926cafabc283e2
> https://svnweb.freebsd.org/base?view=revision=93481
> https://github.com/NetBSD/src/commit/a19c45064f8d362783a3e36c2820544bc05d644a
> http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/pr/pr.c
>
> I did not touch -f or -F, though those can easily be changed later if desired.
> I also did not touch -n and its numbering limit.
> Implementation note: while POSIX says a "", i.e.
> '\r', should be waited for, FreeBSD, NetBSD, OpenSolaris, and Unix
> 10th edition wait for '\n' and I followed them rather than POSIX.  It
> would be easy to make pr wait for either '\n' or '\r' though.
>
> I don't know whether to add a new date or name to the
> copyright/license text at the top.  A whole new flag was added, but
> it's adapted from another implementation.
> I mostly imitated pr's pre-existing non-style(9) style, except for
> using proper style(9) inside the new prpause() function.
>
> Thanks for reading!

Adding -p to pr(1)

[Andras Farkas]

Hi!

After seeing the diff for cat -n earlier today, and just browsing Unix
stuff on my own, I noticed OpenBSD's pr(1) command has no -p option
despite pr.1 stating:
> The pr utility is compliant with the IEEE Std 1003.1-2008 ("POSIX.1") 
> specification.
https://man.openbsd.org/pr.1
This part of the man page was added in this diff:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/pr/pr.1.diff?r1=1.16=1.17
https://github.com/openbsd/src/commit/7c5a075bb35c9874ed6ed8040f78870dae704a20
and was never correct.  -p has been a mandatory (it's neither XSI nor
optional) part of POSIX since 2001.
It's also not merely a SysVism or POSIXism, as -p exists in Unix 8th
and 10th editions:
http://man.cat-v.org/unix_8th/1/pr
http://man.cat-v.org/unix_10th/1/pr

In case the -p option is not desired, I have a small diff attached
(no-p.txt) that fixes the man page, and fixes a typo in pr.c
But I also have a bigger diff (pr-p.txt) adding -p to pr.
It's inspired by the FreeBSD and NetBSD diffs, but mostly the NetBSD one:
https://github.com/freebsd/freebsd/commit/cace3f9d081619c267182e7e1c926cafabc283e2
https://svnweb.freebsd.org/base?view=revision=93481
https://github.com/NetBSD/src/commit/a19c45064f8d362783a3e36c2820544bc05d644a
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/pr/pr.c

I did not touch -f or -F, though those can easily be changed later if desired.
I also did not touch -n and its numbering limit.
Implementation note: while POSIX says a "", i.e.
'\r', should be waited for, FreeBSD, NetBSD, OpenSolaris, and Unix
10th edition wait for '\n' and I followed them rather than POSIX.  It
would be easy to make pr wait for either '\n' or '\r' though.

I don't know whether to add a new date or name to the
copyright/license text at the top.  A whole new flag was added, but
it's adapted from another implementation.
I mostly imitated pr's pre-existing non-style(9) style, except for
using proper style(9) inside the new prpause() function.

Thanks for reading!
Index: pr.1
===
RCS file: /cvs/src/usr.bin/pr/pr.1,v
retrieving revision 1.27
diff -u -p -r1.27 pr.1
--- pr.14 Jun 2014 07:57:27 -   1.27
+++ pr.111 Dec 2020 23:33:33 -
@@ -310,12 +310,6 @@ operand is
 .Xr more 1 ,
 .Xr ascii 7
 .Sh STANDARDS
-The
-.Nm
-utility is compliant with the
-.St -p1003.1-2008
-specification.
-.Pp
 The flag
 .Op Fl f
 is marked by
Index: pr.c
===
RCS file: /cvs/src/usr.bin/pr/pr.c,v
retrieving revision 1.43
diff -u -p -r1.43 pr.c
--- pr.c22 Jan 2020 07:52:37 -  1.43
+++ pr.c11 Dec 2020 23:33:33 -
@@ -64,7 +64,7 @@
  * pr: more boundary conditions than a four-legged porcupine
  *
  * the original version didn't support form-feeds, while many of the ad-hoc
- * pr implementations out there do.  Addding this and making it work reasonably
+ * pr implementations out there do.  Adding this and making it work reasonably
  * in all four output modes required quite a bit of hacking and a few minor
  * bugs were noted and fixed in the process.  Some implementations have this
  * as the as -f, some as -F so we accept either.
Index: extern.h
===
RCS file: /cvs/src/usr.bin/pr/extern.h,v
retrieving revision 1.6
diff -u -p -r1.6 extern.h
--- extern.h19 Jan 2015 15:30:52 -  1.6
+++ extern.h12 Dec 2020 02:42:34 -
@@ -50,6 +50,7 @@ intonecol(int, char **);
 int otln(char *, int, int *, int *, int);
 voidpfail(void);
 int prhead(char *, char *, int);
+voidprpause(int);
 int prtail(int, int);
 int setup(int, char **);
 voidterminate(int);
Index: pr.1
===
RCS file: /cvs/src/usr.bin/pr/pr.1,v
retrieving revision 1.27
diff -u -p -r1.27 pr.1
--- pr.14 Jun 2014 07:57:27 -   1.27
+++ pr.112 Dec 2020 02:42:34 -
@@ -33,7 +33,7 @@
 .\"
 .\" from: @(#)pr.1 8.1 (Berkeley) 6/6/93
 .\"
-.Dd $Mdocdate: June 4 2014 $
+.Dd $Mdocdate: December 11 2020 $
 .Dt PR 1
 .Os
 .Sh NAME
@@ -43,7 +43,7 @@
 .Nm pr
 .Op Cm + Ns Ar page
 .Op Fl Ar column
-.Op Fl adFfmrt
+.Op Fl adFfmprt
 .Op Fl e Ns Oo Ar char Oc Ns Op Ar gap
 .Op Fl h Ar header
 .Op Fl i Ns Oo Ar char Oc Ns Op Ar gap
@@ -256,6 +256,9 @@ If the
 .Fl o
 option is not specified, the default is zero.
 The space taken is in addition to the output line width.
+.It Fl p
+Pause before beginning each page if the standard output is a terminal, ring 
the bell, and wait for a newline on
+.Pa /dev/tty
 .It Fl r
 Write no diagnostic reports on failure to open a file.
 .It Fl s Ns Op Ar char
Index: pr.c
===
RCS file: /cvs/src/usr.bin/pr/pr.c,v
retrieving revision 1.43
diff -u -p -r1.43 pr.c
--- pr.c22 Jan 2020 07:52:37 -  1.43
+++ pr.c12 Dec 2020 02:42:34 -
@@ 

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

[Andras Farkas]

Hello!

While reading 68.html I noticed some of the man page links pointed to
the man pages in the wrong section of the manual. (at least, given the
manual section numbers listed next to them in the 68.html text)
I decided to fix these.

While there, I also made the fixed links point at 6.8 man pages rather
than -current man pages.  This is important in case functionality
mentioned in 68.html is changed or removed in a later version of
OpenBSD.
I also turned two mentions of bettertls.com into hyperlinks.

Diff attached:
SHA256 (68diff) =
d16eb33d863866b004d75041e42c24100dd4200864a5b2243913f98ad5d8eaa9

Also, some links on 68.html (like amlpwrc and sftp-client) ended up
linking to blank, missing man page webpages.  I didn't touch those.
But the links should probably be removed or fixed, as they don't have
man pages on OpenBSD itself either.
Also, if this diff is accepted, I'll send in another one, after,
fixing issues noticed by
https://validator.w3.org/nu/
There was also a mention of sshd(1) that should probably be ssh(1) but
I wasn't sure.  Please check.

Thanks. :3


68diff
Description: Binary data

vi.beginner diff and analysis (vi.advanced to follow)

[Andras Farkas]

I went through vi.beginner.  It works both with vi's regular settings,
and with the settings applied via EXINIT in vi.tut.csh.
I have a diff attached.  I was mostly light and gentle with my
changes, but I indeed did change some outdated info and incorrect
info.

I seriously doubt vi.tut.csh's usefulness, but I'll ultimately judge
it after going through vi.advanced.  I'll reply to my own email with a
vi.advanced diff when I go through it. (not tonight, but some night
soon)


Notably, I wasn't able to attach my diff in Firefox on the OpenBSD
snapshot I used.  Neither could Firefox use the normal file: URL type.
(I had to scp my diff to another machine to attach it to this email)
Index: vi.beginner
===
RCS file: /cvs/src/usr.bin/vi/docs/tutorial/vi.beginner,v
retrieving revision 1.2
diff -u -p -r1.2 vi.beginner
--- vi.beginner	8 Nov 2003 19:17:29 -	1.2
+++ vi.beginner	24 May 2020 05:03:29 -
@@ -174,19 +174,19 @@ look at any line in the file we like.  U
 followed by a character used in an {m} command, we can return to any location
 in the file we have marked.
 
-However, try {m3}, or {mM}.  You should hear a beep, or bell.  Only lower-case
-letters are acceptable to the {m} and {'} commands: numbers, upper-case
-letters, and special characters are not acceptable.
-
-If you type the {'} command with a character that is lower-case alphabetic but
-that has not been used in an {m} command, or for which the 'marked' text has
-been deleted, you will also get a beep.  Try {'i}.  You should get a beep
-because the command {mi} has never been issued.  (Unless you've been
-experimenting.)
+Try {m3}, {mM}, or {m$}.  Not only lower-case letters are acceptable to the
+{m} and {'} commands: numbers, upper-case letters, and special characters are
+also acceptable.
+
+If you type the {'} command with a character that that has not been used in an
+{m} command, or for which the 'marked' text has been deleted, you will get a
+beep.  Try {'i}.  You should get a beep because the command {mi} has never
+been issued.  (Unless you've been experimenting.)
 
 The command {''} attempts to return you to the location at which you last
 modified some part of your file.  However, my experience has been that it is
 difficult to predict exactly where you will end up.  
+
 Section 10: {^M} {-}
 Now do {ma}, marking your position at the top of the screen.  Now hit {^M} (or
 return) until the cursor is right ... 
@@ -235,12 +235,12 @@ The {-} command moves the cursor to the 
 {-}, which attempts to move the cursor to the previous line in this file.
 However, that line is not on the screen.  The resulting action will depend on
 your terminal.  (Do a {^Mz^M} to reposition the file).  On intelligent
-terminals (e.g. VT100s, Z19s, Concept 100s), a top line is 'scrolled on' and
-the bottom line is 'scrolled off'.  Other terminals, however, may not have
-this 'reverse scrolling' feature.  They will simply repaint the screen with
-the cursor line in the middle of the screen.  On such terminals it is
-necessary to type {z^M} to get the cursor line back to the top of the screen.
-
+terminals (e.g. VT100s, xterm, most modern terminals), a top line is 'scrolled
+on' and the bottom line is 'scrolled off'.  Some very old terminals, however,
+may not have this 'reverse scrolling' feature.  They will simply repaint the
+screen with the cursor line in the middle of the screen.  On such terminals it
+is necessary to type {z^M} to get the cursor line back to the top of the
+screen.
 
 
 
@@ -358,13 +358,13 @@ sequence shown):
 
 The first command looks for the next occurrence of the string 'Here 2'.
 However the second line of commands looks for an occurrence of 'Here 2' that
-is at the beginning of the line.  When the up-arrow is the first character of
-a search string it stands for the beginning of the line.  When the dollar-sign
-is the last character of the search string it stands for the end of the line.
-Therefore, the third line of commands searches for the string only when it is
-at the end of the line.  Since there is only one place the string begins a
-line, and only one place the string ends the line, subsequent {//^M} and
-{??^M} will find those same strings over and over.
+is at the beginning of the line.  When the caret (circumflex, up-arrow) is the
+first character of a search string it stands for the beginning of the line.
+When the dollar-sign is the last character of the search string it stands for
+the end of the line.  Therefore, the third line of commands searches for the
+string only when it is at the end of the line.  Since there is only one place
+the string begins a line, and only one place the string ends the line,
+subsequent {//^M} and {??^M} will find those same strings over and over.
 
 The {n} command will find the next occurrence of the / or ? search
 string.  Try {/Here 2/^M} followed by several {n} and observe the
@@ -380,7 +380,7 @@ the screen.  Remember 

httpd diff (fixes single instance of XHTML-style element)

[Andras Farkas]

Hello!
Today I noticed, when looking at an autoindex page on my own website,
that despite the page being HTML (as evidenced by  being used
rather than  further down, and also by the page being served as
text/html) there was a single instance of an XHTML-style element:

Notice the second to last character, the slash.  This makes the META
element here invalid HTML.
This simple attached patch fixes this.
Thanks. :D
Index: server_file.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_file.c,v
retrieving revision 1.67
diff -u -p -r1.67 server_file.c
--- server_file.c   18 May 2020 14:40:06 -  1.67
+++ server_file.c   20 May 2020 22:16:22 -
@@ -488,7 +488,7 @@ server_file_index(struct httpd *env, str
"\n"
"\n"
"\n"
+   "charset=utf-8\">\n"
"Index of %s\n"
"\n"
"\n"
Index: server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.138
diff -u -p -r1.138 server_http.c
--- server_http.c   18 May 2020 14:40:06 -  1.138
+++ server_http.c   20 May 2020 22:16:22 -
@@ -932,7 +932,7 @@ server_abort_http(struct client *clt, un
"\n"
"\n"
"\n"
+   "charset=utf-8\">\n"
"%03d %s\n"
"\n"
"\n"

Re: correction for insque.3

[Andras Farkas]

I have an alternative to insque3difflarge.txt as for clarifying the
wording: simply removing the word "respectively", so the end of the
sentence is just "in the queue."  (that said, I have a preference for
what I actually sent as a diff)

On Thu, Apr 23, 2020 at 5:48 PM Andras Farkas  wrote:
>
> I was reading the thread about STAILQ and SIMPLEQ and thought it was
> interesting, so I then read a little about sys/queue.h and search.h
> I noticed an error in insque.3:
> https://man.openbsd.org/insque.3
> The words "next" and "previous" are swapped, as it is the first
> pointer that points to the next element, and the second pointer that
> points to the previous element.
> I confirmed this both in insque.c (to make sure I understood the
> directionality correctly):
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib/insque.c?rev=1.3=text/x-cvsweb-markup
> and in POSIX, which the man page states OpenBSD's insque() conforms to:
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/insque.html
>
> I have the diff to fix this both inline and attached.
> Checksum for anyone trying to grab the diff from inline, since my
> inline diffs usually get mangled:
> SHA256 (insque3diff.txt) =
> 8340d135c06abc46127a12307b9611d274e1ad3e35dc6cf662da15a1f4502dec
>
> Index: insque.3
> ===
> RCS file: /cvs/src/lib/libc/stdlib/insque.3,v
> retrieving revision 1.10
> diff -u -p -r1.10 insque.3
> --- insque.3 30 Nov 2014 20:19:12 - 1.10
> +++ insque.3 23 Apr 2020 21:13:10 -
> @@ -61,7 +61,7 @@ struct qelem {
>  .Ed
>  .Pp
>  The first two elements in the struct must be pointers of the
> -same type that point to the previous and next elements in
> +same type that point to the next and previous elements in
>  the queue respectively.
>  Any subsequent data in the struct is application-dependent.
>  .Pp
>
> Also, I feel the phrasing isn't as clear as it could be.  The way
> "respectively" is used makes more sense in the way the other BSD man
> pages use "first and second" (in "first and second members") rather
> than the OpenBSD man page's "first two" (in "first two elements").  I
> think "respectively" makes more sense when used in analogy, or pairing
> up words.
> https://www.freebsd.org/cgi/man.cgi?query=insque=0=0=FreeBSD+12.1-RELEASE+and+Ports=default=html
> https://netbsd.gw.com/cgi-bin/man-cgi?insque
> https://leaf.dragonflybsd.org/cgi/web-man?command=insque=ANY
> Their wording is identical.
>
> I have a larger diff as an option, in light of the above:
> SHA256 (insque3difflarge.txt) =
> c2e242221f016ae4bafa3b40a466f27016d4f44b3f58053a60204e06aecefaf9
>
> Index: insque.3
> ===
> RCS file: /cvs/src/lib/libc/stdlib/insque.3,v
> retrieving revision 1.10
> diff -u -p -r1.10 insque.3
> --- insque.3 30 Nov 2014 20:19:12 - 1.10
> +++ insque.3 23 Apr 2020 21:42:07 -
> @@ -60,8 +60,8 @@ struct qelem {
>  };
>  .Ed
>  .Pp
> -The first two elements in the struct must be pointers of the
> -same type that point to the previous and next elements in
> +The first and second elements in the struct must be pointers of the
> +same type that point to the next and previous elements in
>  the queue respectively.
>  Any subsequent data in the struct is application-dependent.
>  .Pp
>
> Thanks for reading!

correction for insque.3

[Andras Farkas]

I was reading the thread about STAILQ and SIMPLEQ and thought it was
interesting, so I then read a little about sys/queue.h and search.h
I noticed an error in insque.3:
https://man.openbsd.org/insque.3
The words "next" and "previous" are swapped, as it is the first
pointer that points to the next element, and the second pointer that
points to the previous element.
I confirmed this both in insque.c (to make sure I understood the
directionality correctly):
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib/insque.c?rev=1.3=text/x-cvsweb-markup
and in POSIX, which the man page states OpenBSD's insque() conforms to:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/insque.html

I have the diff to fix this both inline and attached.
Checksum for anyone trying to grab the diff from inline, since my
inline diffs usually get mangled:
SHA256 (insque3diff.txt) =
8340d135c06abc46127a12307b9611d274e1ad3e35dc6cf662da15a1f4502dec

Index: insque.3
===
RCS file: /cvs/src/lib/libc/stdlib/insque.3,v
retrieving revision 1.10
diff -u -p -r1.10 insque.3
--- insque.3 30 Nov 2014 20:19:12 - 1.10
+++ insque.3 23 Apr 2020 21:13:10 -
@@ -61,7 +61,7 @@ struct qelem {
 .Ed
 .Pp
 The first two elements in the struct must be pointers of the
-same type that point to the previous and next elements in
+same type that point to the next and previous elements in
 the queue respectively.
 Any subsequent data in the struct is application-dependent.
 .Pp

Also, I feel the phrasing isn't as clear as it could be.  The way
"respectively" is used makes more sense in the way the other BSD man
pages use "first and second" (in "first and second members") rather
than the OpenBSD man page's "first two" (in "first two elements").  I
think "respectively" makes more sense when used in analogy, or pairing
up words.
https://www.freebsd.org/cgi/man.cgi?query=insque=0=0=FreeBSD+12.1-RELEASE+and+Ports=default=html
https://netbsd.gw.com/cgi-bin/man-cgi?insque
https://leaf.dragonflybsd.org/cgi/web-man?command=insque=ANY
Their wording is identical.

I have a larger diff as an option, in light of the above:
SHA256 (insque3difflarge.txt) =
c2e242221f016ae4bafa3b40a466f27016d4f44b3f58053a60204e06aecefaf9

Index: insque.3
===
RCS file: /cvs/src/lib/libc/stdlib/insque.3,v
retrieving revision 1.10
diff -u -p -r1.10 insque.3
--- insque.3 30 Nov 2014 20:19:12 - 1.10
+++ insque.3 23 Apr 2020 21:42:07 -
@@ -60,8 +60,8 @@ struct qelem {
 };
 .Ed
 .Pp
-The first two elements in the struct must be pointers of the
-same type that point to the previous and next elements in
+The first and second elements in the struct must be pointers of the
+same type that point to the next and previous elements in
 the queue respectively.
 Any subsequent data in the struct is application-dependent.
 .Pp

Thanks for reading!
Index: insque.3
===
RCS file: /cvs/src/lib/libc/stdlib/insque.3,v
retrieving revision 1.10
diff -u -p -r1.10 insque.3
--- insque.330 Nov 2014 20:19:12 -  1.10
+++ insque.323 Apr 2020 21:13:10 -
@@ -61,7 +61,7 @@ struct qelem {
 .Ed
 .Pp
 The first two elements in the struct must be pointers of the
-same type that point to the previous and next elements in
+same type that point to the next and previous elements in
 the queue respectively.
 Any subsequent data in the struct is application-dependent.
 .Pp
Index: insque.3
===
RCS file: /cvs/src/lib/libc/stdlib/insque.3,v
retrieving revision 1.10
diff -u -p -r1.10 insque.3
--- insque.330 Nov 2014 20:19:12 -  1.10
+++ insque.323 Apr 2020 21:42:07 -
@@ -60,8 +60,8 @@ struct qelem {
 };
 .Ed
 .Pp
-The first two elements in the struct must be pointers of the
-same type that point to the previous and next elements in
+The first and second elements in the struct must be pointers of the
+same type that point to the next and previous elements in
 the queue respectively.
 Any subsequent data in the struct is application-dependent.
 .Pp

a POSIXy diff for what(1)

[Andras Farkas]

I don't use what often, but I do use it sometimes.  Today I noticed
the format of what's output on OpenBSD was different than that of what
on FreeBSD.
Looking in what.1:
https://man.openbsd.org/what
I noticed OpenBSD's what is documented as abiding by POSIX:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/what.html
Thus, the following output:

tewi$ what /usr/bin/lorder
/usr/bin/lorder
$OpenBSD: lorder.sh,v 1.15 2015/07/03 11:43:55 jca Exp $
lorder.sh   8.1 (Berkeley) 6/6/93

is missing a single colon after the name/path/argument.
After applying the attached diff, the output is:

tewi$ ./what /usr/bin/lorder
/usr/bin/lorder:
$OpenBSD: lorder.sh,v 1.15 2015/07/03 11:43:55 jca Exp $
lorder.sh   8.1 (Berkeley) 6/6/93

Hope this helps!  Of course, if there's a reason the : is omitted,
that's fine too.
? whatcdiff.txt
Index: what.c
===
RCS file: /cvs/src/usr.bin/what/what.c,v
retrieving revision 1.15
diff -u -p -r1.15 what.c
--- what.c  9 Oct 2015 01:37:09 -   1.15
+++ what.c  18 Apr 2020 07:55:29 -
@@ -85,7 +85,7 @@ main(int argc, char *argv[])
perror(*argv);
exit(matches ? 0 : 1);
}
-   printf("%s\n", *argv);
+   printf("%s:\n", *argv);
search(match);
} while(*++argv);
exit(matches ? 0 : 1);

Re: FAQ4.html Commit Revert

[Andras Farkas]

For me, faq4.html displays fine in Firefox, lynx, and Chromium, both
with and without the CSS.

On Thu, Jan 2, 2020 at 10:47 AM Oleg Pahl  wrote:
>
> Hi @All,
>
>
>
> could you be so kind to revert this commit in FAQ 4?
>
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/www/faq/faq4.html.diff?r1=1.495=1.496
>
>
> Commit message : convert two ugly bullet lists into definition lists because 
> that's what they are.
> ok tj
> ---
>
>
>
> Before >
>
> After >
>
> BR,
>
> Oleg Pahl

Re: ksh: support "function name()"

[Andras Farkas]

On Sat, Dec 28, 2019 at 10:08 AM Mark Kettenis  wrote:
> [snip]
> Are there other ksh implementations that have this "feature"?
As for this question, I can at least confirm that no version of ksh93 has it.

Re: ksh: support "function name()"

[Andras Farkas]

If this diff gets accepted, in ksh's man page, you'll probably have to
change the following line as it's not entirely disambiguous how a
function would behave if it had both 'function' and '()' where it was
defined:
"Functions defined with the function reserved word are treated
differently in the following ways from functions defined with the ()
notation:"
Notably, would someone learning ksh realise 'function funname()' isn't
being defined with both notations at once?
Examples might be:
"Functions defined with the function reserved word are treated
differently in the following ways from functions defined solely with
the () notation:"
"Functions defined with the function reserved word are treated
differently in the following ways from functions defined without it:"

That said, I personally think to define a function with both
'function' and '()' is a genuine syntax error.

On Sat, Dec 28, 2019 at 8:42 AM Jeremie Courreges-Anglas  
wrote:
>
>
> We have a few ports (~12) patched because of shell script constructs
> like
>
>   function usage()
>   {
>
> which are rejected by our ksh.  Indeed ksh only supports either
>
>   usage()
>   {
>
> or
>
>   function usage
>   {
>
> Both bash and zsh also allow an optional "()".  The diff below
> implements the missing bits.
>
> Since the "reject = true;" mechanism bypasses yylex(), I have to
> pass token() the same flags as with the musthave('{') call below.
>
> ok?
>
>
> Index: ksh.1
> ===
> RCS file: /d/cvs/src/bin/ksh/ksh.1,v
> retrieving revision 1.208
> diff -u -p -r1.208 ksh.1
> --- ksh.1   26 Nov 2019 22:49:01 -  1.208
> +++ ksh.1   27 Dec 2019 12:27:37 -
> @@ -679,7 +679,7 @@ The exit status of a
>  statement is the last exit status of the
>  .Ar list
>  in the body of the loop; if the body is not executed, the exit status is 
> zero.
> -.It Xo Ic function Ar name
> +.It Xo Ic function Ar name Op ()
>  .No { Ar list ; No }
>  .Xc
>  Defines the function
> Index: syn.c
> ===
> RCS file: /d/cvs/src/bin/ksh/syn.c,v
> retrieving revision 1.39
> diff -u -p -r1.39 syn.c
> --- syn.c   24 Apr 2018 08:25:16 -  1.39
> +++ syn.c   27 Dec 2019 11:25:41 -
> @@ -555,6 +555,12 @@ function_body(char *name,
>  * an open-brace.
>  */
> if (ksh_func) {
> +   /* allow optional () after function name */
> +   if (token(CONTIN|KEYWORD|ALIAS) == '(')
> +   musthave(')', 0);
> +   else
> +   reject = true;
> +
> musthave('{', CONTIN|KEYWORD|ALIAS); /* } */
> reject = true;
> }
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
>

Re: Clarify drand48() return values

[Andras Farkas]

Not to appeal to majority, but to compare and contrast...
FreeBSD, NetBSD, POSIX, and Solaris all use the correct (or the more
explicit) interval notation for [0.0, 1.0) in drand48.3
https://www.freebsd.org/cgi/man.cgi?query=drand48=0=3=FreeBSD+12.1-RELEASE+and+Ports=default=html
https://netbsd.gw.com/cgi-bin/man-cgi?drand48+3
https://pubs.opengroup.org/onlinepubs/9699919799/functions/drand48.html
https://docs.oracle.com/cd/E88353_01/html/E37843/drand48-3c.html
https://docs.oracle.com/cd/E26505_01/html/816-5168/drand48-3c.html
(though, Solaris's latter two of three intervals are wrong, unless
they really do mean their upper bound is inclusive)

On Thu, Dec 19, 2019 at 10:48 PM Andras Farkas
 wrote:
>
> On Thu, Dec 19, 2019 at 10:05 PM Theo de Raadt  wrote:
> > It's a mathematical notation that anyone using this page should
> > understand because it comes with the territory.
> > [snip]
> >
> > I think understanding the landscape's notation is a requirement, and we
> > don't need to say things a 2nd time in baby talk.
> I agree it doesn't need to be repeated, but I think there's value in
> explicitly showing whether an interval is open or closed.
> Though, in this case, the interval would be correctly expressed as
> [0.0, 1.0)
> or
> [0.0, 1.0[
> rather than how j's diff does it.
>
> I attached a diff which I feel concisely does this.  I elected to not
> change the latter two of the three intervals in the man page, since
> they already included -1 in their upper bound.  But I also have that
> as an option, via largediff.txt

Re: Clarify drand48() return values

[Andras Farkas]

On Thu, Dec 19, 2019 at 10:05 PM Theo de Raadt  wrote:
> It's a mathematical notation that anyone using this page should
> understand because it comes with the territory.
> [snip]
>
> I think understanding the landscape's notation is a requirement, and we
> don't need to say things a 2nd time in baby talk.
I agree it doesn't need to be repeated, but I think there's value in
explicitly showing whether an interval is open or closed.
Though, in this case, the interval would be correctly expressed as
[0.0, 1.0)
or
[0.0, 1.0[
rather than how j's diff does it.

I attached a diff which I feel concisely does this.  I elected to not
change the latter two of the three intervals in the man page, since
they already included -1 in their upper bound.  But I also have that
as an option, via largediff.txt
Index: rand48.3
===
RCS file: /cvs/src/lib/libc/stdlib/rand48.3,v
retrieving revision 1.20
diff -u -p -r1.20 rand48.3
--- rand48.310 Nov 2015 23:48:18 -  1.20
+++ rand48.320 Dec 2019 03:43:34 -
@@ -101,7 +101,7 @@ and
 return values of type double.
 The full 48 bits of r(n+1) are
 loaded into the mantissa of the returned value, with the exponent set
-such that the values produced lie in the interval [0.0, 1.0].
+such that the values produced lie in the interval [0.0, 1.0).
 .Pp
 .Fn lrand48
 and
Index: rand48.3
===
RCS file: /cvs/src/lib/libc/stdlib/rand48.3,v
retrieving revision 1.20
diff -u -p -r1.20 rand48.3
--- rand48.310 Nov 2015 23:48:18 -  1.20
+++ rand48.320 Dec 2019 03:46:09 -
@@ -101,13 +101,13 @@ and
 return values of type double.
 The full 48 bits of r(n+1) are
 loaded into the mantissa of the returned value, with the exponent set
-such that the values produced lie in the interval [0.0, 1.0].
+such that the values produced lie in the interval [0.0, 1.0).
 .Pp
 .Fn lrand48
 and
 .Fn nrand48
 return values of type long in the range
-[0, 2**31-1].
+[0, 2**31).
 The high-order (31) bits of
 r(n+1) are loaded into the lower bits of the returned value, with
 the topmost (sign) bit set to zero.
@@ -116,7 +116,7 @@ the topmost (sign) bit set to zero.
 and
 .Fn jrand48
 return values of type long in the range
-[-2**31, 2**31-1].
+[-2**31, 2**31).
 The high-order (32) bits of r(n+1) are loaded into the returned value.
 .Pp
 In the deterministic mode, the

Re: un-boolean_t ANSIfy ddb(4) for hppa & sparc64

[Andras Farkas]

On Wed, Nov 20, 2019 at 9:38 AM Theo de Raadt  wrote:
> Kernel environment cannot use userland includes.

On Wed, Nov 20, 2019 at 12:18 PM Todd C. Miller  wrote:
> Changing from int -> bool is error prone since you inevitably have
> code that use true, false and -1.  Finding those outliers that are
> relying on the type being int is not always easy.  Speaking from
> personal experiance, it is easy to introduce bugs this way.

I see. Thanks for the info!
:D

Re: un-boolean_t ANSIfy ddb(4) for hppa & sparc64

[Andras Farkas]

Out of curiosity, why not just use stdbool.h if these are actually
meant to be booleans?  Wouldn't that be more readable?
I wonder if there's something I'm not understanding.

On Tue, Nov 5, 2019 at 8:05 AM Martin Pieuchot  wrote:
>
> ok?
>
> Index: arch/hppa/hppa/db_disasm.c
> ===
> RCS file: /cvs/src/sys/arch/hppa/hppa/db_disasm.c,v
> retrieving revision 1.20
> diff -u -p -r1.20 db_disasm.c
> --- arch/hppa/hppa/db_disasm.c  15 Oct 2014 17:22:56 -  1.20
> +++ arch/hppa/hppa/db_disasm.c  5 Nov 2019 12:22:33 -
> [snip]

add errata66 to security.html

[Andras Farkas]

This diff adds a link to
https://www.openbsd.org/errata66.html
on
https://www.openbsd.org/security.html

I noticed this when reading the 6.6 announcement email.
Index: security.html
===
RCS file: /cvs/www/security.html,v
retrieving revision 1.442
diff -u -p -r1.442 security.html
--- security.html   1 Jun 2019 23:12:51 -   1.442
+++ security.html   28 Oct 2019 20:14:00 -
@@ -72,7 +72,8 @@ For security advisories for specific rel
 6.2,
 6.3,
 6.4,
-6.5.
+6.5,
+6.6.
 
 
 

fix acme manpage link in faq/upgrade66.html

[Andras Farkas]

Diff attached, changes bad link:
https://man.openbsd.org/OpenBSD-6.6/acme-client.5
to
https://man.openbsd.org/OpenBSD-6.6/acme-client.conf.5
on this page:
https://www.openbsd.org/faq/upgrade66.html

Do documentation-related diffs like this belong in tech, bugs, or misc?
Index: upgrade66.html
===
RCS file: /cvs/www/faq/upgrade66.html,v
retrieving revision 1.11
diff -u -p -r1.11 upgrade66.html
--- upgrade66.html  17 Oct 2019 02:25:57 -  1.11
+++ upgrade66.html  24 Oct 2019 17:55:05 -
@@ -138,7 +138,7 @@ any post-release fixes.
   https://man.openbsd.org/OpenBSD-6.6/acme-client.1;>acme-client(1)
   has been updated to implement the recently published RFC8555. Users 
   must change the api url in
-  https://man.openbsd.org/OpenBSD-6.6/acme-client.5;>
+  https://man.openbsd.org/OpenBSD-6.6/acme-client.conf.5;>
   /etc/acme-client.conf from
   
   

Re: Fix a segmentation fault in awk

[Andras Farkas]

On Mon, Aug 12, 2019 at 3:45 PM Frederic Cambus  wrote:
> Hi tech@,
> Here is a diff to fix a segmentation fault in awk, from upstream
> version 20121220 [1]. Upstream fix didn't check for strdup return value
> so I added the check.
I've always been curious, why isn't the latest version of awk, the
2012 version, used in OpenBSD?  There may be a reason, but I've never
been able to figure it out.

Re: printf(1) man page has a small omission

[Andras Farkas]

On Thu, Aug 1, 2019 at 5:54 PM Ingo Schwarze  wrote:
> please do not cross-post on OpenBSD lists, choose whatever list fits
> best.  I trimmed bugs@ for this followup.
Ah, my bad.  I just found it unclear which list to send documentation
issues to.  I've normally sent them to bugs@ in the past, but then I
also sent a diff and I've been told diffs usually go to tech@
Any advice?
I'd totally subscribe to a docs@ if there was one. :D
> I don't quite agree with your patch.  In practice, both \0num
> and \num work; i inspected the code of FreeBSD and NetBSD which
> both appear to support \num, too, even though they don't document
> it, and i tested on Linux, and on Solaris 9, 10, and 11, and both
> forms work everywhere:
>
>$ printf '%b\n' '\0176x'
>   ~x
>$ printf '%b\n' '\176x'
>   ~x
True, that's right.
> So here is an alternative patch.
This patch looks great.
*thumbs-up*

Re: printf(1) man page has a small omission

[Andras Farkas]

I have a diff attached which fixes the man page.

On Mon, Jun 3, 2019 at 2:12 PM Andras Farkas  wrote:
>
> https://man.openbsd.org/man1/printf.1
> The section on the b format (%b) neglects to mention that for that
> format, it's \0num rather than \num
> Because of the way OpenBSD's printf is made, both \0num and \num work
> for %b, but, \0num is more correct and portable when using printf(1)'s
> %b format.
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
>
> For comparison:
> https://www.freebsd.org/cgi/man.cgi?query=printf=0=1=FreeBSD+12.0-RELEASE+and+Ports=default=html
> https://netbsd.gw.com/cgi-bin/man-cgi?printf+1
Index: printf.1
===
RCS file: /cvs/src/usr.bin/printf/printf.1,v
retrieving revision 1.32
diff -u -p -r1.32 printf.1
--- printf.12 Jun 2019 06:16:37 -   1.32
+++ printf.130 Jul 2019 03:51:32 -
@@ -328,6 +328,13 @@ all remaining characters in this argumen
 and all remaining characters in the
 .Ar format
 string.
+The string
+.Ar argument
+uses
+.Cm \e0 Ns Ar num
+rather than
+.Cm \e Ns Ar num
+for octal escapes.
 .It Cm c
 The first character of
 .Ar argument

Re: ksh "clear-screen" editing command

[Andras Farkas]

On Tue, Apr 2, 2019 at 11:32 AM Klemens Nanni  wrote:
> On Tue, Apr 02, 2019 at 05:20:19PM +0200, Theo Buehler wrote:
> > Yes, ^L is printed in vi insert mode. The text you quoted is about vi
> > command mode which does indeed redraw the current line on ^L. I agree
> > with jca, no need for a change there.
> I'm confused.  Without jca's diff, I did the following:
>
> xterm -e /bin/sh
> $ set -o vi
> $ ^L^L  # literal escape, nothing happens
>
> $ set -o emacs
> $ true^L# redraws the line
> $ true
>
> So where does ^L redraw the current line on ^L for you?

$ set -o vi
$ true^[^L #redraws the line
$ true

vi uses the escape or ^[ character to go into command mode from insert mode

Re: [vi] moving by sentences is inconsistent

[Andras Farkas]

On Mon, Oct 8, 2018 at 11:04 AM Theo de Raadt  wrote:
> You only checked the clones?  You need to compare to the past.
What you're implying is right: a comment (the one with the AB CD example) in
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/vi/vi/v_sentence.c
implies that this unfortunate and broken behavior comes from the
original vi, working contrary to the documentation.

Re: [Patch] mg(1) tutorial: no columns :(

[Andras Farkas]

On Fri, May 25, 2018 at 7:43 AM, Leonid Bobrov  wrote:
> Index: tutorial
> ===
> RCS file: /cvs/src/usr.bin/mg/tutorial,v
> retrieving revision 1.17
> diff -u -p -u -p -r1.17 tutorial
> --- tutorial30 May 2017 07:11:40 -  1.17
> +++ tutorial25 May 2018 03:42:23 -
> @@ -218,10 +218,9 @@ you're editing a file named "tutorial".
>  saved it, it should have a "**" to the left of those words. If this file is
>  read-only, you should see a "%%" to the left of those words.
>
> -To the right of the status line, you should see L followed by digits and C
> -followed by some more digits. These indicate the line number and column 
> number
> -of the file that your cursor is currently on. If you move the cursor around,
> -you should see the line and column number change.
> +To the right of the status line, you should see L followed by digits. This
> +indicates the line number of the file that your cursor is currently on. If
> +you move the cursor up or down, you should see the line number change.
>
>  In the middle of the screen, you should see the word "(fundamental)" which
>  indicates that the current editing mode is "fundamental-mode". The mg editor
>
If you M-x column-number-mode you can enable seeing the column number
in mg.  Perhaps the tutorial should mention that somewhere, in
addition to, or instead?
Though having column-number-mode enabled by default might be nice, as
line-number-mode is enabled already.

Re: manpage text width

[Andras Farkas]

On Fri, Mar 30, 2018 at 11:23 AM, Chris Bennett
 wrote:
> This is very important. Our brains just are not good at working with
> long lines. This is hard-wired. If anyone doesn't believe me, try
> setting your browser window to a narrower width or use reader mode.
> We read by mapping things out on the line. If it's too long, our brains
> get "confused" and information is lost.
Is there any research backing this up?  I've seen this sentiment twice
in this thread, but man's column limit has always been the most
dreaded part about man for me. (I'm very happy to find I can change it
with -Owidth)  I've found that doubling it to 160 columns has always
been far, far more comfortable for me, so I have doubt that the 80/78
column limit is anything more than a tradition looking for any reason
to continue existing.
If a user resizes their terminal before running a program, it makes
perfect sense for text to wrap to the terminal's size, just like with
programs that simply use stdout to output text.

Re: [PATCH] usr.bin/calendar/calendars/calendar.uk - Burns' Night -> Burns Night

[Andras Farkas]

On Fri, Jan 12, 2018 at 3:11 PM, Jason McIntyre  wrote:
> hilariously, i just realised the apostrophe in the quote above is in the
> wrong place! maybe it should be "Burns Hog Weighing Method" ;)
I'd also like to note that while some people would do:
Burns' Hog Weighing Method
The following is also considered valid and correct:
Burns's Hog Weighing Method
In fact, the second method, using Burns's, is the first thing
mentioned in the first chapter of The Elements of Style by William
Strunk Jr. and E.B. White
Coincidentally, one of the three examples given is verbatim:
Burns's poems

Re: README patch

[Andras Farkas]

On Mon, Nov 13, 2017 at 8:16 AM, Sebastian Benoit  wrote:
> http://ftp.openbsd.org/pub/OpenBSD/6.2/README
Much more minor, but "This is our 43nd release." should be "This is
our 43rd release."
Also,
"For further details, please visit https://OpenBSD.org/faq;
actually ends up being https://www.openbsd.org/faq/ with a slash at
the very end.

Re: Mistake in flex man page

[Andras Farkas]

On Fri, Dec 23, 2016 at 11:14 PM, Philip Guenther  wrote:
> Many options to cc are position sensitive, including the -l
> option.

Oh wow, I see. You're absolutely right.
Thank you!

Mistake in flex man page

[Andras Farkas]

Afternoon!

The attached flexdiff changes flex.1 to be accurate about how flex
currently works: -lfl does not provide yywrap() by default.

Attached also are two lex files I used to find out that the man page
wasn't correct.
The man page says one can either use %option noyywrap or link with
-lfl but only the former solution works.
The two lex files intend to do the same thing: to be the simplest lex
program, and to produce an a.out that acts like cat.

This works:
lex optnoyy.l
cc -lfl lex.yy.c

This does not work:
lex noopt.l
cc -lfl lex.yy.c

The compiler finds undefined references to yywrap, which shows that
-lfl does not provide yywrap(), unlike what is said on the man page.

I did this testing on 6.0 release, but looking at cvsweb I don't think
it'll be any different on -current.

Thanks for reading. :D


flexdiff
Description: Binary data


optnoyy.l
Description: Binary data


noopt.l
Description: Binary data

Re: netcat service lookup

[Andras Farkas]

Oh, someone pointed the possible problem out to me:
I'm running OpenBSD 5.9 instead of current.

Sorry.

On Thu, Jun 2, 2016 at 3:58 AM, Andras Farkas <deepbluemist...@gmail.com> wrote:
>> Andras - your original diff does not apply to -current as mailed, and
>> you also have a bug when the -v option is used, because you end up
>> putting port names in the portlist array instead of numbers and
>> so -v doesn't work right.
>>
>> Try this instead:
>
>
> Thank you, I was trying to look for bugs and still didn't find any myself
> yet.
> What exact command got that bug to occur? Even when I test now with -v it
> doesn't happen.

Re: netcat service lookup

[Andras Farkas]

Andras - your original diff does not apply to -current as mailed, and
you also have a bug when the -v option is used, because you end up
putting port names in the portlist array instead of numbers and
so -v doesn't work right.

Try this instead:


Thank you, I was trying to look for bugs and still didn't find any 
myself yet.
What exact command got that bug to occur? Even when I test now with -v 
it doesn't happen.

Re: netcat service lookup

[Andras Farkas]

Ah, okay.
> I don't see how it makes it easier.  There are a number of netcat
> versions out there, mostly trying to be somewhat compatible.  On a
> whim, this introduces an incompatibility --> scripts become less
> portable.

netcat service lookup

[Andras Farkas]

Evening!
This diff allows users to use the name of a service in /etc/services 
instead of a port number when using netcat. Hopefully, this will make 
using netcat easier for some users.



? nc
Index: nc.1
===
RCS file: /cvs/src/usr.bin/nc/nc.1,v
retrieving revision 1.71
diff -u -p -r1.71 nc.1
--- nc.125 Sep 2015 14:56:33 -  1.71
+++ nc.11 Jun 2016 02:56:09 -
@@ -51,7 +51,7 @@
 .Op Fl X Ar proxy_protocol
 .Op Fl x Ar proxy_address Ns Op : Ns Ar port
 .Op Ar destination
-.Op Ar port
+.Op Ar port | service
 .Sh DESCRIPTION
 The
 .Nm
@@ -344,6 +344,10 @@ a destination port must be specified,
 unless the
 .Fl U
 option is given.
+.Pp
+.Ar service
+is the name of a service in
+.Pa /etc/services
 .Sh CLIENT/SERVER MODEL
 It is quite simple to build a very basic client/server model using
 .Nm .
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.152
diff -u -p -r1.152 netcat.c
--- netcat.c28 May 2016 20:14:58 -  1.152
+++ netcat.c1 Jun 2016 02:56:09 -
@@ -1291,22 +1291,43 @@ atelnet(int nfd, unsigned char *buf, uns
 void
 build_ports(char *p)
 {
+   struct servent *entry;
const char *errstr;
char *n;
+   char *proto;
int hi, lo, cp;
int x = 0;

+   if (uflag == 1)
+   proto = "udp";
+   else
+   proto = "tcp";
+
if ((n = strchr(p, '-')) != NULL) {
*n = '\0';
n++;

/* Make sure the ports are in order: lowest->highest. */
hi = strtonum(n, 1, PORT_MAX, );
-   if (errstr)
-   errx(1, "port number %s: %s", errstr, n);
+   if (errstr) {
+   if (errno == EINVAL) {
+   entry = getservbyname(n, proto);
+   if (entry == NULL)
+   errx(1, "service \"%s\" unknown", n);
+   hi = ntohs(entry->s_port);
+   } else
+   errx(1, "port number %s: %s", errstr, n);
+   }
lo = strtonum(p, 1, PORT_MAX, );
-   if (errstr)
-   errx(1, "port number %s: %s", errstr, p);
+   if (errstr) {
+   if (errno == EINVAL) {
+   entry = getservbyname(p, proto);
+   if (entry == NULL)
+   errx(1, "service \"%s\" unknown", p);
+   hi = ntohs(entry->s_port);
+   } else
+   errx(1, "port number %s: %s", errstr, p);
+   }

if (lo > hi) {
cp = hi;
@@ -1334,8 +1355,15 @@ build_ports(char *p)
}
} else {
hi = strtonum(p, 1, PORT_MAX, );
-   if (errstr)
-   errx(1, "port number %s: %s", errstr, p);
+   if (errstr) {
+   if (errno == EINVAL) {
+   entry = getservbyname(p, proto);
+   if (entry == NULL)
+   errx(1, "service \"%s\" unknown", p);
+   hi = ntohs(entry->s_port);
+   } else
+   errx(1, "port number %s: %s", errstr, p);
+   }
portlist[0] = strdup(p);
if (portlist[0] == NULL)
err(1, NULL);