Re: interactive documentation for read builtin differes from manual, leaves out critical info

On 7/27/26 11:51 AM, Britton Kerin wrote:

> Ok, but the help should still aim for a level of specificity that's
> consistent feature-to-feature.  The help output for the -t option to
> read goes into considerable detail about behavior including return
> code, behavior on 0, etc., but it doesn't mention the conditions under
> which the option is operative *at all*.  That's highly inconsistent
> specificity and should be fixed. 

I disagree. The current text describes the effect of various arguments to
`-t', since `timeout' is included in the synopsis.

`read' reads from standard input (leaving -u aside for a moment), and
the documentation doesn't go into all the variations in behavior that can
occur based on the type of file descriptor stdin is. Should it?

The `help' builtin exists to provide quick help for the most common
modes of operation. The man page/info file is where you go for all the
nitty gritty. I think the `read' split is ok.

(As an aside, what kind of timeout are you using here? And where is the
file? Even if `read' didn't ignore the timeout for regular files, you'd
have to have an extremely short timeout to see any effect with a local
regular file.)

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [email protected]    http://tiswww.cwru.edu/~chet/

-----BEGIN PGP SIGNATURE-----

wmMEABEIACMWIQR8ATX7CIqvbGbGULm7WGnwZOp0qwUCanOZFQUDAAAAAAAKCRC7WGnwZOp0qzkT
AKCGm0i4TJjkfStwBNYT7LoFB0uJqwCfeTRJ685GrRmTZxvT2VQviO0noqY=
=SwzN
-----END PGP SIGNATURE-----