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

[Dennis Williamson]

On Sun, Feb 6, 2011 at 5:14 PM, Slevin McGuigan
<slevin.mcguigan@googlemail.com> wrote:
> 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)
>
>

^J is an ASCII LF (Unix newline), CR is ^M, so CRLF is ^M^J

However, KSH uses nulls (0x00) to separate history entries. Newlines
separate the lines in a multiline command.