Description of problem: tcsh often empties its ~/.history file... Version-Release number of selected component (if applicable): > tcsh --version tcsh --version tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-unknown-linux) options wide,nls,dl,al,kan,rh,color,filec How reproducible: sporadic (once a day) - i dont know why... settings: > set | grep hist histdup erase history 1000 savehist (1000 merge) Steps to Reproduce: 1. start csh and tcsh via gnome-terminal and crontab Actual results: after some time (funnily about at 09:00UTC the 2nd time) the ~/.history file has 0 bytes length... Expected results: the ~/.history file should keep the last 1000 unique commands "in mind"... :-) Additional info: maybe there is insufficient locking, when 2 tcsh sessions end the same time?
i just had a look at the tcsh src code and found that the authors r aware of this bug (they suggest to do certain things (open, create, dump) atomically)... a fix seems to be complicated (e g dosource() doesnt allow a "do it atomically" parameter)... :-) i wasnt aware of that RHEL-5 bug report... maybe i should have waited just some years longer (that bug is very ooooold)... :-)) sorry for the trouble... -arne
As you said - to do that atomically is not so easy - and authors are aware of the issue. Vojta is new tcsh maintainer and he is now trying to make a patch and propose it to upstream (independently on this report) ... so hopefully it's not a matter of years...
Hopefully not :)
i made a workaround: (a little blunt *blush* but it works) > grep histfile .cshrc set histfile=`/usr/local/bin/csh-hist-workaround.sh $$` > cat devel/chw/csh-hist-workaround.sh #!/bin/sh # $Id$ cd /tmp lockfile history.lock touch history.fst ls -tr history.[1-9]*.?????????? 2> /dev/null | \ while read f ; do pid=`echo $f | sed -e 's:^history\.::' -e 's:\..*::'` if pgrep tcsh | fgrep -q $pid ; then continue fi if [ -f history.fst ] ; then rm history.fst mv $f history else cat $f >> history rm $f fi done fn=`mktemp /tmp/history.$1.XXXXXXXXXX` if [ -f history ] ; then cp history $fn fi rm -f history.fst rm -f history.lock echo -n $fn > -arne
it should be grep -q ^$pid'$' instead of fgrep -q $pid -arne
here is an update of the workaround (its disk complexity is slightly better): lockfile /tmp/history.lock set histfile=`mktemp /tmp/history.$$.XXXXXXXXXX` set history=2000 set histdup=erase set savehist=(2000 merge) test -f /tmp/history && history -L /tmp/history foreach f ( `ls -tr /tmp/history.[1-9]*.??????????` ) >& /dev/null history -M $f history -S /tmp/history test -e /proc/`echo $f | sed -e 's:^/tmp/history\.::' -e 's:\..*::'` || rm -f $f end rm -f /tmp/history.lock -arne
i found a further optimization: lockfile -1 /tmp/history.lock set history=2000 set histdup=erase set savehist=(2000 merge) test -f /tmp/history && history -L /tmp/history set hsn="" foreach f ( `ls -tr /tmp/history.[1-9]*.??????????` ) >& /dev/null test -e /proc/`echo $f|sed -e 's:^/tmp/history\.::' -e 's:\..*::'` && continue history -M $f rm -f $f set hsn=1 end set histfile=`mktemp /tmp/history.$$.XXXXXXXXXX` test -z "$hsn" || history -S /tmp/history rm -f /tmp/history.lock -arne
Arne, thank you for your help. Unfortunately, we can't use such workarounds as a final solution.
Created attachment 530274 [details] solution that needs an additional lock file i found a new workaround... it uses an additional lockfile, because: dosource (or so) seems to drop the lock to the history file...
Created attachment 562503 [details] fcntl .history file locking - shared readers, exclusive writer
congratulations! looks like a voluminous fix... :-) but it is more elegant with a lock on the history file... (i mean: an extra file (like in my workaround) is quite clumsy...) -arne
Fixed in Rawhide. Builds for stable Fedora releases coming probably with few other fixes..
(In reply to comment #13) > congratulations! > looks like a voluminous fix... :-) > but it is more elegant with a lock on the history file... > (i mean: an extra file (like in my workaround) is quite clumsy...) Thanks Arne! And thank you again for your help, I really appreciated that.
oops it still happens that the .history file is empty... i think it happens when the X session is killed (e. g. with ctrl+alt+backspace)... is it possible, that tcsh doesnt ignore signals during saving history? or does it get a SIGKILL (which cant be ignored IIRC) (but why does it delete the history file then)? currently i use tcsh.x86_64 (6.17-18.fc17)...
Arne, I'm going to release new tcsh Fedora builds with the latest .history file locking changes that came from the RHEL-6 QA/testing phase. Stay tunned for the new builds - I'd be happy to hear your feedback then again.
oh - ok - i thought the fix would be part of fc17 already... :-) -arne
is it fixed in tcsh.x86_64 6.17-18.fc17? i lost my history file again...
did the patch reach fc18? or what does "status: MODIFIED" mean? i had to switch to bash, because: tcsh continued to destroy my .history file...
Vojtech no longer maintains the package, I moved it to current maintainer.
Hi, the patch made by Vojtech is not in f17, only in f18.