preferred #include guard idiom?

[ropers]

I'm looking at the #include guards in various .h files in /usr/include.
There seem to be different (comment) idioms present at the bottom of
those files/#include guards.


For example:

ctype.h:
#endif /* !_CTYPE_H_ */

float.h:
#endif  /* _FLOAT_H_ */

err.h:
#endif /* !_ERR_H_ */

curses.h:
#endif /* _CURSES_H_ */


Is there agreement on what notation is correct?


It seems to me that both are defensible or at least arguable.  The
straightforward idiom without the ! works simply as a reminder of
which file/#define the #endif belongs to.  The version with the !
seems to me to be intended to also take note of the fact that it says
#ifndef at the top, with emphasis on the n.

>From running commands such as
$ grep '#endif /\* _' *.h | wc -l
and
$ grep '#endif /\* !_' *.h | wc -l
it would appear the former is about twice as common.


Should a single style be adopted?


style(9) doesn't cover this admittedly less-than-crucial point.
Speaking of include guards, is #pragma once ever okay here, or is that
a big no-no?

Thanks and regards,
Ian

(Ian Ropers)

Re: ksh emacs search-history misbehaviour

[ropers]

I appreciate not everyone is as verbose as I can be, but your initial
email was very terse.  For example, when you say:

> in emacs search-history mode, abort if ^@ is encountered

is that the desired behaviour or the problem behaviour?

>From testing, it seems like the current behaviour is that it's
aborting, and from reading only your diff, it looks like you want it
not to abort but ignore an accidentally typed U+ character.  But
it also looks like this could relate to another ksh/emacs.c
history-related issue I've previously observed but STILL not offered
up a diff for.

I think if you elaborated a little, that might make your email more
accessible.  Don't assume people know what you know.  The less
work--even thinking--people need to do to see where you're coming from
the better.  Thus, what are your exact steps, etc.?  Also, what
exactly do zsh and bash do?

I tried to test a little to obtain a better understanding of what's
bugging you (and arguably ksh), and I got somewhat inconsistent
results -- with ksh's behaviour depending on whether I'd already typed
something else.  Sometimes I got a "phantom abort" where it looked
like I was back to the regular prompt but actually wasn't.  I even got
ksh to dump core once, but that was oksh on a Linux box, so YMMV.
In short, I'm not sure I'm really doing and seeing what you're seeing.
I suspect if you described things more comprehensively, that might
help not just little old me understand.

Thanks and regards,
Ian

