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
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.
For some systems (OSes, versions, architectures) custom-baudrate
support is enabled by default.
For others, support may work, but must be enabled by defining
USE_CUSTOM_BAUD in the Makefile
You can also disable custom baudrate support altogether (even for
systems where it's enabled by default), by defining NO_CUSTOM_BAUD in
the Makefile
Introduced `#define HAS_CUSTOM_BAUD` for platforms which have appropriate implementation.
Moving that `#if defined(__linux__) && defined(USE_CUSTOM_BAUD)` ... stuff out of `term.c`and put it to `termios2.h` / `custbaud_bsd.h` headers.
Moving that platform specific `#ifdefs` to the platform specific headers helps removing duplicate complex `#ifdef` constructs.
The both platform specific headers then do `#define HAS_CUSTOM_BAUD` to signal that custom baudrate support is implemented for the target platform.
I'd tested all above mentioned platforms with both USE_CUSTOM_BAUD unset and set to check if that refactoring don't raises unexpected issues.
If given together with **--noreset**, picocom will not reset the serial
port to it's original settings on exit, but it *will* clear the modem
control lines (typically DTR and RTS) to signal a modem hangup. Without
the **--noreset** option (explicitly given, or implied by extiting with
the "Quit" command) **--hangup** has no effect (without **--noreset**
picocom always clears the modem control lines on exit, anyway).
term_flush() does not work with some drivers. If we try to drain or even
close the port while there are still data in it's output buffers *and*
flow-control is enabled, we may block forever. So we "fake" a flush, by
temporarily setting f/c to none, waiting for any data in the output
buffer to drain, and then reseting f/c to it's original setting.
If picocom exits due to an "Exit" or "Quit" command, the contents of the
output queue (data read from the terminal but not written to the port)
are, anyway, discarded. Because of this, there is no reason to wait for
the O/S output buffer (data already written to the port but not
transmitted) to drain before exiting. The output port (output buffer) is
instead flushed (data discarded) before exiting due to a command.
Picocom will always set the HUPCL control bit of the serial port,
according to the --noreset option. If --noreset is given, then
HUPCL for the port is cleared, and will remain so after exiting
picocom. If --noreset is *not* given, then HUPCL is set for the
port, and will remain so after exiting picocom. This is true, regardless
of the way picocom terminates (command, read zero-bytes from standard
input, killed by signal, etc), and regardless of the --noinit
option. If picocom exits with the "Quit" command, then --noreset is
assumed given. Almost always this is the most DWIM behavior.
Fixes#72
Exit picocom immediatelly after opening and configuring the serial
port. Do *not* read *anything* from the standard input or from the
serial port. If an init string is also given, picocom exits imediatelly
after sending (writing) the init string to the serial port. Again,
nothing is read from the standard input, or from the serial port. The
ouput map, the local echo option, and the local-echo map are observed
when sending the init string. The **--exit** option, overrides
the **--exit-after** option.
- Allow stdin to be a non-tty (print a warning, though). Some things may
not work as expected in this case, but most will, and it's useful in
several occasions.
- If picocom reads zero bytes from stdin, then:
- If --exit-after is set, then keep operating (without reading from
stdin) until the idle timeout expires, or we are killed by a signal
- Otherwise, exit picocm, but only after transmitting the contens of
the output queue.
Suppress picocom from printing initial greetings banners and other
messages not explicitly requested by the user. Command responses and
errors or warnings are still printed.
