On 5/21/16 5:16 PM, adonis papaderos wrote:
> Bash Version: 4.3
> Patch Level: 42
> Release Status: release
>
> Description:
> When using redirections preceded by a word on builtins
> 'i.e. : {varname}<&1'
> the redirection persists to the current shell.
This is by design, an
On 4/8/16 3:01 PM, Paul Eggert wrote:
> [Sending this to bug-bash@gnu.org since the mail was rejected by
> bash-test...@cwru.edu.]
That list only accepts messages from subscribed email addresses.
> Bash Version: 4.4
> Patch Level: 0
> Release Status: rc1
Thanks for the report.
--
``The lyf s
I had read this before sending this message. The discussion you mention
concerns leaking named redirections from function calls. This is not what I
was trying to say. I was talking about the difference in behaviour between
the creation and the destructions of the fd. There is also the difference
in
From: osirisgot...@hotmail.com
To: bug-bash@gnu.org,b...@packages.debian.org
Subject: compat42 and compat41 behave incorrectly, compat41 not possible
at all
compat42 and compat41 shell options are set incorrectly when set via
BASH_COMPAT
Configuration Information [Automatically generated, d
The nameref resolution search doesn’t re-start back at the original
context. It’s like a symbolic link — it continues at the same context as
the resolved nameref.
If the assignment to the global variable is intentional, then shouldn’t
expansion use the global variable’s value as well?
The expansi
This multiple-vars-at-same-scope thing happens also happens in the case
that the nameref points to a variable at a higher scope of the same name as
the nameref. I suspect this is related to the nameref resolution issue here
http://lists.gnu.org/archive/html/bug-bash/2016-05/msg00115.html
Given a f
The following should probably work:
$ declare -n ref=var ref+=[@]
bash: declare: [@]: invalid variable name for name reference
But the following should not:
$ declare -n ref=re ref+=f
$ declare -p refdeclare -n ref="ref"
The latter causes a segfault for export/readonly.
These all appear to work correctly in the devel branch.
On Sun, May 22, 2016 at 2:52 PM, Gabriel Sharp
wrote:
> From: osirisgot...@hotmail.com
> To: bug-bash@gnu.org,b...@packages.debian.org
> Subject: compat42 and compat41 behave incorrectly, compat41 not possible
> at all
>
> compat42 and comp
On 5/20/16 6:47 PM, Grisha Levit wrote:
> I would propose that the following behavior would be least surprising for
> assignments before command names:
>
> * iff |$ref| is a valid nameref for assignment, assigning/appending to
> |ref| modifies the target variable (for ksh93 compat)
> *
>
On 5/22/16 2:52 PM, Gabriel Sharp wrote:
> From: osirisgot...@hotmail.com
> To: bug-bash@gnu.org,b...@packages.debian.org
> Subject: compat42 and compat41 behave incorrectly, compat41 not possible at
> all
>
> compat42 and compat41 shell options are set incorrectly when set via
> BASH_COMPAT
Tha
On 5/22/16 6:06 PM, Grisha Levit wrote:
> The expansion part really seems like the bug here, and can be demonstrated
> without any crazy cross-scope chains.
>
> As I understand it, the intention is indeed to allow namerefs to point to
> outer-scope variables, even if they happen to have the same
11 matches
Mail list logo