On 18/09/2021, Alexander Hall  wrote:
> Ping. Please don't be discouraged or scared just because it's a diff to
> ksh(1). It really is rather simple.
>
> Noone else ever ran into this ksh command line history search bug?
>
> /Alexander
>
> On September 14, 2021 12:17:22 AM GMT+02:00, Alexander Hall
>  wrote:
>>in emacs search-history mode, abort if ^@ is encountered
>>
>>This has been bugging me for ages, and I finally realized it was me
>>accidentally pressing Ctrl+, rendering ^@ (a.k.a '\0' or NUL)
>>
>>Easily tested with: Ctrl+R Ctrl+ ...
>>
>>Minimal investigation, for reference:
>>  bash: misbehaves in a slightly different manner
>>  zsh:  behaviour matches this fix
>>
>>OK?
>>
>>Index: emacs.c
>>===
>>RCS file: /cvs/src/bin/ksh/emacs.c,v
>>retrieving revision 1.88
>>diff -u -p -r1.88 emacs.c
>>--- emacs.c   27 Jun 2021 15:53:33 -  1.88
>>+++ emacs.c   13 Sep 2021 21:42:37 -
>>@@ -897,7 +897,7 @@ x_search_hist(int c)
>>  if ((c = x_e_getc()) < 0)
>>  return KSTD;
>>  f = kb_find_hist_func(c);
>>- if (c == CTRL('[')) {
>>+ if (c == CTRL('[') || c == CTRL('@')) {
>>  x_e_ungetc(c);
>>  break;
>>  } else if (f == x_search_hist)
>>
>
>

man sed(1) diff

[ropers]

I.

Not to engage in pointless bikeshedding, but I find this clearer and
--if I understand things correctly-- also more technically accurate:

Index: sed.1
===
RCS file: /cvs/src/usr.bin/sed/sed.1,v
retrieving revision 1.60
diff -C8 -u -r1.60 sed.1
cvs server: conflicting specifications of output style
--- sed.1   8 Mar 2021 02:47:28 -   1.60
+++ sed.1   5 Sep 2021 08:23:25 -
@@ -141,19 +141,19 @@
 Normally,
 .Nm
 cyclically copies a line of input, not including its terminating newline
 character, into a
 .Em pattern space ,
 (unless there is something left after a
 .Ic D
 function),
-applies all of the commands with addresses that select that pattern space,
-copies the pattern space to the standard output, appending a newline, and
-deletes the pattern space.
+applies all of the commands with addresses that select that pattern,
+copies the pattern space contents to the standard output, appending a
+newline, and deletes them from the pattern space.
 .Pp
 Some of the functions use a
 .Em hold space
 to save all or part of the pattern space for subsequent retrieval.
 .Sh SED ADDRESSES
 An address is not required, but if specified must be a number (that counts
 input lines
 cumulatively across input files), a dollar character

(I used the diff -C 8 option to show a little more context.)


II.

[Link for easier reading: ]

Also, does the "(unless there is something left after a D function)"
part really relate to the preceding parenthetical clause of "not
including its terminating newline character"?  Should it be moved to
directly follow that instead of following the "into a pattern space"
part?
Alternatively, would it be better to move the "(...)" part to a
separate subsequent sentence like this:
> (A newline character may be present in the pattern space
> if left behind after a
> .Ic D
> function.)
Is it even important to include that information in the man page?  Is
it ever relevant that there may technically be some string and a
newline left in the pattern space?


Thank you,
Ian

Re: timeout: Prettify man page and usage

[ropers]

> Changed to "duration and time may contain a decimal fraction.  The value
> defaults to seconds unless an unit-specifying suffix is given."

a unit, not an unit

It's phonetic; it depends on pronunciation, not on the way it's spelled.

Hence "a unit" /ˈjuːnɪt/
but "an unreal amount" /ʌnˈrɪəl/.

--Ian

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

[ropers]

On 16/08/2021, Jason McIntyre  wrote:
> hi.
>
> when i wrote my mail, i failed to understand that "overrides earlier"
> was really just another way of saying "mutually exclusive". i don;t find
> it as clear, and i don;t hugely like it, but i guess it's just my
> preference.
>
> i also dislike the sentence structure of "Overrides earlier -f."
> although it's understandable, it reads like there's a word or phrase
> missing. Overrides earlier instances of -f. Overrides previous -f
> options.
>
> i just find it clearer when we just say -x and -y are mutually exclusive.
>
> jmc

Not a fan of telegram style so.

https://en.wikipedia.org/wiki/Telegram_style
https://en.wikipedia.org/wiki/Headline#Headlinese
https://en.wikipedia.org/wiki/Ellipsis_(linguistics)

I take no position on the matter before this cal(1) cleanup court, but
I contend that clipped sentences can be clearly cromulent.  Cleverly
copacetic, even.

'Cool.

Ian

Re: [patch] Preserve keymap adjustments on suspend/resume

[ropers]

Would this also preserve the LED status (Num, Scroll Lock, etc.)?

(I'm nobody important and probably can't help, but I'm curious.)

Thanks and regards,
Ian


On 09/08/2021, Sergii Rudchenko  wrote:
> Pardon my impatience -- I am a newbie and I don't really know what
> should happen next (if anything?). I have skipped any introduction from
> my original email, imitating the communication style in this list --
> straight to the point and because it was already long.
>
> Although this is my first patch to OpenBSD I am familiar with inner
> workings of operating systems from few books[1] and commercial
> development of a driver for Windows (CE and NT) back in 2005.  Thanks to
> the very clear organization of OpenBSD code it is a pleasure to study
> and figure things out.
>
> I have spent a week on massaging this problem, discovering corner cases,
> testing and ironing out regressions. I did my best to keep the patch at
> minimum while retaining correctness and clarity. Some changes like the
> move of t_keymap field (apart from the change of type) were done to
> re-align it with NetBSD. I was in doubt about locking, but tracing the
> path of ioctl handling I have not found anything preventing two CPU
> cores from executing wskbd ioctls in parallel on amd64 (and it is a
> NOLOCK syscall). In fact, now I wonder why wskbd_softc is not protected.
>
> Now a little bit on the motivation...
>
> My current day job does not involve system programming anymore and I
> miss it often. Also, with kids growing up I feel I can afford to
> contribute to important open projects with my experience and skills.  I
> fiddle with OpenBSD for a long time and I admire how simple, stable and
> well-documented it is. In our age of pervasive electronic waste, robust
> software often makes a difference between a useful computer and garbage.
>
> I realize that changes in wscons related to custom keymaps and USB
> keyboards is something of little priority.  Nevertheless, this is one
> annoying thing I randomly picked up and got to the bottom of it on my
> short staycation and it was a sufficiently low entry barrier. I hope
> it may be useful for other OpenBSD users, especially on laptop computers
> which may not have a USB keyboard connected yet at boot time.
>
> My longer-term aspiration is extending and maintaining hardware
> support, especially on ARM (I own a Pinebook Pro and few RPis).
>
> I would appreciate a bit of guidance or feedback.
>
>
> Best regards,
> Sergii Rudchenko
>
> [1] Of which the most prominent are:
> - "Modern Operating Systems (3rd edition)" by Andrew S. Tannenbaum
> - "The Design And Implementation Of The Freebsd Operating System"
> by Marshall Kirk McKusick and George V. Neville-Neil
> - "Linux Kernel Development (2nd edition)" by Robert Love
>
> P.S. Sorry for the git patch with a prefix, I came across
> https://www.openbsd.org/faq/faq5.html#Diff too late. As far I understand
> it should be fine with -p1
>
>

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

[ropers]

Hiya,

@Ingo:
Sorry I have been out of touch.  I have arguably been out of sorts,
though hopefully not out of order in your book.

> Index: emacs.c
> ===
> RCS file: /cvs/src/bin/ksh/emacs.c,v
> retrieving revision 1.87
> diff -u -p -r1.87 emacs.c
> --- emacs.c 8 May 2020 14:30:42 -   1.87
> +++ emacs.c 13 May 2021 18:16:13 -
> @@ -1851,11 +1851,17 @@ x_e_getu8(char *buf, int off)
> return -1;
> buf[off++] = c;
>
> -   if (c == 0xf4)
> +   /*
> +* In the following, comments refer to violations of
> +* the inequality tests at the ends of the lines.
> +* See the utf8(7) manual page for details.
> +*/
> +
> +   if ((c & 0xf8) == 0xf0 && c < 0xf5)  /* beyond Unicode */

This threw me at first.  I didn't initially understand why a check
whether this is "beyond Unicode" needed that "(c & 0xf8) == 0xf0 &&"
part at all.

But I now think I got it:  I think I let the comment lead me astray,
because in truth, it does not just check whether that fifth most
significant bit is zero, it also checks if the leftmost nibble is 0xF.
Seeing though that the zero status of the fifth msb is checked twice
(the 0x8 nibble ensures it is 0, and the "c < 0xf5" check ensures it
is 0), would it be clearer to check that only once?  Like thus:

 if ((c & 0xf0) == 0xf0 && c < 0xf5)  /* 4B leading byte, not beyond Unicode */

I'm NOT saying your way is wrong; I'm just throwing this out there.


Also, suppose we get a byte here that IS beyond Unicode, would any
further handling of that be needed once we arrive at "len = 1;" (the
final else) below?

> len = 4;
> else if ((c & 0xf0) == 0xe0)
> len = 3;
> -   else if ((c & 0xe0) == 0xc0 && c > 0xc1)
> +   else if ((c & 0xe0) == 0xc0 && c > 0xc1)  /* use single byte */
> len = 2;
> else
> len = 1;

^Here.

The way I read this, that's still unhandled for now, is it?

> Which problem needs fixing:
> Of the four-byte UTF-8 sequences, only a subset is identified by the
> existing code.  The other four-byte UTF-8 sequences still get chopped
> up resulting in individual bytes being passed on.

Or does that refer to other LEGAL 4-byte UTF-8?


> @@ -1865,9 +1871,10 @@ x_e_getu8(char *buf, int off)
>if (cc == -1)
>break;
>if (isu8cont(cc) == 0 ||
> -  (c == 0xe0 && len == 3 && cc < 0xa0) ||
> -  (c == 0xed && len == 3 && cc & 0x20) ||
> -  (c == 0xf4 && len == 4 && cc & 0x30)) {
> +  (c == 0xe0 && len == 3 && cc < 0xa0) ||  /* use 2 bytes */
> +  (c == 0xed && len == 3 && cc > 0x9f) ||  /* surrogates  */
> +  (c == 0xf0 && len == 4 && cc < 0x90) ||  /* use 3 bytes */
> +  (c == 0xf4 && len == 4 && cc > 0x8f)) {  /* beyond Uni. */
>x_e_ungetc(cc);
>break;
>}

Whatever you ultimately choose there, please DO include your comments,
i.e. these:

/* use single byte */
/* use 2 bytes */
/* surrogates  */
/* use 3 bytes */
/* beyond Uni. */

...because those are actually helpful, especially for nincompoops like me.



On 07/06/2021, Sören Tempel  wrote:
>
> BTW: Is there any reason why ksh doesn't use editline for all its line
> editing needs? That would allow handling all these nitty-gritty details
> in a central place.
>
> Greetings,
> Sören

That might end up fixing a minor quality of life issue and might end
up obsoleting a long-delayed diff that I've let go stale because I've
been too noobish and daft to confidently complete it.  It worked in
principle last time I tried many moons ago, but I didn't fully
comprehend how and why, which is concerning.
The issue is to do with the fact that unlike ksh vi mode, ksh emacs
mode won't let you return to the same line with arrow down after
you've gone back into the past with arrow-up. (It's a BTTF bug.)
Editline could take care of all of that.
Whether that's a good reason to support your suggestion is not for me to say.
(But wait, there's more: I did research and compare lotsa related
things there, which yielded an iffy diff, but mainly a VERY verbose
text file with my notes and findings.)
Should I even try to rediscover what I had and maybe share it with
somebody, perhaps off-list?  (Caveat emptor; it may not be worth your
time, but YMMV.)


Thanks and regards,
Ian


PS: (This part is purely for shits and giggles.)

I'd long thought that actually, octal was a fine way to deal with
UTF-8, because it fits the distribution of bits somewhat more cleanly
than hexadecimal.

Here's why I thought so.  Sorry for the possibly confusing ad-hoc notation:


1 byte : Octal works for code points U+–U+007F b/c "that's all she wrote":
It's ok the left octal is 1 at most; it can't bleed into 

man find -exec -- a little bit more hand-holding

[ropers]

The find man page might benefit from adding a little bit more
user-friendly hand-holding here:

Index: find.1
===
RCS file: /cvs/src/usr.bin/find/find.1,v
retrieving revision 1.98
diff -u -r1.98 find.1
--- find.1  2 Sep 2019 21:18:41 -   1.98
+++ find.1  14 Aug 2020 02:59:48 -
@@ -231,6 +231,10 @@
 .Qq {}
 appears anywhere in the utility name or the
 arguments it is replaced by the pathname of the current file.
+The semicolon will likely have to be escaped, depending on the shell.
+See
+.Sx CAVEATS
+below.
 .Pp
 If terminated by a plus sign,
 the pathnames for which the


EXAMPLE:

$ find ~ -iname ".*" -exec echo {} \;
works, but
$ find ~ -iname ".*" -exec echo {} ;
does not.

(Yes, this is a contrived example.  I wouldn't want to make people
copy things all over the place.)

Re: ksh [emacs.c] -- simplify isu8cont()

[ropers]

On 25/07/2020, Martijn van Duren  wrote:
> This function is used throughout the OpenBSD tree and I think it's
> fine as it is. This way it's clearer to me that it's about byte
> 7 and 8

You mean bits 7 and 8 when counting from 1 from the right?

> and not have to do the math in my head to check if we
> might have botched it.
>
> Also compilers should be smart enough to optimize this out at
> compile-time anyway.
>
> martijn@

So the (0x80 | 0x40) was supposed to be *for* legibility?

IMHO it hurts legibility, but admittedly, it depends on who you are
and what you have memorised:
Finding (0x80 | 0x40) easier than 0xC0 assumes that people have nibble
translation between binary and hexadecimal memorised all the way up to
8 but *NOT* up to C.  And that they find dealing with two values and
an extra binary OR still less hassle than remembering that C is 1100.
Of course if that's your decision, that's your decision, but speaking
as a novice C programmer, I think 'C' is easier. ;D [0]

But while you're reading this, would you at least consider committing
the explanatory comment?  Not everybody is already familiar with how
UTF-8 works, and I think this comment above the function is still some
extra hand-holding beginners might find useful:
/* is octet a UTF-8 continuation byte? */

Also, while you're here, can anyone tell me what the zot in x_zots() /
x_zotc() actually stands for?  I thought it was "zero out the
{string|character}" when I looked at x_zots(), but then I doubted
myself once I saw that that's not strictly what x_zotc() actually
does.  Does anyone know?

Ian


footnote:
[0] Which latter thought, incidentally, is also why someone invented BCHS. ;)




