New formula: BASHDB, the BASH debugger #16743

Closed
wants to merge 4 commits into
from

Projects

None yet

4 participants

From the homepage at bashdb.sourceforge.net:

BASHDB is a source-code debugger for BASH that follows
the GDB command syntax, supporting BASH version 4.1+.

@zenoamaro zenoamaro Initial formula.
BASHDB is a source-code debugger for BASH that follows
the GDB command syntax, supporting BASH version 4.1+.
8d303ef

It will (automatically) install a bin and a manpage:

bashdb/4.2-0.8/bin/bashdb
bashdb/4.2-0.8/share/man/man1/bashdb.1

I will post the full find listage of the Cellar if required.

Just a thing: having the bash sources ready would allow to compile the fast array debugging extension. I know I could depend on bash being built, but I'd like to get the sources without forcing the compile step on the user.

What would the best way to do this be?

Contributor

If you don't need to build a full bash binary from them, and just need the source tree on hand, you can use a subformula. Take a look at android-sdk for an example.

@mistydemeo thanks, I got to it alright, but it's coming out as a problematic build.

In the meantime, the current version will compile and run just fine, so it will suffice while I work this out.

Contributor
adamv commented Feb 3, 2013

Any update here or should we close this while it is worked out?

@adamv the recipe currently works, fully and as intended. It produces the working bashdb, along with everything it needs. It compiles correctly, passes the test, and has no extra or useless code. It may be merged as it is.

I'm sorry if I haven't been clearer on this point.

What I was working on was building an extension which comes with bashdb, which would have been nice, but is completely optional, and the only thing it does is speeding a couple of things by a bit. But I don't think it would currently be worth it to compile it too, for no actual increase in functionality.

Contributor
adamv commented Feb 9, 2013

We should use a Requirement that checks the version of the bash in the path, rather than depending on a full build of bash here, in case the user has a non-Homebrew bash.

I believe it will be pretty uncommon (and also bad) for someone to override the bash in /bin, but else I do agree with you.

This update checks if the user does already have the homebrew bash, without strictly depending on it, but also allows him to specify a custom bash path, while checking if it's the correct version. He will be informed of what bash is being used during the installation step, and how to correct it. If he has neither, the usage of the formula will be explained:

This formula requires to be linked to an installation of Bash > 4.1.

If you are happy with the version that homebrew provides (#{@bash_version}),
you may do `brew install bash` and then brew this formula again.

Else, you may pass the specific bash which you'd like bashdb to use
using the `--with-bash=<path/to/bash>` option.

I'm not checking for the bash in the path, as I believe that will most probably be the system Bash 3.2. Manual compilation usually puts it in /usr/local and seeing that homebrew sets it as owner-writable, it doesn't sound very safe to have /usr/local/bin before /bin in $PATH. Maybe /usr/bin, but I do not know how standard it is in OSX.

I may be wrong, though, and I'm open to suggestions, proposals, or other reasoning.

If auto-detection is desired, though, I think the safest approach would be iterating the /etc/shells and picking the first correct one.

What do you think?

Contributor
adamv commented Mar 27, 2013

Maintainers, any thoughts here?

Owner

I think just depend on Homebrew bash if it doesn't work with the system version.

@mikemcquaid: that's what I did, originally, I simply depended on homebrew bash, as bashdb needs a pretty recent version. Per @adamv's suggestion, I've added the option for the user to specify a particular version of bash if he didn't want the one from homebrew.

Personally, I think the recipe should just eat the homebrew food, and if the user has specific needs he'll probably need to compile it from scratch anyway. So I'd either revert it to the first revision (simplest), or update the recipe to depend on homebrew bash by default, unless a specific bash has been passed as option (which is very similar to how it is now).

Regarding the system bash: unless the user has somehow replaced it (which I think, as I said above, would be a bad thing), it won't work with it, as OSX ships with bash 3 and BashDB needs 4.

Contributor
adamv commented May 2, 2013

Ok, let's have this just depend on Homebrew's Bash.

@adamv so be it. I reverted it to the initial formula, minus the "building bash from source" part, which was unnecessary.

@adamv adamv was assigned May 3, 2013
Contributor
adamv commented May 4, 2013

This formula fails to import for me; seems bomb out on the require 'IO' line.

Also, please keep this squashed to a single commit for review.

@adamv adamv closed this in 4c6561d May 4, 2013
Contributor
adamv commented May 4, 2013

(corrected and pulled)

Mmh. Very strange.

$ brew irb
==> Interactive Homebrew Shell
Example commands available with: brew irb --help
>> require 'IO'
=> true

$ rvm current
ruby-1.9.3-p327

Anyway, thanks for keeping up with this !

@zenoamaro zenoamaro deleted the zenoamaro:formula/bashdb branch May 4, 2013
@handyman5 handyman5 pushed a commit to handyman5/homebrew that referenced this pull request Oct 7, 2013
@zenoamaro @adamv zenoamaro + adamv bashdb 4.2-0.8
Closes #16743.

Signed-off-by: Adam Vandenberg <flangy@gmail.com>
56afb86
@draftycode draftycode added a commit to draftycode/homebrew that referenced this pull request Feb 24, 2014
@zenoamaro @draftycode zenoamaro + draftycode bashdb 4.2-0.8
Closes #16743.

Signed-off-by: Adam Vandenberg <flangy@gmail.com>
e50947f
@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 16, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.