#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 - 2001-04-02
    • labels: 104247 --> 27. Channel Types
  • Andreas Kupries

    Andreas Kupries - 2001-09-07
    • assigned_to: nobody --> andreas_kupries
  • Andreas Kupries

    Andreas Kupries - 2001-09-11

    Logged In: YES

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

  • Don Porter

    Don Porter - 2002-07-05

    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 - 2002-10-19

    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 - 2013-03-24

    oldest open bug in Tcl still hanging in there.

  • Alexandre Ferrieux

    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.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks