Hello Michael The previously embedded lines (the for loop) now have got a timestamp (the > one from the shell start?)! > This is unwanted behavior, because now a cursor-up brings the separated > lines. >
More precisely, any history read from a history file will *not* be in "command-oriented" mode. Command-oriented history has only ever applied to commands in the current session; history files are not written in a format that facilitates reading and separating multi-line commands from it. We can't rely on the timestamp lines to separate commands, because they are only written into the history file when HISTTIMEFORMAT is set. (Even if it's set *now*, that doesn't necessarily mean it was set when the history file was written.) Re-parsing compound commands as they're read from the history file could be done, but it would excruciatingly slow, and would still be unreliable since parsing commands accurately requires knowing what aliases were in effect at the time. Anything else would require some (new?) marker to be written into history files even when they're timestamped. I've encountered the same limitation myself. But to be honest, I run so many shells in parallel that re-loading the history from previous shells is rarely useful. Rather, I tend to simply grep for the relevant line(s) in my actual history file. My own fix was to write a script that runs at log-out and edits the history file to convert the embedded newlines into semicolons. -Martin