The new std.process is ready for review

[Lars T. Kyllingstad]

On Monday, 25 February 2013 at 21:06:54 UTC, Vladimir Panteleev 
wrote:
> On Monday, 25 February 2013 at 20:06:19 UTC, Lars T. 
> Kyllingstad wrote:
>> That is also incredibly obscure.  I'd venture a guess that 
>> only ~10% of D's user base have even heard of Lynx.  Everyone 
>> knows firefox, and will understand what the example is 
>> supposed to illustrate.  (I admit that the ls/grep examples 
>> will also be rather incomprehensible to someone not familiar 
>> with the *NIX command line, and I will replace them with 
>> something else.  The D toolchain, as you suggest below, is a 
>> very good idea.)
>
> I still think using Firefox is a bad idea, but I've already 
> presented my arguments.
>
>> BTW, browse() should never have been added to std.process, in 
>> my opinion.  Maybe to some other utility module, but then it 
>> should at least be done right, and be properly documented.
>
> What would you improve about it?

1. I would document it properly.
2. As long as it runs in the background, I would return some kind 
of process ID from it.  (Yes, most browsers today may just signal 
another instance to open a new tab and then return, but would be 
surprised if they *all* do.)
(3. Maybe put it in a different module, I'm not sure.)

Also, and this is of course extremely subjective, it just looks 
out of place and very much "alone".  Where is 
writeEmailInDefaultClient(address)?  Where is 
openInAssociatedApp(file)?

> I have no opinion on its location in Phobos, but std.process is 
> the most fitting one if you don't consider creating a new 
> module.

Maybe.

[...]

>>> Then, a end-user tries setting the config variable to a path 
>>> that contains spaces, and everything breaks. Wrapping the 
>>> path in quotes does not help either. Due to the way the 
>>> function is designed, it is IMPOSSIBLE for the end-user to 
>>> configure the application to launch a program located at a 
>>> path containing spaces. To end-users, this comes off as a 
>>> classical problem in badly written applications that don't 
>>> handle command-line escaping properly.
>>
>> Exposing the specifics of whatever programming language you 
>> are using to the end user?
>
> I don't understand what you mean here. It's not exposing any 
> specifics if you don't implement anything in a way specific to 
> D.

You pass a string directly from a config file into a rather 
low-level function in the programming language's standard library 
without any kind of validation.

[...]

>> You almost have me convinced that the single-string non-shell 
>> functions must go.  In the case of pipeProcess() and 
>> execute(), pipeShell() and shell() do the same job, with 
>> (arguably, still) less surprises.  Maybe it would then be a 
>> good idea to add a spawnShell() function to go with 
>> spawnProcess().
>
> How about something that converts a ProcessPipes instance into 
> a Tuple!(int, "status", string, "output") as returned by shell? 
> Then you could do e.g.
>
> auto result = shell("command").collectOutput();
> // use result.status or result.output

That's pretty elegant. :)

Lars