On Mon, Mar 11, 2019 at 02:26:20PM -0700, L A Walsh wrote:
> How would that break compatibility?
The same way shellshock did. A function exported by a parent bash
process using format A could not be read by a child bash process expecting
format B.
Now, you may be thinking, "This makes no sense!
On 3/11/19 4:15 PM, L A Walsh wrote:
>
>
> On 3/6/2019 7:18 AM, Chet Ramey wrote:
>>> Except that the bash debugger gets lost on files that don't
>>> have a real source file name. Environment is not the name of the file
>>> containing the function -- it is a nebulous, ephemeral area of a
>>>
On 3/11/2019 1:34 PM, Greg Wooledge wrote:
> It's not documented so much as blatantly obvious by looking at how it's
> implemented.
>
---
Undocumented features are subject to change at will. Those are called
'internals'. How they are implemented is not necessarily pertinent to
what documen
On Mon, Mar 11, 2019 at 01:15:16PM -0700, L A Walsh wrote:
> 1) Where is it documented that if you export a function, the original
> source location is thrown away by bash?
It's not documented so much as blatantly obvious by looking at how it's
implemented.
wooledg:~$ export -f title
wooledg:~$
On 3/6/2019 7:18 AM, Chet Ramey wrote:
>> Except that the bash debugger gets lost on files that don't
>> have a real source file name. Environment is not the name of the file
>> containing the function -- it is a nebulous, ephemeral area of a
>> process -- but it certainly is not the reposi
On 3/5/19 12:13 AM, L A Walsh wrote:
>> OK, doing that doesn't reveal any problem. If you add
>> shopt -s extdebug; declare -F addnums
>> to prog.sh, it prints
>>
>> addnums 0 environment
>>
> That it prints 'environment' and '0' are issues as the manpage says:
>
>the -F option to dec
On 3/4/2019 4:53 PM, Chet Ramey wrote:
> On 3/4/19 6:44 PM, L A Walsh wrote:
>
>
>>> What does `trace' mean here?
>>>
>> ---
>> from the manpage:
>> "output generated when set -x is enabled"
>>
>
> OK. We've only been talking about function tracing to this point. There
> are
On 3/4/19 6:44 PM, L A Walsh wrote:
>> What does `trace' mean here?
> ---
> from the manpage:
> "output generated when set -x is enabled"
OK. We've only been talking about function tracing to this point. There
are several uses for the word, depending on context.
> FWIW, the other day, I a
On 3/4/2019 6:16 AM, Chet Ramey wrote:
> On 3/3/19 9:53 PM, L A Walsh wrote:
>
>> In bash 4.4.12, if I have some 'library' like functions that I
>> read in at login time, and then later call them -- under trace
>> or under bashdb, no source is shown, as bashdb (and for trace, bash)
>> doesn't
On Sun, Mar 3, 2019 at 9:56 PM L A Walsh wrote:
> The first I will call 'lib.sh' that is sourced from my
> /etc/profile
[snip]
> declare -fxr addnums
[snip]
> ---'prog.sh'---
> #!/bin/bash
> # prog: calls addnums on each line read from stdin
> while read ln; do
> addnums $ln
> done
> ---
On 3/3/19 9:53 PM, L A Walsh wrote:
> In bash 4.4.12, if I have some 'library' like functions that I
> read in at login time, and then later call them -- under trace
> or under bashdb, no source is shown, as bashdb (and for trace, bash)
> doesn't seem to be able to retrieve the original source file
In bash 4.4.12, if I have some 'library' like functions that I
read in at login time, and then later call them -- under trace
or under bashdb, no source is shown, as bashdb (and for trace, bash)
doesn't seem to be able to retrieve the original source file name and
line number where the function was
12 matches
Mail list logo
