On 5/23/20 8:59 PM, Rob Landley wrote:
>>> 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.
It't not an interactive shell, and won't source the startup files.
>>> ... 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).
Well, of course: the word has to be in a position that can be the first
word of a simple command, but the expansion does not have to be a simple
command. That's a basic aspect of alias expansion that all shells
implement.
>>>>> 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?
I'm not sure myself.
The backslash-newline gets removed, so the command is a single logical
line, which, since the lexer was on line 1 when the parser figured out it
was parsing a simple command, is all on line 1. The simple command gets
the line number where the lexer is when the parser reduces to a simple
command. That's definitely a yacc/bison artifact.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
