04-Apr-2013 18:22, Jesse Phillips пишет:
> Hello,
>
> I have decided to take on Review Manager for std.process and hopefully
> will keep it up and get through the review queue. This is slightly
> ignoring a "first come, first serve" approach, but that is mostly
> because I didn't want to look into it. (So don't be too upset).
>

At last! And being somewhere near the top of the queue with std.uni I have no objections. Let's just make some progress :)



-- 
Dmitry Olshansky

escapeShellCommand, escapeWindowsArgument, escapeShellFileName - in which way differ and why it's not one function? Why escapeWindowsArgument exists without posix counterpart?

On Thursday, 4 April 2013 at 21:59:01 UTC, Kagamin wrote:
> escapeShellCommand, escapeWindowsArgument, escapeShellFileName - in which way differ and why it's not one function?

Because they do different things. The escaping rules are different.

See the example on escapeShellCommand for how to use them.

> Why escapeWindowsArgument exists without posix counterpart?

escapeWindowsArgument is needed for building e.g. DMD response files on any platform. escapePosixArgument exists, but it is private/undocumented. It could be made public if someone requests it.

Note that these functions aren't new - I've written them for the old std.process a while ago.

On Thursday, 4 April 2013 at 17:04:53 UTC, Steven Schveighoffer wrote:
> On Thu, 04 Apr 2013 12:50:01 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>
>> On 4/4/13, Jesse Phillips <Jesse.K.Phillips+D@gmail.com> wrote:
>>> Source:
>>> https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
>>
>> Dead link.
>
> https://github.com/kyllingstad/phobos/blob/std-process2/std/process.d
>
> At the last minute I insisted we change std.process2 to std.process since it was agreed to incorporate the original API instead of redesigning it slightly.

There was a recent thread [1] about deepening Phobos' module hierarchy, and it seems that most people agree this is something that should eventually happen.

In light of this, here's a suggestion:  How about we, rather than updating the old std.process, create a new module called std.sys.process?  Or even better, IMO, std.sys.environment and std.sys.pipe as well as std.sys.process?

This would also allow us to give developers an earlier heads-up that the old std.process is going the way of the dodo, by using a pragma(msg) in the module.  (The functions in std.process are not templated, so we can't do the nice trick of putting the pragma(msg) inside the functions themselves.)

Lars

[1] http://forum.dlang.org/thread/ugmacrokqghrrwpfovam@forum.dlang.org

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 to say, I am really warming to the idea.  This would come at no cost to the actual usage of these functions; you could still call execute like this:

    execute("my_app");

The cost would be in the form of more complex function signatures (and consequently documentation):

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);

Implementation-wise, it is a trivial task to add this functionality to both pipeProcess/pipeShell and execute/executeShell.  It's a simple matter of forwarding the extra arguments to spawnProcess, with some filtering of 'config'.

Lars

On 2013-04-05 07:37, Lars T. Kyllingstad wrote:

> In light of this, here's a suggestion:  How about we, rather than
> updating the old std.process, create a new module called
> std.sys.process?  Or even better, IMO, std.sys.environment and
> std.sys.pipe as well as std.sys.process?

I like that, to have a "sys" package.

-- 
/Jacob Carlborg

> There was a recent thread [1] about deepening Phobos' module hierarchy, and it seems that most people agree this is something that should eventually happen.
>
> In light of this, here's a suggestion:  How about we, rather than updating the old std.process, create a new module called std.sys.process?  Or even better, IMO, std.sys.environment and std.sys.pipe as well as std.sys.process?
>

Why std.sys? sys is used to group platform specific stuff in the runtime. So I would expect to have a std.sys.linux.process and a std.sys.posix.process etc.

On Friday, 5 April 2013 at 06:33:24 UTC, Tobias Pankrath wrote:
>> There was a recent thread [1] about deepening Phobos' module hierarchy, and it seems that most people agree this is something that should eventually happen.
>>
>> In light of this, here's a suggestion:  How about we, rather than updating the old std.process, create a new module called std.sys.process?  Or even better, IMO, std.sys.environment and std.sys.pipe as well as std.sys.process?
>>
>
> Why std.sys? sys is used to group platform specific stuff in the runtime. So I would expect to have a std.sys.linux.process and a std.sys.posix.process etc.

I'd prefer to have an std.process package, but that is currently not possible.  I agree std.sys is a bit misleading.

Nevermind my suggenstion, then.  If DIP16 gets implemented, we can always split std.process into std.process.manage, std.process.environment, std.process.old, etc.

Lars

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

On Sat, 06 Apr 2013 05:13:10 -0400, Lars T. Kyllingstad <public@kyllingen.net> 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.

This is true.  Even the windows switch is misleading.

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"

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.

As far as a positive flag, what about suppressConsole?  Little verbose I suppose...

-Steve