2

I have a fairly large Rails project that always returns the following after every command in the Rails console:

stty: 'standard input': unable to perform all requested operations

This only happens within TMUX. Without using TMUX I don't see this output.

I'm also not seeing this behavior with smaller Rails projects within TMUX.

I'm on Mac OS Mojave with iTerm 2 (nightly build) and am using vanilla TMUX (i.e. no special configs).

Any ideas?

In response to Joseph Tingiris question:

In TMUX I get:

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

› echo $TERM
screen-256color

Outside of TMUX I get:

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

› echo $TERM
xterm-256color
Nathan
  • 93

1 Answers1

2

Had the same issue using pry in tmux within iTerm2.

This GitHub issue helped me discover that the version of stty provided by gnubin coreutils was overriding the OSX standard /bin/stty.

I modified my PATH to resolve /bin/stty first, and the errors went away.

James Bowman
  • 36
  • 2
  • You're right, that's the culprit! But modifying the path to look in bin/ first skips the gnubin binaries. How can you modify the path to only do this for stty? – Nathan Jan 12 '19 at 01:04
  • 1
    What I ended up doing is copying bin/stty to /bin/usr/sbin/stty/stty and then prepending my path to search there. This lets me keep all the gnubin binaries in tact while pointing stty to the copy of the Mac OS one. Thanks for tip! – Nathan Jan 12 '19 at 01:56
  • Nice. My workaround specifically was mkdir ~/.bin && ln -s /bin/stty ~/.bin, then putting ~/.bin in my $PATH ahead of gnubin. – James Bowman Jan 15 '19 at 20:22