Re: Imaginary File Path
Re: Imaginary File Path
- Subject: Re: Imaginary File Path
- From: John Goodman <email@hidden>
- Date: Fri, 7 Dec 2007 14:09:06 -0500
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.
I'll have to see how well behaved it is. It will be nice if I can
work with stdin instead of a file path. I'm already using NSTask's
setStandardOutput to get data *out* of the tool and into NSPipe's
NSFileHandle. (The tool outputs only through printfs.)
I'll see what I can learn about the tool's handling of its argument
list. Maybe there's more than one way in.
Thanks again for all the food for thought.
John
On Dec 7, 2007, at 12:30 PM, James Bucanek wrote:
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