bug-bash
[Top][All Lists]
Advanced

[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: Slevin McGuigan
Subject: Re: multi-line commands in the history get split when bash is quit
Date: Mon, 07 Feb 2011 00:14:03 +0100
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7

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)



reply via email to

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