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