On Monday, 25 March 2013 at 19:27:31 UTC, Steven Schveighoffer wrote:
> On Mon, 25 Mar 2013 15:17:14 -0400, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2013-02-23 12:31, Lars T. Kyllingstad wrote:
>>> It's been years in the coming, but we finally got it done. :) The upshot
>>> is that the module has actually seen active use over those years, both
>>> by yours truly and others, so hopefully the worst wrinkles are already
>>> ironed out.
>>>
>>> Pull request:
>>> https://github.com/D-Programming-Language/phobos/pull/1151
>>>
>>> Code:
>>> https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
>>>
>>> Documentation:
>>> http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process2.html
>>
>> I would like a function for getting the current process path, i.e. this:
>>
>> http://dsource.org/projects/tango/attachment/ticket/1536/process.d
>
> This is orthogonal to the replacement of process creation functions, can we add this as an enhancement later?  It definitely is useful, but std.process sucks right now.  I don't want to delay the replacement of existing functions with adding extra features.

Speaking of not delaying any more, could we get the "official" review going, and perhaps make it rather brief?  After all, the module has effectively been under review in this forum for several weeks already...

Does anyone want to volunteer as review manager?

Lars

On Tuesday, 26 March 2013 at 14:10:56 UTC, Jacob Carlborg wrote:
> On 2013-03-26 14:07, Lars T. Kyllingstad wrote:
>
>> If this gets added *before* the new std.process, we should at least
>> agree on a consistent naming convention.  The new std.process has
>> @property thisProcessID(), which replaces getpid(), and which is
>> somewhat consistent with std.concurrency.thisTid.  I also think
>> std.file.getcwd() is part of this function family, and that it should be
>> moved to std.process (under a different name).
>>
>> Personally, I dislike function names that start with "get".
>
> so what would you prefer, "thisProcessPath"? Or thisExecutablePath, perhaps?

Something like that, with @property.  thisProcessExecutable is also an option, but it's rather long.  I think I prefer thisExecutablePath.

Lars

On 2013-03-26 15:42, Lars T. Kyllingstad wrote:

> Something like that, with @property.  thisProcessExecutable is also an
> option, but it's rather long.  I think I prefer thisExecutablePath.

I like thisExecutablePath better than thisProcessExecutable.

-- 
/Jacob Carlborg

Am Sat, 23 Feb 2013 12:31:19 +0100
schrieb "Lars T. Kyllingstad" <public@kyllingen.net>:

> It's been years in the coming, but we finally got it done. :) The upshot is that the module has actually seen active use over those years, both by yours truly and others, so hopefully the worst wrinkles are already ironed out.
> 
> Pull request: https://github.com/D-Programming-Language/phobos/pull/1151
> 
> Code: https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
> 
> Documentation: http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process2.html
> 
> I hope we can get it reviewed in time for the next release.  (The wiki page indicates that both std.benchmark and std.uni are currently being reviewed, but I fail to find any "official" review threads on the forum.  Is the wiki just out of date?)
> 
> Lars

Reposted from github:
I think it would be nice if the high level functions would also allow
using custom environment variables. So the execute and executeShell
functions should have overloads which accept a string[string] with
environment variables (and probably accept a Config as well).

The execute and executeShell functions would be trivial to implement though if pipeProcess / pipeShell had an overload with environment and Config parameters. So it's probably more important that pipeProcess / pipeShell get these overloads.

On Sunday, 31 March 2013 at 13:14:52 UTC, Johannes Pfau wrote:
>
> Reposted from github:
> I think it would be nice if the high level functions would also allow
> using custom environment variables. So the execute and executeShell
> functions should have overloads which accept a string[string] with
> environment variables (and probably accept a Config as well).
>
> The execute and executeShell functions would be trivial to implement
> though if pipeProcess / pipeShell had an overload with environment
> and Config parameters. So it's probably more important that
> pipeProcess / pipeShell get these overloads.

Implementation-wise, it is a simple task to add this functionality to both pipeProcess/pipeShell and execute/executeShell.  It comes at the cost of more complex function signatures for high-level functions which have, so far, intentionally been kept rather simple:

ProcessPipes pipeProcess(
    string[] args,
    Redirect redirectFlags = Redirect.all,
    string[string] env = null,
    Config config = Config.none);

Tuple execute(
    string[] args,
    string[string] env = null,
    Config config = Config.none);

