On 27 May 2010, at 11:52, Ken Thomases wrote:
>> I have a daemon that spawns NSTasks on request. A task is passed a number of
>> paths to process. These paths are pased correctly to the task, and in the
>> task I can correctly extract the path string from optarg.
>
> No, they aren't and no you can't, according to what you write below.
Thanks so much for the elaborate and pertinent answer Ken. You are right. I was
not passing the arguments correctly to the task.
I was creating the arguments like this:
[args addObject:[NSString stringWithFormat:@"-f \"%...@\"",
[[sourceDirectoryURL path] stringByAppendingPathComponent:sourceFileName]]];
Whereas, I now understand (hopefully correctly), I should have been creating
them like this:
[args addObject:[NSString stringWithFormat:@"-f%@", [[sourceDirectoryURL
path] stringByAppendingPathComponent:sourceFileName]]];
> Why do you think the string is in Mac Roman encoding? It probably isn't. In
> fact, I happen to know that NSTask converts all of its arguments to "file
> system representation". Even if I didn't know that, that's the only correct
> thing to assume. So, you should use the following to construct an NSString
> from optarg:
>
> NSString* path = [[NSFileManager
> defaultManager]stringWithFileSystemRepresentation:optarg
> length:strlen(optarg)];
It's been a while since I wrote the original code for this, but if memory
serves me correctly, I modelled this after some sample code, and since it
worked, I did not question it. I have adjusted the path extraction to use the
more correct stringWithFileSystemRepresentation: call instead.
> You are almost certainly confused about the need to quote and escape things
> for the shell. The shell needs to take what it receives as a single command
> string and break it up into its component parts. That's what introduces the
> need to quote whitespace and escape special characters when working in the
> shell.
>
> By contrast, NSTask is handed its arguments already neatly separated out into
> individual elements. Plus, it doesn't have any special characters -- it just
> treats all of its arguments literally. Thus, it does not require that its
> arguments be quoted or escaped. Indeed, if you try to do so, those
> characters are just passed along to the new process.
Confused I was indeed (although I did not know it). This is new territory for
me, so I'm not surprised I stumble a bit as I plod through it. :-)
> So, I guess that you have taken a file path string in the parent process and,
> while attempting to pass it through to a subprocess verbatim, you've done
> exactly the wrong thing. You've modified it, putting quote marks around it
> and, apparently, a space before it. If you had done nothing with the string
> but pass it in as one of the task's arguments, _that_ would have gotten it to
> the subprocess verbatim.
Yes. Now that I pass the option's identifier with its parameter appended snugly
to it (without quotes and separating space char) the URL is created correctly.
Kind regards,
António
----------------------------------------------------
Disapprove of sin but not of the sinner
----------------------------------------------------
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
