You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(9) |
Oct
(15) |
Nov
(6) |
Dec
(10) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
(5) |
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(30) |
Sep
(4) |
Oct
(2) |
Nov
(4) |
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(2) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(2) |
2006 |
Jan
(10) |
Feb
(5) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
(6) |
Aug
(13) |
Sep
(1) |
Oct
|
Nov
|
Dec
(9) |
2007 |
Jan
(4) |
Feb
(11) |
Mar
(1) |
Apr
(5) |
May
(3) |
Jun
|
Jul
(6) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(1) |
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(9) |
Sep
(1) |
Oct
(7) |
Nov
|
Dec
(4) |
2009 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
(3) |
Sep
(4) |
Oct
(3) |
Nov
(1) |
Dec
(2) |
2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(6) |
2017 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(5) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: R. B. <ro...@pa...> - 2002-10-22 03:49:50
|
I was thinking about this problem and your patch some more. My mistake before was trying to redirect stdout, not stderr. So a simple fix would have just been to add "2>$_tty" to the "read" builtin when $_tty is defined. I don't think the builtin read needs to be changed at all. Below is a patch that does just that. However.... when I run the regression tests, test "misc" fails because lines don't appear: prof1.cmd called prof2.cmd called... calling prof1.cmd... prof1.cmd called All of these are not printed from the shell test script, but instead from the debugger command script which issues a debugger "print" command for each of these. It is then possble that _bashdb_cmd_source has bug in it, or at minimum interacts funny with the code below. I think the problem is an interaction between the "eval" a "read" command and the "exec" of _bashdb_bash_source to reset the file descriptor. Any thoughts or suggestions? --- bashdb-cmds.inc.~1.72~ 2002-10-21 22:04:33.000000000 -0400 +++ bashdb-cmds.inc 2002-10-21 23:11:58.000000000 -0400 @@ -62,8 +62,16 @@ # Loop over debugger commands IFS="$_bashdb_space_IFS"; - while read -e -p "bashdb${_bashdb_less}$_bashdb_hi${_bashdb_greater} " \ - _bashdb_cmd _bashdb_args <&$_bashdb_input_desc ; do + + local _bashdb_redirect='' + if [[ -n "$_tty" ]] ; then + _bashdb_redirect="2>$_tty" + fi + local _bashdb_read_cmd=\ +"read -e -p 'bashdb${_bashdb_less}$_bashdb_hi${_bashdb_greater}' "\ +"_bashdb_cmd _bashdb_args <&$_bashdb_input_desc $_bashdb_redirect" + + while eval $_bashdb_read_cmd ; do # Set default next, step or skip command if [[ -z $_bashdb_cmd ]]; then |
From: Masatake Y. <je...@gy...> - 2002-10-21 18:42:17
|
Sorry, I forgot to attach the new patch. I took too many mistakes today. |
From: Masatake Y. <je...@gy...> - 2002-10-21 18:34:04
|
Thank you for comments. > A couple of other thoughts. First, you can't assume $_tty is set. See > the ugly code in _bashdb_msg from bashdb-io.inc. You may be inside a > command file and not in an interactive shell in which case there is no > tty. If you can find a cleaner way to handle _bashdb_msg the same > would work here. If not you might have to create the read command and > eval it - ugly. I see. I've decided to use variables that hold -F options and output stream for the prompt. See new patch. > > I've added new option -F to fource print output to stderr. > > You mean to stdout, not stderr, right? Stderr. See read.def::read_builtin: if (prompt && edit == 0) { fprintf (stderr, "%s", prompt); fflush (stderr); } The prompt is written to stderr. > Lastly I suppose we should create a test (in tests) and update the > documentation in bashref.texi. However one might wait until after we > get comments. Before these works. I'd like to commit the code to CVS repository. Ok? Masatake |
From: R. B. <ro...@pa...> - 2002-10-21 17:27:17
|
A couple of other thoughts. First, you can't assume $_tty is set. See the ugly code in _bashdb_msg from bashdb-io.inc. You may be inside a command file and not in an interactive shell in which case there is no tty. If you can find a cleaner way to handle _bashdb_msg the same would work here. If not you might have to create the read command and eval it - ugly. > I've added new option -F to fource print output to stderr. You mean to stdout, not stderr, right? Lastly I suppose we should create a test (in tests) and update the documentation in bashref.texi. However one might wait until after we get comments. |
From: Masatake Y. <je...@gy...> - 2002-10-21 16:13:56
|
Please, evaluate my patch for the issue. I`ve bind output channel of read command to _tty as you suggested. I've added new option -F to fource print output to stderr. Masatake |
From: Masatake Y. <je...@gy...> - 2002-10-21 16:06:22
|
> Will look at when I get a chance... Perhaps others can su Yes! Probably, I solved this issue. I'm doing cvs-diff now. Please wait. |
From: R. B. <ro...@pa...> - 2002-10-21 15:56:32
|
I now understand the problem. It however doesn't mean I know how to fix properly. When you run this: > 4: (autofig --version) < /dev/null > /dev/null 2>&1 || { you are stopping *inside* in a subshell which has had stdin and stdout redirected to /dev/null. The debugger is using stdout in the subshell environment to print the prompt on line; but stdout has beeen redirected to /dev/null. The faulty code is probably on line 65 of bashdb-cmds.inc: while read -e -p "..." _bashdb_cmd _bashdb_args <&$_bashdb_input_desc ... We should redirect output to the debugger's output rather than take the default stdout which may be nulled. bashdb has a variable $_tty, (see _bashdb_msg or _bashdb_printf) but a small test and that didn't work. Will look at when I get a chance... Perhaps others can su |
From: Masatake Y. <je...@gy...> - 2002-10-21 14:50:29
|
> Masatake YAMATO writes: > > (We should use the name of commands: configure, autogen.sh, libtool to > > advertise bashdb. These are too big sh scripts to debug bashdb.) Sorry. I wrote wrong. What I should write: These are too big sh scripts to debug without bashdb. |
From: R. B. <ro...@pa...> - 2002-10-21 14:47:47
|
Masatake YAMATO writes: > (We should use the name of commands: configure, autogen.sh, libtool to > advertise bashdb. These are too big sh scripts to debug bashdb.) Yes, debugging many configure or autogen.sh or libtool scripts would really get lots of bugs out of bashdb. The debugger could stand a lot of debugging itself. > > When I run bashdb with targeting autogen.sh attached to this mail, > bashdb didn't show its prompt. Is this known problem? I wasn't aware of the problem before you gave this example. > (autogen.sh:4): > 4: (autofig --version) < /dev/null > /dev/null 2>&1 || { ^^^^^^^^^^^ The problem seems to be the output redirect above. Don't know how to fix right now, perhaps someone else has a suggestion. The problem is probably somewhere in bashdb-sig.inc the call to _bashdb_print_source_line or _bashdb_print_source_line in bashdb-list.inc. |
From: Masatake Y. <je...@gy...> - 2002-10-21 13:48:54
|
(We should use the name of commands: configure, autogen.sh, libtool to advertise bashdb. These are too big sh scripts to debug bashdb.) When I run bashdb with targeting autogen.sh attached to this mail, bashdb didn't show its prompt. Is this known problem? [jet@chuf frontline]$ bashdb autogen.sh Bourne-Again Shell Debugger, release bash-2.05b Copyright 2002 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. (autogen.sh:4): 4: (autofig --version) < /dev/null > /dev/null 2>&1 || { |
From: Masatake Y. <je...@gy...> - 2002-10-21 13:16:10
|
Forgive me my wrong quotation in the last mail. I've just added a screenshot that shows bashdb's backtrace function. |
From: Masatake Y. <je...@gy...> - 2002-10-21 12:48:48
|
I've added new screenshots to the web page. Please, check. > I just looked at bashdb-devel just now and just subscribed to > it. Shame on me. Also I'm going hiking for a week starting Monday (and > have a wedding to attend on Sunday). > > Do you still have "make check" problems? It looks like the difference > is just in the file names. This probably needs to be tracked down as > to why the file appears as xxx for you and ./xxx for me (or vice > versa). > > As for tracking changes in the unmodified bash, yes it sort of is my > intention that we'll have to track the changes in releases and this is > not going to be fun. Given the situation I don't know what else to do. |
From: R. B. <ro...@pa...> - 2002-09-23 22:22:50
|
Here's the NEWS entry: - Document "break" command. - Change "line" to "linespec" in online help where appropriate. - Add commands "tbreak" (one-time break) and "display" (automatic display). - Add provision to debug into a script ("debug" command), and leave script without going back into debugger command loop (BASHDB_QUIT_ON_QUIT environment variable). - Document "tbreak", "enable" and "disable" in manual. |
From: Masatake Y. <je...@gy...> - 2002-09-22 03:29:04
|
> By the way, the screen shot looks truncated when I looked at. Sorry. I just put new one. |
From: R. B. <ro...@pa...> - 2002-09-22 02:14:13
|
I just looked at bashdb-devel just now and just subscribed to it. Shame on me. Also I'm going hiking for a week starting Monday (and have a wedding to attend on Sunday). Do you still have "make check" problems? It looks like the difference is just in the file names. This probably needs to be tracked down as to why the file appears as xxx for you and ./xxx for me (or vice versa). As for tracking changes in the unmodified bash, yes it sort of is my intention that we'll have to track the changes in releases and this is not going to be fun. Given the situation I don't know what else to do. It's possible if there is not enough help or everyone is busy that we just have patches on the major releases whatever that may mean. As for the problem with index.html. Really this is a copy of bashdb/htdocs/index.html. I create this file without g+w which was a mistake. I tried deleting the file and recreating it to see if I could make it g+w. Of course, before I scp it to /home/groups/b/ba/bashdb/htdocs I could make it g+w which is what I just did. However I know if the future I am going to forget. We may need to open a ticket to force this file g+w. I tried adding the link. If you wnat to change index.html (and by all means do it - it is really very plain), please change the CVS version and check it in and then do the copy. By the way, the screen shot looks truncated when I looked at. Again, I apologize for not being more on the ball with the mailing list I set up. Gimme time to get used to all this newfangle technology. |
From: Masatake Y. <je...@gy...> - 2002-09-19 17:10:01
|
All make check's test fails on my thinkpad. Do you know already? Or something wrong? |
From: Masatake Y. <je...@gy...> - 2002-09-19 16:15:28
|
> You mean the current bash maintainer, not the original other. I think > so. But it is hard to know what the maintainer knows and doesn't since > he seems often to be uncommunicative often. Two years ago, I submitted > some patches and received no word on it - whether it was received, > needed changes or whatnot. Before starting this I sent info on what > the changes were to get to the first version of this. Again nothing. I see. However, we have to make efforts ANYWAY. I could help you in these political hacking. To be useful, bashdb should handle any bash syntax. If the bash development and bashdb development become branched, finally bashdb could not handle all bash syntax. I believe this is the most important point of bashdb project. Masatake |
From: Masatake Y. <je...@gy...> - 2002-09-19 16:11:25
|
Hi, > > I cannot do much things, however, I could do some small things. > > Please, add me. My sourceforge account name is "masata-y". > > First my task is putting a bashdb.el screenshot to the project > > web page:) > > Great. Yet Again, thanks! I've put bashdb.sourceoforge.net:/home/groups/b/ba/bashdb/htdocs/bashdb.png. It seems that index.html is not writable for me. So 1. do chmod g+w index.html or 2. add a link to bashdb.png to index.html. Do you know evenyone loves screenshots:) Masatake YAMATO |
From: Masatake Y. <je...@gy...> - 2002-09-19 15:37:39
|
> You mean the current bash maintainer, not the original other. I think > so. But it is hard to know what the maintainer knows and doesn't since > he seems often to be uncommunicative often. Two years ago, I submitted > some patches and received no word on it - whether it was received, > needed changes or whatnot. Before starting this I sent info on what > the changes were to get to the first version of this. Again nothing. I see. However, we have to make efforts ANYWAY. I could help you in these political hacking. To be useful, bashdb should handle any bash syntax. If the bash development and bashdb development become branched, finally bashdb could not handle all bash syntax. I believe this is the most important point of bashdb project. Masatake |
From: Masatake Y. <je...@gy...> - 2002-09-19 15:21:50
|
Hi, > > I cannot do much things, however, I could do some small things. > > Please, add me. My sourceforge account name is "masata-y". > > First my task is putting a bashdb.el screenshot to the project > > web page:) > > Great. Yet Again, thanks! I've put bashdb.sourceoforge.net:/home/groups/b/ba/bashdb/htdocs/bashdb.png. It seems that index.html is not writable for me. So 1. do chmod g+w index.html or 2. add a link to bashdb.png to index.html. Do you know evenyone loves screenshots:) Masatake YAMATO |
From: R. B. <ro...@pa...> - 2002-09-18 15:41:07
|
Masatake YAMATO writes: > I write what I know. In Autotools book written by Gary V. Vaughan, et > al., bootstrap.sh and autogen.sh are introduced for this purpose. The > difference between bootstrap.sh and autogen.sh is runnint configure at > the end of script or not; autogen.sh runs and bootstrap.sh does not. > I cound find autogen.sh in many projects. However, bootstrap.sh is > good for cross compiling. Thanks for the information! I guess then the best thing to do is to make it so cvscompile.sh, bootstrap.sh and autogen.sh all work. By the way I've set up a mailing list bas...@li.... (I'm copying that list to see if it *really* works.) If in the past there has been private mail, it's not been by intention but just a lack of getting an open discussion list set up. Your mail has been very helpful to this project and perhaps others will find the information you write useful too. > > The idea of putting this in an open CVS was to encourage multiple > > developers. (Personally, I'm not a big fan of bash. However I am too > > often forced to use it.) If you would like write access work on > > development and make changes to this project let me know. > > I cannot do much things, however, I could do some small things. > Please, add me. My sourceforge account name is "masata-y". > First my task is putting a bashdb.el screenshot to the project > web page:) Great. Yet Again, thanks! > The buggiest question is: does the bash author know this project? You mean the current bash maintainer, not the original other. I think so. But it is hard to know what the maintainer knows and doesn't since he seems often to be uncommunicative often. Two years ago, I submitted some patches and received no word on it - whether it was received, needed changes or whatnot. Before starting this I sent info on what the changes were to get to the first version of this. Again nothing. |