Crucial to "How Tcl is special" is the pipeline. Through the syntax
set channel [open |$external_command r+]
Tcl opens an external process, and connects to the stdin and stdout of $external_command. A special syntax is needed in external_command to get stderr to be concantenated to stdout. Reading and writing to stdin and stdout are with the usual Tcl I/O commands: gets, puts, and read. (It may be necessary to flush resp. fflush to prevent deadlocks caused by buffering).
This makes for exceptionally handy glue for many situations.
The concept of pipeline, however, requires the external command to be designed to interact with data either on its stdin or stdout. Many GUI applications (and occasionally non-graphical applications) do not do so. In those cases, the pipeline provides little benefit.
The concept of the pipeline is opimally utilitized when writing tools using a filter paradigm.
Many Wiki pages and other references obliquely discuss or illustrate Tcl process pipelines. While the construction is crucial to a proper understanding of Tcl's capabilities, many newcomers take quite a while to come across an explanation that "gets through" to them. Among the pertinent available writings are
This transcript of an interaction session illustrates a simple pipeline with Unix's bc executable:
% set channel [open |bc r+]
file3
% puts $channel "1234567890 * 987654321"
% flush $channel
% puts [gets $channel]
1219326311126352690
with winnt cmd: % set channel open |cmd r+
file3
% gets $channel % gets $channel
% puts $channel "hostname"
% flush $channel
% gets $channel% gets $channel
% puts [gets $channel]
% close $channel
While (classic) MacOS supports no Tcl pipelines, see "Inventory of IPC methods" for generalizations that apply there and elsewhere.
[Explain "named pipe" as specialization of concept.]