> On Sat, 2020-07-25 at 17:40 +0100, ropers wrote:
>> Index: emacs.c
>> ===
>> RCS file: /cvs/src/bin/ksh/emacs.c,v
>> retrieving revision 1.87
>> diff -u -r1.87 emacs.c
>> --- emacs.c  8 May 2020 14:30:42 -   1.87
>> +++ emacs.c  25 Jul 2020 16:31:22 -
>> @@ -269,10 +269,11 @@
>>  { 0, 0, 0 },
>>  };
>>
>> +/* is octet a UTF-8 continuation byte? */
>>  int
>>  isu8cont(unsigned char c)
>>  {
>> -return (c & (0x80 | 0x40)) == 0x80;
>> +return (c & 0xC0) == 0x80;
>>  }
>>
>>  int
>>
>
>

ksh [emacs.c] -- simplify isu8cont()

[ropers]

Index: emacs.c
===
RCS file: /cvs/src/bin/ksh/emacs.c,v
retrieving revision 1.87
diff -u -r1.87 emacs.c
--- emacs.c 8 May 2020 14:30:42 -   1.87
+++ emacs.c 25 Jul 2020 16:31:22 -
@@ -269,10 +269,11 @@
{ 0, 0, 0 },
 };

+/* is octet a UTF-8 continuation byte? */
 int
 isu8cont(unsigned char c)
 {
-   return (c & (0x80 | 0x40)) == 0x80;
+   return (c & 0xC0) == 0x80;
 }

 int

