What is the effect of pipe symbol in the second statement shown below? How does it differ from first one?
set nt [open "file" "r"]
set nt [open "|file" "r"]

Hello and welcome to LQ!

Where are you running or setting this command from? From the linux command line, or within another program? The more details you give us, the better....

Cheers,

Josh

PS - By the way, the pipe "|" directs output to a pipe - see this following link for details, as I have a hard time describing certain things... https://secure.wikimedia.org/wikiped...ine_%28Unix%29

The pipe command is pretty much allows you to issue a command and filter it through another. Example say you want to list all services That are set to start on boot you would do this to get the list

# chkconfig --list
This will list all services

Now if you wanted to see what servers are on and thats all you want you would want to filter the list through something like grep.

Example
# chkconfig --list |grep on

Here is another example.

If you did

$ls /etc

You would get all files listed. But say you wanted to list them from top to bottom and scroll down them. Then you would filter it though another program though the pipe. Such as

$ls /etc |less


But im not sure exactly what info you want to you need to provide more details.

Basically it is a piece of Tcl code. I was learning how to run Unix programs with Tcl scripts using open and exec commmands.The open command returns a file descriptor which in this example, is assigned to variable nt.I have learned that "If the first character of fileName is not | then the open command opens a file: fileName gives the name of the file to open. If the first character of fileName is “|” then the remaining characters of fileName are treated as a list of arguments that describe a command pipeline to invoke, in the same style as the arguments for exec. In this case, the channel identifier returned by open may be used to write to the command's input pipe or read from its output pipe, depending on the value of access. If write-only access is used (e.g. access is w), then standard output for the pipeline is directed to the current standard output unless overridden by the command. If read-only access is used (e.g. access is r), standard input for the pipeline is taken from the current standard input unless overridden by the command."

What I dont understand is that what is meant by Command pipeline and channel identifier in above explanation. Also another example

set fd1 [open "simpleinput" "r"] ;# open the file for reading
set fd5 [open "|simple1" "r"] ;# Read the stdout of simple1 as fd5

set fd2 [open "reldirect/simpleoutput" "w"] ;# open the file for writing
set fd6 [open "|simple2" "w"] ;# Writes to fd6 are read by simple2 on its stdin

How does second statement differ from first one in each pair.

First case:

set fd1 [open "simpleinput" "r"] ;

simpleinput is a file in the current working directory, and you are creating a tcl channel identifier fd1, which can now be used to read from that file.

2nd case:

set fd5 [open "|simple1" "r"] ;

simple1 is a program or script that will be executed, and the standard output from that program (the stream that would be sent to the terminal if you invoked the program directly from the command line) can now be read from tcl channel identifier fd5.

3rd case:

set fd2 [open "reldirect/simpleoutput" "w"] ;

simpleoutput is a file in directory reldirect below the current working directory, and you are opening that file (which will be created if it does not already exist) to receive any data that you send to tcl channel identifier fd2.

4th case:

set fd6 [open "|simple2" "w"] ;

simple2 is again a program or script that will be executed, and whatever you write to tcl channel identifier fd6 will be sent to that program's standard input.

1 members found this post helpful.

Thanx rknichols for a comprehensive and detailed explanation. I got it now

Actually there were multiple errors in what I wrote. fd1, fd2, etc., are arbitrary tcl channel identifier names that bear enough resemblance to file descriptor numbers to get me confused. To make matters worse, file descriptor numbers start at 0 for "stdin" and 1 for "stdout", so my description of the standardized file descriptor numbers was flat out wrong. What I originally posted was probably close enough to get you on the right path, but I've made corrections to avoid confusing anyone else who comes across this.

In the 4th case, the pipe comes after the executable name surely?

No. RTFM.

Wow, dude.