From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27938 invoked from network); 22 Oct 1999 06:59:00 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 22 Oct 1999 06:59:00 -0000 Received: (qmail 27889 invoked by alias); 22 Oct 1999 06:51:56 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8367 Received: (qmail 11634 invoked from network); 21 Oct 1999 21:12:55 -0000 From: "Bart Schaefer" Message-Id: <991021211235.ZM14963@candle.brasslantern.com> Date: Thu, 21 Oct 1999 21:12:35 +0000 In-Reply-To: <199910211928.OAA22771@wo1203.cmg.FCNBD.COM> Comments: In reply to Brian Boonstra "Re: BUG: doinsert() in NextStep/OpenStep 4.2" (Oct 21, 2:28pm) References: <199910211531.KAA17425@wo1203.cmg.FCNBD.COM> <991021175506.ZM14852@candle.brasslantern.com> <199910211928.OAA22771@wo1203.cmg.FCNBD.COM> X-Mailer: Z-Mail Lite (5.0.0 30July97) To: Brian Boonstra Subject: Re: BUG: doinsert() in NextStep/OpenStep 4.2 Cc: zsh-workers@sunsite.auc.dk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 21, 2:28pm, Brian Boonstra wrote: > Subject: Re: BUG: doinsert() in NextStep/OpenStep 4.2 > > (gdb) c > > Breakpoint 1, doinsert (str=0xbfffeea8 "l") at zle_misc.c:54 > 54 line[cs++] = *s == Meta ? *++s ^ 32 : *s; > (gdb) s > Program generated(1): Memory access exception on address 0x0 (protection failure). > 0x8b517 in doinsert (str=0xbfffeea8 "l") at zle_misc.c:54 > 54 line[cs++] = *s == Meta ? *++s ^ 32 : *s; That sure looks like the debugger thinks a null pointer deref happened. > I have to say that I can't see why this line is failing. Since zshcs==0, > and *s!=Meta, this should just be setting line[0]="l" with no problem. Is > there something unusual I misunderstand about attaching debuggers to shells? Not that I can see ... but it may be that the debugger is confused. Do you get a crash at that point when running without the debugger attached? > Lacking xterm, I did not try to use your shell code > especially because I don't think my gdb accepts a --tty argument. You can also redirect the I/O at the (gdb) prompt like this: (gdb) run < /dev/ttypq 2>&1 > /dev/ttypq but then you don't get keyboard signals from the new tty, so you can't debug things that require interrupts. > I hadn't tested 3.0.7 before, actually. I just took a look at it, and it > does compile, but gives a different kind of problem. Any command (even > "exit") ends up in the mini-editor until you Ctrl-C out of it, like this: > > wo1203 % ls /Cache/zsh/zsh-3.0.7 > > > > > wo1203 % exit /Cache/zsh/zsh-3.0.7 > > > > > wo1203 % /Cache/zsh/zsh-3.0.7 That indicates that your RETURN key is not sending the character that zsh has bound to the ZLE accept-line action. Zsh is supposed to map both CR and LF to the same thing on input so that this does not happen. What if you type Ctrl-J or Ctrl-M explicitly? If one of those works, what is the output you get from "stty -a" ? It may be that zsh is selecting the wrong terminal-manipulation package. grep TERM config.h might tell something. You should try running both bart-7 and 3.0.7 as "zsh +Z" to turn off the line editor, to see if the problems are related to terminal handling.