-
-
Notifications
You must be signed in to change notification settings - Fork 348
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
cmd/gosh: echo *
in interactive mode requires further input
#835
Comments
Hey @mvdan can we get this fixed? I've run into this as well with my experimental Go Linux(ish) 😅 |
echo *
in interactive mode requires further inputecho *
in interactive mode requires further input
The lexer wants to know if literal characters like `*` or `@` are followed by `(`, because then they would be an extended globbing expression like `@(pattern-list)`. However, the current implementation first peeked for the bytes `()`, to detect function declarations like `@() { ... }`. Unfortunately, this caused interactive shells to hang on `echo *` followed by a newline, as a newline is a single character. To work around the problem, only peek `()` if we first peek `(`. Moreover, the logic to call Parser.fill in Parser.peekBytes seems wrong. The conditional definitely needs to use len(s), as that is the number of bytes we want to look for. The new logic seems clearly better; we call Parser.fill when p.bs contains fewer remaining bytes than len(s). Note that we no longer loop on that logic, because we have zero tests exercising that edge case, and I am slightly worried about endless loops until we properly test those edge cases. Fixes #835.
Took a brief look, wasn't as tricky to fix as I initially thought. It looks like this was a somewhat recent regression, from #771. |
The lexer wants to know if literal characters like `*` or `@` are followed by `(`, because then they would be an extended globbing expression like `@(pattern-list)`. However, the current implementation first peeked for the bytes `()`, to detect function declarations like `@() { ... }`. Unfortunately, this caused interactive shells to hang on `echo *` followed by a newline, as a newline is a single character. To work around the problem, only peek `()` if we first peek `(`. Moreover, the logic to call Parser.fill in Parser.peekBytes seems wrong. The conditional definitely needs to use len(s), as that is the number of bytes we want to look for. The new logic seems clearly better; we call Parser.fill when p.bs contains fewer remaining bytes than len(s). Note that we no longer loop on that logic, because we have zero tests exercising that edge case, and I am slightly worried about endless loops until we properly test those edge cases. Fixes #835.
The lexer wants to know if literal characters like `*` or `@` are followed by `(`, because then they would be an extended globbing expression like `@(pattern-list)`. However, the current implementation first peeked for the bytes `()`, to detect function declarations like `@() { ... }`. Unfortunately, this caused interactive shells to hang on `echo *` followed by a newline, as a newline is a single character. To work around the problem, only peek `()` if we first peek `(`. Moreover, the logic to call Parser.fill in Parser.peekBytes seems wrong. The conditional definitely needs to use len(s), as that is the number of bytes we want to look for. The new logic seems clearly better; we call Parser.fill when p.bs contains fewer remaining bytes than len(s). Note that we no longer loop on that logic, because we have zero tests exercising that edge case, and I am slightly worried about endless loops until we properly test those edge cases. Fixes #835.
I can confirm your patch fixed this bug. But now I'm wondering, does this library support globbing on the shell? It doens't seem to 🤔 |
It certainly should. The test I added shows it, since it matches main.go and main_test.go. |
Yeah I saw. Don't worry it's likely a bug in my implementation of |
Running
echo *
ingosh
in interactive mode hangs forever until you press enter (or ^D):Running
echo **
requires pressing enter twice:Weird.
Originally posted by @theclapp in #834 (comment)
The text was updated successfully, but these errors were encountered: