bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: History file clobbered by multiple simultaneous exits


From: Linda Walsh
Subject: Re: History file clobbered by multiple simultaneous exits
Date: Thu, 18 Jul 2013 02:18:46 -0700
User-agent: Thunderbird



Geoff Kuenning wrote:
address@hidden wrote:
        Locking should be used when truncating and writing the history
        file.  (Yes, I know it's a pain in a portable program like
        bash.)

        What might be cooler would be to merge all the history lines
        from all shells, in timestamp order.  But given the current
        history file format, that seems...hard.
----
You shouldn't write to the same history file from multiple
sessions.  Encode the session name (or ttyname) in the history file name
Then they won't collide as you can only have 1 person logged in / tty.

Sigh.

Bug reporter: "Program X doesn't work correctly when used in perfectly
reasonable fashion Y--which happens to be the default."
----
Bug reporter is using a program that's *history system( developed for 
single-user,
single-processor, non-networked computers.

But reporter doesn't realize that the tools are in place for them
to work around it, or they can' ask that some elaborate complex system
of locking that won't be portable to all the systems bash runs on, be
created, when you can get 99% of the way their by using some variation
on the method I suggested.  Actually, I use the hostname and the tty name
as part of my bash history file name.  If you are on the same host+tty with
multiple instances... you are asking alot for a basic shell, but fine,
add in the pid as well.

you can add in whatever makes it uniq in your environment.

There were some people on here that shared their ways of auto-combining history
files -- removing duplicates, sorting them and keeping a uniq history log going 
back
multiple years that was loaded and reused in each of their new bash sessions.

They did all this without locking.

It's in the archives.  The history log is a convenience.  If you want history
as an auditing feature, then bash isn't the right tool -- but a session recorder
like is built in to 'sudo', that will record every keystroke -- now there, as
sudo is making itself out to be an uber-security tool, you'd have a basis for
complaining that it is a bug if they didn't get it right.  But w/bash, it's just
that some overly complex locking system hasn't been implemented for the rare
cases that can't be solved with normal scripting.




Maintainer: "You shouldn't do Y.  I don't do Y, therefore nobody else
should do Y either, they should go out of their way and do Z instead.  I
don't want to fix the incorrect behavior even though it can happen in
many situations."
-----
        *LOL*... I'm the one always pointing out things that are breaking
or broken when things change, or that don't work -- I'm not a maintainer.

        Have you looked at the bash code?  It's scary -- hard coded
constants and gnu-braindead tabbing... Ug...

        I'm was just pointing out as another user who has had
problems with colliding histories -- and I was usually able to work around them.



It's normal to open multiple windows.  By default, bash writes to
~/.history.  Furthermore, for perfectly good reasons I want all my
sessions to write to--and more importantly, to read from--the same
history file.
----

        I use multiple windows too:  Try this in your .profile:

  ((HISTFILESIZE=HISTSIZE=2**30))
  TTY=$(command -p tty)
  TTY_NAME=${TTY##/dev/}
  export HISTSIZE HISTFILESIZE
  export HISTFILE=~/.hist${HOSTNAME}_$TTYNAME
  export HISTCONTROL="erasedups"
  export HISTTIMEFORMAT="address@hidden: "
  if [ ! -d ${_local_dir:=`dirname $HISTFILE`} ] ; then
    if [ ! -e $_local_dir ]; then
      echo "Created .hist dir, $_local_dir"
      mkdir -p $_local_dir || \
        echo "ERROR creating $_local_dir"
    fi
  fi
  unset _local_dir
  set  +o histexpand
  shopt -s cmdhist histappend histverify lithist histreedit


And in this the case the suggested workaround is loaded with flaws.  For
example, it's quite easy to be logged in to the same filesystem multiple
times under the same tty name.  (Think NFS.)
----
        Loaded with flaws?  You've mentioned one that my default
system wouldn't have a problem with.  I just simplified my mention
in a quick note...


The correct response to a valid bug report isn't "go away and change
your behavior."  It's to fix the bug.

----
You are asking for new behavior -- that's asking for a new feature.
If you can find where bash says it *won't* overwrite files if you write to the 
same
name, they you'd have a case for calling it a bug, but bash has never had
such a feature, thus calling it a bug is specious at best.  New feature, yet,
bug... stretching the word.

If you tried to put this feature into bash, (if you want to submit a patch,
PLEASE don't make it on by default, cuz locking on windows and NFS can
get real hairy and bash might end up suffering performance probs or
hanging due to lock contention -- unlikely, but then I've never heard of
anyone having _major_ problems with history file contention either.  So,
ya never know.

Check the archives, though .. I'm probably more like you than you might
think -- I have a long history of pointing out problems -- some of which
I become convinced were ill conceived, and others of which I don't and don't
let go of easily.

How often do you think your history files collide and how easy would it be
to come up with a workaround like the above .. vs. implementing a locking
solution that would work across all the platforms and file systems that
bash runs on?...   The latter might never be done to perfection, the former
can be done to your satisfaction.

It would be a good idea -- having it automerge history as well, but
it's alot of work for not alot of pay-off and thus it doesn't sound
practical..?


Hey... you work with multiple windows... do you ever cut & paste
from one to another?  or cut/past code from an editor into bash
to try it out while you are creating it?  Does your code have tabs
in it?

Did you know bash used to have, effectively, no_empty_line_completion,
vs. now having no_empty_cmd_completion, which isn't close to the same
thing?   Now since that *used* to work but broke when people wanted
completion to work in the middle of continued command lines, that, I'd
call a bug.  Or the one...nevermind, I'd be here all night.

cheers!
;-)

BTW -- the HISTTIMEFORMAT--- that gives you your ability to sort the 
timestamps...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]