Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Abort when running multiple read in a row on Fish 2.6.0 #4206
Description of the bug:
When running multiple read in a row without creating a full interactive session, fish will abort.
This can be reproduced by launching:
fish -c 'read a; read b'
or executing a script such as:
#!/usr/bin/env fish read a read b
Note that this issue is also seen when running it as:
fish -i -c 'read a; read b'
This produce the following output:
The complete output of my test can be seen here: https://gist.github.com/0rax/d7392b40f61c6081a12ccc93c664d3eb
This was not present in Fish v2.5 and has been tested on ArchLinux + Fish v2.5.0.
Bug seen on:
I had replaced an
Your commit seems to have fix the issue for simple double calls but I still experience some issue with read in some context.
I first discovered this issue when running complex
This test script creates 2 functions and pass them as arguments to read for each subsection we want to test, we are doing so with:
I've done some testing to pin down the issue, and I saw that it now segv when calling read with with either
For example running
You can see my full test logs here: https://gist.github.com/0rax/2ca4b8029209d7165274a5097d9bbac8.
To go back to the context of
diff --git a/internals/__fishline_test.fish b/internals/__fishline_test.fish index f53b2f7..f12654a 100644 --- a/internals/__fishline_test.fish +++ b/internals/__fishline_test.fish @@ -16,8 +16,9 @@ function __fishline_test --argument-names segment -d 'test segments' fishline -l -s $FLINT_TEST_STATUS $FLINT_TEST_SEG end - read -R flint_test_right -p flint_test_left + read -R flint_test_right -p flint_test_left TEST_VAR + set -e FLINT_TEST_VAR set -e FLINT_TEST_SEG set -e FLINT_TEST_STATUS
It looks like this fix (5dc78dd) introduced a new regression while fixing one.
FYI : The test script I found these issues with had been working fine since it was created (since Fish 2.4.0 IIRC).
referenced this issue
Jul 17, 2017
@krader1961 oh right, it just went to the next issue then, just telling that your last commit uncovered it !
I am using it pretty much as a way to preview a prompt, this making it pretty much a side-effect (just print and ignore input), so when called without any variable name after I am expecting that either no variable is assigned or as for bash's read a default variable such as
Though as seen in your new issue, I am completely fine with forcing a variable name to be set when calling read if it's what follow fish's philosophy. This will make a script using read backward compatible but will still be a forward breaking change for older calls.
In my case, I will push my change to the repository to make sure a variable is set even though I am not using it.