Fish prints new lines when entering text

[SamTebbs33]

When entering text into the prompt, fish seems to arbitrarily print new lines, and it sometimes hides text.

Reproduction Steps:

1. Open fish via cygwin
2. Enter text and press keys while at the prompt

Expected behavior:

The shell should only go on to a new line when pressing the enter key.

Observed behavior:

It goes on to a new line arbitrarily when entering text.

In the above image, I continued to enter the command "echo "hello"" and during this fish went on to a new line arbitrarily and hid the text when I closed the speech marks.

Additional information:

This has happened ever since I installed fish.

---

Fish version: 2.2.0

Operating system: Windows 10 with Cygwin

Terminal or terminal emulator: Cygwin

---

For 2.3.1 release:

• Update release notes

[faho]

I'm sorry, the image doesn't help much.

Is it that you just "randomly" get that "test: Missing argument at index 2"? That tells me some fish script has a test invocation that isn't correct for you (most likely because a variable is unset in your environment). This fish script might be in a completion (which are run to feed into suggestions).

If it's not that, please try to explain again.

[floam]

The behavior he is trying to report is most easily noticed by looking at the "ech"... lines - you can get a temporal sense of what he experienced from that as he couldn't have caused that exact result by hitting enter and that autosuggestion is there. He typed "ech", there was an autosuggestion, and then for some reason a new prompt was printed on him down below.

But we don't really know what's going wrong aside from the test error - the main thing multiline prompts seem to do is print themselves too too much whenever everything isn't just right. Solve whatever is bombing out in windows for you in whatever script that is and you probably solve your glitch.

[faho]

Oooh, that's it!

@SamTebbs33: Can you start fish -d 3? This will print some debug output, including which completion and related scripts are run.

[SamTebbs33]

@faho @floam Here is perhaps a more representative image of the problem. Note that all I am doing is typing out "echo "hello"" and fish is printing out the prompt several times over.

I will try using fish -d 3 soon. Could this issue be down to my prompt function? (Although I use the same functions on my mac and it works perfectly)

[floam]

Please do run it with -d 3 and also let me know which prompt that is? Can you upload the actual .fish file you defined it in to here?

[SamTebbs33]

Here is the version using fish -d 3.

The output does go on, let me know if you need the rest of the debug output.

[faho]

Unfortunately that doesn't have anything of value.

Can you give us your configuration files (preferably all of them, including the fishd file)?

[floam]

Thanks but I can't see anything in there giving a hint as to that failing test case or what is going awry. Just send over the prompt code and, and actually all user scripts if you can.

The output does go on, let me know if you need the rest of the debug output.

Wouldn't hurt, you can copy and paste the text instead of doing a screenshot. But we can see that the trace doesn't have anything to offer regarding of what is going on when you actually have the weird highlighting.and duplicating prompts.

[floam]

What's with the bash error in the first screenshot? Are you running fish under bash?

[floam]

Duh!

It's choking on a carriage return there - perhaps you edited some files in notepad/wordpad? That will use the wrong kinds of line endings that unix utilities will not expect. Run all your scripts through dos2unix and see what happens.

Convert over that bash shell script cygwin is I guess running before it loads fish in order to initialize an environment, and also any fish scripts you've edited.

A decent text editor that should be safe to use that is available on Windows for free is Notepad++.

[krader1961]

The output does go on, let me know if you need the rest of the debug output.

Yes, we do. In particular that screen capture doesn't include the error message. However, for this don't use screen captures. They're too hard to read and we can't use normal text processing tools to examine them. Instead use the script command to capture everything written to the terminal. When you're done reproducing the problem type exit to exit the shell and the script capturing session. Screen captures are great when you need to convey something about the visual aspects of what you're seeing (like colors) but are not so great for anything else.

Also, like @floam mentioned, if you're editing your fish files with notepad or a similar program that insists on inserting CRLF pairs that will cause lots of problem. Either run the resulting files through dos2unix or use a different editor which doesn't do that.

[SamTebbs33]

