Strange side effect of read

[lsoksane]

I get strange behaviour when I run

read; git clone https://myusername@git.overleaf.com/myrepository

Git asks for a password and when I paste it in MATE Terminal it is not recognized. If I type the password it works. Everything works if I remove read; in the beginning, or if I replace it with fish -c read.

Here is some context:

fish --version
fish, version 3.2.2

echo $version
3.2.2

uname -a
Linux lo-xps 5.4.0-81-generic #91~18.04.1-Ubuntu SMP Fri Jul 23 13:36:29 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

mate-terminal --version
MATE Terminal 1.20.0

Running with

sh -c 'env HOME=$(mktemp -d) fish'

didn't affect the behaviour.

[faho]

echo $version
3.2.2

Please upgrade to fish 3.3.1, we offer PPAs at https://fishshell.com/.

[faho]

Okay, I can reproduce with fish 3.3.1, what's happening here is that bracketed paste is kept on, because it's only deactivated on preexec.

[mqudsi]

Probably a stupid question, but do we want (or maybe I should say need?) bracketed paste enabled for user-specified read invocations?

[faho]

It's probably the simplest fix. It would break pasting multline things, but tbh read typically works on single lines anyway, so meh.

[faho]

(a tentative 3.6.1, @zanchey)

[zanchey]

The more I think about this, the less I like it for a minor release that's supposed to be preserving compatibility. Surely it would be better to disable bracketed paste when read finishes reading?

[faho]

Surely it would be better to disable bracketed paste when read finishes reading?

We do not currently have an event for "when read finishes reading". There is no event that triggers:

> foo; read; bar
           ^ here

We have one that triggers before the foo (fish_preexec), before the read (fish_read) and after the bar (fish_postexec).

Honestly, ideally bracketed paste would actually be handled inside the reader directly instead of with this fish script event approach, but that's a bigger change.

This is a trade-off, because read is typically used to read a line or less (something like y/n), while running it this way breaks all later commands. This has come up a few times - I believe I came back to this after someone mentioned it on stackoverflow?

Of course if you don't like it for 3.6.1 it's your call to not take it for 3.6.1.