Adding logging to file feature

[GoogleCodeExporter]

I use picocom often and it was missing a small feature for my use. It would be 
very handy to be able to have a log of the communications that go through the 
cable.

It will be useful for those who use many different systems and that the output 
of the terminal is the only way to gather data about that system.

Original issue reported on code.google.com by casat...@gmail.com on 15 Jan 2014 at 8:08

Attachments:

• log_file_feature.diff

[GoogleCodeExporter]

Just tried this patch and it works great! Is there any particular reason why 
the log files get created as executable though? IMHO they should just be rw 
rather than rwx.

Does the last picocom update being 2 years ago ( 
https://code.google.com/p/picocom/source/list ) imply that picocom is now a 
dormant project, and so this logging feature will never make it into a standard 
build? :-(

Original comment by gc...@loowis.durge.org on 28 Feb 2014 at 12:54

[GoogleCodeExporter]

Picocom with logging feature works splendidly!  Thanks.
Kirby

Original comment by dingq...@gmail.com on 19 Nov 2014 at 6:21

[npat-efault]

As I see you only log what you read from tty_fd. What about the stuff you write to tty_fd? What if local echo is enabled, or not? Needs more thought.

[q2dg]

The thing is it would be really great if picocom had an option similar to -C (--capturefile) from minicom

[shepmaster]

One workaround is to use tee:

picocom /dev/cu.usbmodem1411 | tee my-log

[JoeMerten]

I currently use linux script command for logging picocom communication, but it has the drawback that my logfile also contains all the settings output an startup and the Thanks for using picocom message at the end.

I'd now merged the above mentioned log_file_feature.diff into my repo (Joe-Merten/picocom) and it works great. So I also decide to provide a pull request for this.

Btw: minicom don't write tx data to the logfile, but it logs local echo.

[npat-efault]

I would consider a PR for logging with the following features:

• An option for specifying the log-file name: --logfile. Default value picocom.log. Consider: If exists, file should be opened in append mode (??).
• An option to control what should be logged; input (from serial), output (to serial), or both. Something like: --log i (=input) | o (=output) | b (=both) | n (=none / default)
• Logging write()s should happen immediately after writing to the port (picocom.c:1201) and/or after reading from the port (picocom.c:1187). Output logging should be done after performing ouput-maping, and input logging after performing input-mapping.

[JoeMerten]

I'll vote for the following behavior:

• --logfile <filename> without additional --log <mode> should behave similar to e.g. minicom:

  • Logging all uart input (before input mapping). Main reason: If my counterpart sends <LF> lineends, then I have to call picocom with --imap lfcrlf to get correct lineends displayed on my linux console. But if my device sends <LF>, I dislike <CR><LF> in my logfiles.
  • Logging of console input (which will be transmitted via serial port) only, if local echo is enabled. This might be done after mapping to have the real TX data in the logfile.

• Always appending to an existing logfile.

• Regarding your --log <mode> option:

  • Default logfile name to picocom.log unless --logfile <filename> has been specified.
  • Need to define what input means: Either input from console or input from serial.
    Assuming that input means: Received input from serial.
  • About the mode:
    • --log i (=input): Logging all data received from serial port, not more or less.
    • --log o (=output): Logging all data transmitted to serial port, not more or less.
    • --log b (=both): Logging both.
    • --log d (=default): Like described above; Logging all data received from serial port but also TX data if local echo is on.
    • --log n (=none): Don't log anything (really needed?).
  • Note, that I currently don't have a real use case for those --log <mode>, but I'll implement it if you want. The default behavior is IMHO the most important logging feature.

[npat-efault]

Let me think about it...

[npat-efault]

Ok, I see your point! A single --logfile option should be enough:

--logfile: Use specified file for logging (recording) serial input, and possibly serial output. If the file exists, it is appended to. Every character read from the serial port is written to the specified file (before input mapping is performed). If local-echo mode is is enabled (see --echo option and C-c command), then every character written to the serial port (after output mapping is performed) is also logged to the same file.

The only question is: Is it possible that someone might need to log output-to-serial even if local-echo is not enabled? And: Is it possible that someone might not want to log output-to-serial even if local-echo is enabled? For both questions the answer seems to be: It's very unlike. So if the need arises in the future (most likely, it won't), we can then provide extra options to modify the behavior.

Agree?

[JoeMerten]

Agree, keep it simple, for the first. I'll provide a new PR soon.

[JoeMerten]

could be closed now, isn't it?