ency would be a focus of those forum threads.
Given, "in" is a unique case, there likely will never be a "consistent
policy" for it, until there is an addition to bash, of a second such
RESERVED WORD, that can never be used as the first word. Only then,
will any progress be made in determining, in discussing, in setting a
consistent policy.
So, I forgo thinking that 'now' is good time to discuss policy. It
would waste everyone's time, as compared to making this a single
management decision, to make a one time edit to the man page.
I see the issue as one of: Is there a volunteer who can step up to make
code changes and man page edits, for this issue, that the other
involved configuration control staff can 'quickly' agree to, so as to
not waste the volunteer's time and effort?
That said, any improvement in the man page, would be faster than coding
and testing. Managing this issue as solely a documentation change is
easy at this time. Very easy, compared to doing a change to the syntax
parsing error processing algorithm, for this one "unique" RESERVED
WORD. A man page edit is my recommendation. No code changes.
And when a second such RESERVED WORD is invented, only then would code
changes be justified, the volunteer time be worth it, in addition to
the man page edit to support the behavior coded into bash for this
second word. And even then, perhaps the third reserved word is the
decision point, not the second, as again, for the second word, easy,
lowest cost, by far, is to the edit the man page to cover the
condition.
Only the expert coder of the 2nd word would truly know the cost benefit
of changing the syntax error message, to reflect the true condition.
I have not looked at the code, so ... I defer to the experts, and the
druthers of the coder of the 2nd reserved word syntax parsing. And to
those who talk to him, and ask him, what is the effort level, to
support a truly useful error message, for the 2nd word, and if they
would code the same for the word "in".
That's one man's opinion. He is not changing it.
Peter
P.S. Volunteer time is the most precious commodity on this planet. It
created "Ecology." Which then cleaned up the air, water and food, and
greatly increases the quality of living for every individual on this
planet. Volunteer time generates over 100 trillion dollars in economic
benefit via the concept of "open source" - code that rejects the past
failures, since 1957, on how not to implement an algorithm, and used
only the best algorithm known at the time. Open source will enable us
to travel to the rest of Solar System, and see the Milky Way. That
Pale Blue Dot is the single nest of humanity. We must get off this
planet, for long term survival. Only Open Source can do this, as it's
less expensive. You heard it here first.
On Mon, 2019-11-25 at 20:15 -0500, Clint Hepner wrote:
> > On 2019 Nov 25 , at 4:43 p, Peter Benjamin
> > wrote:
> >
> >
> > Description:
> > 'in' is a builtin command and is not listed in the man page as
> > such.
> >
> > Repeat-By:
> >
> > type at the bash command line:
> >
> > $ in
> > bash: syntax error near unexpected token `in'
>
> This should be a big hint that it is *not* a built-in command. If it
> were, you would have run the command, not gotten a syntax error.
>
> >
> > Why is this bug report important? Why change the man page? I
> > wasted
> > 20 minutes of my time, to prove to my satisfaction that 'in' was
> > not
> > invoking my script at all. Search engines did not find a match to
> > the
> > error message. I can not imagine this report is the first time
> > this
> > bug was found.
>
> Given that ``in'' *is* documented as a reserved word
>
> RESERVED WORDS
>Reserved words are words that have a special meaning to
> the shell. The
>following words are recognized as reserved when unquoted
> and either the
>first word of a simple command (see SHELL GRAMMAR below)
> or the third
>word of a case or for command:
>
>! case coproc do done elif else esac fi for function
> if in select
>then until while { } time [[ ]]
>
> the question becomes, what change to the man page do you think would
> have helped you
> find this more quickly?
>
> One thing that comes to mind would be a short (though off-topic)
> entry in
> the SHELL BUILTIN COMMANDS section, like
>
> in
> See the Compound Commands section under SHELL GRAMMMAR. Used
> to form the ``case'', ``select'', and ``for'' commands.
>
> I don't really li
