Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I was su'ed into a user to run a particular long running script. I wanted to use screen but I got the error message "Cannot open your terminal '/dev/pts/4' - please check."

So I Googled around and came across a forum post that instructed to run $ script '/dev/null/'. I did so and then I could screen.

Why does this work? What is su doing that screen cannot run as the su'ed user? Why does re-directing 'script' to /dev/null do that is prevented otherwise? Is it using script to write a log as the original user to somewhere?

share|improve this question
1  
Cleaner would be to run su from within a screen session. –  justarobert Apr 4 '11 at 22:27

2 Answers 2

up vote 22 down vote accepted

Well, technically you're not redirecting anything here.

Calling script /dev/null just makes script save the whole typescript into /dev/null which in practice means discarding the contents.

See man script for detailed info and util-linux-ng package for implementation (misc-utils/script.c).

This has nothing to do with screen actually. Why this works is invoking script has a side effect of creating a pseudo-terminal for you at /dev/pts/X. This way you don't have to do it yourself, and screen won't have permission issues - if you su from user A to user B, by directly invoking screen you try to grab possession of user A's pseudo-terminal. This won't succeed unless you're root. That's why you see the error message.

share|improve this answer

To output directly to your terminal window, the running program needs to be able to write to your controlling terminal. If you are using an xterm or ssh or some other virtual connection (as opposed to a real live directly connected terminal) your controlling terminal is a pseudo tty (pty).

Your pty is set up with write permission for only you when you log on, otherwise other users could scribble on your display (or read it). Thus when you su to another user (and that user is not root), that user does not have access to the underlying pty.

However, more complex I/O such as screen requires direct access to the pty to work it's magic of controlling your whole screen. That's when you run in to problems with the person running the command not having proper access to the controlling terminal.

Redirecting the script to /dev/null causes screen to not try to write to the controlling terminal, so it doesn't hit the permission problem.

share|improve this answer
1  
So how am I able to I see what screen writes if it goes to /dev/null? I'm pretty sure I misunderstood and it doesn't really go to /dev/null, but where does it go? –  user63623 Oct 7 '13 at 22:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.