Re: History file clobbered by multiple simultaneous exits

[Geoff Kuenning]

I have to apologize; it's clear that we're not connecting.

I must also apologize for misunderstanding your (Linda's) role; I DO
appreciate getting suggestions and help from a bash fan regardless of
whether you're personally responsible for the code.

It's perhaps also worth mentioning that the underlying cause of the
problem isn't so much multiple windows as multiple cores; I've been
running the same multi-windowed setup for decades without trouble but
only started encountering problems when multicore machines arrived,
because it was only then that true simultaneity occurred.

Now, to clarify: the difficulty isn't that bash overwrites the history
file.  That's the default behavior, and it's to be expected.  If a user
opens three shells (in any fashion) and then successively types "exit"
in each, it's to be expected that only the last one's history would be
written to HISTFILE.  And that's what I, personally, want to happen.

But right now, if all three of those shells exit simultaneously--for
whatever reason--there is a significant probability that the history
file will end up zero-length.  That's not theoretical; I've experienced
it multiple times.  And that's a bug, plain and simple.  And I suspect
that it can be fixed on 99+% of all deployed systems by just adding
O_EXCL to the open.

It's certainly helpful to be offered 10+ line solutions to the problem
that can be adapted to my personal situation.  (Special thanks for the
pointer to HISTTIMEFORMAT; I hadn't realized that it affects the
history file and that's a _really_ cool feature!)

But it's still true that the default behavior should be reasonable, and
it's not reasonable to wipe the history file completely when there is
actually tons of history that could be saved.  Nor is it reasonable to
expect millions of bash users to edit their .bashrc to work around the
problem.

(I'll also mention that I'm not swayed by arguments of the general form
"it's really hard to do."  That argument can be justification for
putting a bug into the database and then, in extreme cases, deciding to
indefinitely postpone the fix.  But it's still a bug, and in this
situation the 99% fix is easy.)

>       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...

As did I.  As another example, we have 50+ machines in our labs.  I
might log in from pine and ten minutes later log in from oak.  I want
the history from the first to be available on the second.

This falls into the general misunderstanding I alluded to in a previous
message, i.e., assuming that one person's solution is applicable to
another's situation.  As I mentioned, I have good reasons for the setup
I use.  That's why I reported a bug rather than asking the
Google-answerable "How can I have different history for different
windows?"

> 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.

This would be where I am glaringly guilty of bad writing, because if I
had written clearly you wouldn't have said that.  I am most definitely
NOT asking for "no overwrite" behavior.  I'm just asking for "no
simultaneous opens for write"--i.e., O_EXCL.
-- 
    Geoff Kuenning   geoff@cs.hmc.edu   http://www.cs.hmc.edu/~geoff/

It's is not, it isn't ain't, and it's it's, not its, if you mean it
is.  If you don't, it's its.  Then too, it's hers.  It isn't her's.  It
isn't our's either.  It's ours, and likewise yours and theirs.
                -- Oxford University Press, Edpress News