It's a fair point but I think there may be a reasonable middle-ground, in which common pitfalls are briefly addressed in TFM, but the manual doesn't become bogged down with exhaustive detail of every possible pitfall.
After all, information overload would just become another thing preventing readers from absorbing the information. ----- Original Message ----- From: "Greg Wooledge" <wool...@eeg.ccf.org> To:<bug-bash@gnu.org> Cc: Sent:Thu, 29 Jun 2017 15:39:20 -0400 Subject:Re: mapfile doesn't accept input from a pipe On Thu, Jun 29, 2017 at 03:22:24PM -0400, tetsu...@scope-eye.net wrote: > So I look at this not just as a RTFM issue, it's a pitfall built-in to > the design of the language, and programmers need to understand a bit > about the implementation of the language to understand what's going > on. As such I think it may be worth spelling it out a bit more > directly in terms of the implications here. For instance, stick it in > the help for 'read' and 'mapfile': If you include helpful text about every pitfall in every builtin, the bash documentation will become three times its current size.
