add spec test for nested subshell parse error#2399
Conversation
dd66ba4 to
23ecb4d
Compare
|
Oh yes I saw this in the logs ... I wonder if this is the same as #2337 Awhile ago I added a couple tests in I think this one might require some design; there is the issue of
In theory I think |
|
Oh great! We can close this then |
|
I was thinking about this issue, and I realized it does help to have all the real examples encoded in the spec tests The one I added was this The But this one is slightly different, so I think it's useful to have it too. And to note that it came from gzip. (hm I didn't note which package the other error is from) Because we don't know what the exact solution is yet. But they should be in the same file, I guess |
|
So yeah I think having the exact line helps, and then we can reduce to something more minimal as we fix it The reducing process is often how I figure out what the bug actually is |
|
Ah ok. I'll reopen this and plop it in |
gzip has a utility script called zdiff. It gets used at some point in
the check step when building gzip from source. It also makes use of
nested subshells in a few places. The osh parser is tripping over these.
Here's an example from a simple script.
((echo foo) | tr o 0)
^~~
_tmp/foo.sh:1: Unexpected token after arithmetic expression (Id.Word_Compound != Id.Arith_RParen)
Other shells seem to handle this case, so in preparation for an inbound
fix, this commit adds a new spec test to cover it.
23ecb4d to
d7f11fd
Compare
|
great thanks! |
gzip has a utility script called zdiff. It gets used at some point in the check step when building gzip from source. It also makes use of nested subshells in a few places. The osh parser is tripping over these. Here's an example from a simple script.
Other shells seem to handle this case, so in preparation for an inbound fix, this commit adds a new spec test to cover it.
Related to #2398