Current in bash 5.0 and earlier, the value of BASH_REMATCH might chanted
inside a debug hook.
Since BASH_REMATCH is read-only, resetting the value on hook return to the
debugged program is a bit tricky and fragile...
There are way to change a bash readonly variable but that involve using
either
Bashdb skip help is now
https://sourceforge.net/p/bashdb/code/ci/master/tree/command/skip.sh#l30
If this is incorrect, deficient, or you have improvements, let me know.
Thanks.
On Sat, Apr 8, 2017 at 7:52 PM, Rocky Bernstein wrote:
> Good point! Will make note of that too.
>
> On S
Good point! Will make note of that too.
On Sat, Apr 8, 2017 at 7:15 PM, Chet Ramey wrote:
> On 4/8/17 6:48 PM, Rocky Bernstein wrote:
> > Thanks for giving me a heads up here. I have updated the bashdb
> > documentation for the skip command make clear that $? is no changed in
Thanks for giving me a heads up here. I have updated the bashdb
documentation for the skip command make clear that $? is no changed in
skipping an instruction.
More generally bash saves and restores some state on entry and exit to
extdebug, like the variable $? (the extdebug function can issue a c
No failure using 4.4.0(1)-beta (x86_64-unknown-linux-gnu).
Thanks. I'll adjust things on my side then.
On Mon, Oct 26, 2015 at 2:00 PM, Chet Ramey wrote:
> On 10/26/15 1:25 PM, Rocky Bernstein wrote:
>
> > Bash Version: 4.3
> > Patch Level: 11
> > Release Status
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE
On Tue, May 5, 2015 at 2:54 PM, Chet Ramey wrote:
> On 4/30/15 9:27 AM, Chet Ramey wrote:
> > On 4/29/15 10:31 PM, Rocky Bernstein wrote:
> >
> >> $ ./bash --debugger -i /tmp/foo.sh
> >> hi
> >>
> >> $ ./bash --debugger /tmp/
Thanks.
On Thu, Apr 30, 2015 at 9:27 AM, Chet Ramey wrote:
> On 4/29/15 10:31 PM, Rocky Bernstein wrote:
>
> > $ ./bash --debugger -i /tmp/foo.sh
> > hi
> >
> > $ ./bash --debugger /tmp/foo.sh
> > bash debugger, bashdb, release 4.3-0.91
> >
>
/bash --debugger -i /tmp/foo.sh
hi
On Wed, Apr 29, 2015 at 9:39 PM, Chet Ramey wrote:
> On 4/29/15 9:07 PM, Rocky Bernstein wrote:
>
> > And to the end of being more informative, In the thread you cited, there
> > was a suggestion about being more informative about skippin
sh: foo: disabling debugging mode*
It wouldn't be that hard to add this in an "else" branch.
Thanks. and Thanks for addressing this issue.
On Wed, Apr 29, 2015 at 8:22 PM, Chet Ramey wrote:
> On 4/29/15 8:05 PM, Rocky Bernstein wrote:
> > I am sure you have changed thi
hanks.
On Wed, Apr 29, 2015 at 7:21 PM, Chet Ramey wrote:
> On 4/29/15 1:51 PM, Rocky Bernstein wrote:
> > Now I am really confused and I am not sure we are talking about the same
> > thing
>
> We really are.
>
> > In bash-4.3.30 on ftp://ftp.gnu.org/gnu/bash
ger main file is
getting read. But this is different from the problem encountered.
On Wed, Apr 29, 2015 at 10:57 AM, Chet Ramey wrote:
> On 4/28/15 10:11 PM, Rocky Bernstein wrote:
> > It's come to my attention that running bash --debugger doesn't source
> > DEBUGGER_ST
It's come to my attention that running bash --debugger doesn't source
DEBUGGER_START_FILE
when the script to be debugged isn't followed by any arguments.
An example will probably make this clear. Suppose */tmp/foo.sh* is:
echo hi
And you run:
bash --debugger /tmp/foo.sh
I get "hi" prin
I am trying to build a bash builtin on cygwin. Here's the error message I
get via automake/make:
$ make
gcc -g -O2 -o set0.exe -shared set0-set0.o
set0-set0.o: In function `set0_builtin':
/tmp/bashdb/builtin/set0.c:46: undefined reference to `_builtin_error'
/tmp/bashdb/builtin/set0.c:47: undef
On Tue, Sep 23, 2008 at 8:46 AM, Chet Ramey <[EMAIL PROTECTED]> wrote:
> Rocky Bernstein wrote:
>> Sorry for the delayed reply.
>>
>> As I now understand it, the situation right now seems a bit
>> inconsistent. "read -e" in a script uses emacs bindings
d thus left it,
instead saving my commands in my own array. It's possible others have
experienced this. Some of this may be a result of the compressed
information, although I think there are other issues such as lack of
examples or overall organization as well.
On Sat, Sep 13, 2008 at
There is a connection between the "set -o emacs", "set -o vi", and "set -o
history" commands and the way "read -e" works. But there is nothing that I
could find in any of the bash/readline/history documents that make this
connection explicit. Changing one of these "line editing" settings changes
k
y
bindings which no longer are in effect. I threw in the bind command just to
try to help me see what was going on.
On Thu, Sep 11, 2008 at 11:36 AM, Chet Ramey <[EMAIL PROTECTED]> wrote:
> Rocky Bernstein wrote:
> > Many thanks for the explanation. I've just updated bashd
Many thanks for the explanation. I've just updated bashdb CVS to add an edit
style (emacs/vi) and which will give more complete readline handling in
entering debugger commands.
There still is some weirdness in how history retrieval works, but I need to
isolate what's going on there.
And it looks
19 matches
Mail list logo
