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
n/set0.c:42: undefined reference to `_builtin_error'
/tmp/bashdb/builtin/set0.c:43: undefined reference to `_builtin_usage'
collect2: ld returned 1 exit status
make: *** [set0.exe] Error 1
Perhaps I need to tell cygwin that these symbols are supposed to be
undefined since they are part of bash?
Thanks for the help or suggestions,
rocky
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
these settings and how the bind and read builtins work.
If you want me to suggest some text, I'd be happy to.
Thanks again.
On Thu, Sep 11, 2008 at 9:29 AM, Chet Ramey <[EMAIL PROTECTED]> wrote:
> rocky wrote:
> > The most recent bash docs say this about builtin function re
The most recent bash docs say this about builtin function read with
option -e:
Readline (@pxref{Command Line Editing}) is used to obtain the line.
Consider this little program:
PS4='-$LINENO: $? $ '
set -x
builtin bind '"\C-x\C-r": "bind completion"'
builtin bind -P
while read -e -p 'huh? ' li
20 matches
Mail list logo
