Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#1198 bad interaction of input redirect from named pipe with backg

obsolete: 8.0p2

OriginalBugID: 950 Bug
Version: 8.0p2
SubmitDate: '1998-12-14'
LastModified: '1999-12-07'
Severity: SER
Status: Assigned
Submitter: pat
ChangedBy: hobbs
OS: Linux
Machine: Other
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'

Name: Harald

Run the following script.

# exec tclsh8.0 "$0"

exec mkfifo fifo
puts [exec cat <fifo >@stdout &]

Although there is an `&' at the end
of the exec-arguments, the exec does
not return.

If `&' is at the end of exec-args,
exec should always return soon, independent of input redirection.

There is a not-so-perfect workaround. The fifo can be opened with NONBLOCK and the handle to the opened fifo can be used to redirect input. However then the child-process sees a non-blocking
input channel, which is probably not what was intended.
Verified in 8.2.2 on Solaris.
-- 12/07/1999 hobbs


  • Don Porter
    Don Porter

    • labels: 104247 --> 27. Channel Types
    • assigned_to: nobody --> andreas_kupries
  • Logged In: YES

    Harald = <kir@iitb.fhg.de> ...
    Harald Kirsch, author of 'bras'.

  • Don Porter
    Don Porter

    Logged In: YES

    Is this still a valid bug report?

    If so, it may be the oldest Open bug in Tcl.

  • Joe Mistachkin
    Joe Mistachkin

    Logged In: YES

    Tested and verified on

    FreeBSD 4.7-STABLE FreeBSD 4.7-STABLE #1: Thu Oct 10
    13:55:32 EDT 2002 /usr/obj/usr/src/sys/GENERIC i386

  • Don Porter
    Don Porter

    oldest open bug in Tcl still hanging in there.

  • To me, [exec &] does the best compromise between asynchronicity and immediate reporting of lethal failures.

    The most popular "immediate failure" that [exec &] reports synchronously is one about the executable (not found, or improper rights). Nobody complains about that.

    In the same logic, it also reports *synchronously* about a failure to do the redirections. This is done by putting the open() *before* the sync point. Again, everybody is happy about this behavior I guess.

    Then, in the specific case of a named pipe with nobody yet on the other end, this very open() will block. That's a necessary consequence of the above. It may surprise people because it is unlike the Bourne Shell, where the open()s lay completely within the forked process and no rendezvous will propagate the blocking. But I still think this rendezvous is a superior feature of Tcl, geared towards better error reporting.

    So I'd rather document the gotcha than overhaul a sane behavior.