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

[Rob Landley]

On 5/23/20 3:40 PM, Chet Ramey wrote:
> On 5/23/20 1:06 PM, Rob Landley wrote:
>> On 5/23/20 9:41 AM, Chet Ramey wrote:
>>> On 5/21/20 6:50 PM, Rob Landley wrote:
>>>
>>>>>> But the same command line in the current shell and in bash -c are parsing
>>>>>> different despite presumably reading the same .bashrc and friends?
>>>>>
>>>>> My guess is that the interactive shell has extglob enabled somehow, whether
>>>>> it was in .bashrc or interactively after it was started. The -c command
>>>>> shell doesn't read startup files, so that doesn't matter.
>>>>
>>>> Mine too, but grep isn't finding extglob under /etc or ~/.*
>>>
>>> I can only suggest looking in your shell history.
>>
>> It's there in each new terminal tab. It's not a thing I typed.
> 
> Maybe run `bash -x' or `bash --login -x' and see where it gets set.

Scrolled off the terminal history. Let's see...

  $ bash -x 2>&1 | tee florp.txt
  exit
  + exit

And that produces an almost empty file.

Eh, I don't care about that enough. I'm willing to accept that it's happening
somewhere and leave it at that.

>> ... can aliases expand to unbalanced ( or { ?
> 
> Yes. The way to implement aliases is to check for an alias expansion in the
> lexer before you return a WORD, and if you have one, push the expanded text
> onto the input stack and restart the read.

  $ alias potato=iguana
  $ echo potato
  potato

It's not the generic "gimme next word" parsing that's doing alias substitution,
it's the first word in a line that gets substituted (presumably after it's been
returned as a word).

>>>>   $ potato\
>>>>   > \
>>>>   > (
>>>>   bash: syntax error near unexpected token `newline'
>>>>
>>>> You're right, it does. I'm not doing that.
>>>
>>> There can't be any newlines between the word and the open paren. That's the
>>> shell grammar.
>>
>> But wasn't \ supposed to eat the newline?
> 
> Sorry, I misread it. That's not the newline it's complaining about. You
> can't have any newlines between the parens.
> 
> function_definition : fname '(' ')' linebreak function_body
> 
> Something like
> 
> potato\
> \
> (\
> )\
> { echo hello; }
> 
> works just fine.

Ok, I screwed that up too. But my question was more "read ahead by one line to
determine whether or not we're in a function affects LINENO, but doesn't
determine whether we're in a function"?

I think I'm just leaning towards "I'm gonna get LINENO wrong", because at this
point I still don't understand what LINENO is doing.

>>>> So in bash, $LINENO isn't the starting line of a multi-line span, and it isn't
>>>> the ending line of a multi-line span, it's the SECOND line of a multi-line span.
>>>
>>> No. Consider one of the original examples:
>>>
>>> echo $LINENO \
>>> $LINENO
>>>
>>> The shell has already recognized this as a simple command by the time it
>>> sees the backslash-newline pair.
>>
>>   $ echo $LINENO \
>>   > $LINENO \
>>   > $LINENO
>>   1 1 1
>>
>>   $ bash -c $'echo $LINENO \\\n$LINENO'
>>   0 0
>>
>> Wait, why's it not doing it now?
> 
> We already agreed that starting LINENO at 0 in -c command was a bug, and
> I fixed it several weeks ago.

No, I meant the LINENO on the second line isn't noticing it's on a later line,
it's now reporting the first line for both LINENOs, and I thought my initial
confusion was about it NOT doing that?

Now I've gotta reread the thread to figure out what we were talking about. (This
is why I blog into a big easily searchable text file...)

>>> Universities are famous for cast-off hardware. I wrote a considerable
>>> portion of bash-2.0 on an IBM RT in the basement of my first house running
>>> a custom version of 4.3 BSD. I wrote a troff package to do APA style so my
>>> wife could write her doctoral thesis on it.
>>
>> Did you actually get to use IBM Academic OS?
> 
> Yes. That's what I started with, since I had source. I added things from
> MIT and 4.3-tahoe and reno that IBM hadn't added and maintained the kernel
> myself.
> 
>>
>> There was this whole "everybody used BSD in 1980-1984, then AT&T paid them to
>> switch to System V" thing that isn't sufficiently documented, and I've never
>> figured out if AOS->AIX is part of that or just IBM hadn't gotten into unix yet.
> 
> AOS was a side branch for IBM. They already had a version of AIX that, I
> think, ISC did for them that ran on the RT. AOS was an offshoot of the
> support IBM gave Project Athena, and was only available to higher ed with
> the right Unix licenses. AIX 2.x was wretched; when IBM donated the RTs to
> us, it came with AIX, and we swapped it for AOS as soon as I could get the
> licensing straightened out and get the tapes.

Sadly, this part is off topic for the toybox list or it would easily take over
the conversation. :)

> Chet

Rob