-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nested command literals don't parse correctly #32609
Comments
Could be considered a dup of #3150. |
@JeffBezanson Doesn't look like the same thing to me. #3150 is more like a feature request or something. What seems to be happening here is that the parser is failing to recognize valid syntax. julia> `echo $(`foo`) `
ERROR: LoadError: UndefVarError: @foo_cmd not defined It thinks the command literal ends when it hits the backtick inside the expression interpolation block. To me, the expected behavior is that the parser would recognize interpolation syntax and that any backticks found in that context would not be able to close the outer command literal until the interpolation expression has its closing parenthesis. I don't really need this myself, but I generally expect parsers to recognize nesting, as in, e.g. julia> "this $("that")"
"this that" I guess this is complicated by the fact that the parser transforms this directly into a call to the |
What we're doing currently, is trying to parse backticks in the parser without it knowing anything about interpolation, then using a julia macro to parse the interpolations within that. In contrast, we parse interpolations in string literals in the parser. That's why string literals can handle it but backticks can't. Hence the issue title "parse command interpolations at parse time" --- that would fix it. That issue points out a different problem, but I think they're both symptoms of the same thing. |
I see. Should I close the issue, then? |
@JeffBezanson did anyone ever think further about this? |
i have a similar seeming issue with this: # original breaks with syntax error
macro e(x::AbstractString)
run(`${ENV["EDITOR"]} $x`)
end
# my workaround
macro e(x::AbstractString)
editor = ENV["EDITOR"]
run(`$editor $x`)
end not ideal, but not a killer either |
You want |
Yeah, that's just an error because |
Closing in favor of #3150 |
Granted, people probably shouldn't be writing code this way, but this looks like a parser bug. The syntax should theoretically be kosher. Of course, this works:
The text was updated successfully, but these errors were encountered: