Talk:Named pipe

OS/2

OS/2 also has a \pipe\ file hierarchy. Probably Windows NT took it from there.

Windows named pipes vs. TCP streams

Can someone perhaps explain what makes Windows named pipes different from TCP streams? —The preceding unsigned comment was added by 193.57.156.241 (talk) 10:16, 7 March 2007 (UTC).

everything —Preceding unsigned comment added by 69.125.110.223 (talk) 19:19, 18 December 2007 (UTC)

yeah, everything, for a start, Windows named pipes are netbios not TCP. Jasen betts (talk) 05:01, 27 April 2012 (UTC)

Unix example

We tried this and it didn't work. ("We" have 20 cumulative years experience with Linux, BTW...) Could someone improve the example? —Preceding unsigned comment added by 70.165.47.112 (talk) 15:09, 13 June 2008 (UTC)

A cleaner way to compress from stdandard input but without named pipe is using a pipeline: echo 'compress this' | bzip2 -f - > compressed.bz2

If you have 20 years of experience you should be more than capable of writing your own example. I have 4 years experience and I am capable of thinking of an example... (note that I'm not the person who gave the one above). —Preceding unsigned comment added by 82.33.119.96 (talk) 13:42, 10 August 2008 (UTC)

I have written an example that I use at work. It makes importing compressed MySQL "OUTFILES" much more efficient and exemplifies what named pipes are for and can do. Sam Barsoom 00:38, 3 October 2009 (UTC)

Exactly two?

and two separate processes can access the pipe by name.

• Only exactly two processes, no more no less? --Abdull (talk) 17:15, 5 August 2008 (UTC)

I think what is meant is that there is one process at each "end" of the pipe, and yes, I think that the functionality of a named pipe depends on there being two, and only two, processes involved. --RenniePet (talk) 18:57, 5 August 2008 (UTC)

In fact only one process can read (others are blocked), but many of processes can write on that pipe. And the result is unpredictible, you have a mess (mixature of content). So the example could work, but the ziped file is unreadable if you have more than one input stream at a time. --MaNeMeBasat (talk) 16:25, 24 January 2009 (UTC)

Pipes tend to work best when they are connected to exactly 2 processes. Other configurations are possible but prone to problems(Just think of plumbing). Sam Barsoom 00:54, 3 October 2009 (UTC)

Using C library functions on Windows

I dispute an assertion made in change http://en.wiki.x.io/w/index.php?title=Named_pipe&diff=prev&oldid=55964676 (reads: "C library functions such as fopen, fread, fwrite, and fclose can also be used, ...") which is not backed-up. Yes, it can appear to be working but I experienced several problems when straying from Named Pipe Operations into C library functions which appear to implement unconnected buffering systems (buffer alignment might be a factor) and can ignore the configuration set at the server end (e.g. PIPE_TYPE_MESSAGE and PIPE_WAIT), resulting in strange behaviour such as requiring two read operations when only one should be necessary to receive a 'message'.

It would have been very useful if C functions worked over a pipe because the application data I wanted to capture was output to user-specified filename as a command-line option, so source code availability would not have been a consideration.

My advice is to stick to the Named Pipe Operations at both client and server ends of the pipe and it works without pain. I shall remove the statement because I have not found a claim in a MSDN document that Named Pipes work using C library functions.

Daxx wp (talk) 13:34, 24 November 2009 (UTC)

Mac OS X

This article stated that named pipes are called "sockets" in Mac OS X, which is incorrect. While they are both file-system-present IPC mechanisms, Unix domain sockets are different from named pipes and Mac OS X supports both. --Jaybeeunix (talk) 18:24, 29 March 2010 (UTC)

The use of named pipes

Wouldn't it make sense to clarify the situations in which named pipes can be useful for IPC, given that similar solutions (e.g. sockets) exist.

I would point out (for example) the fact that they exist on the filesystem, and that they can be read from and written to using the exact same library calls that would normally be used for file input/output. Thus, unless a program explicitly checks whether they're reading from a named pipe or not, you can generally pass it a named pipe whenever it's expecting a file. (You can't normally pass a program a TCP socket when it expects a file, unless that programmer has made some special effort to support TCP sockets.)

So, say you have program X which reads from a hard-coded file path "/etc/motd", if you want to trick it into getting its data from another process, you just delete that file, create a named pipe in its place, and have your other process write to the named pipe. — Preceding unsigned comment added by 77.89.160.242 (talk) 14:57, 21 December 2011 (UTC)

When did named pipes appear?

According to the FreeBSD manpage,

The mkfifo command appeared in 4.4BSD.

But the 4.3BSD/Net2 distro already had it, "under development", and said it was "IEEE Std 1003.2 (POSIX.2) compliant" so it was already specified by POSIX back then. Where did mkfifo and named pipes originate? In POSIX? In System V? SunOS 4.1.3 apparently had a mkfifo system call, but not a command. Qwertyus (talk) 14:41, 8 May 2013 (UTC)

Update: ESR suggests they come from System V. Qwertyus (talk) 14:50, 8 May 2013 (UTC)