From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1606 invoked from network); 11 May 1997 05:27:14 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 11 May 1997 05:27:14 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id BAA16676; Sun, 11 May 1997 01:12:50 -0400 (EDT) Resent-Date: Sun, 11 May 1997 01:12:50 -0400 (EDT) From: "Bart Schaefer" Message-Id: <970510221515.ZM15578@candle.brasslantern.com> Date: Sat, 10 May 1997 22:15:15 -0700 In-Reply-To: <199705110314.XAA03760@hzoli.home> Comments: In reply to Zoltan Hidvegi "Re: History bug still present in 3.0.3-test5" (May 10, 11:14pm) References: <199705110314.XAA03760@hzoli.home> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Zoltan Hidvegi Subject: Re: History bug still present in 3.0.3-test5 Cc: zsh-workers@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"533S3.0.V44.HLLTp"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/3116 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On May 10, 11:14pm, Zoltan Hidvegi wrote: } Subject: Re: History bug still present in 3.0.3-test5 } } > xterm -e zsh -l } > } > and then use the window manager to kill the xterm. The $HISTFILE file will } > be truncated to zero size. } } I cannot reproduce this Linux I'm running my own compile of 2.0.28, dropped into a RedHat 4.0 installation, on a 100MHz Pentium with SCSI drives. Just in case you think that matters. } but from the backtrace you sent earlier it } seems that the problem is that first zle notices that the input is lost and } calls zexit(), and while zexit is saving the history, zsh receives the HUP } signal. It seems to be a kernel or xterm bug, since HUP should really come } before the input is lost. Here is the fix. I applied this patch and tried the xterm -e test above, and once again got a truncated-to-zero history file. So whatever is going on isn't related to this patch. And it happens with `zsh -f -l' too, so it's not some odd thing I'm doing. Here's a more complete stack trace. 3.0.3-test5 with the patch from your message applied. I only see zexit in there once, called from handler(), so I don't think zsh has seen the EOF yet. (gdb) where #0 0x8061120 in savehistfile (s=0x80efee0 "/home/schaefer/.zhistory", err=1, app=0) at ../../zsh-3.0.3-test5/Src/hist.c:1433 #1 0x8050a93 in zexit (val=1, from_signal=1) at ../../zsh-3.0.3-test5/Src/builtin.c:4640 #2 0x8070093 in handler (sig=1) at ../../zsh-3.0.3-test5/Src/signals.c:470 #3 0xbffff658 in ?? () #4 0x807dc34 in getkey (keytmout=0) at ../../zsh-3.0.3-test5/Src/zle_main.c:284 #5 0x807e505 in getkeycmd () at ../../zsh-3.0.3-test5/Src/zle_main.c:520 #6 0x807e153 in zleread (lp=0x80e67d0 "%m[%h] ", rp=0x80e67e0 "%n") at ../../zsh-3.0.3-test5/Src/zle_main.c:430 #7 0x8062ed7 in inputline () at ../../zsh-3.0.3-test5/Src/input.c:228 #8 0x8062df5 in ingetc () at ../../zsh-3.0.3-test5/Src/input.c:184 #9 0x805ec79 in hgetc () at ../../zsh-3.0.3-test5/Src/hist.c:118 #10 0x8065331 in gettok () at ../../zsh-3.0.3-test5/Src/lex.c:361 #11 0x8064ea9 in yylex () at ../../zsh-3.0.3-test5/Src/lex.c:176 #12 0x806d99c in parse_event () at ../../zsh-3.0.3-test5/Src/parse.c:59 #13 0x80616ea in loop (toplevel=1) at ../../zsh-3.0.3-test5/Src/init.c:117 #14 0x8061607 in main (argc=2, argv=0xbffff954) at ../../zsh-3.0.3-test5/Src/init.c:77 #15 0x80480eb in _start () (gdb) p t $1 = 0x0 (gdb) p ev 5 [There were only 4 events in the history. Starting from an empty history, I typed exactly 4 commands before killing the xterm. Looks like it's trying to save an event that hasn't happened yet?] -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern