[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues with exported functions
From: |
lolilolicon |
Subject: |
Re: Issues with exported functions |
Date: |
Fri, 26 Sep 2014 03:55:44 +0800 |
On Fri, Sep 26, 2014 at 2:53 AM, Linda Walsh <address@hidden> wrote:
> ---
> "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).
LOL, you're reinforcing my opinion of your style of argument, but I'll keep
that to myself. BUT you spelt my nick wrong :(
[...]
> 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.
What you're proposing here is the polar opposite of most people's
reaction to this bug; many are asking for a way to disable function
export, an obscure feature they never expected from bash.
I'm not sure how you want other kinds of export to work. I suppose you
want them to be inherited from the env? Then you want to invent a
protocol / syntax / minilanguage for bash to export and import those.
This is IMO not what the env is suitable for, since it's meant to be used
as a very simple and flat "name=value" format for passing environment
variables around. But maybe you can elaborate?
>
> 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")"
Wow. That's advanced...
It looks like you have built a language on top of bash. Perhaps, just
maybe, your needs have outgrown what bash can reasonably provide?
(Feel free to dismiss this, I know this is a subjective thing.)
- Re: Issues with exported functions, (continued)
- Re: Issues with exported functions, lolilolicon, 2014/09/24
- Re: Issues with exported functions, Linda Walsh, 2014/09/24
- Re: Issues with exported functions, lolilolicon, 2014/09/25
- Re: Issues with exported functions, Pierre Gaston, 2014/09/25
- Re: Issues with exported functions, lolilolicon, 2014/09/25
- Re: Issues with exported functions, Pierre Gaston, 2014/09/25
- Re: Issues with exported functions, lolilolicon, 2014/09/25
- Re: Issues with exported functions, Chet Ramey, 2014/09/25
- Re: Issues with exported functions, lolilolicon, 2014/09/25
- Re: Issues with exported functions, Linda Walsh, 2014/09/25
- Re: Issues with exported functions,
lolilolicon <=
- Re: Issues with exported functions, Steve Simmons, 2014/09/24
- Re: Issues with exported functions, Gabriel Corona, 2014/09/25
- Re: Issues with exported functions, Gabriel Corona, 2014/09/25
- Re: Issues with exported functions, Chet Ramey, 2014/09/25
- Re: Issues with exported functions, Dan Douglas, 2014/09/25
- Re: Issues with exported functions, Chet Ramey, 2014/09/25
- Re: Issues with exported functions, Dan Douglas, 2014/09/25
- Re: Issues with exported functions, Eric Blake, 2014/09/25
- Re: Issues with exported functions, Gabriel Corona, 2014/09/25
- Re: Issues with exported functions, Gabriel Corona, 2014/09/25