CODEWITHSUNDEEP
goterminalsystem-callsstty
lyderic
lyderic

Reputation: 442

Terminal in golang: syscall vs os/exec stty

This is how one can get a (POSIX) terminal size with a syscall in go:

func getTermDim() (width, height int, err error) {
    var termDim [4]uint16
    if _, _, err := syscall.Syscall6(syscall.SYS_IOCTL, uintptr(0), uintptr(syscall.TIOCGWINSZ), uintptr(unsafe.Pointer(&termDim)), 0, 0, 0); err != 0 {
        return -1, -1, err
    }
    return int(termDim[1]), int(termDim[0]), nil
}

Now, the same thing, calling stty with os/exec:

func getTermDim() (width, height int, err error) {
        cmd := exec.Command("stty", "size")
        cmd.Stdin = os.Stdin
        var termDim []byte
        if termDim, err = cmd.Output(); err != nil {
                return
        }
        fmt.Sscan(string(termDim), &height, &width)
        return
}

In practice, the first solution can get pretty heavy and unreadable, when one has to put a terminal in raw mode, set up options etc. When one is used to stty (e.g. in shell scripts), the second solution is so much easier!

So my question is: what are the benefits of using the first solution? It is speed? Is it that we cannot rely on the stty command to be installed on the host machine? Anything else I don't think of?

In a nutshell, what is the "risk" or the "cost" of using stty vs a syscall?

Upvotes: 6

Views: 2858

Answers (2)

ijw
ijw

Reputation: 4526

In all likelihood, if stty exists on the box, the syscall is also present. It's seems that it, and the argument TIOCGWINSZ, are a part of the SVR4 standard, which dates back about 20 years at this point and are widely implemented by Unixes everywhere, so it's unlikely you would need variant code for different OSes and an ioctl would be portable.

Running stty is more readable, certainly, but you're running a separate process, which comes with a cost.

It's slower and considerably more expensive: the OS is starting a new process context and loading the binary; not only does your code make multiple syscalls, so does the process you run.

It also comes with a set of security concerns. Perhaps the stty you found on your path is one the user put there, as just one example; and if you embed a path, perhaps it's wrong for this specific OS).

Upvotes: 1

dolmen
dolmen

Reputation: 8706

About the risk:

  • stty: your program will not work correctly if the stty command is not available in $PATH. Or if the stty command in $PATH is not the one you expect (it might be a security issue). Or if the program runs in a Docker container with a minimalist footprint: you'll have to put stty in the image.
  • syscall: your program is dependent on the OS. It is fine as long as you write that function in file protected with build tags to ensure the build will fail at compile time on unsupported OS.

About the performance, just write a benchmark using package testing. But I can already tell you that exec.Command implies multiple syscalls much more costly than IOCTL/TIOCGWINSZ.

Upvotes: 1

Related Questions