On 2/20/15 2:42 PM, SN wrote:
> Thanks to you both for the answers. I am glad to see that my original
> issue has been fixed.
> The thread is indeed long and detailed, so let me just leave a note
> about a weird behaviour with 4.4.0 (devel) I have that may or may not be
> the intended behaviour.
>
> Yes. The issue is that the assignment doesn't make the variable visible,
> when it clearly should. I've attached a patch that will fix that.
And it does.
> The next version of bash will do things differently, as noted in a
couple of followups to this message. The proposal that prompted the
cha
On 2/18/15 2:44 PM, Eduardo A. Bustamante López wrote:
> Let's wait to see what Chet has to say on that matter. Changes on the devel
> branch are not documented, so he's the only one that knows what's going on.
All changes are in the changelog (CWRU/CWRU.chlog or CWRU/changelog). A
typical chang
On 2/18/15 2:30 PM, SN wrote:
> Thanks for checking it on various versions! In 4.4.0(1)-devel this test
> passes for a few variations I tried. For example:
>
> $ f() { declare -a a="()"; eval "declare -p a"; printf "[%s]\n"
> "${a[@]}"; }; f
> declare -a a=([0]="()")
> [()]
>
> and
>
> $ f() {
On 2/17/15 5:46 PM, Eduardo A. Bustamante López wrote:
> You're reporting the behavior of the master branch, but it seems to
> be already fixed in devel. I'm not sure about the inconsistency
> between:
> | "$bash" -c 'declare -a a="()"; declare -p a'
> and
> | "$bash" -c 'f(){ declare -a a="()
On 2/16/15 3:38 PM, SN wrote:
> By the way, empty arrays seem to be reported as "not set".
> a=(); test -v a || echo "not set"
> This might be related (or not), but consider that the return
> status of `test -v'
> is different on a bash version unaffected by the bug
On 2/16/15 3:38 PM, SN wrote:
> Hello all,
>
> I have found a problem with the declare builtin.
>
> Patch Level: 33
> Release Status: release
>
> Description:
> Apparently, there is a problem with how bash interprets some
> variable assignments.
> It only happens in a function (p
On Wed, Feb 18, 2015 at 08:30:31PM +0100, SN wrote:
> > Also, remember to state the version you're using.
> I pasted version in the format printed by bashbug. In case it's not enough:
Yep, you omitted this part though:
Bash Version: 4.3 <- that
Patch Level: 33
Release Status: release
Let's wait to
> Also, remember to state the version you're using.
I pasted version in the format printed by bashbug. In case it's not enough:
$ LANG=C bash --version
GNU bash, version 4.3.33(1)-release (x86_64-pc-linux-gnu)
...
> This particular
> feature seems to behave differently in the -devel branch:
>
>
>
I'm pretty sure this was already discussed in this thread:
* http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00108.html
But... it's huge, so it's hard to find the precise part where this
was discussed.
Also, remember to state the version you're using. This particular
feature seems to behave
> Already reported:
>
> * test -v: http://lists.gnu.org/archive/html/bug-bash/2014-11/msg00099.html
> * declare -p arrname:
> https://lists.gnu.org/archive/html/bug-bash/2012-11/msg00084.html
The second thread is about something completely different as I
understand it.
It is about variables whose
Already reported:
* test -v: http://lists.gnu.org/archive/html/bug-bash/2014-11/msg00099.html
* declare -p arrname:
https://lists.gnu.org/archive/html/bug-bash/2012-11/msg00084.html
Hello all,
I have found a problem with the declare builtin.
Patch Level: 33
Release Status: release
Description:
Apparently, there is a problem with how bash interprets some
variable assignments.
It only happens in a function (probably related to `declare'
making variables local)
13 matches
Mail list logo
