environment variable handling cleanup ?

environment variable handling cleanup ?

[Vincent Legoll]

Hello,

as I'm trying to ramp up my scheme & guix -fu, I'm wondering if
something along the lines of :

  (define* (env-prepend env-var value #:key (separator ":"))
    (let* ((env-val (or (getenv env-var) ""))
           (new-val (if (string-null? env-val)
                      value
                      (string-append value separator env-val))))
      (setenv env-var new-val)))

  (define* (env-append env-var value #:key (separator ":"))
    (let* ((env-val (or (getenv env-var) ""))
           (new-val (if (string-null? env-val)
                      value
                      (string-append env-val separator value))))
      (setenv env-var new-val)))

Would be useful / wanted / controversial ?

My crude approximation tells me there is 1 or 2 hundred such
instances that this could replace.

I expect this would turn ~2 SLOCs into one at each site, so the
gains are not huge compared to the size of guix source code base.

The readability enhancement is also up to debate.

There's also the added (or (getenv ...) "") which is not present in
all target cases.

Another question is the usefulness of the separator parameter,
as I think all target cases use ":", so hardcoding it would be a
sensible choice.

WDYT ?

-- 
Vincent Legoll

Re: environment variable handling cleanup ?

[Hartmut Goebel]

Am 22.03.20 um 15:40 schrieb Vincent Legoll:
> as I'm trying to ramp up my scheme & guix -fu, I'm wondering if
> something along the lines of :

Well, I did not count how often this is used, but (guix built utils
update-env) might benefit from this, to.


> There's also the added (or (getenv ...) "") which is not present in
> all target cases.

I suggest to default the value to #f (False), since - depending on the
variables semantic - it may make a difference whether the variabel is
empty or actually unset. This is especially true when used within a
programming language like Scheme which has a notion of "False" - which
env-vars do not have.


> Another question is the usefulness of the separator parameter,
> as I think all target cases use ":", so hardcoding it would be a
> sensible choice.

I doubt there Is a need for different separators The path separator is
defined to be ":" in Posix. So I'd suggest to use a hardcoded value.

-- 

Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: environment variable handling cleanup ?

[Vincent Legoll]

Hello,

since no one objected to the idea, I'm going forward with this.

On Mon, Mar 23, 2020 at 9:55 AM Hartmut Goebel
<h.goebel@crazy-compilers.com> wrote:
> Well, I did not count how often this is used, but (guix built utils
> update-env) might benefit from this, to.

I don't know if you meant that (guix build utils) was the right place
to put those helpers, or if you were hinting me at a place where I
can use them, or both.

It looks like there is something that they can replace in this file:
(wrap-script ... (update-env ...))

But...
[reordering email content]

> > Another question is the usefulness of the separator parameter,
> > as I think all target cases use ":", so hardcoding it would be a
> > sensible choice.
>
> I doubt there is a need for different separators. The path separator is
> defined to be ":" in Posix. So I'd suggest to use a hardcoded value.

To replace (update-env ...) code, I will need to keep separator as a
parameter, since some cases in the match-lambda don't use an
hardcoded ":".

What should I do there ?
Can you clarify ?

> > There's also the added (or (getenv ...) "") which is not present in
> > all target cases.
>
> I suggest to default the value to #f (False), since - depending on the
> variables semantic - it may make a difference whether the variabel is
> empty or actually unset. This is especially true when used within a
> programming language like Scheme which has a notion of "False" - which
> env-vars do not have.

OK, I'll do that, I'll just remove the (or (getenv ...) default-value) as the
return value for getenv on a non-existent variable is already #f

Thanks

-- 
Vincent Legoll