artwork.html -- minor fixes

[ropers]

These small changes mainly fix a minor cosmetic issue where the 
headers are closer to the items above than below them, making it look
as if the early releases were the audio CDs, etc.

Index: artwork.html
===
RCS file: /cvs/www/artwork.html,v
retrieving revision 1.11
diff -u -r1.11 artwork.html
--- artwork.html9 Jul 2020 10:22:30 -   1.11
+++ artwork.html22 Jul 2020 22:18:07 -
@@ -14,8 +14,8 @@
 }

 caption {
+   padding-top: 1em;
font-weight: bolder;
-   margin-bottom: 1.2em;
 }

 tr + tr td {
@@ -23,6 +23,7 @@
 }

 th {
+   padding-top: 2.4em;
font-weight: normal;
 }

@@ -55,7 +56,7 @@
 To accompany this free software released on the internet, we make
 artwork and music.
 This artwork emblazoned CDs and posters up until version 6.0, after which
-we stopped producing product and only release software on the internet.
+we stopped producing merchandise.  We now only release software on
the internet.

 
 Past releases also had shirts printed along
@@ -72,7 +73,7 @@

 
 
-
+
 Post-CD-ROM Era
 
 6.7
@@ -374,7 +375,6 @@
 
 
 
-   
 Fan art
 
 PuffyvsCthulhu
@@ -391,4 +391,6 @@
 
 
 
+
+
 


DETAILED DESCRIPTION OF CHANGES:

@@ -14,8 +14,8 @@
  Lower the caption and remove its bottom margin to avoid excessive
  whitespace between it and the first table header.
@@ -23,6 +23,7 @@
  Add generous padding on top of all table headers instead.
@@ -55,7 +56,7 @@
  Minor copyedit.
@@ -72,7 +73,7 @@
  There are actually two tables on top of each other in the sauce.
  Their not having been unified looks like a deliberate choice for
  nicer auto-alignment, and I'm not going to mess with that.  To avoid
  extra vertical whitespace between the two tables here, override the
  above CSS rule in just this one instance:  Reduce padding for the
  second table's first .
@@ -374,7 +375,6 @@
   whitespace is ghetto.
@@ -391,4 +391,6 @@
  Did I just say break whitespace was ghetto?  Sorry, I lied!  Forget
  what I said.  I love ghetto!  If I were to define this purely cosmetic
  extra bottom-of-the-page whitespace at the top, or worse, in the
  middle of the page, where the second table begins, nobody would see it
  there.  Breakin' two time right here.  Now KISS.

  PS:  Tough if you insist on being all gentrified and received
  pronunciation and double-barrelled name and everything, you can always
  decide to raze the ghetto and instead focus on being all styled up and
  body-positive or whatever the twitterati want to see.  I'm sure that
  helps with margins.  Gotta distance yourself from that bottom:
  body {
margin-bottom: 3em;
  }

Re: switch default MANPAGER from more(1) to less(1)

