Some libc implementations (e.g. musl) do not define the cispeed and
cospeed struct termios fields. So we have to check the
_HAVE_STRUCT_TERMIOS_C_ISPEED and _HAVE_STRUCT_TERMIOS_C_OSPEED
macros. If not defined, we disable custom baudrate support.
The completion script tries to remove (not suggest) mappings you have
already specified. This must not happen for the currently under
completion (i.e. last) mapping (if it matches a specifier). Example: If
you try to complete "lfcr" (no blank of comma at the end) then the list
of possible completions must still include "lfcr" along with
"lfcrlf". If not, readline will replace the current word with "lfcrlf",
which is wrong
If picocom is compiled *with* custom-baudrate support (USE_CUSTOM_BAUD)
for Linux, then it uses a new set of ioctl's (TCGETS2 vs TCGETS, etc) to
access the serial ports. This patch allows the custom baudrate support
to be disabled at runtime (without recompiling), and picocom to switch
to using the old ioctl's.
To disable custom baudrate support (and switch back to the "old" ioctls)
simply define the environment variable NO_CUSTOM_BAUD, before starting
picocom.
This applies only to Linux and, obviously, only when picocom has been
compiled with custom baudrate support (USE_CUSTOM_BAUD).
Allow more than one non-option arguments. Use the last one as the port
name, ignore others.
Rationale. Allow easily setting a default port using an alias or
script. The port can then be overriden by a subsequent argument. E.g.
alias picocom='picocom -b 115200 /dev/ttyS0'
picocom <-- call with default port
picocom /dev/ttyUSB0 <-- override default
Call flock(fd, LOCK_UN) explicitly for managed file at term_exitfunc().
This should, normally, not be necessary. Normally, exiting the program
should take care of unlocking the file. Unfortuntelly, it has been
observed that, on some systems, exiting or closing an flock(2)'ed tty fd
has peculiar side effects (like not reseting the modem-control lines,
even if HUPCL is set).
Set the levels of DTR and RTS modem-control lines (according to the
--lower/raise-dtr/rts command-line options) *twice*: Once
immediatelly (as quickly as possible) after opening the port (before
actually configuring it), and once after configuring it. On some systems
configuring the port (i.e. calling tcsetattr) has the effect of reseting
the DTR and RTS signals.