On 12/12/16 5:11 AM, Laur Aliste wrote:
>
> Hi,
> is it accepted behavior for a failing assignment of a readonly variable to
> return successfully?
The readonly builtin did not fail; the variable `j' was set readonly, and,
as a side effect, the shell assigned it the null string.
The assignment t
On 12/12/16 12:26 PM, Arion Deno wrote:
> I believe the bug should have already been fixed .. but
It's not a bug.
> A description of the bug behaviour. :
>
> When you type the command: history -c, to clear the bash history,
> typing bash -v appears to open all configuration files, and the
> comm
I believe the bug should have already been fixed .. but
The version number of Bash:
GNU Bash 4.4
---
Hardware and OS:
Intel pentium 2 300 MHZ
256 MB Ram
VGA: Nvidia MX 4000 - 64 mb
Gnu/ Linux Debian 8.6.0 - i586 , LXDE
-
The compiler used to compile Bash:
Gcc 4.9.2
-
Hi,
is it accepted behavior for a failing assignment of a readonly variable to
return successfully?
See following code:
fail() {
return 1
}
o() {
local i j
i="$(fail)" || echo "i init failed"
readonly j="$(fail)" || echo "j init failed" # this echo is not
executed
}
Expected
Forgot to add: GNU bash, version *4.4.5(1)-release* (x86_64-pc-linux-gnu),
running on Debian testing.
On Mon, Dec 12, 2016 at 11:11 AM, Laur Aliste wrote:
>
> Hi,
> is it accepted behavior for a failing assignment of a readonly variable to
> return successfully?
>
> See following code:
>
> fail(