[ropers]

Ah, I see where you're coming from, Ingo.  You've dropped the idea of
testing for less(1) in non-portable mandoc because we know less(1) is
in base.[1]

That makes a lot of sense.

Like you said, the idea of testing for less might be worth revisiting
in mandoc-portable.  Admittedly, testing for less there would in fact
be "adding portability goo", which is never entirely cost-free, but
maybe that's justified here?

> Maybe test for the availability of less(1) in ./configure, which is quite 
> easy to do and which ./configure already does for many operating system 
> features. That would also be convenient because the mandoc ./configure is set 
> up in such a way that it is trivial for downstream package maintainers (say 
> in Void Linux, FreeBSD, or Illumos) to manually override in their package any 
> result that ./configure automatically detects.

There presently is a test for less on line 340 in -portable's configure file:

$ cat -n configure | sed -ne '155G; 149,155p; 338,350p'
   149  ismanual() {
   150  [ -z "${3}" ] && return 1
   151  echo "tested ${1}: HAVE_${2}=${3} (manual)" 1>&2
   152  echo "tested ${1}: HAVE_${2}=${3} (manual)" 1>&3
   153  echo 1>&3
   154  return 0
   155  }

   338  if ismanual "less -T" LESS_T ${HAVE_LESS_T}; then
   339  :
   340  elif less -ET /dev/null test-noop.c 1>/dev/null 2>&3; then
   341  HAVE_LESS_T=1
   342  echo "tested less -T: yes" 1>&2
   343  echo "tested less -T: yes" 1>&3
   344  echo 1>&3
   345  else
   346  HAVE_LESS_T=0
   347  echo "tested less -T: no" 1>&2
   348  echo "tested less -T: no" 1>&3
   349  echo 1>&3
   350  fi

That's slightly more advanced but similar in principle to the silly
little shell-based less test I sent you off-list, though I'm not
certain I understand why they're passing /dev/null as a tagsfile.
Maybe to test if any -T  throws any error?  (I also don't
actually understand the redirection to file descriptor 3.  Cluebats
welcome, on- or off-list.)

Anyway, I think your afore-enumerated advantages notwithstanding,
there's a downside to compile-time testing in that it might leave
someone stranded if the install environment differs, or if users
break their less after the fact but before they figure out they can
get things back to normal via PAGER variables, etc.  Not that that
sounds like anyone I know (*cough*).

But I will add, HOLY PAPER[2], I didn't even realise fixing this would
also drastically improve man usability on OpenBSD itself, where of
course it all hinges on this too.  That crazy pseudo-more, pseudo-less
behaviour where man kind of acts like less in that less keys work, but
if you reach the bottom of the man page via 'j' or space or Ctrl-f, it
throws you out, which less normally doesn't?  Yeah, that's all gone
now.  Or, it is once more -s is banished.[3]  I thought that man
behaviour was par for the course, but it doesn't have to be.  And
legit less-paged man feels so much nicer and faster, especially on a
not-so-well supported console.  Space and Ctrl+f and Ctrl+b are so
much more responsive now.[4]  Speeed!  Especially Ctrl+b.  Gotta go
fast!  It didn't hit me before your email how this little tangential
-portable thing points back to OpenBSD man behaviour, which is a BIG
part of the out-of-the-box OpenBSD[5] user experience and superficial
newbie-friendliness.
Thank you!  Great stuff!

Ian

footnotes:
[1] And that's just one more benefit to controlling the environment
and providing a complete operating system instead of drinking the
distro juice.
[2] 
[3] Fellow newbies note:
To test, run man man, then Ctrl+z and  ps ax|egrep '[m]ore|[l]ess'  to
see what actually runs, then fg.  Btw., seriously, "more -s -T"?  more
isn't even supposed to have a -T option.  I know it's the same
executable, but man, make up your mind!  Whoever you choose to be,
we'll respect you, more or less. Anyhoo, check export -p and run
export PAGER=/usr/bin/less.  unset PAGER to reverse (also check
MANPAGER in case of probs).
[4] The only niggle there is that if you page past an article's end,
less doesn't stop at the cliff edge but gives you vi-like tilde-filed
empty lines, even if the article is longer than a whole page.  I'm not
sure if that's a bug or feature since it preserves page up/down
alignment, but other implementations stop and realign themselves at
the bottom.  "Started from the bottom, now we here."
Oh, and the only *other* niggle is that help, i.e. man help now
doesn't auto-exit either, but what noob would not figure out to press
q to exit?  So I'm not sure this needs to be mentioned on help.1, but
maybe?
Also, as the *other* other niggle, should the contents of of the man
page be kept onscreen when less-paged man exits?  They are on console,
but not in xterm.  Is that even something related to this or would
harmonising that require kernel wscons driver hacking?
[5] 

events.html -- add year links and corresponding id parameters as anchor targets

[ropers]

Hello tech@,

The following adds a line of clickable year numbers near the top of events.html.

This is to aid navigation of this now very long page, so visitors can
jump to any desired year without being condemned to the smartphone
user one-button coma of having to scroll, scroll, scroll.

Ian


Index: www/events.html
===
RCS file: /cvs/www/events.html,v
retrieving revision 1.1197
diff -u -r1.1197 events.html
--- www/events.html 17 Jul 2020 17:19:25 -  1.1197
+++ www/events.html 18 Jul 2020 18:37:00 -
@@ -48,9 +48,36 @@

 

