On 4/20/15 4:04 PM, Peng Yu wrote:
>> I disagree that performance overhead in typical use is `significant'.
>> This point is more or less identical to the one I discussed Friday in
>> regards to creating huge numbers of variables. Who creates 100,000
>> shell functions in a single script? The ov
On Mon, Apr 20, 2015 at 03:04:00PM -0500, Peng Yu wrote:
> Hi Chet,
> > I disagree that performance overhead in typical use is `significant'.
> > This point is more or less identical to the one I discussed Friday in
> > regards to creating huge numbers of variables. Who creates 100,000
> > shell f
Hi Chet,
>>> That's the difference: if you're careful with naming and rigorous about
>>> your calling conventions, your one-time-use functions are about as close
>>> as you can get to local functions in bash, but you have to pay attention
>>> to the declaration's side effects.
>>
>> There is at le
On 4/19/15 10:38 PM, Peng Yu wrote:
>> That's the difference: if you're careful with naming and rigorous about
>> your calling conventions, your one-time-use functions are about as close
>> as you can get to local functions in bash, but you have to pay attention
>> to the declaration's side effect
Hi Chet,
>> Eduardo A. Bustamante López wrote:
>>> Well, if your scripts are so simple, why use local functions at all?
>> ---
>> Cleanliness, Hygiene...
>
> Please, let's not have this argument again. I think you're all using the
> term `local function' to mean different things.
>
> You seem
On 4/17/15 6:27 PM, Linda Walsh wrote:
>
>
> Eduardo A. Bustamante López wrote:
>> Well, if your scripts are so simple, why use local functions at all?
> ---
> Cleanliness, Hygiene...
Please, let's not have this argument again. I think you're all using the
term `local function' to mean diff
Hey Linda. I do remember that thread, and I apologize for my words.
I honestly try my best here. But it seems that I cannot reply to you without
offending you, so, to avoid further offenses I will not reply to any further
email from you in the future.
I'm sorry that I offended you, it was not my
Eduardo A. Bustamante López wrote:
Well, if your scripts are so simple, why use local functions at all?
---
Cleanliness, Hygiene...
You're
claiming we invent stuff to make your examples fail, but I don't know anyone
that writes such complex code for very simple tasks that can even b
Well, if your scripts are so simple, why use local functions at all? You're
claiming we invent stuff to make your examples fail, but I don't know anyone
that writes such complex code for very simple tasks that can even be done
without functions. So, the burden to prove these convoluted approaches a
Greg Wooledge wrote:
The problem is, ALL function definitions (and un-definitions) are global.
---
yeah...
If there was a "func" defined at the global scope, you've obliterated it.
I don't understand why you don't understand this.
---
I don't understand why you think I don't understa
On Fri, Apr 17, 2015 at 11:58:15AM -0700, Linda Walsh wrote:
> >outerfunc() {
> > func() { ...; }
> > func args
> > unset -f func
> >}
> >outerfunc
The problem is, ALL function definitions (and un-definitions) are global.
If there was a "func" defined at the global scope, you've obliterated it.
I
Eduardo A. Bustamante López wrote:
On Thu, Apr 16, 2015 at 10:38:22PM -0700, Linda Walsh wrote:
[...]
AFAIK, _exec_gvim, can only be called from within "function gvim", no?
No. Doing this:
outerfunc() {
func() { ...; }
func args
unset -f func
}
outerfunc
Doesn't guarantee that `func' wi
Greg Wooledge wrote:
AFAIK, _exec_gvim, can only be called from within "function gvim", no?
That is not correct. In bash, all function definitions are global.
imadev:~$ f1() { f2() { echo "I'm f2"; }; }; f1; f2
I'm f2
You left out a few important parts, like f2 being called inside f1
On Thu, Apr 16, 2015 at 10:38:22PM -0700, Linda Walsh wrote:
[...]
> AFAIK, _exec_gvim, can only be called from within "function gvim", no?
No. Doing this:
outerfunc() {
func() { ...; }
func args
unset -f func
}
outerfunc
Doesn't guarantee that `func' will be only called from outerfunc. If yo
On Thu, Apr 16, 2015 at 10:38:22PM -0700, Linda Walsh wrote:
> It's a trite example, but I do something like:
>
>
> sub gvim () {
> array orig_args=($@) gv_files=() gv_ops=()
> int use_tab=0 look_for_ops=1
>
>sub _exec_gvim() {
> array args
> ((use_tab)) && args=("-p")
> (
Pierre Gaston wrote:
> Is there a particular problem you're trying to solve for which local
> functions would be the appropriate solution?
Cleanliness.
Not polluting the global namespace.
Ensuring the function can't be called from outside a function.
It's a trite example, but
On 4/16/15 11:43 AM, Dan Douglas wrote:
> I thought Bash always first splits the identifier from the subscript,
> then checks which attributes the variable has set. If it has the
> associative array attribute plus a subscript then the subscript is
> only processed for expansions and the resulting s
On Thu, Apr 16, 2015 at 11:07:34AM -0400, Chet Ramey wrote:
[...]
> I knew that rang a bell somewhere. mt_hash is a function in the bash
> malloc library that keeps track of all allocations and deallocations in
> a table. It's part of the debugging that is enabled when you build from
> the devel
I thought Bash always first splits the identifier from the subscript,
then checks which attributes the variable has set. If it has the
associative array attribute plus a subscript then the subscript is
only processed for expansions and the resulting string is used as the
key. If the associative arr
On 4/12/15 5:56 PM, Eduardo A. Bustamante López wrote:
> Oh, you already have lots of things to do to bother with this :-)
>
> Anyways, I'll expand them.
>
> On Fri, Apr 10, 2015 at 04:35:25PM -0400, Chet Ramey wrote:
>> On 4/10/15 10:13 AM, Eduardo A. Bustamante López wrote:
>>
>>> - a faster im
On 4/12/15 5:56 PM, Eduardo A. Bustamante López wrote:
> Oh, you already have lots of things to do to bother with this :-)
>
> Anyways, I'll expand them.
>
> On Fri, Apr 10, 2015 at 04:35:25PM -0400, Chet Ramey wrote:
>> On 4/10/15 10:13 AM, Eduardo A. Bustamante López wrote:
>>
>>> - a faster im
On 4/12/15 5:56 PM, Eduardo A. Bustamante López wrote:
> Yes. I've been using gprof to study the code paths of some basic functions,
> and
> it seems like it spends quite some time in the find_variable() and related
> functions (IIRC, there was an mt_hash or something function taking up some
> pr
On 4/13/15 8:33 AM, Greg Wooledge wrote:
> On Sat, Apr 11, 2015 at 01:27:53PM -0400, Chet Ramey wrote:
>> On 4/10/15 11:09 AM, Greg Wooledge wrote:
>>> - Fix the $"..." security hole (I tried and failed).
>>> http://www.gnu.org/software/gettext/manual/html_node/bash.html
>>
>> Yeah, I didn't like
On Sat, Apr 11, 2015 at 01:27:53PM -0400, Chet Ramey wrote:
> On 4/10/15 11:09 AM, Greg Wooledge wrote:
> > - Fix the $"..." security hole (I tried and failed).
> > http://www.gnu.org/software/gettext/manual/html_node/bash.html
>
> Yeah, I didn't like the all-or-nothing choice the patch implemen
Oh, you already have lots of things to do to bother with this :-)
Anyways, I'll expand them.
On Fri, Apr 10, 2015 at 04:35:25PM -0400, Chet Ramey wrote:
> On 4/10/15 10:13 AM, Eduardo A. Bustamante López wrote:
>
> > - a faster implementation of the variable lookup code
>
> What does this mean,
On 4/10/15 11:09 AM, Greg Wooledge wrote:
> On Fri, Apr 10, 2015 at 09:13:17AM -0500, Eduardo A. Bustamante López wrote:
>> Now, for the features in bash that'd be actually useful:
>>
>> - discipline functions and compound datatypes (like in ksh)
>> - a way to do wrap arbitrary OS system calls with
On Thu, Apr 9, 2015 at 5:40 PM, Peng Yu wrote:
> However, the real problem is that global variable make larger programs
> difficult to maintain. Therefore, the problem becomes severe for
> people using bash for making bash libraries. Any ad hoc use of bash
> can always get away from this prob
On 4/10/15 10:13 AM, Eduardo A. Bustamante López wrote:
> - a faster implementation of the variable lookup code
What does this mean, exactly? Optimizing the existing code paths? (Have at
it.) Different semantics? Static as opposed to dynamic scoping?
> - a shopt to disable evaluation of shell
28 matches
Mail list logo
