Re: multi-line commands in the history get split when bash is quit

[Slevin McGuigan]

Hi all,

wow, that was much very much information. Thanks for all the hints and 
the discussion. Please apologize when I missed something in one of your 
comments...

My ideas/comments on what some of you wrote

Michael Witten wrote:
..
> When you quit bash, the history is stored very naively in "$HISTFILE";
> the history is simply dumped to it line-by-line, and each line of the
> file is later interpreted by a new bash instance as a complete command
> line input. Hence, the multi-line nature of your command input is lost
> between dumping it to "$HISTFILE" and later populating the history
> from "$HISTFILE".
>
Correct, thats exacly what I mean. Currently $HISTFILE is very, very 
simple (good: easy to parse etc; bad: multi-line input is lost).

I also agree with this comment of jon...

Jon Seymour wrote:
> You don't have to do that - the timestamp is encoded in a "comment"
> line between entries. See the example below. One could simply assume
> all lines between two lines beginning with # are part of the one
> entry,
>
> #1296950290
> pwd
> #1296950293
> bash -version
> #1296950327
> for i in 1 2
> do
> echo $i
> done
> #1296950337

... but I think that introducing a change which (if cmdhist and lithist 
are set) treats lines between two comments as one command would cause 
pretty many new questions and issues (and maybe bugs). Basicly I agree 
to Michael who stated that
> .. it seems like an unrobust way have handling the situation
> (both for multi-line comments and for the existing timestamp
> purposes).

And also I agree with Chet Ramey who wrote
> Any new format would have to either use some delimiter to note the
> beginning and end of the history entry -- using a timestamp which may
> or may not be present is not a good option -- or encode newlines in
> commands using some other character

> In any case, there won't be any new history file format until the
> next major bash/readline release, if it happens.

As Chet is the bash maintainer (see 
http://tiswww.case.edu/php/chet/bash/bashtop.html#Maintainer) I guess I 
will have to hope & wait for the next major release and live with my 
workaround (script in vi to replace ; with RETURN) until then. What a 
pitty...

best regards,
Slevin


PS:
what about the ksh approach? Isn't this what Chet describes as "encode 
newlines using some other character?" (by the way, thats why I miss this 
feature. I used ksh very much in my "old" HP-UX times...)
# ksh
# for KSH in K S H
do
echo $KSH
done

looks like this if I fetch it from the history
# for KSH in K S H^Jdo^Jecho $KSH^Jdone

and in the .sh_history it looks like this
# tail .sh_history
...
for KSH in K S H
do
echo $KSH
done
tail .sh_history
#


==> so, by using ^J (which is CRLF, CR, LF, whatever... some kind of 
linefeed I guess) ksh manages to get the multiline command from the 
still very, very flat and simple .sh_history file. Maybe this mechanism 
can be taken into consideration (some day)