Shell log output contains unwanted characters

[Chris Jones]

Good morning,

I've been trying to log (Shell -> Log -> Start/Stop) an iTerm2 ssh
session to a server but when I go to display the output in a text editor
it contains all sorts of additional characters such as ^M & ^H making
the log illegible. I'm using version 1.0.0.20120724.

Any help is appreciated.

Cheers,
-Chris

[George Nachman]

If you don't want to see the control codes, your best bet is to select the text you want and choose shell->save selected text.

[Marko Milivojevic]

I think he brings up a valid point though. Sometimes we just want to
log the session as we go through it. It would be a good thing to have
an options for "filtered" log.

-Marko.

[George Nachman]

Good point. Please file a feature request. The only trick is that the logs couldn't actually be written until the window closes or logging stops.

[Rick Hornsby]

> On Mon, Dec 24, 2012 at 12:09 PM, Chris Jones <jo...@chrisdavid.ca> wrote:
>>
>> Good morning,
>>
>> I've been trying to log (Shell -> Log -> Start/Stop) an iTerm2 ssh
>> session to a server but when I go to display the output in a text editor
>> it contains all sorts of additional characters such as ^M & ^H making
>> the log illegible

Chris,

Alternatively, write yourself a sed filter.  It's pretty easy.  I'm in the middle of some family things atm, but I could whip something up for you later tonight or tomorrow.

The noise you're seeing are control characters mostly from your terminal colors (colored ls output etc) and cursor position manipulation.

On Dec 24, 2012, at 15:55, George Nachman <gnac...@llamas.org> wrote:

Good point. Please file a feature request. The only trick is that the logs couldn't actually be written until the window closes or logging stops.

I like the idea of a built-in filtering mechanism.  However, there is risk inherent in waiting for a finished and done event before writing anything to disk.  For example, there is a long-standing(?) nasty kernel bug recently discussed here (more than once I'm sure) where OSX crashes. Your current session logs would almost certainly be completely gone.

A bunch of Linux systems I manage (and need to fix) are currently set up badly and won't log the bash history until the shell exits cleanly - ie the logout event. Haven't had time to dig into why, but this is really irritating when a wifi drop kills the ssh session -> no logs.

-rick

Sent from my iPhone

[George Nachman]

A sed script could handle some of it, but a regex that parses out all control codes would be pretty complicated.

Good point. Please file a feature request. The only trick is that the logs couldn't actually be written until the window closes or logging stops.

I like the idea of a built-in filtering mechanism.  However, there is risk inherent in waiting for a finished and done event before writing anything to disk.  For example, there is a long-standing(?) nasty kernel bug recently discussed here (more than once I'm sure) where OSX crashes. Your current session logs would almost certainly be completely gone.

A bunch of Linux systems I manage (and need to fix) are currently set up badly and won't log the bash history until the shell exits cleanly - ie the logout event. Haven't had time to dig into why, but this is really irritating when a wifi drop kills the ssh session -> no logs.

The problem is that you can always make your window bigger and change something that used to be in scrollback history! Once a log is written, it is forever, but the data is always mutable (in the limit).