+2020
+2019
+2018
+2017
+2016
+2015
+2014
+2013
+2012
+2011
+2010
+2009
+2008
+2007
+2006
+2005
+2004
+2003
+2002
+2001
+2000
+1999
+1998
+1997
+
+
+
 Past events:

-2020
+2020

 

@@ -68,7 +95,7 @@

 

-2019
+2019

 

@@ -182,7 +209,7 @@

 

-2018
+2018
 

 
@@ -336,7 +363,7 @@
 

 
-2017
+2017
 

 
@@ -450,7 +477,7 @@
 

 
-2016
+2016
 

 
@@ -552,7 +579,7 @@
 

 
-2015
+2015
 

 
@@ -727,7 +754,7 @@

 

-2014
+2014
 

 
@@ -885,7 +912,7 @@

 

-2013
+2013
 

 
@@ -995,7 +1022,7 @@

 

-2012
+2012
 

 
@@ -1059,7 +1086,7 @@
 
 

-2011
+2011
 

 T-Dose 2011,
@@ -1136,7 +1163,7 @@

 

-2010
+2010
 

 
@@ -1219,7 +1246,7 @@

 

-2009
+2009
 

 
@@ -1351,7 +1378,7 @@

 

-2008
+2008
 

 
@@ -1573,7 +1600,7 @@

 

-2007
+2007
 

 
@@ -1943,7 +1970,7 @@

 

-2006
+2006
 

 
@@ -2382,7 +2409,7 @@
 
 

-2005
+2005

 

@@ -2844,7 +2871,7 @@
 
 

-2004
+2004

 
 
@@ -3092,7 +3119,7 @@
 
 

-2003
+2003

 
 
@@ -3288,7 +3315,7 @@
 
 

-2002
+2002

 
 
@@ -3382,7 +3409,7 @@
 
 

-2001
+2001

 
 
@@ -3479,7 +3506,7 @@
 
 

-2000
+2000

 
 
@@ -3707,7 +3734,7 @@
 
 

-1999
+1999

 
 The Bazaar,
@@ -3887,7 +3914,7 @@
 
 

-1998
+1998

 
 
@@ -4008,7 +4035,7 @@
 
 

-1997
+1997

 
 

Re: ed(1) man page doesn't mention use of single / and ?

[ropers]

On 07/07/2019, ropers  wrote:
> Second thought, maybe the 'i.e.'s should be changed to 'e.g.'s,
> because '/' and '?' also work (instead of '//' and '??',
> respectively), so '/re' and '?re' are indeed only examples.
>
> Or maybe this is overdoing it. I don't know. Whatever you all think is
> best and most correct. I have no strong personal opinion on this. I'm
> just trying to respond to mazocomp's reasonable observation and
> suggestion.

Okay, so here's an "e.g." version of the patch, which also removes an
extraneous `Ns` that was still present in the earlier, "i.e." version:

Index: ed.1
===
RCS file: /cvs/src/bin/ed/ed.1,v
retrieving revision 1.70
diff -u -r1.70 ed.1
--- ed.126 Apr 2018 12:18:54 -  1.70
+++ ed.17 Jul 2019 13:19:34 -
@@ -269,6 +269,9 @@
 current line, if necessary.
 .Qq //
 repeats the last search.
+The second slash is optional for a bare search without any suffixed
command, e.g.\&
+.Qq / Ns Ar re
+is sufficient when followed by a newline.
 .It Pf ? Ar re ?
 The previous line containing the regular expression
 .Ar re .
@@ -276,6 +279,9 @@
 current line, if necessary.
 .Qq ??
 repeats the last search.
+The second question mark is optional for a bare search without any
suffixed command, e.g.\&
+.Qq ? Ns Ar re
+is sufficient when followed by a newline.
 .It \&' Ns Ar lc
 The line previously marked by a
 .Ic k

However: *This isn't even my final form*, because it does not take
into account Matthew's concerns, which he hasn't clarified yet,
perhaps because he's not subscribed to tech@:


Thus Spake Chohag-jtan:
>> Better to be thorough, if this is to be done. The final slash in a
>> substitution is also unnecessary and ed reacts differently depending
>> whether or not it's included. I expect it's the same for the other
>> commands with delimited options.
>>
>> Matthew


Quoth the Jason:
> let's keep this on one mailing list only. since there's a diff, i guess
> tech is now fine.
>
> matthew: "ed reacts differently depending whether or not it's included".
> can you explain how?
>
> jmc


Also, it says in the DESCRIPTION in `man 1 ed` that
>> (...) commands have the structure:
>>   [address [,address]]command[parameters]
and I guess since /re[/] and ?re[?] are technically addresses, that
means that, with bare single addresses being legal and sufficient for
search, the command is technically optional too. So would one write
that as follows?
>>   [address [,address]][command[parameters]]
Or would it make more sense to add a second, bare address form there?

W/r/t Matthew's concerns, I also note that the
> (.,.)s/re/replacement/
section does mention this in its second paragraph:
>> If one or two of the last delimiters is omitted, then the last line
>> affected is printed as though the print suffix p were specified.
I'm not quite sure what is meant by omission of *two* of the last
delimiters there, but this does at least seem relevant to what we're
discussing here.


Oh, and Jason, earlier on you recommended NOT to document the second
delimiter omission with `g/RE`. Is there a reason why? I appreciate
that on its own, `g/RE` may not seem to make too much sense at first
sight, but it's actually different from `/RE`, and these are all
legal:

