bashdb-devel Mailing List for bash debugger

Feb 8, 2026, 19:07 by ***@***:

> Mailing list is fine. The project has moved to github so > https://github.com/Trepan-Debuggers/bashdb/issues>  can also be used for reporting bugs.
>
> I don't know why, but support and interest in debuggers have been in my later life, not very well supported or funded.
>
I'm surprised to hear that. I can't imagine people are just happy to use Bash solely with 'set -x / -v'.

Ah, so GitHub is where it's at now. Well this is a bit awkward, but so far GitHub has not allowed me to
create an account with this email address, despite me trying different browsers and even disabling some
extensions. And I've solved their captchas on every single attempt. I guess the bots have won.

The point with this address was to *not* expose my private address to the whole world. So I've also tried
to make accounts on Codeberg and GitLab, and that went fine. I'm now in the process of putting some
 things on Codeberg at least - for the time being.
If you're interested, see branch 'devel' on https://codeberg.org/DonQuicoder/bashdb


> This has now been fixed on the 5.2 branch.
>
Wow great, that was fast. To be honest, I did not even expect a response today. I'll have a look after.


> [...]
>  
> Generally, I try to not use POSIX commands when possible if there is a BASH equivalent.  
>
> In bash on Debian, > "${VAR%/*}" >  performs $(dirname VAR). 
>
> For a readlink equivalent, that's trickier, since there can be symbolic links. 
>
> I am curious, though, if others have this concern over using dirname or bash. 
>

Good to know. I'm not really a Bash expert, either, so I just went for what looked concise and did the job
(plus proper quoting for this case). I don't mind either way, or rather, I'm content with "bashisms". I'll
revisit that again.

It'll probably be some time until I'm happy with what I'm doing here on my end - still have to learn more
and my current fix for the "paths-with-spaces problem" is a hack. I'll try again with GitHub when I feel
that things are in a better spot.

On Sat, Feb 7, 2026 at 11:58 PM donquicoder--- via Bashdb-devel <
bas...@li...> wrote:

> Hi,
>
> I'm not sure where this should go, so I'm trying the mailing list.
>

Mailing list is fine. The project has moved to github so
https://github.com/Trepan-Debuggers/bashdb/issues can also be used for
reporting bugs.


>
> First of all, thanks for all the work that went into this. I've only
> discovered bashdb a few months ago and am kind of surprised how obscure it
> is - or for me at least it was - when it is so very useful.
>

I don't know why, but support and interest in debuggers have been in my
later life, not very well supported or funded.


> So, recently, I've been trying to make a proper Debian package for bashdb


Thanks!


> and have run into a few problems. Note that I have no problem with the
> regular configure, make, make check, make install. Therefore it's at best a
> low priority issue. Specifically, I want to get 'make distcheck' to work,
> which currently fails with a number of errors.
>
> I am not very experienced with GNU Autotools nor everything on the Debian
> side (not a Debian Maintainer), so that's what I'm currently looking into
> and it will take a while.
>
> Of course I can create working .deb packages by simply disabling/skipping
> some tests, but that's not my goal.
>
> In any case, I've already stumbled on some smaller things which are easy
> to fix, if you want:
>
> README.md: there's a typo "folliwng" instead of "following"
>

This has now been fixed on the 5.2 branch.


> check-prefix.sh: calls compute-prefix.sh, but not in a working-dir
> agnostic way; however, distcheck at some point calls the former from a
> subdirectory.
> test/unit/test-get-sourceline.sh.in: for some reason, the unit test
> test_get_source_line_with_spaces() is duplicated. Which makes it get called
> twice, but even if this were intentional (for a slightly different test),
> the latter overrides the former. (Also mixes tabs & spaces.)
>

If you or others have a suggested fix, please put in  a PR  at
https://github.com/Trepan-Debuggers/bashdb/pulls

Please put in one or more PR's for the below. Thanks!


