Re: [lmi] [lmi-commits] odd/multiarch adf0725 04/10: Validate $LMI_COMPILER as well as $LMI_TRIPLET

[Greg Chicares]

On 2019-05-15 22:44, Vadim Zeitlin wrote:
> On Wed, 15 May 2019 17:59:55 -0400 (EDT) Greg Chicares <address@hidden> wrote:
> 
> GC> branch: odd/multiarch
> GC> commit adf072500fa4f5bda7ce8c81df8ae8ad6f75ee4d
[...]
> GC> +        # This script is to be sourced, so it can't use a builtin
> GC> +        # command like 'print' here. Similarly, 'exit' would have
> GC> +        # a surprising effect.
> GC> +        echo "Changed nothing because compiler is untested."
> GC> +        return 2;
> GC> +        ;;
> GC> +esac
> 
>  I've missed a similar comment that had been previously added in the switch
> over LMI_TRIPLET, but now that I've noticed it I can't prevent myself from
> asking where does the idea that built-ins can't be used in sourced files
> come from?

I have no idea. Perhaps, as you speculate below, I had tried to use
the 'print' zsh builtin, but sourced the script in a dash session.

> AFAIK there is no problem with this and a simple test seems to
> confirm that it works just fine.

I tried searching for this online, but even fairly disreputable
sites don't support this notion.

>  Of course, as we had previously discussed, "print" is zsh-specific, but
> a next commit already corrects it to "printf", and the latter should be
> perfectly usable here. And even though I have no particular problems with
> using "echo" neither, I think the first part of this comment is surprising
> and, AFAICS, misleading.

I'll fix it. Thanks for pointing this out.

> GC> +foo
> GC> +
> GC>  unset -f foo
> 
>  And while I'm asking questions, why do we use this foo function? This is
> actually 2 questions:
> 
> 1. Why do we use a function at all?

A comment says:

# Implemented as a function that runs and then erases itself, so that
# sourcing this script changes the environment only as intended.

I can do local stuff inside the function, and the function's {} wrapper
contains it, so that it won't leak out and pollute the environment.

> 2. Why does this function use this meaningless name?

I was thinking of changing it to 'f'. I like names that lack any
possible lexical significance, where there's only one possible
meaning: "actually do the thing this script is supposed to do".