A documentation coincidence

[G. Branden Robinson]

Hi Chet,

I just saw this pass by:

  commit 9d1eb43fdd363137dd687bc411b14ab4946f939c (HEAD -> devel, origin/devel)
  Author: Chet Ramey 
  Date:   Tue Oct 8 09:52:21 2024 -0400

  First set of documentation updates to man page, texinfo manual

What a coincidence!  I was preparing a big batch of updates myself.
Attached for your edification, not so much for integration, as I'm sure
many of them won't apply now.

Reckon I'll see how your updates settle out before restarting this work.

Good to see the docs getting some love.

Regards,
Branden


bash.1-patches.tar.gz
Description: application/gzip


signature.asc
Description: PGP signature

AW: Re: read command sometimes misses newline on timeout

[Thomas Oettli via Bug reports for the GNU Bourne Again SHell]

Well, that sounds like a challenge. Please let me know if I can help you in any 
way.
I am running many Gentoo systems that use binary packages built on my own 
buildhost,
therefor it is fairly easy for me to patch the current version of Bash and test 
it on some systems.
Thanks in advance for your help.

  *
Thomas


Von: Martin D Kealey 
Gesendet: Dienstag, 8. Oktober 2024 06:23
An: Martin D Kealey 
Cc: Thomas Oettli ; bug-bash 
Betreff: [EXT] Re: read command sometimes misses newline on timeout

CAUTION: This email originated from outside the SFS organization. Do not follow 
guidance, click links or open attachments unless you recognize the sender and 
know the content is safe.
MAIL FROM:  <@mar...@kurahaupo.gen.nz>  Report as Spam / Check 
Mail

OK, running a similar test with instrumentation gets:

$ time (
  trap ' echo BANG ' SIGALRM ;
  while :; do printf TEST; sleep .00$((1+RANDOM%2)); echo; done |
  for ((r=10 ;r>0; --r)) do line= ; read -t .002 line; rc=$?; [[ $line = 
TEST ]] ; echo "STATUS $rc $? $line" ; done
 ) |&
  sort | uniq -c

  1 +# Hit read timeout SIGALRM, run from line 699 in ./read.def #+ STATUS 
142 1 TES
  1 +# Hit read timeout SIGALRM, run from line 72 in zread.c #+ STATUS 
142 1
  2 +# Hit read timeout SIGALRM, run from line 865 in ./read.def #+ STATUS 
142 1 T
  1 +# Hit read timeout SIGALRM, run from line 865 in ./read.def #+ STATUS 
142 1 TES
 16 +# Hit read timeout SIGALRM, run from line 913 in ./read.def #+ STATUS 
142 0 TEST
   1721 +# Hit read timeout SIGALRM, run from line 913 in ./read.def #+ STATUS 
142 1
  3 STATUS 0 0 TEST
  32649 STATUS 0 1
  34367 STATUS 142 0 TEST
  31235 STATUS 142 1
  2 STATUS 142 1 EST
  2 STATUS 142 1 T

real3m21.411s
user1m14.054s
sys 1m46.493s

That's to say, that out of 10 reads:

  *   0.003% had both `read` returning 0 and filling var with TEST.
  *   34.4% had `read returning non-zero but filling var with TEST.
  *   32.6% had `read` returning 0 but leaving var empty (which is presumably 
the delayed bare newline after previously filling the var with TEST but 
returning 142).
  *   1.7% were handled by `check_read_timeout()`, and all had read returning a 
status of 142 (and leaving var empty).

I note that 1721+32649-34367=3 so I infer that the last 3 cases are 
interconnected:

Of that 1.7% almost all were handled by this section of read.def:
  /* I don't think this clause ever tests true. */
  if (skip_ctlnul && saw_escape && i == 1 && input_string[0] == CTLNUL)
saw_escape = 0; /* Avoid dequoting bare CTLNUL */

  input_string[i] = '\0';
  check_read_timeout ();

#if defined (READLINE)
  if (edit)
free (rlbuf);
#endif

-Martin
PS: I've since run other tests that confirm the association I noted above, but 
I didn't keep the output. I'll run them again if anyone wants to see a more 
precise demonstration.