[Toybox] Would someone please explain what bash is doing here?

[Chet Ramey]

On 5/17/20 7:11 AM, Rob Landley wrote:
> I had a reply window open to this when my laptop battery died, and thunderbird
> doesn't store unfinished messages like kmail and vi and chrome...
> 
> Anyway, I was reminded of this thread by:
> 
>   $ IFS=x; ABC=cxd; for i in +($ABC); do echo =$i=; done
>   =+(c=
>   =d)=
>   $ bash -c 'IFS=x; ABC=cxd; for i in +($ABC); do echo =$i=; done'
>   bash: -c: line 0: syntax error near unexpected token `('
>   bash: -c: line 0: `IFS=x; ABC=cxd; for i in +($ABC); do echo =$i=; done'
>   $ readlink -f /proc/$$/exe
>   /bin/bash

Yes, you need extglob to get a word like +(xyz) to parse unquoted. Since
the word list following `in' is subject to pathname expansion, it's valid
in that context.

> 
> (I tried inserting shopt -o extglob; and shopt +o extglob; at the start of the
> -c and it didn't change anything?)

Because extglob isn't one of the `set -o' options. I wanted `shopt' to be
suitable to set all the shell options, so it understands -o and o and can
modify the `set -o' option set. You want `shopt -s extglob'.

> Generated code exists and has its costs whether or not you had to manually write
> it. 

Sure. I'm comfortable with the tradeoff  to this point. There are other
things I'd rather work on than writing a new parser.

> 
>>> which said to _me_ that the parsing order of operations is
>>>
>>> A) keep parsing lines of data until you do NOT need another line.
>>>
>>> B) then do what the lines say to do.
>>
>> Roughly, if you mean "complete commands have been resolved with a proper
>> terminator" and "execute the commands you just parsed."
> 
> The execution can be deferred arbitrarily long (you may be defining a function)
> or never (the else case of an if statement that was true), but yeah.

In a way. A function definition is a compound command with a separate exit
status, and it's the `if' command we're talking about here, not its
constituent parts, some of which may indeed never be executed.




> Anyway, that structure needs an "int lineno" added that gets snapshot from the
> global TT.lineno, and what I've learned from all this is it gets snapshot at the
> end when we close out the sh_pipeline and start the next one, not at the
> beginning when it's allocated. (That's the observation that makes the behavior
> make sense now.)

No. Kind of in the middle. Consider the following:

echo \
one \
two \
$LINENO \
done

Bash will always expand $LINENO to 2 in this construct, since it was on
line 2 when it figured out it was parsing a simple command.

> Last time I looked up youtube clips for the princess bride "once his HEAD is in
> range HIT IT WITH THE ROCK", and winnie the pooh "bear of very little brain",
> but I haven't got the spoons to do that again.

You fell victim to one of the classic blunders.

>> You can probably get away with it as long as that option parsing code stops
>> at the first word that doesn't begin with `-'.
> 
> That's literally one character ("^" at the start of the option string in the
> middle argument of the NEWTOY() macro.)

You've lost me there. Are you saying that you use ^ to mean something when
parsing options?


>>> Documenting this as a deviance from <strike>posix</strike> the bash man page
>>> seems the better call in this instance. 
>>
>> Documenting what as a deviation? POSIX doesn't do long options; you can do
>> whatever you like with them.
> 
> My shell standard isn't posix, the standard I'm trying to implement is the bash
> man page.
Then why recommend that I document it as a deviation from something POSIX
doesn't standardize?

>>> These days I handle that sort of thing by waiting for somebody to
>>> complain. That way I only add missing features somebody somewhere actually _uses_.)
>>
>> It has to be a lot more than one person.
> 
> Yeah, but if I'm on the fence about it to begin with it only takes one person to
> confirm "yeah, that's actually used".

Sometimes. I'm not getting paid for any of this; if I implement something
new it has to be something I think is valuable or will pay off in the long
run, or something lots of people are requesting.

> Also, Elliott speaks for the Android userbase. They ship a billion devices
> annually. When he tells me he needs a thing, it carries some weight. (We argue
> about how and where, but "what" is generally a foregone conclusion.)

Sure. The Linux distros play the same role for me, though I did get some
good input from the Solaris guys a while back.

> Yes and no. There's bsd and macos support now, and post-1.0 I might put some of
> my own effort into expanding the BSD side of it. (MacOS is a cross between
> "BSD's downstream" and "a weird proprietary mega-corporation that can sign a
> check if it wants me to care", but Elliott has users who build AOSP on MacOS and
> borrows a laptop to do fixups there every six months or so, and sends me patches.)

I do all my development on Mac OS X and do testing and some debugging on
Linux. But I don't pretend that Apple is ever going to update the bash
version they ship, and I know they're going to try and deprecate it due to
licensing issues, so I don't spend any time putting in anything Mac OS-
specific. Most of the proposals -- even the bad ones -- come from the Linux
side.


>>> It's a pity posix is moribund.
>>
>> It's not dead, just slow.
> 
> Give him time.

I think you give Jorg a lot more credit for influence than he deserves.

> 
>> https://www.austingroupbugs.net/view.php?id=789
>>
>> So we started talking about this in some official proposed way in 2013,
>> continued sporadically until 2018, decided on some official text to add
>> to the standard in September, 2018, and it will be in the next major
>> revision of Posix, issue 8.
> 
> There's going to be an issue 8? 

Yes, Geoff is preparing the document now.

Posix has been replacing issue 7 in place doing
> the "continuous integration" thing (grab random snapshot du jour from the
> website and call it good, no two people ever experience quite the same version)
> for 12 years now.

That's mostly up to the open group, not the people working on the standard
itself.

> (I ranted a lot more here last time in the email that got lost. Probably a good
> thing.)

About release schedules? How much more is there to say about them? I mean,
release engineering is complex, but it doesn't seem like there are that
many new topics to consider.

> I only started using bash in 1998. :)

And it was 10 years old at that time. Man, we've come a long way.


>   If your current locale setting has an appropriate gettext database installed,
>   $"strings" get looked up and replaced with translated versions, otherwise
>   they act like normal double quoted strings. Also, "bash -D SCRIPT" will show
>   you all the $"" strings in a SCRIPT so translators can make a gettext database
>   for a new $LANG.

Pretty much.

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