I built bash using scan-build
(https://clang-analyzer.llvm.org/scan-build.html) and I noticed that
it was able to detect the null pointer dereference reported earlier by
Jaren (https://lists.gnu.org/archive/html/bug-bash/2017-04/msg00100.html).
dualbus@debian:~/src/gnu/bash$ scan-build-3.9 make
sc
On 4/23/17 4:25 PM, Florian Mayer wrote:
>> That's not a reasonable expectation.
> Why not? Why is it not reasonable to expect an intuitive
> result from (())? The most intuitive thing, in my opinion,
> would be to use nameref for side effects by default, because in order
> to get a value from an i
On 4/23/17 2:52 AM, Noneofthebusiness Ofsomehere wrote:
> There is an annoying problem I struggle with that might be associated with
> tab completion. I would like to share it with you. It might be a bug. I
> really don't know and I'm new to Linux and programming, hence I am being
> extra careful i
On Sun, Apr 23, 2017 at 3:25 PM, Florian Mayer wrote:
[...]
> Why not? Why is it not reasonable to expect an intuitive
> result from (())? The most intuitive thing, in my opinion,
> would be to use nameref for side effects by default, because in order
> to get a value from an id, (()) already foll
There is an annoying problem I struggle with that might be associated with tab
completion. I would like to share it with you. It might be a bug. I really
don't know and I'm new to Linux and programming, hence I am being extra careful
in naming this a bug:
https://unix.stackexchange.com/questio
> That's not a reasonable expectation.
Why not? Why is it not reasonable to expect an intuitive
result from (())? The most intuitive thing, in my opinion,
would be to use nameref for side effects by default, because in order
to get a value from an id, (()) already follows namerefs.
So if you have
On 4/23/17 8:28 AM, Florian Mayer wrote:
> What I’m saying is, that if bash does recursively apply expansion
> mechanisms on the identifiers until it can retrieve a number,
> it should do it symmetrically.
That's not a reasonable expectation.
Here's how it works. When bash reads a token, such a
On 4/23/17 12:14 PM, Eduardo Bustamante wrote:
> I tried the following patch:
>
> dualbus@debian:~/src/gnu/bash$ git diff -- bashline.c
> diff --git a/bashline.c b/bashline.c
> index 129714aa..7884416a 100644
> --- a/bashline.c
> +++ b/bashline.c
> @@ -2545,7 +2545,7 @@ static void
> maybe_make_
On Sun, Apr 23, 2017 at 12:56 AM, Jaren Stangret wrote:
> Hello,
>
> Instead of segfaulting, BASH should ensure READELINE_LINE is unset or set
> and empty.
I am able to reproduce this with the latest devel branch. Here's the
stack trace:
Program received signal SIGSEGV, Segmentation fault.
0x000
> what shoud echo $((foo++)) do?
Give out an error message hopefully (and it does), because
the expression (bar+14+moo*2)++ makes no semantical sense
in terms of arithmetic expressions the bash uses, because ++
only can apply to locations and (bar+14+moo*2) evaluates to a number no matter
the con
Hello,
Instead of segfaulting, BASH should ensure READELINE_LINE is unset or set
and empty.
*Configuration Information:*
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64
On Sun, Apr 23, 2017 at 4:07 PM, Florian Mayer wrote:
> It does not matter, how this construct in this particular context is
> called.
> The difference between $(()) and (()) is that $(()) actually expands to
> something
> whereas (()) just executes a C-like expression. In (())
> can also
> incl
> And in my opinion those are not correct...
So in a scenario like the mentioned
$ foo=bar; bar=moo; moo=123
the line
$ ((foo++)); echo $foo $bar $moo
should actually evaluate to
„bar moo 124“
or at least say something like
„error, can not execute side effects, because I
can’t keep track of wha
It does not matter, how this construct in this particular context is called.
The difference between $(()) and (()) is that $(()) actually expands to
something
whereas (()) just executes a C-like expression. In (())
can also
include assignments, as the bash manual that you properly cited, also
e
On Sun, Apr 23, 2017 at 3:28 PM, Florian Mayer wrote:
> What I’m saying is, that if bash does recursively apply expansion
> mechanisms on the identifiers until it can retrieve a number,
> it should do it symmetrically. That is,
> it should remember what chain of expansion had been necessary for
>
What I’m saying is, that if bash does recursively apply expansion
mechanisms on the identifiers until it can retrieve a number,
it should do it symmetrically. That is,
it should remember what chain of expansion had been necessary for
a particular number to appear at the end of the expansion.
So i
On Sun, Apr 23, 2017 at 1:12 PM, Florian Mayer wrote:
> Consider
>
> $ foo=bar; bar=moo; moo=123
> $ echo $foo $bar $moo
> => bar moo 123
> $ echo $((foo))
> => 123
> $ echo $foo $bar $moo
> => bar moo 123
> $ # so far so good but
> $ ((foo++))
> $ echo $foo $bar $moo
> => 123 moo 123
>
> Now my
Consider
$ foo=bar; bar=moo; moo=123
$ echo $foo $bar $moo
=> bar moo 123
$ echo $((foo))
=> 123
$ echo $foo $bar $moo
=> bar moo 123
$ # so far so good but
$ ((foo++))
$ echo $foo $bar $moo
=> 123 moo 123
Now my chain of indirections is broken…
18 matches
Mail list logo
