On Tue, 26 Feb 2013 07:28:11 -0500, Vladimir Panteleev
<[email protected]> 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
