another way to run an external command with incorrect tty modes #2619
Description
Short version: You can execute an external command in a way that does not ensure tty modes are set to sane values. Specifically by invoking fish with the -c or --command CLI option.
Long version: Ben Yakawp started a thread on the fish-users mailing list with subject line "Problems with 'read' command in a tmux sub shell". The problem he observed has nothing whatsoever to do with tmux. The problem is that a command run via the -c (or --command) CLI option causes an external command (such as a shell script) to be run with unspecified tty modes. Prior to my PR #2578 (which addresses issue #217 to allow binding \cM separate from \cJ) the tty modes would be whatever was in effect when fish was exec'd. After my change it will be the fish shell tty modes. Those modes disable automatic echoing of input characters and mapping of \cM to \cJ (among other things).
You don't need tmux to reproduce this problem. You do need a fish built from source since commit 16c34b3. Simply create a shell script named t containing the following:
#!/bin/bash
stty -a
echo "Your name please"
read input
echo hello $input
echo "Press enter to quit ..."
read k
Then invoke it via fish -c ./t. You should see in the stty output that ICRNL mode is disabled (-icrnl). You'll also find that you can't simply press the [enter] key; you have to press \cJ at each prompt.
I'll track down why fish is executing external commands (i.e., programs) with its private tty modes and correct that bug so it uses tty modes appropriate for an external command.
P.S., There is also issue #2315 opened by @mwm who has proposed a change (PR #2317) to address a related problem. I'm beginning to think that the fish approach to handling tty modes is over-engineered and causes more problems than it prevents.