$ alias ed
alias ed='ed -p ed:\ '
$ ed ed.1
20317
ed: H
ed: /tuple
.Ar n Ns -tuple
ed: g/tuple
.Ar n Ns -tuple
.Ar n Ns -tuple .
ed: 200,210g/tuple
.Ar n Ns -tuple
.Ar n Ns -tuple .
ed: 200,205g/tuple
.Ar n Ns -tuple
ed: g/tuple/n
203 .Ar n Ns -tuple
208 .Ar n Ns -tuple .
ed: q
$

I've included the /n command form for clarification there.
This is my edited ed.1. YMMV w/r/t line numbers.
My ed has an `ed: ` prompt because I've aliased ed(1) to that. I would
*maybe* even weakly suggest this diff:

Index: dot.profile
===
RCS file: /cvs/src/etc/skel/dot.profile,v
retrieving revision 1.5
diff -u -r1.5 dot.profile
--- dot.profile 2 Feb 2018 02:29:54 -   1.5
+++ dot.profile 7 Jul 2019 16:17:19 -
@@ -4,3 +4,5 @@

 
PATH=$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games
 export PATH HOME TERM
+
+if (-x /bin/ed) alias ed='ed -p ed:\ '

(NB: Perhaps `alias ed='ed -p ed\>\ '` or `alias ed='ed -p ed\*\ '
would be more acceptable?)

This would be a confusion-decreasing convenience for new users, but
maybe this is imposing too much of a personal viewpoint; you tell me;
I have no strong opinion on this.

I do however have a strong opinion on the next thing I've just found:
The following diff incorporates three additional changes that fix a
documentation bug that could result in actual data loss, or at least
that's where it could lead an unwary user:

Index: ed.1

Re: ed(1) man page doesn't mention use of single / and ?

[ropers]

Second thought, maybe the 'i.e.'s should be changed to 'e.g.'s,
because '/' and '?' also work (instead of '//' and '??',
respectively), so '/re' and '?re' are indeed only examples.

Or maybe this is overdoing it. I don't know. Whatever you all think is
best and most correct. I have no strong personal opinion on this. I'm
just trying to respond to mazocomp's reasonable observation and
suggestion.

Ian

On 07/07/2019, ropers  wrote:
> mazocomp opined:
>> Hi!
>>
>> I am not good at explaining something shortly and clearly to fit into
>> proper documentation, so I'll just describe my experience here.
>>
>> Terminating regular expressions with / or ? is necessary only if they
>> are followed by commands, otherwise the following are legal in both
>> OpenBSD ed, Plan 9 ed and GNU ed:
>> /something
>> /
>> ?
>> g/ing
>>
>> I hope I made life of many ed users easier :)
>
>
>> On Thu, Jul 04, 2019 at 11:47:50PM +0200, ropers wrote:
>>> Do I understand correctly that this is in reference to these parts of
>>> man
>>> 1 ed:
>>>
>>> > /re/
>>> >The next line containing the regular expression re. The search
>>> > wraps
>>> > to the beginning of the buffer and continues down to the current line,
>>> > if necessary. ???//??? repeats the last search.
>>>
>>> > ?re?
>>> >The previous line containing the regular expression re. The search
>>> > wraps to the end of the buffer and continues up to the current line,
>>> > if
>>> > necessary.  repeats the last search.
>>>
>>> and:
>>>
>>> > (1,$)g/re/command-list
>>> >Applies command-list to each of the addressed lines matching a
>>> > regular expression re. The current address is set to the line
>>> > currently
>>> > matched before command-list is executed. At the end of the g command,
>>> > the current address is set to the last line affected by command-list.
>>> > If
>>> > no lines were matched, the current line number remains unchanged.
>>> >
>>> >Each command in command-list must be on a separate line, and every
>>> > line except for the last must be terminated by a backslash (???\???).
>>> > Any commands are allowed, except for g, G, v, and V. A newline alone
>>> > in
>>> > command-list is equivalent to a p command.
>>>
>>>
>>> If yes, then the corresponding parts of ed.1 are:
>>>
>>> 
>>>
>>> and:
>>>
>>> 
>>>
>>> I'm not actually sure how to rewrite that. Would this call for
>>> separate /re, ?re and (1,$)g/re entries, or would it suffice to say
>>> that the second question mark or slash can be omitted if immediately
>>> followed by a newline?
>>>
>>> Does anyone else have any ideas?
>>>
>>> NB: In case people haven't seen it, here's an excellent ed(1)
>>> tutorial: https://sanctum.geek.nz/arabesque/actually-using-ed/
>>> I just thought I'd mention that.
>
>
> Mohamed proffered:
>> To add to Ian's reference. "Ed Mastery" is the only book I know
>> specific to ed(1).
>>
>> Mo
>
>
> Jason McIntyre expounded:
>>
>> hi.
>>
>> if we were going to document it, i'd say it definitely wouldn;t warrant
>> adding separate entries. it would be enough to describe when the / or ?
>> were optional.
>>
>> neither freebsd nor netbsd seemingly document this.
>>
>> posix documents it for /re/ and ?re?, but not g/RE/command-list, like
>> this:
>>
>>  In addition, the second  can be omitted at the end of a
>>  command line.
>>
>> without having tested any of this, i guess we'd want to add such a note
>> to /re/ and ?re?, but not g/RE/command-list. something along the lines
>> of:
>>
>>  The second slash is optional when followed by a newline.
>>
>> you could ping a diff to tech, and see if anyone has any input that
>> could help. if no one does, i'll take it.
>
>
> Okay, so since nobody else appears to be making any pertinent noise, I
> guess it falls to me:
>
> Index: ed.1
> ===
> RCS file: /cvs/src/bin/ed/ed.1,v
> retrieving revision 1.70
> diff -u -r1.70 ed.1
> --- ed.1  26 Apr 2018 12:18:54 -  1.70
> +++ ed.1  6 Jul 2019 21:20:15 -
> @@ -269,6 +269,9 @@
>  current line, if necessary.
>  .Qq //
>  repeats the last search.
> +The second slash is optional for a bare search without any suffixed
> command, i.e.\&
> +.Qq / Ns Ar re
> +is sufficient when followed by a newline.
>  .It Pf ? Ar re ?
>  The previous line containing the regular expression
>  .Ar re .
> @@ -276,6 +279,9 @@
>  current line, if necessary.
>  .Qq ??
>  repeats the last search.
> +The second question mark is optional for a bare search without any
> suffixed command, i.e.\&
> +.Ns Qq ? Ns Ar re
> +is sufficient when followed by a newline.
>  .It \&' Ns Ar lc
>  The line previously marked by a
>  .Ic k
>
> Questions? Comments? Complaints? Secondary trade sanctions?
>
> And no, don't ask me how much of my weekend I wasted figuring out how
> to suppress mandoc's insistence upon two spaces after the 'i.e.' just
> because there's a period at the end of a line. Because *

Re: ed(1) man page doesn't mention use of single / and ?

[ropers]

mazocomp opined:
> Hi!
>
> I am not good at explaining something shortly and clearly to fit into
> proper documentation, so I'll just describe my experience here.
>
> Terminating regular expressions with / or ? is necessary only if they
> are followed by commands, otherwise the following are legal in both
> OpenBSD ed, Plan 9 ed and GNU ed:
> /something
> /
> ?
> g/ing
>
> I hope I made life of many ed users easier :)


> On Thu, Jul 04, 2019 at 11:47:50PM +0200, ropers wrote:
>> Do I understand correctly that this is in reference to these parts of man
>> 1 ed:
>>
>> > /re/
>> >The next line containing the regular expression re. The search wraps
>> > to the beginning of the buffer and continues down to the current line,
>> > if necessary. ???//??? repeats the last search.
>>
>> > ?re?
>> >The previous line containing the regular expression re. The search
>> > wraps to the end of the buffer and continues up to the current line, if
>> > necessary.  repeats the last search.
>>
>> and:
>>
>> > (1,$)g/re/command-list
>> >Applies command-list to each of the addressed lines matching a
>> > regular expression re. The current address is set to the line currently
>> > matched before command-list is executed. At the end of the g command,
>> > the current address is set to the last line affected by command-list. If
>> > no lines were matched, the current line number remains unchanged.
>> >
>> >Each command in command-list must be on a separate line, and every
>> > line except for the last must be terminated by a backslash (???\???).
>> > Any commands are allowed, except for g, G, v, and V. A newline alone in
>> > command-list is equivalent to a p command.
>>
>>
>> If yes, then the corresponding parts of ed.1 are:
>>
>> 
>>
>> and:
>>
>> 
>>
>> I'm not actually sure how to rewrite that. Would this call for
>> separate /re, ?re and (1,$)g/re entries, or would it suffice to say
>> that the second question mark or slash can be omitted if immediately
>> followed by a newline?
>>
>> Does anyone else have any ideas?
>>
>> NB: In case people haven't seen it, here's an excellent ed(1)
>> tutorial: https://sanctum.geek.nz/arabesque/actually-using-ed/
>> I just thought I'd mention that.


Mohamed proffered:
> To add to Ian's reference. "Ed Mastery" is the only book I know
> specific to ed(1).
>
> Mo


Jason McIntyre expounded:
>
> hi.
>
> if we were going to document it, i'd say it definitely wouldn;t warrant
> adding separate entries. it would be enough to describe when the / or ?
> were optional.
>
> neither freebsd nor netbsd seemingly document this.
>
> posix documents it for /re/ and ?re?, but not g/RE/command-list, like
> this:
>
>   In addition, the second  can be omitted at the end of a
>   command line.
>
> without having tested any of this, i guess we'd want to add such a note
> to /re/ and ?re?, but not g/RE/command-list. something along the lines
> of:
>
>   The second slash is optional when followed by a newline.
>
> you could ping a diff to tech, and see if anyone has any input that
> could help. if no one does, i'll take it.


Okay, so since nobody else appears to be making any pertinent noise, I
guess it falls to me:

Index: ed.1
===
RCS file: /cvs/src/bin/ed/ed.1,v
retrieving revision 1.70
diff -u -r1.70 ed.1
--- ed.126 Apr 2018 12:18:54 -  1.70
+++ ed.16 Jul 2019 21:20:15 -
@@ -269,6 +269,9 @@
 current line, if necessary.
 .Qq //
 repeats the last search.
+The second slash is optional for a bare search without any suffixed
command, i.e.\&
+.Qq / Ns Ar re
+is sufficient when followed by a newline.
 .It Pf ? Ar re ?
 The previous line containing the regular expression
 .Ar re .
@@ -276,6 +279,9 @@
 current line, if necessary.
 .Qq ??
 repeats the last search.
+The second question mark is optional for a bare search without any
suffixed command, i.e.\&
+.Ns Qq ? Ns Ar re
+is sufficient when followed by a newline.
 .It \&' Ns Ar lc
 The line previously marked by a
 .Ic k

Questions? Comments? Complaints? Secondary trade sanctions?

And no, don't ask me how much of my weekend I wasted figuring out how
to suppress mandoc's insistence upon two spaces after the 'i.e.' just
because there's a period at the end of a line. Because *