Re: [4.0.2 bug] commands not written to history

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

[Moved to zsh-workers]

On Jul 21,  3:44pm, Vincent Lefevre wrote:
} Subject: Re: [4.0.2 bug] commands not written to history
}
} This problem occurred again, but this time with a local FS [...]
} Moreover, the command I got after cmd1 was "startx", which means that
} cmd2 (the command that hadn't been written to the history) was the
} last command typed in the shell, like in my previous bug report.

Something that just occurred to me:  You're sure that `cmd2' has run to
completion and the prompt has returned before the shell where you typed
that command exited?  E.g. you didn't type `cmd2' and then while it was
still running, shut down your X server or kill the xterm window?

Here's what you should try next:

Make a directory ~/zhist-debug (call it whatever you like).

Put in your .zshrc the commands:

	date > ~/zhist-debug/startup.$$
	TRAPEXIT() {
	  # Order here is important!
	  fc -WI ~/zhist-debug/unsaved.$$
	  fc -W ~/zhist-debug/complete.$$
	  # This assumes you have GNU `cp'
	  cp -p $HISTFILE ~/zhist-debug/histfile.$$
	}

If there is a `startup' file with none of the other files, then zsh may be
exiting without writing the history at all, which shouldn't matter with
INC_APPEND_HISTORY but might be a clue all the same.

Because zsh writes the history before calling TRAPEXIT, the `unsaved' file
should always be empty.  If it is not, then INC_APPEND_HISTORY is causing
an error when the history is written at exit time.

For the same reason, the modify time of the `histfile' file (copied from
$HISTFILE by `cp -p') should be EARLIER THAN the modify time of the
`complete' file.  If it isn't, then multiple shells are writing to the
histfile almost simultaneously (e.g., because you killed your entire X
session rather than exiting from each individual shell), so zsh may have
a locking problem.  (Note that if you exit from a lot of shells at once,
even if locking is working properly the order in which $HISTFILE gets
updated will be essentially random; obtaining the lock is a race.)

My guess is that `startx' is being inserted into $HISTFILE by your console
login shell at the time the `startx' command finishes, i.e., after all the
xterm shells have shut down.  So none of the `histfile' files except the
one for the console shell should have the `startx' command at the end.  If
`startx' appears near the end of more than one of those files, then the
problem may be that the console shell is incrementally appending `startx'
to $HISTFILE before all the exiting xterm shells have finished saving their
own commands, thus garbling the expected ordering.

If none of these races happened, then the `complete' file should have the
same last $HISTSIZE entries (assuming SAVEHIST > HISTSIZE) as the `histfile'
file, possibly modulo incrementally saved entries from other shells which
may have been in $HISTFILE.  Any unexplained differences may give us a clue.

Finally, by examining the file times of the various files we can tell in
what order the shells are starting and exiting, which may help determine
what sequence of events causes the error.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net