The new std.process is ready for review

[Vladimir Panteleev]

On Tuesday, 26 February 2013 at 07:17:49 UTC, Lars T. Kyllingstad 
wrote:
>> 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.)

Pretty sure all major Windows browsers do.

The result is useless anyway. The user can browse away to another 
website, and if the browser is tabbed, open a completely 
different website and close the tab containing your website. What 
the user does from that moment is not the program's business. If 
it's important to detect when your website/webapp's tab is 
closed, I'd suggest implementing a long-polling request (COMET) 
and acting on when the connection is interrupted and there is no 
reconnection in 5 seconds.

> (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 guess no one simply wrote them yet?

writeEmailInDefaultClient(address) is accomplished by opening the 
"mailto:"~address URL.

The matter of protocols other than http needs some attention, 
though...

> 4. I would design it so that if I do browse("foo.txt") it opens 
> foo.txt in the web browser.  Correct me if I'm wrong, but it 
> currently seems that it will open it in the user's text editor 
> on Windows.  (On POSIX systems, too, if $BROWSER isn't set.)

I don't know how you would accomplish that on Windows, without 
accessing the association in the OS registry for e.g. the http 
protocol. Might be better to change the documentation instead.

>>> 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.

Running a program from another program should be that simple. I 
don't think anyone expects to validate a command-line.