On Saturday, 6 April 2013 at 15:26:01 UTC, Steven Schveighoffer wrote:
> The origin of the name 'gui' is from when one wanted to start a windows GUI application from another windows GUI application, and you did it without this flag, it would pop up an annoying console window.  So you can read it as "I'm starting a GUI application"

When is this true?

> If we could, I'd fix Windows so the process you were starting made the determination of whether it should start a console or not, that makes more sense to me.

Um, that's exactly how it works. There is a value in the PE header which determines this. The corresponding linker flag is /SUBSYSTEM:WINDOWS for a GUI program or /SUBSYSTEM:CONSOLE for a console program.

The flag specifies that you want to run a console application, but want to suppress its console window.

On Sat, 06 Apr 2013 11:38:14 -0400, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> Um, that's exactly how it works. There is a value in the PE header which determines this. The corresponding linker flag is /SUBSYSTEM:WINDOWS for a GUI program or /SUBSYSTEM:CONSOLE for a console program.
>
> The flag specifies that you want to run a console application, but want to suppress its console window.

Shit, I didn't remember this correctly at all!

Yes, I remember now.  It was for GUI applications that wanted to run a console application.  Because there was no console window for the parent process, windows creates one.

Like an application that wanted to run a script or something.  I ran into this a million years ago when I was using Tango, and I had a GUI agent that ran programs on behalf of a remote process, and annoying console windows would pop up if the application was a script, seemingly at random.

Sorry I misrepresented!

In light of this, there really is no good reason it was called gui!  I probably was this confused when I picked that name to begin with ;)

-Steve

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

I think that is probably a good idea. The exec functions allowed for this. I've never made use of it myself but if it can be done for all OSs we may as well.

On Saturday, 6 April 2013 at 15:26:01 UTC, Steven Schveighoffer wrote:
> On Sat, 06 Apr 2013 05:13:10 -0400, Lars T. Kyllingstad <public@kyllingen.net> wrote:
>> I know some people don't like negative flags, but in this case it seems more precise.  It doesn't create a GUI, it prevents the creation of a console.
>
> [...]
>
> As far as a positive flag, what about suppressConsole?  Little verbose I suppose...

No, that's great.  It's even more precise than noConsole.  I've changed it now.

Lars

On Saturday, 6 April 2013 at 09:13:11 UTC, Lars T. Kyllingstad wrote:
> I wonder if we should change the name of Config.gui to Config.noConsole.  It corresponds to the CREATE_NO_WINDOW flag in the Windows API, for which the documentation says:
>
> "The process is a console application that is being run without a console window. Therefore, the console handle for the application is not set. This flag is ignored if the application is not a console application [...]"
>
> I know some people don't like negative flags, but in this case it seems more precise.  It doesn't create a GUI, it prevents the creation of a console.
>
> Lars

I think noConsole or suppressConsole is acceptable, with preference to the latter. It seems to me gui is very mis-representative of what it is.

On Friday, 5 April 2013 at 05:54:39 UTC, Lars T. Kyllingstad wrote:
> The following is a message posted by Johannes Pfau to the other (pre-)review thread which didn't seem to get noticed, along with an edited version of my reply.
>
> 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.

I have implemented this now.  I think this was a great improvement.  pipeProcess(/-Shell) and execute(Shell) now wield more of the power of spawnProcess(/-Shell) without complicating their usage.

Please comment.

Lars

On Sunday, 7 April 2013 at 18:52:12 UTC, Lars T. Kyllingstad wrote:
> I have implemented this now.  I think this was a great improvement.  pipeProcess(/-Shell) and execute(Shell) now wield more of the power of spawnProcess(/-Shell) without complicating their usage.
>
> Please comment.
>
> Lars

From the docs it looks like in order to pass a Config you'd also need to pass an Environment, since all overloads take one and Config comes last.

On Sunday, 7 April 2013 at 19:28:12 UTC, Jesse Phillips wrote:
> On Sunday, 7 April 2013 at 18:52:12 UTC, Lars T. Kyllingstad wrote:
>> I have implemented this now.  I think this was a great improvement.  pipeProcess(/-Shell) and execute(Shell) now wield more of the power of spawnProcess(/-Shell) without complicating their usage.
>>
>> Please comment.
>>
>> Lars
>
> From the docs it looks like in order to pass a Config you'd also need to pass an Environment, since all overloads take one and Config comes last.

I suspect that people will modify the environment more often than the config parameter, which is why I've placed them in that order. If you just want to inherit the parent's environment, simply  set env to null.

Lars

Not sure if this is the right place for this, but I have found a problem in my fairly old version of the new process module. The problem was in the POSIX spawnProcessImpl() just after the fork() call in the child process branch.

The child would occasionally block forever on an attempt by the D code to lock a mutex.

The problem went away when I moved the toStringx() and toArgz() calls to before the fork() call.

I have no idea what is going on here, but it seems like fork() leaves the child in bad shape, so my 'fix' is very much a band-aid.

On Monday, 8 April 2013 at 05:22:09 UTC, Graham St Jack wrote:
> Not sure if this is the right place for this, but I have found a problem in my fairly old version of the new process module. The problem was in the POSIX spawnProcessImpl() just after the fork() call in the child process branch.
>
> The child would occasionally block forever on an attempt by the D code to lock a mutex.
>
> The problem went away when I moved the toStringx() and toArgz() calls to before the fork() call.
>
> I have no idea what is going on here, but it seems like fork() leaves the child in bad shape, so my 'fix' is very much a band-aid.

This is definitely the right place for it. :) That said, the bug has already been reported and fixed, in exactly the way you suggest.

Lars