2

Some program started in a large script is doing stty -echo. I'm not sure which program it is so I have to try to find it by trial and error. Is </dev/null 2>&1 | tee /dev/null sufficient to block programs from accessing the terminal, or is there another way to get access to the terminal?

Actually I was unable to determine which program accesses the terminal (attempts to strace the entire script produced a 17MB file without tcsetattr, so I assume the terminal modifications are just writes of control characters). The problem was also non-deterministic; it was sometimes interfering with the terminal and sometimes not.

Placing the following prelude in the script seemed to stop interference with the terminal doesn't fix the problem. However, it's not clear why it doesn't fix the problem: are processes still accessing the terminal through /dev/tty, or are escape codes written by the programs still being dumped to the terminal by cat.

MKTEMP="$(mktemp)"
mkfifo "$MKTEMP".fifo
(
  set +o xtrace
  cat "$MKTEMP".fifo
  rm -f "$MKTEMP".fifo "$MKTEMP"
) </dev/null 2>&1 &
exec 1>"$MKTEMP".fifo
exec 2>&1
exec 0</dev/null
Improve this question
5
  • Close voters, mind explaining why this is such a bad question?
    – DepressedDaniel
    Commented Dec 20, 2016 at 21:47
  • 3
    Fiddling with IO redirection is way off in the Y land of a XY problem. Why not use strace or sysdig to find out what is running stty or otherwise making relevant system calls (e.g. tcsetattr)?
    – thrig
    Commented Dec 20, 2016 at 21:56
  • Any program can open /dev/tty and do what it wants to do with it. See man 4 tty. Use thrig's recommendation.
    – AlexP
    Commented Dec 20, 2016 at 22:03
  • @AlexP man 4 tty indicates TIOCNOTTY can be used to detach from the tty, after which open of /dev/tty will fail. Is there a wrapper program that does this? It sounds like a good idea for non-ncurses batch scripts that shouldn't be doing strange things to the terminal.
    – DepressedDaniel
    Commented Dec 20, 2016 at 22:13
  • The point is that you must find out what program does what in your script. Use bisecting, use strace, or read the script. And TIOCNOTTY applies to the procees which calls it, not to the shell. You can also try to enter blindly <Enter>reset<Enter> after the script terminates. Or open another terminal and watch the processes. Seriously, use thrig's suggestion.
    – AlexP
    Commented Dec 20, 2016 at 22:18

1 Answer 1

Reset to default
1

Dilemma solved. The problem was a backgrounded sudo -g asking for the password on the terminal even though the current account has no password. This seems to be a bug in sudo; it shouldn't ask for a password if the account has no password (and it doesn't when changing users, it only does it when changing groups):

ubuntu@ubuntu:~$ sudo -u nobody ls
Desktop  Documents  Downloads  Music  Pictures  Public  Templates  Videos
ubuntu@ubuntu:~$ sudo -g nogroup ls
[sudo] password for ubuntu: 
ubuntu@ubuntu:~$

The workaround was to add NOPASSWD: to sudoers, which made the problem go away.

The non-determinism was due to sudo eventually allowing the command the next time you pressed enter on the terminal, and not asking for a password again for some time.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .