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

[enh]

On Mon, May 18, 2020 at 8:41 AM Chet Ramey <chet.ramey at case.edu> wrote:
>
> 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.

`export BASH_SILENCE_DEPRECATION_WARNING=1` ftw :-)

> >>> 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/