1

We're reading a file from stdin into file_buffer, and then stepping into a method more.

As soon as we use system("stty cbreak -echo");, the output prints "stty: stdin isn't a terminal" and doesn't set our terminal to the settings we asked for.

This problem only exists when we use standard in. If we use a file argument, the program works fine -- the terminal settings get set, and there is no error message.

So, this is okay: myprogram file1.txt

But this is not: myprogram < file1.txt

Either way the contents are being read into file_buffer before being used at all. What the heck is wrong with using stty if we're taking input from stdin??

user1472747
  • 529
  • 3
  • 10
  • 25

2 Answers2

1

If you use input redirection or pipes, then stdin is not a TTY.

You can use isatty to check for that.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
  • Oh okay, thanks! Can I ask how I would turn off echo in the terminal then if we're using stdin? I was doing it with stty before, but if we can't do that with stdin, then what should be used? – user1472747 Apr 05 '13 at 17:59
  • @user1472747 See e.g. [this old SO answer](http://stackoverflow.com/a/6869218/440558). – Some programmer dude Apr 06 '13 at 05:21
1

When the standard input is a file, it isn't a terminal, so setting terminal attributes on stty's standard input won't work.

It sounds daft at first, but you will probably find that you can use either stdout or stderr as the input for stty and it will adjust the terminal. Therefore:

system("stty cbreak -echo <&2");

is likely to set the terminal characteristics. If you have a GNU version of stty, you could also use:

system("stty -F /dev/stderr cbreak -echo");

or substitute /dev/stdout or /dev/tty for /dev/stderr. You could also use any of the named devices instead of the &2 in the redirection in the first variant.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278