[Top][All Lists]

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

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

From: Dennis Williamson
Subject: Re: multi-line commands in the history get split when bash is quit
Date: Sun, 6 Feb 2011 17:39:50 -0600

On Sun, Feb 6, 2011 at 5:14 PM, Slevin McGuigan
<address@hidden> 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.

reply via email to

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