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?

  • 2
    Cleaner would be to run su from within a screen session. Apr 4, 2011 at 22:27
  • @justarobert not if you want multiple users to be able to attach to that same screen for a service/batch-script-running account.
    – Ashley
    Feb 25, 2015 at 0:09

2 Answers 2


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.


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.

  • 3
    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, 2013 at 22:26
  • "it", meaning screen output, doesn't go to /dev/null. First: script records your session (see the manpage), and you don't need it at all: so that goes to /dev/null. But it doesn have a side-effect: it makes a pseudo terminal, and now you are using this, and screen can write to this oneSee @karol-piczak 's anwer.
    – Nanne
    Jul 21, 2015 at 12:55

You must log in to answer this question.

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