Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Sep 2022 12:21:10 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 266627] stty -f <file> should be non-blocking
Message-ID:  <bug-266627-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266627

            Bug ID: 266627
           Summary: stty -f <file> should be non-blocking
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: se@FreeBSD.org

Ths stty man-page describes the -f option to cause a non-blocking open of t=
he
passed file:

     -f      Open and use the terminal named by file rather than using
             standard input.  The file is opened using the O_NONBLOCK flag =
of
             open(), making it possible to set or display settings on a
             terminal that might otherwise block on the open.

This does work when TTY options are fetched and displayed, but not when
attempting to set some parameter.

I'd expect the following command to not block, but instead to fail with a
non-zero exit status:

$ stty -f /dev/tty sane &

But the command blocks, waiting for a "fg" command, and only then executes =
the
requested operation on the TTY.

The reason seems to be that the tcsetattr() function ignores the O_NONBLOCK
flag of the passed file descriptor (or rather that the ioctl() it invokes
ignores it).

This appears to be a deviation from documented behavior (and breaks a script
I'm working on which wants to reset the TTY on exit, but now blocks exiting
from the script when it has been put into the background by the user).

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-266627-227>