Message-ID: <3534E5C1.6395@CGSTE.MQ> Date: Wed, 15 Apr 1998 11:52:17 -0500 From: HANRIGOU Philippe Reply-To: HANRIGOU AT cgste DOT mq Organization: CONSEIL GENERAL DE LA MARTINIQUE / DGA2 MIME-Version: 1.0 To: "Martin Stromberg ; Eli Zaretskii" CC: DJGPP Subject: Re: Problem with bash References: <199804030603 DOT IAA07087 AT mars DOT lu DOT erisoft DOT se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Hi, Martin Stromberg wrote: > Ok. I think these functions come with bash. > > Now, I think if you look at the file mm, you'll understand. Just run > it, perhaps? I think that's what I did. > > Thanks, > > MartinS T H A N K S Martin!!!!! I ran mm and ... I got brand new bash.exe. So cool. Thanks for all your help. Without it , I had no chance to succeed. (maybe I would have succeeded with a miracle, but after next release of bash :-) ). Nevertheless, I've not understood everything. Why the mm script is not included in the makefile, offering two different ways of linking bash (the original one and the "mm" one) dependind on an option? Nevermind I've got enough stuff to debug bash. ----------------------------------------------------------------------- BACK TO ORIGINAL ISSUE: bash freezing after one ls command. I've tried to identify where bash is blocked: I've run a few sessions, always the same way, consisting in launching bash, and typing one "ls" command. Then, as already decribed, bash displays a prompt and freezes. bash seems to be blocked on its first "read" call in "rl_getc" function (file "lib/readline/readline.c"). More precisely in the line: result = read (fileno (stream), &c, sizeof (unsigned char)); To detect that I ran bash with gdb. I set a breakpoint to yyparse and rl_getc. At first call to yyparse, rl_getc is called 3 times, and each time does a "read" (for "l", "s", and "") with no problem. At second call to yyparse, the first time rl_getc is called and try to "read" the program is freezed. Nevertheless argument values of "read" calls are always the same. I don't know what went wrong between the two yyparse calls. Here is the backtrace of all stack frames just before the "fatal" read call: #0 rl_getc (stream=0x59468) at readline.c:3523 #1 0x31a9b in rl_read_key () at readline.c:615 #2 0x316e1 in readline_internal () at readline.c:366 #3 0x315d6 in readline (prompt=0x167f90 "bash$ ") at readline.c:304 #4 0x6243 in yy_readline_get () at y_tab.c:852 #5 0x6175 in yy_getc () at y_tab.c:784 #6 0x69c9 in shell_getc (remove_quoted_newline=1) at y_tab.c:1460 #7 0x6fdf in read_token (command=0) at y_tab.c:1853 #8 0x6e10 in yylex () at y_tab.c:1682 #9 0x501b in yyparse () at y_tab.c:389 #10 0x2a0f in parse_command () at shell.c:1325 #11 0x2acf in read_command () at shell.c:1365 #12 0x27d2 in reader_loop () at shell.c:1222 #13 0x213a in main (argc=1, argv=0x167050, env=0x164000) at shell.c:872 #14 0x42956 in __crt1_startup () Have you got an idea? I really don't know where to investigate to find what went wrong. Regards, Philippe. _______________________________________________________________________ Philippe HANRIGOU Conseil Général de la Martinique Ingénieur informatique D.D.S.T. - service I.T.S. Immeuble Concorde, route de la Folie Tél: (0596) 59-84-63 97200 Fort de France E-mail: HANRIGOU AT cgste DOT mq FRANCE _______________________________________________________________________