-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathINSTALL
134 lines (96 loc) · 5.1 KB
/
INSTALL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
SHORT INSTRUCTIONS:
0. download the latest bash debugger from:
http://prdownloads.sourceforge.net/bashdb/?sort_by=date&sort=desc
The name should start out bashdb-4.x...
and ungzip/untar it. If you are reading this, you've
probably done that already.
1. Make your current directory the debugger directory. If you want
the bash extension command readarray that speeds up loading of
large scripts than read step 3 of the long instructions especially
down at the bottom. Basically to speed up the initialy debugger
loading, you need the bash source headers and need to run
configure using --with-bash-src.
configure, build, test, and install the debugger:
cd bashdb-4.x... # <-- put name of release for 4.x...
./configure # use --with-bash-src to speed up bash debugging
make && make check
su -c 'make install'
On systems which don't install GNU Make by default you may have to use
"gmake" instead of "make".
In creating files and directories for the bashdb, beware that the
umask of the account performing the installation is consulted as it
would be for any new file or directory. In particular, if your
umask is, for example, 007, then directories that get created will
have permission drwx------ which only allows that user to access
the debugger support files. Since the root account sometimes has
that umask, you may want to set the umask to something more
permissive like 022, before running the "make install".
That's it!
- - - -
This debugger needs a debugger-enabled version of Bash 4.1 or greater.
It is possible to try out the debugger without installing it by using
the bashdb script that is in this directory. To do so you would invoke
your script as follows, assuming you are currently in the directory
(debugger) that you originally found this file in.
$BASH -L . ./bashdb *script-to-be-debugged* *options-to-debugged-program*
where $BASH above is bash 4 with debugging enabled.
A downside to this approach is that $0 in will be ``bashdb'' (or more
likely ``./bashdb'') rather than the name of the script to be
debugged. Also, the parameters to the bashdb invocation do not appear
in a stack trace. If this is a problem, then you will have to install
the debugger, or modify the script to be debugged to point to the
debugger-enabled version of bash. For example if your script were in
this directory (debugger) as well is your current working directory
(as shown by ``pwd''), then having this at the beginning of your
script:
#!/some-location/bash --debugger
might also work.
For information on the differences between "bash --debugger" and
bashdb, see Chapter 2 (Getting In and Out) of the bashdb documentation
(bashdb.info, bashdb.html, or bashdb.texi)
Steps 0 and 1 you've probably already done if you are reading these
instructions.
0. download the latest bash debugger from:
http://prdownloads.sourceforge.net/bashdb/?sort_by=date&sort=desc
The name should start out bashdb-4.x...
1. ungzip/untar the bashdb debugger package.
gzcat bashdb-4.x... | tar -xvpf - # <-- put name of release for 4.x...
(There's a shorter way to do this GNU tar 1.15 or later)
2. Make your current directory the debugger directory.
cd bashdb-4.x...
3. Look at configure help options and decide what you want:
./configure --help
is your friend here.
On those OS's that support it, it is possible to create an
extension which allows bashdb to set $0 (from "bashdb") to the
program being debugged. For this you need the bash source or at
least the headers since we need to compile against that. And you
need to tell configure where to use it via --with-bash-src.
It is important that the source match the bash that is going to be
used when debugger. For example using bash release 4.1 source for
an installed bash 4.0 binary will not work as there are
incompatiblities. Should you have several bash binaries around,
you can tell configure which one you want to use for the debugger
via the option --with-bash.
For --with-bash use absolute paths, not relative paths or the
regression tests will fail.
4. configure the debugger to suit your needs:
./configure # you may want to add options gleened from step 3 above.
# in particular --with-bash-src.
There is a lot of verbiage, but do pay attention to any errors or
warning you see here.
5. Build:
make # make options, but I think none are generally needed
Any old "make" should work, but if it doesn't, use GNU make (sometimes
installed as "gmake". Again, even though there is verbiage pay attention
to errors. If you don't have texi2html you may see some errors in building
HTML pages; these you can ignore.
6. Run the regression tests:
make check # or gmake check
7. Install the debugger:
su -c 'make install'
As above, pay attention to errors. In particular here if you don't have
permission to fully install or overwrite existing files you may get a
message that you can't run "bash --debugger" but must use the "bashdb"
script. See above for a larger discussion of the difference.
No, really. that's it!