Adding logging to file feature about picocom HOT 12 CLOSED

One workaround is to use tee:

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

from picocom.

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

from picocom.

could be closed now, isn't it?

from picocom.

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

from picocom.

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 [email protected] on 28 Feb 2014 at 12:54

from picocom.

Picocom with logging feature works splendidly!  Thanks.
Kirby

Original comment by [email protected] on 19 Nov 2014 at 6:21

from picocom.

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.

from picocom.

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.

from picocom.

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.

from picocom.

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.

from picocom.

Let me think about it...

from picocom.

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?

from picocom.