Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(fish shell) cannot run read command in .envrc #967

Open
masayoshi644 opened this issue Jul 11, 2022 · 2 comments
Open

(fish shell) cannot run read command in .envrc #967

masayoshi644 opened this issue Jul 11, 2022 · 2 comments
Labels

Comments

@masayoshi644
Copy link

Describe the bug
I set the read command in my .envrc file. But the command cannot run in fish shell; When I use it in bash, it can run without trouble.
It apparently cannot accept keyboard inputs in fish shell. If you have any idea, could you give me, please?

To Reproduce

  1. Create a .envrc file as the below.
echo -n "test:" && read test
echo $test
  1. Run direnv using fish shell.

Expected behavior
I am supposed to be able to input keyboard events, but I don't know why I cannot do it using fish shell.

Environment

  • OS: macOS Catalina
  • Shell: fish
  • Direnv version: v2.29.0

Additional context
Perhaps, it might be fish shell trouble, because bash can run without trouble. Also, My friend said zsh is also run without problem.

@mike-lloyd03
Copy link

I think I found the cause for this and a workaround.

If you add stty sane at the top of your .envrc, read commands work as expected:

stty sane
echo -n "test:" && read test
echo $test

This is because direnv is setting some different terminal line settings when running the .envrc file. This is what I get when running stty -a in a normal fish session:

speed 38400 baud; rows 43; columns 188; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc

And this is what I get when I add stty -a to my .envrc:

direnv: loading ~/repos/rudric/.envrc
speed 38400 baud; rows 43; columns 188; line = 0;
intr = ^C; quit = <undef>; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = <undef>; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc

Key differences when running stty -a in .envrc:

  • quit and susp keys are undefined

The following settings are disabled in .envrc but enabled normally:

  • icrnl (map carriage return to newline on input)
  • isig (generate signals on interrupt, quit, suspend, or flow control)
  • icanon (enable canonical input processing)
  • iexten (enable implementation-defined input processing)
  • flusho (output is being flushed)
  • echoctl (echo control characters as ^(Char))
  • echoke (kill character is echoed by erasing each character on the line)

This setting is enabled in .envrc but disabled normally:

  • extproc (external processing)

(Thanks ChatGPT for explaining all that to me).

Also, stty -a outputs the same thing for bash whether it's run inside the .envrc or outside, which probably explains why this only happens on Fish.

I'm not sure if these differences are intentional or not. Perhaps a dev can shed some insight. I'd be happy to open a PR if someone could point me in the right direction.

@masayoshi644
Copy link
Author

@mike-lloyd03

Thank you for your comment!

I'm not sure if these differences are intentional or not. Perhaps a dev can shed some insight. I'd be happy to open a PR if someone could point me in the right direction.

I don't know if it's appropriate to open the PR, but your comments and the workaround will be helpful to many.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants