Skip to content
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

Closed
ninjaaron opened this issue Jul 17, 2019 · 9 comments
Closed

nested command literals don't parse correctly #32609

ninjaaron opened this issue Jul 17, 2019 · 9 comments
Labels
parser Language parsing and surface syntax

Comments

@ninjaaron
Copy link
Contributor

julia> run(`echo $(read(`ls /`, String))`)
┌ Warning: special characters "#{}()[]<>|&*?~;" should now be quoted in commands
│   caller = ip:0x0
└ @ Core :-1
ERROR: syntax: invalid syntax (incomplete #<julia: "incomplete: premature end of input">)

julia> versioninfo()
Julia Version 1.1.1
Commit 55e36cc308 (2019-05-16 04:10 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.1 (ORCJIT, haswell)

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:

julia> cmd = `ls /`
`ls /`

julia> run(`echo $(read(cmd, String))`)
@JeffBezanson
Copy link
Member

Could be considered a dup of #3150.

@JeffBezanson JeffBezanson added the parser Language parsing and surface syntax label Jul 17, 2019
@ninjaaron
Copy link
Contributor Author

ninjaaron commented Jul 17, 2019

@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 cmd macro without actually looking at what's inside the string. Still, the current behavior is unexpected from a user's perspective, especially since the same approach to nesting works in string interpolation.

@JeffBezanson
Copy link
Member

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.

@ninjaaron
Copy link
Contributor Author

I see. Should I close the issue, then?

@alok
Copy link

alok commented Mar 20, 2021

@JeffBezanson did anyone ever think further about this?

@alok
Copy link

alok commented Mar 20, 2021

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

@simeonschaub
Copy link
Member

simeonschaub commented Mar 20, 2021

You want `$(ENV["EDITOR"]) $x​`​. Curly brackets are not valid interpolation syntax.

@StefanKarpinski
Copy link
Member

Yeah, that's just an error because {ENV["EDITOR"]} is not valid Julia syntax. Unrelated to this issue.

@c42f
Copy link
Member

c42f commented Jan 2, 2022

Closing in favor of #3150

@c42f c42f closed this as completed Jan 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
parser Language parsing and surface syntax
Projects
None yet
Development

No branches or pull requests

6 participants