>
>
> -----
>
Patch for 2. (adapted from https://stackoverflow.com/a/1482133):
>
> diff --git a/check-prefix.sh b/check-prefix.sh
> index d575089..55239e1 100755
> --- a/check-prefix.sh
> +++ b/check-prefix.sh
> @@ -17,7 +17,7 @@ if [[ -z $bash_loc ]] ; then
>      exit 3
> fi
>
> -check_loc=$(./compute-prefix.sh $SH_PROG)
> +check_loc=$("$(dirname -- "$(readlink -f $0)")/compute-prefix.sh"
> $SH_PROG)
> if [[ $PREFIX != $check_loc ]] ; then
>      echo  >&2 "bash says prefix should be $check_loc. You gave $PREFIX"
>      exit 4
>
>
Generally, I try to not use POSIX commands when possible if there is a BASH
equivalent.

In bash on Debian, "${VAR%/*}"  performs $(dirname VAR).

For a readlink equivalent, that's trickier, since there can be symbolic
links.

I am curious, though, if others have this concern over using dirname or
bash.


-----
>
> Patch for 3. or rather, my current changes because it somehow also finds
> the wrong frame.sh. I'm actively looking into a better overall solution,
> though. That is, regarding the mentioned problem, which I assume is about
> autoconf and dealing with names containing spaces.
>
> So this is just to illustrate the point and not meant to be included
> verbatim:
>
> diff --git a/test/unit/test-get-sourceline.sh.in b/test/unit/
> test-get-sourceline.sh.in
> index 37456f7..4f8eef5 100755
> --- a/test/unit/test-get-sourceline.sh.in
> +++ b/test/unit/test-get-sourceline.sh.in
> @@ -32,25 +32,10 @@ test_get_source_line_with_spaces()
>      # Can't figure out how to get this packaged with autoconf, so this
>      # will work with git only.
>      _Dbg_frame_file
> -    if [[ -f $_Dbg_frame_filename ]] && [[ $_Dbg_frame_filename =~
> 'frame.sh' ]] ; then
> -       _Dbg_get_source_line 2
> -       assertEquals 'x=1' "$_Dbg_source_line"
> -    else
> -       startSkipping
> -       echo "Skipping test due to autoconf problems"
> -       assertEquals 'skipped' 'skipped'
> -       endSkipping
> -    fi
> -}
> -# Test check_line
> -# test should appear after tests which read in source.
> -test_get_source_line_with_spaces()
> -{
> -    _Dbg_frame_last_filename="${abs_top_srcdir}test/example/dir with
> spaces/bug.sh"
> -    # Can't figure out how to get this packaged with autoconf, so this
> -    # will work with git only.
> -    _Dbg_frame_file
> -    if [[ -f $_Dbg_frame_filename ]] && [[ $_Dbg_frame_filename =~
> 'frame.sh' ]] ; then
> +    printf %s\\n "$_Dbg_frame_filename"
> +    if [[ -f $_Dbg_frame_filename ]] && [[ $_Dbg_frame_filename =~
> 'frame.sh' ]] \
> +            && [[ ! $_Dbg_frame_filename =~ '..' ]] ; then
> +            # condition above: don't allow distcheck to escape its
> environment
> _Dbg_get_source_line 2
> assertEquals 'x=1' "$_Dbg_source_line"
>      else
>
>
> -----
>
> Best regards
>
>

Hi,

I'm not sure where this should go, so I'm trying the mailing list.

First of all, thanks for all the work that went into this. I've only discovered bashdb a few months ago and am kind of surprised how obscure it is - or for me at least it was - when it is so very useful.

So, recently, I've been trying to make a proper Debian package for bashdb and have run into a few problems. Note that I have no problem with the regular configure, make, make check, make install. Therefore it's at best a low priority issue. Specifically, I want to get 'make distcheck' to work, which currently fails with a number of errors.

I am not very experienced with GNU Autotools nor everything on the Debian side (not a Debian Maintainer), so that's what I'm currently looking into and it will take a while.

Of course I can create working .deb packages by simply disabling/skipping some tests, but that's not my goal.

In any case, I've already stumbled on some smaller things which are easy to fix, if you want:

README.md: there's a typo "folliwng" instead of "following"
check-prefix.sh: calls compute-prefix.sh, but not in a working-dir agnostic way; however, distcheck at some point calls the former from a subdirectory.
test/unit/test-get-sourceline.sh.in: for some reason, the unit test test_get_source_line_with_spaces() is duplicated. Which makes it get called twice, but even if this were intentional (for a slightly different test), the latter overrides the former. (Also mixes tabs & spaces.)


-----

Patch for 2. (adapted from https://stackoverflow.com/a/1482133):

diff --git a/check-prefix.sh b/check-prefix.sh
index d575089..55239e1 100755
--- a/check-prefix.sh
+++ b/check-prefix.sh
@@ -17,7 +17,7 @@ if [[ -z $bash_loc ]] ; then
     exit 3
fi
 
-check_loc=$(./compute-prefix.sh $SH_PROG)
+check_loc=$("$(dirname -- "$(readlink -f $0)")/compute-prefix.sh" $SH_PROG)
if [[ $PREFIX != $check_loc ]] ; then
     echo  >&2 "bash says prefix should be $check_loc. You gave $PREFIX"
     exit 4


-----

Patch for 3. or rather, my current changes because it somehow also finds the wrong frame.sh. I'm actively looking into a better overall solution, though. That is, regarding the mentioned problem, which I assume is about autoconf and dealing with names containing spaces.

So this is just to illustrate the point and not meant to be included verbatim:

diff --git a/test/unit/test-get-sourceline.sh.in b/test/unit/test-get-sourceline.sh.in
index 37456f7..4f8eef5 100755
--- a/test/unit/test-get-sourceline.sh.in
+++ b/test/unit/test-get-sourceline.sh.in
@@ -32,25 +32,10 @@ test_get_source_line_with_spaces()
     # Can't figure out how to get this packaged with autoconf, so this
     # will work with git only.
     _Dbg_frame_file
-    if [[ -f $_Dbg_frame_filename ]] && [[ $_Dbg_frame_filename =~ 'frame.sh' ]] ; then
-	_Dbg_get_source_line 2
-	assertEquals 'x=1' "$_Dbg_source_line"
-    else
-	startSkipping
-	echo "Skipping test due to autoconf problems"
-	assertEquals 'skipped' 'skipped'
-	endSkipping
-    fi
-}
-# Test check_line
-# test should appear after tests which read in source.
-test_get_source_line_with_spaces()
-{
-    _Dbg_frame_last_filename="${abs_top_srcdir}test/example/dir with spaces/bug.sh"
-    # Can't figure out how to get this packaged with autoconf, so this
-    # will work with git only.
-    _Dbg_frame_file
-    if [[ -f $_Dbg_frame_filename ]] && [[ $_Dbg_frame_filename =~ 'frame.sh' ]] ; then
+    printf %s\\n "$_Dbg_frame_filename"
+    if [[ -f $_Dbg_frame_filename ]] && [[ $_Dbg_frame_filename =~ 'frame.sh' ]] \
+            && [[ ! $_Dbg_frame_filename =~ '..' ]] ; then
+            # condition above: don't allow distcheck to escape its environment
_Dbg_get_source_line 2
assertEquals 'x=1' "$_Dbg_source_line"
     else


-----

Best regards

make[3]: *** [check-TESTS] 错误 1                                                            
make[3]: 离开目录“/root/bashdb-4.2-0.7/test/integration”                                     
make[2]: *** [check-am] 错误 2                                                               
make[2]: 离开目录“/root/bashdb-4.2-0.7/test/integration”                                     
make[1]: *** [check-recursive] 错误 1                                                        
make[1]: 离开目录“/root/bashdb-4.2-0.7/test”                                                 
make: *** [check-recursive] 错误 1

I just build and ran the tests for bashdb-4.3-0.91 on a machine running
Ubuntu 16.04 (bash version 4.3.48(1)-release (x86_64-pc-linux-gnu)).

I had one test error:

============================================================================
Testsuite summary for bashdb 4.3-0.91
============================================================================
# TOTAL: 42
# PASS:  39
# SKIP:  2
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See test/integration/test-suite.log
Please report to bas...@li...
============================================================================

I attached the test-suite.log from the run.

-Todd

-- 
Todd Bezenek <http://www.linkedin.com/in/toddbezenek/>
be...@gm...

A people hire A people, B people hire C people.
  --Jim Gray <http://en.wikipedia.org/wiki/Jim_Gray_(computer_scientist)>

Thanks for the detailed report. Whatever the bug is, it doesn't look that
serious. Will see if I can reproduce the problem.

On Tue, Nov 21, 2017 at 1:49 PM, Andrew <and...@gm...> wrote:

> (6) andrew@andrew integration $ bash --version
> GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
>
> ***
>
> (6) andrew@andrew integration $ cat /etc/*release
> DISTRIB_ID=LinuxMint
> DISTRIB_RELEASE=17.3
> DISTRIB_CODENAME=rosa
> DISTRIB_DESCRIPTION="Linux Mint 17.3 Rosa"
> NAME="Ubuntu"
> VERSION="14.04, Trusty Tahr"
> ID=ubuntu
> ID_LIKE=debian
> PRETTY_NAME="Ubuntu 14.04 LTS"
> VERSION_ID="14.04"
> HOME_URL="http://www.ubuntu.com/"
> SUPPORT_URL="http://help.ubuntu.com/"
> BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
>
> ***
>
> ======================================================
>    bashdb 4.3-0.91: test/integration/test-suite.log
> ======================================================
>
> # TOTAL: 42
> # PASS:  39
> # SKIP:  2
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
>
> .. contents:: :depth: 2
>
> SKIP: test-file-with-spaces
> ===========================
>
> Skipping test due to autoconf problems
>
> FAIL: test-bug-loc
> ==================
>
> --- /home/andrew/Downloads/bashdb-4.3-0.91/test/integration/bug-
> loc.check2017-11-21
> 18:45:16.755011602 +0000
> +++ /home/andrew/Downloads/bashdb-4.3-0.91/test/data/bug-loc.
> right2014-12-11
> 13:22:03.000000000 +0000 @@ -1,10 +1,10 @@ (bug-loc.sh:5):
> -5:dirname=${BASH_SOURCE%/*}   # equivalent to dirname($0)
> +5:dirname=${BASH_SOURCE%/*}   # equivalent to dirname($0)
>  +# Test to see that we read in files that mentioned in breakpoints
>  +# but we don't step into.
>  +step
>  (bug-loc.sh:6):
> -6:source ${dirname}/library.sh
> +6:source ${dirname}/library.sh
>  +step
>  (bug-loc.sh:7):
>  7:echo 'script line 7'
>
> SKIP: test-file-with-spaces
> ===========================
>
> Skipping test due to autoconf problems
>
>
> --
> Andrew Woodward
> RLU: #437175
> https://www.linuxcounter.net/cert/437175.png
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

(6) andrew@andrew integration $ bash --version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)

***

(6) andrew@andrew integration $ cat /etc/*release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.3
DISTRIB_CODENAME=rosa
DISTRIB_DESCRIPTION="Linux Mint 17.3 Rosa"
NAME="Ubuntu"
VERSION="14.04, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

***

======================================================
   bashdb 4.3-0.91: test/integration/test-suite.log
======================================================

# TOTAL: 42
# PASS:  39
# SKIP:  2
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

SKIP: test-file-with-spaces
===========================

Skipping test due to autoconf problems

FAIL: test-bug-loc
==================

--- /home/andrew/Downloads/bashdb-4.3-0.91/test/integration/bug-loc.check2017-11-21
18:45:16.755011602 +0000
+++ /home/andrew/Downloads/bashdb-4.3-0.91/test/data/bug-loc.right2014-12-11
13:22:03.000000000 +0000 @@ -1,10 +1,10 @@ (bug-loc.sh:5):
-5:dirname=${BASH_SOURCE%/*}   # equivalent to dirname($0)
+5:dirname=${BASH_SOURCE%/*}   # equivalent to dirname($0)
 +# Test to see that we read in files that mentioned in breakpoints
 +# but we don't step into.
 +step 
 (bug-loc.sh:6):
-6:source ${dirname}/library.sh
+6:source ${dirname}/library.sh
 +step 
 (bug-loc.sh:7):
 7:echo 'script line 7'

SKIP: test-file-with-spaces
===========================

Skipping test due to autoconf problems


-- 
Andrew Woodward
RLU: #437175
https://www.linuxcounter.net/cert/437175.png

-- 
Terveisin,






STAVROS
NTENTOS

Associate, QA Engineer - VPN Team, EMEA






FORCEPOINT

M: +358
469 33 2424
www.forcepoint.com


Protecting
the human point.

With commit 6792f1ba93337ee8ce3043e42592fe6265e5944f I think I have the
last of the bash 4.4 changes addressed. I tried on Ubuntu Zesty rather than
CentOS 7. So after updating from git, give it a shot and let me know how it
goes.

If things go well, I probably have time to put out another release.

On Mon, Jul 31, 2017 at 12:12 PM, Brad Dussiaume <br...@fo...
> wrote:

> Hello:
>
> Here is the file of errors I received while running 'make check'.  Do I
> need to do anything to get this to work?
>
> Brad
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

Hello:

Here is the file of errors I received while running 'make check'.  Do I need to do anything to get this to work?

Brad

I had a little the time to try running the tests on bash 4.4 so I can
confirm the errors and get detailed information about them. None are
serious, but do indicate a change in behavior between 4.3 and 4.4 in the
way bash works.

The most unusual change seems to be something in comparing strings so that
sorted lists appear differently and are no longer sorted. Other changes
seem to be in what is reported in a BASH_SOURCE when bashdb is the first
argument. So tracebacks appear differently, although they have more
information now.

It will probably a while for me to have the time to track down all of the
bugs when using bash 4.4, but in the meantime I believe what's there most
will not any significant problem in using bashdb as is.

On Sun, Jun 4, 2017 at 9:52 AM, Rocky Bernstein <ro...@gn...> wrote:

> Uh, ok. Just send  test/integration/test-suite.log   I suggested before
> to me. I don't think people on the devel list are interested in the
> specific differences.
>
> I'll look at when I get a chance, but it might not be for a while.
>
> On Sun, Jun 4, 2017 at 9:48 AM, jean-christophe manciot <
> act...@gm...> wrote:
>
>> I never tried to build bashdb with bash 4.3, but with earlier bashdb git
>> commits (such as the latest ones in december 2016), I had fewer failed
>> tests (4) vs 9 today.
>>
>> On Sun, Jun 4, 2017 at 3:38 PM, Rocky Bernstein <ro...@gn...> wrote:
>>
>> > Thanks - I'll look at this when I get a chance. Some general information
>> > and then some general questions.
>> >
>> > The failing integration tests look are the tests that are most fragile
>> and
>> > can change with bash release. Generally it's nothing serious, in that
>> it is
>> > the test that is wrong, not the functioning of bashdb.
>> >
>> > To verify this belief, look at the file test/integration/test-suite.log
>> > as the above output suggests. You should see diff-style output showing
>> what
>> > was expected and what you got instead. Send it to me directly and I'll
>> look.
>> >
>> > Just today earlier I was working on detecting the terminal background
>> and
>> > whether it was dark or light, and I recall a lot of failures in the same
>> > files listed above. Most of what I had to do was make sure to pass the -
>> > -no-highlight option in the tests to make output checking more
>> > predictable. The kinds if differences I was seeing was in adding ansi
>> > escape sequences for marking the output that I was getting but wasn't
>> > expected.
>> >
>> > Are you working off of sourceforge git or the last release? If git, make
>> > sure to "git pull" since this changed a little while ago.
>> >
>> > The other place where tests start failing is on a new release (from
>> > bashdb's standpoint) of bash. I am not sure I have tried version 4.4
>> yet.
>> > (I might have but I don't remember)
>> > Is this the first time you've tried bashdb with  bash version 4.4?  With
>> > bash 4.3 that works, right?
>> >
>> >
>> >
>> >
>> > On Sun, Jun 4, 2017 at 9:03 AM, jean-christophe manciot <
>> > act...@gm...> wrote:
>> >
>> >> distribution: Ubuntu Zesty
>> >> bash sources: https://packages.debian.org/source/stretch/bash
>> >> bash version: 4.4.12(1) (built from latest debian 4.4-5)
>> >> bashdb sources: git://git.code.sf.net/p/bashdb/code
>> >> bashdb commit: 4e1479d18829a4de1081b936a4976ac534007016
>> >> bashdb configure options:
>> >>  --with-bash-src=/home/actionmystique/src/Bash/bash-4.4-5 \
>> >>                                            --build=x86_64-pc-linux-gnu
>> \
>> >>                                            --prefix=/usr
>> --sysconfdir=/etc
>> >> --localstatedir=/var \
>> >>                                            --infodir=/usr/share/info
>> >> --mandir=/usr/share/man
>> >> bashdb build tool: remake --trace
>> >> bashdb check tool: make check
>> >> bashdb tests log: attached test/integration/test-suite.log
>> >>
>> >> PASS: test-bug-step-subshell
>> >> FAIL: test-complete
>> >> PASS: test-debug
>> >> PASS: test-delete
>> >> PASS: test-export
>> >> PASS: test-file-with-spaces
>> >> PASS: test-info-args
>> >> FAIL: test-interrupt
>> >> PASS: test-misc
>> >> PASS: test-setshow
>> >> FAIL: test-sig
>> >> PASS: test-action
>> >> PASS: test-brkpt
>> >> PASS: test-bug-args
>> >> PASS: test-bugI
>> >> PASS: test-bugIFS
>> >> PASS: test-bug-loc
>> >> PASS: test-bug-source
>> >> PASS: test-command
>> >> PASS: test-display
>> >> PASS: test-enable
>> >> PASS: test-finish
>> >> PASS: test-frame
>> >> PASS: test-list
>> >> FAIL: test-lopts
>> >> PASS: test-multi
>> >> PASS: test-parm
>> >> PASS: test-restart
>> >> PASS: test-search
>> >> FAIL: test-settrace
>> >> PASS: test-skip
>> >> FAIL: test-sopts
>> >> FAIL: test-bug-break
>> >> PASS: test-bug-clear
>> >> PASS: test-bug-step
>> >> PASS: test-subshell
>> >> PASS: test-tbreak
>> >> FAIL: test-trace
>> >> PASS: test-watch1
>> >> PASS: test-watch2
>> >> ============================================================
>> >> ================
>> >> Testsuite summary for bashdb 4.4-0.92
>> >> ============================================================
>> >> ================
>> >> # TOTAL: 42
>> >> # PASS:  33
>> >> # SKIP:  0
>> >> # XFAIL: 0
>> >> # FAIL:  9
>> >> # XPASS: 0
>> >> # ERROR: 0
>> >> ============================================================
>> >> ================
>> >> See test/integration/test-suite.log
>> >> Please report to bas...@li...
>> >> ============================================================
>> >> ================
>> >>
>> >> --
>> >> Jean-Christophe
>> >> ------------------------------------------------------------
>> >> ------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Bashdb-devel mailing list
>> >> Bas...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>> >>
>> >
>> >
>>
>>
>> --
>> Jean-Christophe
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Bashdb-devel mailing list
>> Bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>>
>
>

Uh, ok. Just send  test/integration/test-suite.log   I suggested before to
me. I don't think people on the devel list are interested in the specific
differences.

I'll look at when I get a chance, but it might not be for a while.

On Sun, Jun 4, 2017 at 9:48 AM, jean-christophe manciot <
act...@gm...> wrote:

> I never tried to build bashdb with bash 4.3, but with earlier bashdb git
> commits (such as the latest ones in december 2016), I had fewer failed
> tests (4) vs 9 today.
>
> On Sun, Jun 4, 2017 at 3:38 PM, Rocky Bernstein <ro...@gn...> wrote:
>
> > Thanks - I'll look at this when I get a chance. Some general information
> > and then some general questions.
> >
> > The failing integration tests look are the tests that are most fragile
> and
> > can change with bash release. Generally it's nothing serious, in that it
> is
> > the test that is wrong, not the functioning of bashdb.
> >
> > To verify this belief, look at the file test/integration/test-suite.log
> > as the above output suggests. You should see diff-style output showing
> what
> > was expected and what you got instead. Send it to me directly and I'll
> look.
> >
> > Just today earlier I was working on detecting the terminal background and
> > whether it was dark or light, and I recall a lot of failures in the same
> > files listed above. Most of what I had to do was make sure to pass the -
> > -no-highlight option in the tests to make output checking more
> > predictable. The kinds if differences I was seeing was in adding ansi
> > escape sequences for marking the output that I was getting but wasn't
> > expected.
> >
> > Are you working off of sourceforge git or the last release? If git, make
> > sure to "git pull" since this changed a little while ago.
> >
> > The other place where tests start failing is on a new release (from
> > bashdb's standpoint) of bash. I am not sure I have tried version 4.4 yet.
> > (I might have but I don't remember)
> > Is this the first time you've tried bashdb with  bash version 4.4?  With
> > bash 4.3 that works, right?
> >
> >
> >
> >
> > On Sun, Jun 4, 2017 at 9:03 AM, jean-christophe manciot <
> > act...@gm...> wrote:
> >
> >> distribution: Ubuntu Zesty
> >> bash sources: https://packages.debian.org/source/stretch/bash
> >> bash version: 4.4.12(1) (built from latest debian 4.4-5)
> >> bashdb sources: git://git.code.sf.net/p/bashdb/code
> >> bashdb commit: 4e1479d18829a4de1081b936a4976ac534007016
> >> bashdb configure options:
> >>  --with-bash-src=/home/actionmystique/src/Bash/bash-4.4-5 \
> >>                                            --build=x86_64-pc-linux-gnu \
> >>                                            --prefix=/usr
> --sysconfdir=/etc
> >> --localstatedir=/var \
> >>                                            --infodir=/usr/share/info
> >> --mandir=/usr/share/man
> >> bashdb build tool: remake --trace
> >> bashdb check tool: make check
> >> bashdb tests log: attached test/integration/test-suite.log
> >>
> >> PASS: test-bug-step-subshell
> >> FAIL: test-complete
> >> PASS: test-debug
> >> PASS: test-delete
> >> PASS: test-export
> >> PASS: test-file-with-spaces
> >> PASS: test-info-args
> >> FAIL: test-interrupt
> >> PASS: test-misc
> >> PASS: test-setshow
> >> FAIL: test-sig
> >> PASS: test-action
> >> PASS: test-brkpt
> >> PASS: test-bug-args
> >> PASS: test-bugI
> >> PASS: test-bugIFS
> >> PASS: test-bug-loc
> >> PASS: test-bug-source
> >> PASS: test-command
> >> PASS: test-display
> >> PASS: test-enable
> >> PASS: test-finish
> >> PASS: test-frame
> >> PASS: test-list
> >> FAIL: test-lopts
> >> PASS: test-multi
> >> PASS: test-parm
> >> PASS: test-restart
> >> PASS: test-search
> >> FAIL: test-settrace
> >> PASS: test-skip
> >> FAIL: test-sopts
> >> FAIL: test-bug-break
> >> PASS: test-bug-clear
> >> PASS: test-bug-step
> >> PASS: test-subshell
> >> PASS: test-tbreak
> >> FAIL: test-trace
> >> PASS: test-watch1
> >> PASS: test-watch2
> >> ============================================================
> >> ================
> >> Testsuite summary for bashdb 4.4-0.92
> >> ============================================================
> >> ================
> >> # TOTAL: 42
> >> # PASS:  33
> >> # SKIP:  0
> >> # XFAIL: 0
> >> # FAIL:  9
> >> # XPASS: 0
> >> # ERROR: 0
> >> ============================================================
> >> ================
> >> See test/integration/test-suite.log
> >> Please report to bas...@li...
> >> ============================================================
> >> ================
> >>
> >> --
> >> Jean-Christophe
> >> ------------------------------------------------------------
> >> ------------------
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> _______________________________________________
> >> Bashdb-devel mailing list
> >> Bas...@li...
> >> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
> >>
> >
> >
>
>
> --
> Jean-Christophe
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

I never tried to build bashdb with bash 4.3, but with earlier bashdb git
commits (such as the latest ones in december 2016), I had fewer failed
tests (4) vs 9 today.

On Sun, Jun 4, 2017 at 3:38 PM, Rocky Bernstein <ro...@gn...> wrote:

> Thanks - I'll look at this when I get a chance. Some general information
> and then some general questions.
>
> The failing integration tests look are the tests that are most fragile and
> can change with bash release. Generally it's nothing serious, in that it is
> the test that is wrong, not the functioning of bashdb.
>
> To verify this belief, look at the file test/integration/test-suite.log
> as the above output suggests. You should see diff-style output showing what
> was expected and what you got instead. Send it to me directly and I'll look.
>
> Just today earlier I was working on detecting the terminal background and
> whether it was dark or light, and I recall a lot of failures in the same
> files listed above. Most of what I had to do was make sure to pass the -
> -no-highlight option in the tests to make output checking more
> predictable. The kinds if differences I was seeing was in adding ansi
> escape sequences for marking the output that I was getting but wasn't
> expected.
>
> Are you working off of sourceforge git or the last release? If git, make
> sure to "git pull" since this changed a little while ago.
>
> The other place where tests start failing is on a new release (from
> bashdb's standpoint) of bash. I am not sure I have tried version 4.4 yet.
> (I might have but I don't remember)
> Is this the first time you've tried bashdb with  bash version 4.4?  With
> bash 4.3 that works, right?
>
>
>
>
> On Sun, Jun 4, 2017 at 9:03 AM, jean-christophe manciot <
> act...@gm...> wrote:
>
>> distribution: Ubuntu Zesty
>> bash sources: https://packages.debian.org/source/stretch/bash
>> bash version: 4.4.12(1) (built from latest debian 4.4-5)
>> bashdb sources: git://git.code.sf.net/p/bashdb/code
>> bashdb commit: 4e1479d18829a4de1081b936a4976ac534007016
>> bashdb configure options:
>>  --with-bash-src=/home/actionmystique/src/Bash/bash-4.4-5 \
>>                                            --build=x86_64-pc-linux-gnu \
>>                                            --prefix=/usr --sysconfdir=/etc
>> --localstatedir=/var \
>>                                            --infodir=/usr/share/info
>> --mandir=/usr/share/man
>> bashdb build tool: remake --trace
>> bashdb check tool: make check
>> bashdb tests log: attached test/integration/test-suite.log
>>
>> PASS: test-bug-step-subshell
>> FAIL: test-complete
>> PASS: test-debug
>> PASS: test-delete
>> PASS: test-export
>> PASS: test-file-with-spaces
>> PASS: test-info-args
>> FAIL: test-interrupt
>> PASS: test-misc
>> PASS: test-setshow
>> FAIL: test-sig
>> PASS: test-action
>> PASS: test-brkpt
>> PASS: test-bug-args
>> PASS: test-bugI
>> PASS: test-bugIFS
>> PASS: test-bug-loc
>> PASS: test-bug-source
>> PASS: test-command
>> PASS: test-display
>> PASS: test-enable
>> PASS: test-finish
>> PASS: test-frame
>> PASS: test-list
>> FAIL: test-lopts
>> PASS: test-multi
>> PASS: test-parm
>> PASS: test-restart
>> PASS: test-search
>> FAIL: test-settrace
>> PASS: test-skip
>> FAIL: test-sopts
>> FAIL: test-bug-break
>> PASS: test-bug-clear
>> PASS: test-bug-step
>> PASS: test-subshell
>> PASS: test-tbreak
>> FAIL: test-trace
>> PASS: test-watch1
>> PASS: test-watch2
>> ============================================================
>> ================
>> Testsuite summary for bashdb 4.4-0.92
>> ============================================================
>> ================
>> # TOTAL: 42
>> # PASS:  33
>> # SKIP:  0
>> # XFAIL: 0
>> # FAIL:  9
>> # XPASS: 0
>> # ERROR: 0
>> ============================================================
>> ================
>> See test/integration/test-suite.log
>> Please report to bas...@li...
>> ============================================================
>> ================
>>
>> --
>> Jean-Christophe
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Bashdb-devel mailing list
>> Bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>>
>
>


-- 
Jean-Christophe

Thanks - I'll look at this when I get a chance. Some general information
and then some general questions.

The failing integration tests look are the tests that are most fragile and
can change with bash release. Generally it's nothing serious, in that it is
the test that is wrong, not the functioning of bashdb.

To verify this belief, look at the file test/integration/test-suite.log as
the above output suggests. You should see diff-style output showing what
was expected and what you got instead. Send it to me directly and I'll look.

Just today earlier I was working on detecting the terminal background and
whether it was dark or light, and I recall a lot of failures in the same
files listed above. Most of what I had to do was make sure to pass the -
-no-highlight option in the tests to make output checking more predictable.
The kinds if differences I was seeing was in adding ansi escape sequences
for marking the output that I was getting but wasn't expected.

Are you working off of sourceforge git or the last release? If git, make
sure to "git pull" since this changed a little while ago.

The other place where tests start failing is on a new release (from
bashdb's standpoint) of bash. I am not sure I have tried version 4.4 yet.
(I might have but I don't remember)
Is this the first time you've tried bashdb with  bash version 4.4?  With
bash 4.3 that works, right?




On Sun, Jun 4, 2017 at 9:03 AM, jean-christophe manciot <
act...@gm...> wrote:

> distribution: Ubuntu Zesty
> bash sources: https://packages.debian.org/source/stretch/bash
> bash version: 4.4.12(1) (built from latest debian 4.4-5)
> bashdb sources: git://git.code.sf.net/p/bashdb/code
> bashdb commit: 4e1479d18829a4de1081b936a4976ac534007016
> bashdb configure options:
>  --with-bash-src=/home/actionmystique/src/Bash/bash-4.4-5 \
>                                            --build=x86_64-pc-linux-gnu \
>                                            --prefix=/usr --sysconfdir=/etc
> --localstatedir=/var \
>                                            --infodir=/usr/share/info
> --mandir=/usr/share/man
> bashdb build tool: remake --trace
> bashdb check tool: make check
> bashdb tests log: attached test/integration/test-suite.log
>
> PASS: test-bug-step-subshell
> FAIL: test-complete
> PASS: test-debug
> PASS: test-delete
> PASS: test-export
> PASS: test-file-with-spaces
> PASS: test-info-args
> FAIL: test-interrupt
> PASS: test-misc
> PASS: test-setshow
> FAIL: test-sig
> PASS: test-action
> PASS: test-brkpt
> PASS: test-bug-args
> PASS: test-bugI
> PASS: test-bugIFS
> PASS: test-bug-loc
> PASS: test-bug-source
> PASS: test-command
> PASS: test-display
> PASS: test-enable
> PASS: test-finish
> PASS: test-frame
> PASS: test-list
> FAIL: test-lopts
> PASS: test-multi
> PASS: test-parm
> PASS: test-restart
> PASS: test-search
> FAIL: test-settrace
> PASS: test-skip
> FAIL: test-sopts
> FAIL: test-bug-break
> PASS: test-bug-clear
> PASS: test-bug-step
> PASS: test-subshell
> PASS: test-tbreak
> FAIL: test-trace
> PASS: test-watch1
> PASS: test-watch2
> ============================================================
> ================
> Testsuite summary for bashdb 4.4-0.92
> ============================================================
> ================
> # TOTAL: 42
> # PASS:  33
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  9
> # XPASS: 0
> # ERROR: 0
> ============================================================
> ================
> See test/integration/test-suite.log
> Please report to bas...@li...
> ============================================================
> ================
>
> --
> Jean-Christophe
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

distribution: Ubuntu Zesty
bash sources: https://packages.debian.org/source/stretch/bash
bash version: 4.4.12(1) (built from latest debian 4.4-5)
bashdb sources: git://git.code.sf.net/p/bashdb/code
bashdb commit: 4e1479d18829a4de1081b936a4976ac534007016
bashdb configure options:
 --with-bash-src=/home/actionmystique/src/Bash/bash-4.4-5 \
                                           --build=x86_64-pc-linux-gnu \
                                           --prefix=/usr --sysconfdir=/etc
--localstatedir=/var \
                                           --infodir=/usr/share/info
--mandir=/usr/share/man
bashdb build tool: remake --trace
bashdb check tool: make check
bashdb tests log: attached test/integration/test-suite.log

PASS: test-bug-step-subshell
FAIL: test-complete
PASS: test-debug
PASS: test-delete
PASS: test-export
PASS: test-file-with-spaces
PASS: test-info-args
FAIL: test-interrupt
PASS: test-misc
PASS: test-setshow
FAIL: test-sig
PASS: test-action
PASS: test-brkpt
PASS: test-bug-args
PASS: test-bugI
PASS: test-bugIFS
PASS: test-bug-loc
PASS: test-bug-source
PASS: test-command
PASS: test-display
PASS: test-enable
PASS: test-finish
PASS: test-frame
PASS: test-list
FAIL: test-lopts
PASS: test-multi
PASS: test-parm
PASS: test-restart
PASS: test-search
FAIL: test-settrace
PASS: test-skip
FAIL: test-sopts
FAIL: test-bug-break
PASS: test-bug-clear
PASS: test-bug-step
PASS: test-subshell
PASS: test-tbreak
FAIL: test-trace
PASS: test-watch1
PASS: test-watch2
============================================================================
Testsuite summary for bashdb 4.4-0.92
============================================================================
# TOTAL: 42
# PASS:  33
# SKIP:  0
# XFAIL: 0
# FAIL:  9
# XPASS: 0
# ERROR: 0
============================================================================
See test/integration/test-suite.log
Please report to bas...@li...
============================================================================

-- 
Jean-Christophe

The short story is that probably everything's okay, and even if not this is
not likely to have an impact on using it that you'd notice.

The integration tests are a little fragile which means they are often
breaking when output changes slightly and should be reworked to make them
less so. But I'm probably not going to spend the time to do so and that
means that no one else will either.

The longer story is that from summary information alone, one has very
little information to try to fix. At a minimum one needs the version of
bash and as it says in the put you do have, the log file as more
information like which test failed and what result it gave.

When I just tried running current git sources on GNU bash, version
4.3.46(1)-release (x86_64-pc-linux-gnu)  I got one failure in test-watch
and it is failing because the line number inside the debugger program has
change from line 98 to line 95 which is most likely an output update bug on
my part.

I know the output instructions say send to this list when you hit a
failure, and so I appreciate that you followed those instructions. (Those
instruction though too are kind of the boilerplate default when one uses
gnu automake/autoconf.)


On Wed, Jan 18, 2017 at 9:07 PM, Richard Steiger <rst...@bp...> wrote:

> FYI, getting the following errors in response to “make & make check”
> incantation:
> ============================================================
> ================
> Testsuite summary for bashdb 4.4-0.92
> ============================================================
> ================
> # TOTAL: 42
> # PASS:  33
> # SKIP:  5
> # XFAIL: 0
> # FAIL:  4
> # XPASS: 0
> # ERROR: 0
> ============================================================
> ================
> See test/integration/test-suite.log
> Please report to bas...@li...
> ============================================================
> ================
> make[4]: *** [test-suite.log] Error 1
> make[3]: *** [check-TESTS] Error 2
> make[2]: *** [check-am] Error 2
> make[1]: *** [check-recursive] Error 1
> make: *** [check-recursive] Error 1
>
> No need to respond, unless the above indicates problems that will prevent
> bashdb from working properly.
>
> Regards,
> -rjs
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

FYI, getting the following errors in response to “make & make check” incantation:
============================================================================
Testsuite summary for bashdb 4.4-0.92
============================================================================
# TOTAL: 42
# PASS:  33
# SKIP:  5
# XFAIL: 0
# FAIL:  4
# XPASS: 0
# ERROR: 0
============================================================================
See test/integration/test-suite.log
Please report to bas...@li...
============================================================================
make[4]: *** [test-suite.log] Error 1
make[3]: *** [check-TESTS] Error 2
make[2]: *** [check-am] Error 2
make[1]: *** [check-recursive] Error 1
make: *** [check-recursive] Error 1

No need to respond, unless the above indicates problems that will prevent bashdb from working properly.

Regards,
-rjs

------------------------------------------------------------------------------------------------------------
bashdb .drive-filter-files-list
bash debugger, bashdb, release 4.4-0.92

Copyright 2002, 2003, 2004, 2006-2012, 2014, 2016 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.

(/usr/bin/.drive-filter-files-list:86):
86: shopt -s extglob
bashdb<0> set args .driveinclude local sync
bashdb<1> break 136
Breakpoint 1 set in file /usr/bin/.drive-filter-files-list, line 136.
bashdb<2> R
*Restarting with: /bin/bashdb .driveinclude local sync *
/usr/share/share/bashdb/command/run.sh: line 75: cd: too many arguments
bash debugger, bashdb, release 4.4-0.92

Copyright 2002, 2003, 2004, 2006-2012, 2014, 2016 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.

(/bin/bashdb:1):
1: #!/bin/bash
------------------------------------------------------------------------------------------------------------

R should rather call ".drive-filter-files-list .driveinclude local sync" in
this example.
-- 
Jean-Christophe

One last little thing. Just because you *think *you have configured not to
compile files needing bash source, that doesn't necessarily mean that was
the case. That's why details are important. It definitely looks like the
configuration was set to try to build source. And the fact that read.c
didn't barf in finding bash headers (but instead elsewhere) supports that
belief.

At the end of the configure script we dump what's up. For example:

Location    : /bin/bash
Prefix      : /usr/share
prefix checks out
We will try to build the set0 builtin to set variable $0
using source located at /src/build/bash-4.4.

That import output was omitted in your log. But even if the "Will try to"
line was missing since the configure run wasn't clean that too may be
suspect. So the next thing I would look at is config.status and for the
configuration above we would have

S["BASH_SRC"]="/src/build/bash-4.4"

But independent of any of this the fact that read.c was compiled means that
the configuration was most likely somehow with some sort of bash source
set. remake -x on a run will often also elucidate what's happening in a
build.




On Sat, Dec 3, 2016 at 3:24 PM, Rocky Bernstein <roc...@gm...>
wrote:

> Ok. Looked at this more. As I said, bash 4.4 changes the API
> vaid_array_reference. As best as I can tell, it just breaks the old API
> without adding anything.
>
> As for the ac_aux_dir problems, I get that too now. That too seems to be a
> difference in how autoconf and automake work over the years and what they
> now expect.
>
> Commit 68d03c3a85252447e04a87a686c7b14ae18616d should address both of
> these.
>
> On Sat, Dec 3, 2016 at 11:42 AM, jean-christophe manciot <
> act...@gm...> wrote:
>
>> Here are the details you've asked for:
>> bash --version
>> GNU bash, version 4.4.0(1)-release
>> on Ubuntu 16.10 4.8
>>
>> You have missed the fact that the configure line with --with-bash-src=...
>> has been *commented out* because of the bug described in the comment
>> located just above it and not reported. It has no effect in this bug
>> report.
>>
>> The log & bug reported by this mail is the consequence of the non
>> commented configure & make lines.
>>
>> On Sat, Dec 3, 2016 at 3:48 PM, Rocky Bernstein <
>> roc...@gm...> wrote:
>>
>>> Jean-Christophe -
>>>
>>> Thanks for reporting the problems you encountered. I have a little
>>> trouble reading the report because, although there is a bit that is
>>> specific, various oher details aren't there.
>>>
>>> So here's my take on what the log given.
>>>
>>> 'readc.c:848:46: error: too few arguments to function
>>>> ‘valid_array_reference’'
>>>
>>>
>>> is probably caused by a change in the bash API to the function
>>> valid_array_reference().
>>> The offending line in bashdb is:
>>>
>>>       if (legal_identifier (varname) == 0 && valid_array_reference
>>> (varname) == 0)
>>>
>>> What version of bash did you run against? If you or someone eise in the
>>> devel lis is up for it, perhaps you can figure how to change read.c for the
>>> changed var_array_reference call.
>>>
>>> If you remove  --with-bash-src=/home/actionmystique/Program-Files/
>>> Ubuntu/Bash/git-bash from the configure option, bashdb won't try to
>>> compile read.c.
>>>
>>> That particular function that is getting compiled allows bashdb to do a
>>> command-completion kind of read inside it debugger read loop. It not needed
>>> for overall basic functioning, but I guess it is a nice thing to have.
>>> Perhaps bash now offers a way to handle completion inside its builtin
>>> read() function. If that's the case we should remove compiling this.
>>> Perhaps you or someone can check?
>>>
>>> As for setting $ac_aux_dir to '.', that may work for you in your
>>> environment but it is symptomatic of some sort of configure script failure.
>>> Any shell variable that starts ac_ is something the configure script sets
>>> (ac stands I guess for autoconf). So if this is set wrong or is not set,
>>> then things are probably misconfigured. When bashdb is misconfigured, the
>>> test scripts may fail.
>>>
>>>
>>> On Fri, Dec 2, 2016 at 2:25 PM, jean-christophe manciot <
>>> act...@gm...> wrote:
>>>
>>>> Hi there,
>>>>
>>>> The following script run with branch=master & tag=release-4.4-0.92:
>>>>
>>>>         echo --------
>>>>         echo Cleaning
>>>>         echo --------
>>>>         cd git-bashdb
>>>>         sudo -u actionmystique -H git-reset-clean-pull-checkout.sh
>>>> $branch
>>>> $tag
>>>>
>>>>         echo ------------------
>>>>         echo Building configure
>>>>         echo ------------------
>>>>         export NOCONFIGURE=yes
>>>>         sudo -Eu actionmystique -H ./autogen.sh
>>>>
>>>>         echo -------------------------------------------------------
>>>>         echo Working around a bug related to $ac_aux_dir/config.sub
>>>>         echo -------------------------------------------------------
>>>>         # Cf. https://sourceforge.net/p/bashdb/bugs/42/
>>>>         sudo -u actionmystique -H sed -i 's|$ac_aux_dir|.|g' ./configure
>>>>
>>>>         echo -----------
>>>>         echo Configuring
>>>>         echo -----------
>>>>         # Bugs 'readc.c:848:46: error: too few arguments to function
>>>> ‘valid_array_reference’'
>>>>         # sudo -u actionmystique -H ./configure
>>>> --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash
>>>> \
>>>>         sudo -u actionmystique -H ./configure   --prefix=/usr/share
>>>> --sysconfdir=/etc --localstatedir=/var
>>>>
>>>>         echo ---------
>>>>         echo Compiling
>>>>         echo ---------
>>>>         sudo -u actionmystique -H make
>>>>
>>>>         echo --------
>>>>         echo Checking
>>>>         echo --------
>>>>         sudo -u actionmystique -H make check
>>>>
>>>> leads to *5 tests errors: attached test-suite.log*
>>>>
>>>> The whole build log is available on request.
>>>> --
>>>> Jean-Christophe
>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Bashdb-devel mailing list
>>>> Bas...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>>>>
>>>>
>>>
>>
>>
>> --
>> Jean-Christophe
>>
>
>

Ok. Looked at this more. As I said, bash 4.4 changes the API
vaid_array_reference. As best as I can tell, it just breaks the old API
without adding anything.

As for the ac_aux_dir problems, I get that too now. That too seems to be a
difference in how autoconf and automake work over the years and what they
now expect.

Commit 68d03c3a85252447e04a87a686c7b14ae18616d should address both of these.

On Sat, Dec 3, 2016 at 11:42 AM, jean-christophe manciot <
act...@gm...> wrote:

> Here are the details you've asked for:
> bash --version
> GNU bash, version 4.4.0(1)-release
> on Ubuntu 16.10 4.8
>
> You have missed the fact that the configure line with --with-bash-src=...
> has been *commented out* because of the bug described in the comment
> located just above it and not reported. It has no effect in this bug
> report.
>
> The log & bug reported by this mail is the consequence of the non
> commented configure & make lines.
>
> On Sat, Dec 3, 2016 at 3:48 PM, Rocky Bernstein <roc...@gm...
> > wrote:
>
>> Jean-Christophe -
>>
>> Thanks for reporting the problems you encountered. I have a little
>> trouble reading the report because, although there is a bit that is
>> specific, various oher details aren't there.
>>
>> So here's my take on what the log given.
>>
>> 'readc.c:848:46: error: too few arguments to function
>>> ‘valid_array_reference’'
>>
>>
>> is probably caused by a change in the bash API to the function
>> valid_array_reference().
>> The offending line in bashdb is:
>>
>>       if (legal_identifier (varname) == 0 && valid_array_reference
>> (varname) == 0)
>>
>> What version of bash did you run against? If you or someone eise in the
>> devel lis is up for it, perhaps you can figure how to change read.c for the
>> changed var_array_reference call.
>>
>> If you remove  --with-bash-src=/home/actionmystique/Program-Files/
>> Ubuntu/Bash/git-bash from the configure option, bashdb won't try to
>> compile read.c.
>>
>> That particular function that is getting compiled allows bashdb to do a
>> command-completion kind of read inside it debugger read loop. It not needed
>> for overall basic functioning, but I guess it is a nice thing to have.
>> Perhaps bash now offers a way to handle completion inside its builtin
>> read() function. If that's the case we should remove compiling this.
>> Perhaps you or someone can check?
>>
>> As for setting $ac_aux_dir to '.', that may work for you in your
>> environment but it is symptomatic of some sort of configure script failure.
>> Any shell variable that starts ac_ is something the configure script sets
>> (ac stands I guess for autoconf). So if this is set wrong or is not set,
>> then things are probably misconfigured. When bashdb is misconfigured, the
>> test scripts may fail.
>>
>>
>> On Fri, Dec 2, 2016 at 2:25 PM, jean-christophe manciot <
>> act...@gm...> wrote:
>>
>>> Hi there,
>>>
>>> The following script run with branch=master & tag=release-4.4-0.92:
>>>
>>>         echo --------
>>>         echo Cleaning
>>>         echo --------
>>>         cd git-bashdb
>>>         sudo -u actionmystique -H git-reset-clean-pull-checkout.sh
>>> $branch
>>> $tag
>>>
>>>         echo ------------------
>>>         echo Building configure
>>>         echo ------------------
>>>         export NOCONFIGURE=yes
>>>         sudo -Eu actionmystique -H ./autogen.sh
>>>
>>>         echo -------------------------------------------------------
>>>         echo Working around a bug related to $ac_aux_dir/config.sub
>>>         echo -------------------------------------------------------
>>>         # Cf. https://sourceforge.net/p/bashdb/bugs/42/
>>>         sudo -u actionmystique -H sed -i 's|$ac_aux_dir|.|g' ./configure
>>>
>>>         echo -----------
>>>         echo Configuring
>>>         echo -----------
>>>         # Bugs 'readc.c:848:46: error: too few arguments to function
>>> ‘valid_array_reference’'
>>>         # sudo -u actionmystique -H ./configure
>>> --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash
>>> \
>>>         sudo -u actionmystique -H ./configure   --prefix=/usr/share
>>> --sysconfdir=/etc --localstatedir=/var
>>>
>>>         echo ---------
>>>         echo Compiling
>>>         echo ---------
>>>         sudo -u actionmystique -H make
>>>
>>>         echo --------
>>>         echo Checking
>>>         echo --------
>>>         sudo -u actionmystique -H make check
>>>
>>> leads to *5 tests errors: attached test-suite.log*
>>>
>>> The whole build log is available on request.
>>> --
>>> Jean-Christophe
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Bashdb-devel mailing list
>>> Bas...@li...
>>> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>>>
>>>
>>
>
>
> --
> Jean-Christophe
>

Here are the details you've asked for:
bash --version
GNU bash, version 4.4.0(1)-release
on Ubuntu 16.10 4.8

You have missed the fact that the configure line with --with-bash-src=...
has been *commented out* because of the bug described in the comment
located just above it and not reported. It has no effect in this bug
report.

The log & bug reported by this mail is the consequence of the non commented
configure & make lines.

On Sat, Dec 3, 2016 at 3:48 PM, Rocky Bernstein <roc...@gm...>
wrote:

> Jean-Christophe -
>
> Thanks for reporting the problems you encountered. I have a little trouble
> reading the report because, although there is a bit that is specific,
> various oher details aren't there.
>
> So here's my take on what the log given.
>
> 'readc.c:848:46: error: too few arguments to function
>> ‘valid_array_reference’'
>
>
> is probably caused by a change in the bash API to the function
> valid_array_reference().
> The offending line in bashdb is:
>
>       if (legal_identifier (varname) == 0 && valid_array_reference
> (varname) == 0)
>
> What version of bash did you run against? If you or someone eise in the
> devel lis is up for it, perhaps you can figure how to change read.c for the
> changed var_array_reference call.
>
> If you remove  --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash
> from the configure option, bashdb won't try to compile read.c.
>
> That particular function that is getting compiled allows bashdb to do a
> command-completion kind of read inside it debugger read loop. It not needed
> for overall basic functioning, but I guess it is a nice thing to have.
> Perhaps bash now offers a way to handle completion inside its builtin
> read() function. If that's the case we should remove compiling this.
> Perhaps you or someone can check?
>
> As for setting $ac_aux_dir to '.', that may work for you in your
> environment but it is symptomatic of some sort of configure script failure.
> Any shell variable that starts ac_ is something the configure script sets
> (ac stands I guess for autoconf). So if this is set wrong or is not set,
> then things are probably misconfigured. When bashdb is misconfigured, the
> test scripts may fail.
>
>
> On Fri, Dec 2, 2016 at 2:25 PM, jean-christophe manciot <
> act...@gm...> wrote:
>
>> Hi there,
>>
>> The following script run with branch=master & tag=release-4.4-0.92:
>>
>>         echo --------
>>         echo Cleaning
>>         echo --------
>>         cd git-bashdb
>>         sudo -u actionmystique -H git-reset-clean-pull-checkout.sh
>> $branch
>> $tag
>>
>>         echo ------------------
>>         echo Building configure
>>         echo ------------------
>>         export NOCONFIGURE=yes
>>         sudo -Eu actionmystique -H ./autogen.sh
>>
>>         echo -------------------------------------------------------
>>         echo Working around a bug related to $ac_aux_dir/config.sub
>>         echo -------------------------------------------------------
>>         # Cf. https://sourceforge.net/p/bashdb/bugs/42/
>>         sudo -u actionmystique -H sed -i 's|$ac_aux_dir|.|g' ./configure
>>
>>         echo -----------
>>         echo Configuring
>>         echo -----------
>>         # Bugs 'readc.c:848:46: error: too few arguments to function
>> ‘valid_array_reference’'
>>         # sudo -u actionmystique -H ./configure
>> --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash \
>>         sudo -u actionmystique -H ./configure   --prefix=/usr/share
>> --sysconfdir=/etc --localstatedir=/var
>>
>>         echo ---------
>>         echo Compiling
>>         echo ---------
>>         sudo -u actionmystique -H make
>>
>>         echo --------
>>         echo Checking
>>         echo --------
>>         sudo -u actionmystique -H make check
>>
>> leads to *5 tests errors: attached test-suite.log*
>>
>> The whole build log is available on request.
>> --
>> Jean-Christophe
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Bashdb-devel mailing list
>> Bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>>
>>
>


-- 
Jean-Christophe

Jean-Christophe -

Thanks for reporting the problems you encountered. I have a little trouble
reading the report because, although there is a bit that is specific,
various oher details aren't there.

So here's my take on what the log given.

'readc.c:848:46: error: too few arguments to function
> ‘valid_array_reference’'


is probably caused by a change in the bash API to the function
valid_array_reference().
The offending line in bashdb is:

      if (legal_identifier (varname) == 0 && valid_array_reference
(varname) == 0)

What version of bash did you run against? If you or someone eise in the
devel lis is up for it, perhaps you can figure how to change read.c for the
changed var_array_reference call.

If you remove  --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash
from the configure option, bashdb won't try to compile read.c.

That particular function that is getting compiled allows bashdb to do a
command-completion kind of read inside it debugger read loop. It not needed
for overall basic functioning, but I guess it is a nice thing to have.
Perhaps bash now offers a way to handle completion inside its builtin
read() function. If that's the case we should remove compiling this.
Perhaps you or someone can check?

As for setting $ac_aux_dir to '.', that may work for you in your
environment but it is symptomatic of some sort of configure script failure.
Any shell variable that starts ac_ is something the configure script sets
(ac stands I guess for autoconf). So if this is set wrong or is not set,
then things are probably misconfigured. When bashdb is misconfigured, the
test scripts may fail.


On Fri, Dec 2, 2016 at 2:25 PM, jean-christophe manciot <
act...@gm...> wrote:

> Hi there,
>
> The following script run with branch=master & tag=release-4.4-0.92:
>
>         echo --------
>         echo Cleaning
>         echo --------
>         cd git-bashdb
>         sudo -u actionmystique -H git-reset-clean-pull-checkout.sh $branch
> $tag
>
>         echo ------------------
>         echo Building configure
>         echo ------------------
>         export NOCONFIGURE=yes
>         sudo -Eu actionmystique -H ./autogen.sh
>
>         echo -------------------------------------------------------
>         echo Working around a bug related to $ac_aux_dir/config.sub
>         echo -------------------------------------------------------
>         # Cf. https://sourceforge.net/p/bashdb/bugs/42/
>         sudo -u actionmystique -H sed -i 's|$ac_aux_dir|.|g' ./configure
>
>         echo -----------
>         echo Configuring
>         echo -----------
>         # Bugs 'readc.c:848:46: error: too few arguments to function
> ‘valid_array_reference’'
>         # sudo -u actionmystique -H ./configure
> --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash \
>         sudo -u actionmystique -H ./configure   --prefix=/usr/share
> --sysconfdir=/etc --localstatedir=/var
>
>         echo ---------
>         echo Compiling
>         echo ---------
>         sudo -u actionmystique -H make
>
>         echo --------
>         echo Checking
>         echo --------
>         sudo -u actionmystique -H make check
>
> leads to *5 tests errors: attached test-suite.log*
>
> The whole build log is available on request.
> --
> Jean-Christophe
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>
>

Hi there,

The following script run with branch=master & tag=release-4.4-0.92:

        echo --------
        echo Cleaning
        echo --------
        cd git-bashdb
        sudo -u actionmystique -H git-reset-clean-pull-checkout.sh $branch
$tag

        echo ------------------
        echo Building configure
        echo ------------------
        export NOCONFIGURE=yes
        sudo -Eu actionmystique -H ./autogen.sh

        echo -------------------------------------------------------
        echo Working around a bug related to $ac_aux_dir/config.sub
        echo -------------------------------------------------------
        # Cf. https://sourceforge.net/p/bashdb/bugs/42/
        sudo -u actionmystique -H sed -i 's|$ac_aux_dir|.|g' ./configure

        echo -----------
        echo Configuring
        echo -----------
        # Bugs 'readc.c:848:46: error: too few arguments to function
‘valid_array_reference’'
        # sudo -u actionmystique -H ./configure
--with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash \
        sudo -u actionmystique -H ./configure   --prefix=/usr/share
--sysconfdir=/etc --localstatedir=/var

        echo ---------
        echo Compiling
        echo ---------
        sudo -u actionmystique -H make

        echo --------
        echo Checking
        echo --------
        sudo -u actionmystique -H make check

leads to *5 tests errors: attached test-suite.log*

The whole build log is available on request.
-- 
Jean-Christophe

This failure means that debugger signal handing is not working for you.

This is a debugger is for bash 3.x, and that specific debugger code is
about 9 years old. I am not going to be further developing code this old.
But if others are so motivated to do so, I'll accept patches.

For that to happen, unless it is yourself, the person helping you would
probably need to know the OS and version of bash you are using.




On Sat, Mar 12, 2016 at 4:20 AM, Song,Ruogang <ruo...@pa...>
wrote:

>
>
> --- /tmp/sig.check      2016-03-12 17:16:57.000000000 +0800
> +++ /cpic/sxxsjs/cs1/bashdb-3.1-0.09/test/sig.right     2007-10-14
> 15:27:46.000000000 +0800
> @@ -21,6 +21,7 @@
>  +handle TERM bogus
>  Need to give a command: stop, nostop, stack, nostack, print, noprint
>  +eval kill -TERM $$
> +Program received signal SIGTERM (15)...
>  +### Should not have printed a stack trace above...
>  +handle TERM noprint
>  +handle TERM stack
> @@ -37,11 +38,20 @@
>  SIGTERM      stop   noprint showstack trap -- '_Dbg_sig_handler 15
> "$BASH_COMMAND" "$@"' SIGTERM
>  +continue
>  Program received signal SIGTERM (15)...
> -->0 in file `sig.sh' at line 17
> -##1 source("sig.sh") called from file `bashdb' at line 277
> -->2 main() called from file `bashdb' at line 0
> +->0 in file `dbg-cmds.inc' at line 2
> +##1 _Dbg_do_eval("kill", "-TERM", "$$") called from file `dbg-cmds.inc'
> at line 343
> +->2 _Dbg_onecmd("eval", "kill -TERM $$") called from file `dbg-cmds.inc'
> at line 157
> +##3 _Dbg_cmdloop() called from file `dbg-sig.inc' at line 220
> +##4 _Dbg_debug_trap_handler("0", "[[ "$1"x != x ]]") called from file
> `sig.sh' at line 7
> +##5 source("sig.sh") called from file `bashdb' at line 277
> +##6 main() called from file `bashdb' at line 0
>  +### Should have printed a stack trace above...
>  +continue
> ++where
> +->0 in file `sig.sh' at line 741
> +##1 source("sig.sh") called from file `bashdb' at line 277
> +##2 main() called from file `bashdb' at line 0
> ++continue
>  Program received signal SIGINT (2)...
>  ->0 in file `sig.sh' at line 23
>  ##1 source("sig.sh") called from file `bashdb' at line 277
> @@ -51,9 +61,5 @@
>  ##1 source("sig.sh") called from file `bashdb' at line 277
>  ->2 main() called from file `bashdb' at line 0
>  Debugged program terminated normally. Use q to quit or R to restart.
> -+where
> -No stack.
> -+continue
> -The program is not being run.
>  +kill
>  sig.tests: line 11: xxxx Killed $BASH ${TOP_BUILDDIR}bashdb -B -q -L ..
> -x $cmdfile $debugged_script
> --- /tmp/sig.check2     2016-03-12 17:16:57.000000000 +0800
> +++ /tmp/sig.right      2016-03-12 17:16:57.000000000 +0800
> @@ -21,6 +21,7 @@
>  +handle TERM bogus
>  Need to give a command: stop, nostop, stack, nostack, print, noprint
>  +eval kill -TERM $$
> +Program received signal SIGTERM (15)...
>  +### Should not have printed a stack trace above...
>  +handle TERM noprint
>  +handle TERM stack
> @@ -37,11 +38,20 @@
>  SIGTERM      stop   noprint showstack trap -- '_Dbg_sig_handler 15
> "$BASH_COMMAND" "$@"' SIGTERM
>  +continue
>  Program received signal SIGTERM (15)...
> -->0 in file `sig.sh' at line 17
> -##1 source("sig.sh") called from file `bashdb' at line 277
> -->2 main() called from file `bashdb' at line 0
> +->0 in file `dbg-cmds.inc' at line 2
> +##1 _Dbg_do_eval("kill", "-TERM", "$$") called from file `dbg-cmds.inc'
> at line 343
> +->2 _Dbg_onecmd("eval", "kill -TERM $$") called from file `dbg-cmds.inc'
> at line 157
> +##3 _Dbg_cmdloop() called from file `dbg-sig.inc' at line 220
> +##4 _Dbg_debug_trap_handler("0", "[[ "$1"x != x ]]") called from file
> `sig.sh' at line 7
> +##5 source("sig.sh") called from file `bashdb' at line 277
> +##6 main() called from file `bashdb' at line 0
>  +### Should have printed a stack trace above...
>  +continue
> ++where
> +->0 in file `sig.sh' at line 741
> +##1 source("sig.sh") called from file `bashdb' at line 277
> +##2 main() called from file `bashdb' at line 0
> ++continue
>  Program received signal SIGINT (2)...
>  ->0 in file `sig.sh' at line 23
>  ##1 source("sig.sh") called from file `bashdb' at line 277
> @@ -51,9 +61,5 @@
>  ##1 source("sig.sh") called from file `bashdb' at line 277
>  ->2 main() called from file `bashdb' at line 0
>  Debugged program terminated normally. Use q to quit or R to restart.
> -+where
> -No stack.
> -+continue
> -The program is not being run.
>  +kill
>  sig.tests: line 11: xxxx Killed $BASH ${TOP_BUILDDIR}bashdb -B -q -L ..
> -x $cmdfile $debugged_script
> FAIL: run-sig
> PASS: run-skip
> checking subshell1...
> checking subshell2...
> checking subshell3...
> PASS: run-subshell
> PASS: run-tbreak
> checking trace...
> checking trace2...
> PASS: run-trace
> PASS: run-watch1
> PASS: run-watch2
> ===================================================
> 1 of 25 tests failed
> Please report to bas...@li...
> ===================================================
> make[2]: *** [check-TESTS] Error 1
> make[2]: Leaving directory `/cpic/sxxsjs/cs1/bashdb-3.1-0.09/test'
> make[1]: *** [check-am] Error 2
> make[1]: Leaving directory `/cpic/sxxsjs/cs1/bashdb-3.1-0.09/test'
> make: *** [check-recursive] Error 1
>
>
>
> Best Regards,
> [logo+纳斯达克邮件.png]
> 宋若刚
> Professional Talent Acquisition
> Mobile: +86.136.8219.7690
> Email: ruo...@pa...<mailto:Jac...@pa...>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>