Re: Issues with exported functions

[Linda Walsh]

lolilolicon wrote:
>  On Thu, Sep 25, 2014 at 9:00 PM, Chet Ramey <chet.ramey@case.edu> wrote:
> > Even if you use it as a rhetorical device, it distracts from (and
> > detracts from) your argument.  It doesn't improve the quality of the
> > discussion, so it's best not to use it.
>  Agreed. People can take light-hearted side remarks too seriously.
>
>  *adds "pervert" & "like a girl" to List of Forbidden Terms in Public
>  Mail*
>
>  Thank you.
---
"prevert"  _might_ have been more obviously seen as applicable to a bash
programmer who is "pre-bent" or "pre-twisted" from having programmed in
shell for so long, compared to the nick, lilololicon, with its 'H'y (as 
in 'Hentai'-y)
connotations it might invoke about someone who might be just a bit too
"pedo-friendly" or pedo-'filic' (unless everyone knows the inside humor).
As for the other phrase... are you from australia as a first guess, maye
euro as a 2nd?  Needless, one needs to make context and humor extra
clear in an international audience (not that I always am a master of
subtlety in such).

>  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.

Spoilt youngster!... Bash is an interpreter and not noted for being
a high-speed scripting language.


>  As to your particular argument for completions: I think zsh optimizes
>  for this with autoloading mechanism, which is a better design.
---
Bash has an autoloading mechanism that people don't use because it's
usually faster to put a bunch of defs in 1 place than spread them over
1000 files.  For interactive use (which is zsh's emphasis), it's fine, but
for something that is as often used as a batch-control language as often
as interactively (like bash), its not.  Zsh isn't a backbone scripting
language.


>  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?
===

Cf.: Isn't the mere fact that you need to use a "safe path" demonstrate
that PATH lookup is trouble?  OTOH, using abs-paths is just as problem
laden.  That you need to use safety precautions to generate robust
programs is "par for the course".

Everything has its up and down side(s).  By defining the programs I will
need as aliases up front, the program will die earlier if it's
requirements are not present.

Nevertheless, I'll redefine progs as functions nearly as often so I can
make a program easier to call (aliases are limited to the easiest stuff)
from my script.

Other functions redefine commands for a login session.  I don't want them
undefined on sub commands.  I'd prefer aliases be exportable (as well as
arrays and hashes).  If my sub commands are built on others, they'd all go
belly-up after the first exec -- more so than when sudo kills them off:

like "rd" for rmdir or "+x" for chmod +x -- both of which I need as
often with a sudo before them as not (and that tend to fail due to
sudo's inability to parse aliases or functions).

To give you an idea of function and definition that is skipped at login
vs.  not:

>  time bash 2>/dev/null <<xxx
xxx
0.00sec 0.00usr 0.00sys (88.59% cpu)

>  time bash -i 2>/dev/null <<xxx
xxx User .bashrc called 2nd time
0.21sec 0.14usr 0.05sys (93.21% cpu)
>

----
Setting up things only 1 time saves considerable time depending on
how much is setup for an interactive shell vs. not.

Also if my script uses 'sudo' it has to pay such penalties unless I patch
sudo.  I'll have scripts that make tons of calls to sudo because the rest
was designed to operate w/o privs and I try to isolate priv calls, so an
unpatch sudo that doesn't preserve environment when told to is a problem.

My only issue "with" function export is it being a partial solution,
missing Aliases (first and foremost) which, for some things, are more
essential than functions, and missing Array and Hash export -- which have
to be annoyingly emulated and reconstructed between commands.

Redoing those with each command is equally painful and requires their
redefinition with each bash invocation via BASH_ENV.  But the number of
redefines to work around those deficits is insignificant to the number of
functions that rely on persistence, so simple scripts like this work:

---show_inc.sh---
#!/bin/bash   
include stdalias
include Util/url

#definitions are important
int a=1+1
string astring=1+1
a+=1+1
astring+=1+1
printf "Integers: 1+1+1+1 = %s.  Strings: 1+1+1+1 = %s\n" "$a" "$astring"

#2nd example
include Util/url

string url="http://google.com/foo";

echo "proto=$(protocol "$url"), host=$(host "$url"), path=$(path "$url")"
---run---
/tmp> show_inc.sh
Integers: 1+1+1+1 = 4.  Strings: 1+1+1+1 = 1+11+1
proto=http, host=google.com, path=fooshow_inc.sh
---

(Yes, I included Util/url twice to show the effect of doing so).

Not only are exported functions a useful timesaver, but aliases, arrays
and hashes are equally useful and would be more so if not needing
reinit.  each time.