But maybe that's not so bad?

Lars

<rant>
While working on std.process, I have developed a deep and intense loathing for Windows process handling in particular, and the Win32 API in general.

On Windows XP, what do you think will happen when you run the following program?

    int main()
    {
        if (TerminateProcess(INVALID_HANDLE_VALUE, 123))
        {
            writeln("TerminateProcess succeeded, but it shouldn't have...");
            return 1;
        }
        else
        {
            writeln("TerminateProcess failed, as it should.");
            return 0;
        }
    }

As you may already have guessed, it does *not* print "TerminateProcess failed" and exit with code 0.

But does it print "TerminateProcess succeeded" and exit with code 1? NO! It prints NOTHING and exits with code 123, because TerminateProcess() terminates the CURRENT process when it is passed INVALID_HANDLE_VALUE.  Aaaaargh!
</rant>

Sorry, just had to get that off my chest.  I just spent quite some time trying to figure out why the Win32 unittests were failing when there was no assert error or any other indication of what went wrong.

On Sun, Mar 31, 2013 at 7:21 PM, Lars T. Kyllingstad <public@kyllingen.net>wrote:

> <rant>
> While working on std.process, I have developed a deep and intense loathing
> for Windows process handling in particular, and the Win32 API in general.
>
> On Windows XP, what do you think will happen when you run the following program?
>
>     int main()
>     {
>         if (TerminateProcess(INVALID_**HANDLE_VALUE, 123))
>         {
>             writeln("TerminateProcess succeeded, but it shouldn't
> have...");
>             return 1;
>         }
>         else
>         {
>             writeln("TerminateProcess failed, as it should.");
>             return 0;
>         }
>     }
>
> As you may already have guessed, it does *not* print "TerminateProcess failed" and exit with code 0.
>
> But does it print "TerminateProcess succeeded" and exit with code 1? NO!
> It prints NOTHING and exits with code 123, because TerminateProcess()
> terminates the CURRENT process when it is passed INVALID_HANDLE_VALUE.
>  Aaaaargh!
> </rant>
>
> Sorry, just had to get that off my chest.  I just spent quite some time trying to figure out why the Win32 unittests were failing when there was no assert error or any other indication of what went wrong.
>

<agreement>

I used to hate Windows for similar reasons. I hated it with passion. I dreamed of devoting my life to the goal of putting Microsoft out of busyness to avenge the loss of countless hours of trying to get things to work as they say they should.

I ended my misery by buying an Apple MacBook Air and I couldn't be happier. The development environment is a bit unusual (needs some tweaking to become full-fledged posix development environment), but worth the time and money. OS X is the absolute best operating system I ever had to work with. It's system API (cocoa) makes so much more sense (despite being a bit hard to access via C ABI).

I really recommend you to ditch that excuse for an operating system and forget it like a bad dream.

</agreement>

-- 
Bye,
Gor Gyolchanyan.

On Sunday, 31 March 2013 at 15:49:59 UTC, Gor Gyolchanyan wrote:
> I really recommend you to ditch that excuse for an operating system and
> forget it like a bad dream.

I think a few people would be disappointed if the new std.process didn't support Windows. :)

Lars

On 2013-03-31 19:28, Lars T. Kyllingstad wrote:

> I think a few people would be disappointed if the new std.process didn't
> support Windows. :)

Those should follow the same advice :)

-- 
/Jacob Carlborg

On Sunday, 31 March 2013 at 15:21:38 UTC, Lars T. Kyllingstad wrote:
> As you may already have guessed, it does *not* print "TerminateProcess failed" and exit with code 0.
>
> But does it print "TerminateProcess succeeded" and exit with code 1? NO! It prints NOTHING and exits with code 123, because TerminateProcess() terminates the CURRENT process when it is passed INVALID_HANDLE_VALUE.  Aaaaargh!

How did INVALID_HANDLE_VALUE get so far in the code as to reach TerminateProcess? Shouldn't an enforce call have been in place to validate whatever the source of the handle is?

Anyway, this is documented behavior. You can pass GetCurrentProcess() to TerminateProcess to terminate the current process.

Your plight was caused by the unfortunate (or perhaps, unforesighted) coincidence that GetCurrentProcess() returns the special (magic) value of (HANDLE)-1, the same value of INVALID_HANDLE_VALUE.