I ran the script command, entered fish, tried to reproduce the problem and then ran exit but the "typescript" file that the script command said it would output to is empty. I fixed the line ending error when fish starts but the problem is persisting. I then ran script, ran fish d -3 and reproduced the problem and the output was successfully put into the "typescript" file, which I have attached below. I believe that I am running fish from bash, but all I did was install the fish plugin during the cygwin setup.

Here are my fish files from the "config/fish" directory: https://github.com/SamTebbs33/fish_files
Here are the files referenced in the fish config: https://github.com/SamTebbs33/dotfiles

typescript.txt

[floam]

Thanks for taking the time to collect and make available these files in a git repo Sam. Very easy to clone over git and with no worries that something converted the line endings in the mix, like if you had pasted the code into the text box on this issue.

[krader1961]

The problem is due to this line in your prompt.fish:

if [ $branch != "" ]

If you're not in a git repo $branch is empty. You need to either quote the var

if [ "$branch" != "" ]

or use the fish idiom to see if the var has at least one value

if set -q branch[1]

Also, in fish the [...] syntax is discouraged in favor of explicitly calling the test command. Note that [ is just a symlink to test and was created to make commands doing argument tests look more like other languages of that era.

[krader1961]

FWIW, To verify what I said above you only need to cd to a directory that is not a git repo and execute

$ set -l branch (git branch ^/dev/null | sed -n '/\* /s///p')
$ count $branch
0
$ test $branch != ""
test: Missing argument at index 2

[SamTebbs33]

@krader1961 Thanks for the help! I amended my mistake in not surrounding the variable with speech marks, but the problem with the prompt is persisting.

[faho]

Okay, so there's two problems, one of which you fixed.

The main issue here (the weird prompt-showing-up-again-and-again) might be related to your history (which we check for suggestions) - can you post your history file? I'm not sure where it is under windows, with 2.2.0 it should be a file called "fish_history" in the same directory as your config.fish.

[SamTebbs33]

@faho Here it is!
fish_history.txt

[faho]

@SamTebbs33: I'm not sure it's the same issue, but when running with your history file, my fish hangs. Converting it to unix line endings makes it work. Maybe try that?

[SamTebbs33]

@faho Nope, the prompt is still being re-printed!

[krader1961]

@SamTebbs33: I installed most of your environment on my machine. Your prompt works just fine for me. I'm willing to bet the problem is with the escape sequences fish is emitting when it draws your left and right prompts. I noticed from your problem statement and the fish debug output that you're running fish under Cygwin. Do you see this problem on a Linux or other UNIX distro? What terminal are you using? You said cygwin but I thought you needed to use msys, mintty, or something similar to get a unix like terminal emulator under cygwin. What does echo $TERM report?

[krader1961]

Also, I noticed in the config files you uploaded you have a functions/fish_prompt.fish file and a dotfiles/prompt.fish which defines the fish_prompt function you're actually using. You should probably delete the former.

[SamTebbs33]

Sorry for the lack in a reply, I have been and will be visiting family until later this month. I will get back to the issue once I once again have access to my pc!

[Dr-Emann]

To bring in some info from #2003, and some testing I just did:

• This issue only occurs on cygwin, the same fish_prompt function on linux does not exhibit the same behavior.
• It is not related to mintty: running in cygwin, on mintty, I can ssh to a machine with a multiline prompt, and the issue is not present.

The easiest way to reproduce is to run the following at an interactive fish shell, running on cygwin

function fish_prompt
    printf '\n>
end

[krader1961]

I propose an experiment: build fish without the code that writes the char sequence that attempts to ensure the prompt never overwrites output that does not end with a newline. I'm happy to write a patch but someone else will have to compile and test it since I don't have a MS Windows machine setup for development.

[barksdml]

krader1961, I built fish (on cygwin) without the code that causes #789, and that problem no longer occurs. However, the repeating multi-line prompt does occur (I'm using ConEmu, not mintty). I have double checked that my fish_prompt file uses unix style line endings, and when I run fish with -d 3 the only thing I see is that path_get_path gets called a lot (but that's the case for a single line prompt as well). I would be happy to test some things out in Sam's absence so we can make progress on this.

[krader1961]

@barksdml: Do you have the script command to capture all output to your terminal? If so it might help to see a minimal recreation of the problem within its environment. I also noticed that this issue does not mention the language locale that fish is operating within. What does locale report on your system? My apologies if these questions seem strange but I haven't used a CLI on MS Windows for at least a decade. The script and locale commands are usually present on UNIX/Linux systems.

Also, what does echo $TERM report? And why do you think whatever the value reported is reasonable for your environment?

[barksdml]

@krader1961 Here is the file output by script and the corresponding screenshot of the view in the terminal. It's hard to make sense of the script output because of the color codes everywhere. You can see the output of echo $TERM (cygwin) and and locale in the screenshot -- it appears that no language is set.
This was the prompt I set:

    function fish_prompt
        echo "line1"
        echo "line2 \$ "
    end

As you can see, line1 was never supposed to have a $ at the end...
typescript.txt

[arturocastro]

@krader1961 Repeating multi-line prompt occurs on my setup as well, let me know how I can help out.

With fish -d3, on input, a single path_get_path call is printed out.

Testing with:

function fish_prompt
 echo -e "\n"
end

If no \n are echo'd, the issue does not occur (eg. this modification of the pure theme is free from the issue and works well).

echo $TERM is xterm-256color
locale is:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

Fish 2.2.0, Cygwin 2.874 (64 bit) on Win7, mintty.

Screen (I just pressed a bunch of "s", I did not press enter):

[SamTebbs33]

I'm back at my PC, what else can I do?

[krader1961]

I installed a copy of Windows 10 so I could explore the new Windows Subsystem for Linux. I also installed the latest Cygwin. I am able to reproduce the problem in both environments. TERM is xterm in both. Running infocmp -L xterm and comparing the output to that on my OS X system shows only a couple of inconsequential differences:

32a33
> enter_dim_mode=\E[2m,
33a35
> enter_italics_mode=\E[3m,
43a46
> exit_italics_mode=\E[23m,
175c178
< set_attributes=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
---
> set_attributes=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,

The "<" lines are OS X, the ">" lines Windows xterm settings.

The output captured by the script command shows the presence of two \cM characters on the windows system before the prompt is repeated. Those \cM chars aren't in the output on the OS X or Linux systems.

[krader1961]

The problem is that s_check_status() in screen.cpp is getting a different modified timestamp for stdout and stderr than it previously cached. That is causing fish to think some other program wrote to the terminal and thus it can't trust the state of the screen which forces the prompt to be rewritten. This happens if you just press [backspace] at the prompt. Why the timestamp is changing on MS Windows but not UNIX is TBD. My guess is that MS Windows has a single timestamp updated by reads and writes and that just reading from the tty updates that shared timestamp.

[krader1961]

A lot of googling didn't yield any answers. But empirical testing shows that that the MS Windows tty has a single timestamp updated when anything is written by a program or typed by the user. That breaks a fundamental assumption made by the fish code.

[krader1961]

It's worse than I thought. The tty device doesn't even have a single activity timestamp. The struct stat timestamps are always the current time when calling fstat() on a tty file descriptor regardless of whether anything has been written or the user has typed anything. Which means it is less than useless. They could have had the decency to put a zero in the stat struct timestamp fields rather than the current time to make it obvious the timestamps are useless.

[SamTebbs33]

I can confirm that the latest update installed with Cygwin has fixed the issue. Thanks for sorting it out!

[SamTebbs33]

The fixed version does not seem to be updated to the apt-get servers. I tried using apt-get to install fish into the Windows 10 Linux subsystem and the bug is present.

[faho]

@SamTebbs33: That of course depends on which repository you use. If you use Ubuntu 16.04's repos, you'll get 2.2.0.

You need to add our PPA to get 2.3.1.