On 2013-02-26 12:02, Dicebot wrote:

> Some linux packagers may not include it, for unknown misunderstanding.
> When dmd2 made its way into main Arch Linux repositories I had a small
> e-mail conversation with new maintainer as I had to prove using code
> from DPL/tools is fine license-wise - he was reluctant to put rdmd in by
> default.

Seems weird.

-- 
/Jacob Carlborg

On Tue, 26 Feb 2013 07:28:11 -0500, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> On Tuesday, 26 February 2013 at 07:08:37 UTC, Lars T. Kyllingstad wrote:
>> What if the variable is set, but empty?  Is that very different
>> from the situation where it doesn't exist at all?  In my opinion,
>> when it comes to environment variables, no.
>
> Until today, I didn't know that empty variables could exist. They don't exist on Windows: setting a variable to an empty string is how you delete it.
>
> Regardless, I think my point still stands on the argument that it's much more likely for a variable to be unexpectedly unset rather than unexpectedly empty. To extend to a general case, we could say that an empty variable is as likely as any invalid or unexpected value. For the 'rm -rf $FOO/$BAR' case, one can come up with any combinations of FOO and BAR, such as "/bin" and "../", where the command would have the same effect.

If I use $XYZ in a script, and XYZ isn't set, it equates to nothing.  When I use getenv, it returns null.  That is the behavior I would intuitively expect.

On one hand, I think the correct behavior is to return null, and let the program deal with checking the error, or use get if they have a default.  If we throw an exception, people will end up catching the exception in order to avoid an unintended error.  Exceptions are not good for flow control, they are for exceptional situations that you didn't plan for.

On the other hand, the other implementation, which is already in std.process, is also a valid implementation, and there already exists code which uses it.  If we have the same abilities via get, then no functionality is lost, it's just a tad more verbose.

In my opinion, the current implementation is only slightly worse than the proposed.  If there is a chance we can simply replace std.process instead of using std.process2 if we go with the original implementation, I think we should do that.

-Steve

On Tue, 26 Feb 2013 07:20:51 -0500, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> On Tuesday, 26 February 2013 at 07:17:49 UTC, Lars T. Kyllingstad wrote:

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

shell("start foo.txt");

At least, I think this would work ;)

-Steve

On Tuesday, 26 February 2013 at 14:08:34 UTC, Steven Schveighoffer wrote:
> On Tue, 26 Feb 2013 07:20:51 -0500, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
>
>> On Tuesday, 26 February 2013 at 07:17:49 UTC, Lars T. Kyllingstad wrote:
>
>>> 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.
>
> shell("start foo.txt");
>
> At least, I think this would work ;)

No, start uses the same function, ShellExecute. It will open whatever is associated with .txt files, a text editor probably.

On Tuesday, 26 February 2013 at 14:02:08 UTC, Steven Schveighoffer wrote:
> If I use $XYZ in a script, and XYZ isn't set, it equates to nothing.  When I use getenv, it returns null.  That is the behavior I would intuitively expect.

I thought well-written scripts should use "set -u"?

On Sat, 23 Feb 2013 06:31:19 -0500, Lars T. Kyllingstad <public@kyllingen.net> 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 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?)

I just reread the docs, considering Vladimir's point about space-containing no-arg programs.  I agree there is a problem.

We need to not get rid of the single program version of spawn, we need to simply interpret it as a no-arg program.

To have this not work:

spawnProcess("c:/Program Files/xyz/xyz.exe");

and require this instead:

spawnProcess("c:/Program Files/xyz/xyz.exe", []);

is not very intuitive.

It reminds me of when we had writefln and not writeln, in order to print out a string with % in it, you had to do writefln("%s", "%s");

Now, I think we have an additional issue in that it's difficult to take a string argument with parameters in it, and pass it in one line:

string executeThis = "prog arg1 arg2";
auto params = split(executeThis);
spawnProcess(params[0], params[1..$]);

It would be nice to just be able to do this:

spawnProcess(split(executeThis));

I think we need an overload for that, especially if we get rid of the auto-splitting of commands.  It should assert if the array is empty.

-Steve

On Tue, 26 Feb 2013 09:15:05 -0500, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> On Tuesday, 26 February 2013 at 14:02:08 UTC, Steven Schveighoffer wrote:
>> If I use $XYZ in a script, and XYZ isn't set, it equates to nothing.  When I use getenv, it returns null.  That is the behavior I would intuitively expect.
>
> I thought well-written scripts should use "set -u"?

I didn't even know about that.  But my point still stands -- if well-written scripts are supposed to use set -u, it should be the default.

Hm... what about something like Environment.throwOnUnsetVariable = true;

-Steve

On Tue, 26 Feb 2013 09:13:01 -0500, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> On Tuesday, 26 February 2013 at 14:08:34 UTC, Steven Schveighoffer wrote:
>> On Tue, 26 Feb 2013 07:20:51 -0500, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
>>
>>> On Tuesday, 26 February 2013 at 07:17:49 UTC, Lars T. Kyllingstad wrote:
>>
>>>> 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.
>>
>> shell("start foo.txt");
>>
>> At least, I think this would work ;)
>
> No, start uses the same function, ShellExecute. It will open whatever is associated with .txt files, a text editor probably.

Oh, I thought that was the desired behavior, I misread the above post...

-Steve

On 2013-02-26 15:22, Steven Schveighoffer wrote:

> It would be nice to just be able to do this:
>
> spawnProcess(split(executeThis));
>
> I think we need an overload for that, especially if we get rid of the
> auto-splitting of commands.  It should assert if the array is empty.

How about:

spawnProcess(string[] args ...);

-- 
/Jacob Carlborg

On Tuesday, 26 February 2013 at 14:26:22 UTC, Steven Schveighoffer wrote:
> On Tue, 26 Feb 2013 09:15:05 -0500, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
>
>> On Tuesday, 26 February 2013 at 14:02:08 UTC, Steven Schveighoffer wrote:
>>> If I use $XYZ in a script, and XYZ isn't set, it equates to nothing.  When I use getenv, it returns null.  That is the behavior I would intuitively expect.
>>
>> I thought well-written scripts should use "set -u"?
>
> I didn't even know about that.  But my point still stands -- if well-written scripts are supposed to use set -u, it should be the default.

Pretty sure it can't be the default due to backwards-compatibility reasons.

> Hm... what about something like Environment.throwOnUnsetVariable = true;

That would break with programs using distinct components that rely on that setting's value...