os.Getenv alternative

513 views
Skip to first unread message

he...@synful.io

unread,
Feb 7, 2015, 5:30:08 PM2/7/15
to golan...@googlegroups.com
Hi All,

The behavior of os.Getenv is that it returns an empty string if the variable is not set. I was thinking that it might be nice to add a little utility function like os.GetenvExists that returns (string, bool) for callers that want to know the difference. The caveat is this: do all OSs support this distinction? I figured maybe such a function doesn't exist because some OS (likely Windows) doesn't acknowledge a semantic difference between unset and the empty string.

Cheers,
Josh

Axel Wagner

unread,
Feb 7, 2015, 5:59:33 PM2/7/15
to he...@synful.io, golan...@googlegroups.com
Hi,

there is http://golang.org/pkg/os/#Environ that you can use to do that
distinction. So, I don't think that it is impossible to do on any os,
but I also don't think it is really important to add it (as most
programs probaly don't need to distinguish and those that do can just
grep through Environ()).

Stan Schwertly

unread,
Feb 7, 2015, 6:47:37 PM2/7/15
to golan...@googlegroups.com
I opened an issue two weeks ago for the same reason: https://github.com/golang/go/issues/9676

The summary is that for now, the syscall package actually provides exactly what you're asking for (string, bool), but it was taken out of the os package because nobody was using it that way. I think it'd be nice to get that behavior back in there, and we had some positive discussions about how to do that. The first proposal (GetenvExists/GetenvCheck) is very easy. The second one might be slightly more work. I've been busy and have felt gross about adding a second synonymous function to the os package. 

Joshua Liebow-Feeser

unread,
Feb 7, 2015, 7:16:49 PM2/7/15
to Stan Schwertly, golan...@googlegroups.com
Stan - I think that EnvironMap has merits on its own in terms of ranging over all environment variables. Still, GetenvExists/GetenvCheck might be nice both because it's a bit cumbersome to have to do `m := os.EnvironMap(); _, ok := m[key]` and because GetenvExists could be implemented much more efficiently (ie, without allocating and making a new map).

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/h3q3KKbeE30/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Stan Schwertly

unread,
Feb 7, 2015, 7:31:26 PM2/7/15
to golan...@googlegroups.com, st...@schwertly.com
Yeah, the two options are separate things that are both useful, and a map would definitely be overkill for a single var. Exists/check is useful for determining the difference between a variable being empty or undefined.  Environmap, or whatever a better name would be :), is how I imagine os.Environ should work now. Right now, it returns a list of strings in the form "KEY=VALUE". My complete guess is that anybody that's using that output is throwing it in a map. I see myself using exists/check for small scripts, and wanting pkg/os to have the environmap thing for convenience.

Joshua Liebow-Feeser

unread,
Feb 7, 2015, 7:37:07 PM2/7/15
to Stan Schwertly, golan...@googlegroups.com
Yeah, that's basically how I feel as well.

brainman

unread,
Feb 7, 2015, 8:22:30 PM2/7/15
to golan...@googlegroups.com
Windows can distinguish between "is blank" and "does not exist".

Alex
Reply all
Reply to author
Forward
0 new messages