Re: Issues with exported functions

[lolilolicon]

On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh <bash@tlinx.org> wrote:
> lolilolicon wrote:
>>
>> I don't expect more than a dozen who rely on this... but bash
>> programmers can be quite the perverts, so...
>>
>
> Personally I find those who don't read the man page, and then claim that
> documented
> behavior is a "bug" are the real "perverts".  They expect documented
> behavior to work
> some way other than is documented... How is that not perverted?

You're arguing "like a girl". I didn't say the documented behavior was a
bug. By "perverts", I meant "clever, sometimes too clever".

By that "but", I also meant to deliver that my expectation would
probably turn out to be wrong, "because bash programmers".

I don't mean to sound offensive. Please don't take it too heavily.

> I also find redefining functions with every invocation of bash a major waste
> of cpu cycles.
>
> Tons of functions are defined these days with all the support for
> bash completions.

I do not think about optimization. My opinion is the need for the
programmer to think about optimization (that's not relevant to the
problem at hand) is a symptom of bad design (of the language / tool), or
perhaps the programmer is using wrong tool / using the tool wrong.

As to your particular argument for completions: I think zsh optimizes
for this with autoloading mechanism, which is a better design.

> In scripts, I usually define *aliases* (which are processed before
> functions)
>
> If you want to execute commands in a script, you must make sure
> you are executing those commands.   So first, those script better set the
> PATH to a
> standard path.  Any script that doesn't has no right to complain about this
> "bug".
>
> 2nd, how many scripts define utils into vars:
>
> cp=/usr/bin/cp
>
> $cp ....
>
> -------
> The safe way to define cmnds which I try to use in most of my scripts is to
> define
> them as ALIASES that get expanded before functions.
>
> Example:
>
> #!bin/bash
>
> function true () { false; }
>
> if true; then echo "true==true"; else echo "true==false" ; fi
>
> # above demonstrates what seems to be the bug (a function overriding a
> command)
> # how it got there, is not entirely relevant
>
> #-- fixed example:
>
> PATH=/sbin:/usr/sbin:/bin:/usr/sbin:$PATH
> shopt -s expand_aliases
> alias true=$(type -P true)
>
> if true; then echo "true2==true2"; else echo "true2==false2" ; fi
>
> ----
> The 2nd example works because it defines the PATH and defines an an alias
> expansion that translates to the abs path that the alias was defined with.
>
> If people programmed safely to begin with, this wouldn't have come up as a
> bug, but a feature.

Isn't the mere fact that you have to do this round-around thing to
"program safely" a proof by demonstration that exported functions are
trouble?

>From a theoretical stand point, function export is really a hack. Or a
backdoor as termed by Eric Blake in another thread. When you export a
function, bash really creates and exports a variable,

    % bash -c 'fun() { :;}; export -f fun; env -0 | grep -z "^fun="'
    fun=() {  :
    }

So the token '() {' is the only "protocol" for bash function export /
import. A bit too magic, IMO. And of course it forbids importing normal
variables that match the token.