cmd/gosh: echo * in interactive mode requires further input
#835
Labels
Comments
|
Hey @mvdan can we get this fixed? I've run into this as well with my experimental Go Linux(ish) 😅 |
mvdan
changed the title
echo * in interactive mode requires further inputecho * in interactive mode requires further input
mvdan
added a commit
that referenced
this issue
Jul 3, 2022
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. |
mvdan
added a commit
that referenced
this issue
Jul 3, 2022
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.
mvdan
added a commit
that referenced
this issue
Jul 3, 2022
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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Running
echo *ingoshin 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: