bug#25398: stty: bug or feature?

[Dave B]

Hi.

While arranging to automate the startup and shutdown of my ham radio
station, for safe remote control use, attempting to do as much as
possible with native Linux commands and tools, I found stty has a rather
annoying "feature", or even a bug..

This is on Linux Mint, 17.2 with the Cinamon desktop environment.  Mint
18.x seems to have more serious issues, but I'm not sure if it's the OS,
PC or serial hardware on that system, hence reverting to a 17.x system.

Anyway.

After some hours experimenting, and a lot of Googling, I can see that
many others have come across the same issue, in respect to using Linux
to program and control Arduino devices, where more often than not, the
devices are reset at inapropriate times.

This is all related to the way a serial port DTR control line is
handled.   Arduino's use it as a reset line, my radio uses it as a
"Transmit" command line.

In essence..

a bash script in the form...

#!/bin/bash

stty -F /dev/ttyUSB0 57600 -hupcl crtscts cs8 -cstopb -parity
echo -n 'EX0270001;' > /dev/ttyUSB0
sleep 1s
echo -n 'PS0;' > /dev/ttyUSB0

Would once the port is open, send the command to prevent the radio from
going into transmit, wait for 1s for that to process, then send the
command to power off.   This is does..

But...

Other software that is used to do the real remote control work, PRIOR to
me wanting to shut it all down with that script, obviously sets the
serial port so that the DTR line can be used...

So, when the above script is run, DTR is immediately asserted, DESPITE
"-hupcl" being specified.  (If I try using -cdtrdsr that results
in:-     stty: invalid argument ‘-cdtrdsr’  )

Would it be possible "one day" for stty to parse the command line args,
and only open the port when all the specified parameters are actualy in
force?

Plus, is the cdtrdsr parameter actually allowed to b negated, as
specified in the man pages.

I and many have found, that if you "do something" with the port,
specifying -hucpl, as the system boots, though at that time DTR is
briefly asserted, for subsequent invocations it is not.   Unless, a
third party program or tool sets it to be used again.

Regards.

Dave Baxter.