Re: Imaginary File Path
Re: Imaginary File Path
- Subject: Re: Imaginary File Path
- From: James Bucanek <email@hidden>
- Date: Fri, 7 Dec 2007 10:30:39 -0700
John Goodman <mailto:email@hidden> wrote (Friday,
December 7, 2007 10:02 AM -0500):
To use a pipe your C++ would have to read the data from stdin,
I'm not the author of the C++ tool; I'm just compiling code I
get from someone else's project. The tool unfortunately doesn't
use stdin, or any stream, for the input data.
Check out the source of the tool. Virtually all well-behaved
UNIX command-line tools that operate on the contents of a file
use the convention: If the file is supplied as an argument, use
the path specified. If either no path is supplied as an
argument, or the argument is simply "-", read the contents from stdin.
If the tool reads the file sequentially, then there's a better
than 90% chance that the tool will read from stdin if you omit
the filename in the argument list.
for a socket your first process would create a UNIX domain socket
using bind (the socket will appear in the filesystem as a socket
file), then pass the path of the socket to the tool.
This sounds promising. My exposure to UNIX is limited to what I've
seen funneled through Mac OS X, so there's a lot I don't know. But the
description of sockets and bind that I'm seeing makes me think I can
learn enough to make this work. ("A socket is created with no name. A
remote process has no way to refer to a socket until an address is
bound to the socket... The bind() call enables a process to specify
the local address of the socket.")
Using sockets would probably require source code changes to your
tool, so this probably isn't the solution you're looking for.
A UNIX domain socket works just like a TCP socket, except
instead of defining a port number you use the AF_UNIX socket
type and create a structure that specifies a path in the
filesystem. When the bind() call is finished, a new socket file
will appear (look in /var/run for examples). These take up no
filesystem space; they just define a named conduit by which two
processes can send packets of data to one another. Again, these
are streams so it's strictly serial access.
--
James Bucanek
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden