On Sat, 16 Nov 2024 at 15:01, Robert Elz <k...@munnari.oz.au> wrote:

>     Date:        Sat, 16 Nov 2024 14:05:17 +1000
>     From:        Martin D Kealey <mar...@kurahaupo.gen.nz>
>     Message-ID:  <CAN_U6MXQJ9cy2d9XMgjGgfU8=
> d1_ebrgbusb2u1sxhyloqq...@mail.gmail.com>
>
>   | I know, but "explicitly" is not the same as "highlighted", let alone
> "well
>   | enough".
>
> Please, nothing at all like you're suggesting.   Man pages are not, and
> not intended to be, tutorials.
>

In the general case I agree; man pages should be reference manuals, not
tutorials.

But in this case we have a language that simultaneously *looks* familiar,
but *actually* has an unfamiliar grammar, radically different semantics,
and a large number of intricate behind-the-scenes interactions. As a
result, some significant fraction of users are going to overestimate how
well they understand it, and prematurely skip from the "tutorial" phase to
the "reference manual" phase.

If nothing else, the manual needs to point out, in unequivocal ways that
cannot be missed, that they really *don't* understand it as well as they
think they do, and that they need to go study a tutorial before doing
anything else (and especially before submitting a bug report). And that
needs to be right up front, where they cannot miss it.

I would hope that this idea isn't controversial, but if you feel my idea
misses something important then please let me know. If you agree with the
idea, then I would welcome suggestions for improving the wording below,
which I offer as a tentative implementation of the idea above.

(Insert this between the "Copyright" and "Description" sections)


*“PrefaceDear reader, if this is your introduction to the Shell programming
language, please be aware that although it may look like other languages
you are familiar with, such similarity is deceptive. The shell language is
different in subtle and non-obvious ways from all (*1) other languages, and
making assumptions based on what you know from other languages will lead
you into traps. Please read the "Shell Grammar" section, allowing **time to
digest it **slowly and thoroughly, and then read at least one of the
recommended tutorials listed in appendix B. If you are unsure whether you
fully understand the Shell, please take the test in appendix A.”*


(Insert this after the "Bugs" section)





*“Appendix A: a self-test to check understanding of basic principles.If you
have trouble answering these questions then you should read one of the
tutorials in Appendix B before consulting this manual. It will also be
helpful to read the "Shell Grammar" section. Please write down your answer
to each question, and then run its code (*2) to see if its behaviour
matches your answer. There is no pass or fail mark, but any mismatch
indicates that you would likely benefit from revision.*
*1. What will be displayed when you run this: foo=bar ; echo zot | read foo
; echo "$foo"*

*2. What will be displayed when you run this: export foo=bar ; foo=zot ;
env | grep ^foo=*
*3.  ...” *(additional questions welcome)


*“Appendix B: Recommended TutorialsBefore consulting this manual, we
recommend reading: https://mywiki.wooledge.org/BashGuide
<https://mywiki.wooledge.org/BashGuide> *http://guide.bash.academy/* etc...
We recommend avoiding the so-called Advanced Bash-Scripting Guide on *
tldp.org <https://tldp.org/LDP/abs/html/>
*...”*(additional reading suggestions welcome)

-Martin

(*1: yes I know it's an offshoot of the UNIX v7 shell, and other similar
languages were designed around the same time, but they're all dead now, and
certainly won't be encountered by a neophyte reading this manual page in
2024.)

(*2: this may require some finessing of nroff to ensure that it does NOT
substitute curly quotes or otherwise mess with the shell syntax, so that
users can simply copy & paste the example code to test it)

Reply via email to