GNU bug report logs -
#25398
stty: bug or feature?
Previous Next
Reported by: Dave B <g8kbv <at> uku.co.uk>
Date: Sun, 8 Jan 2017 18:52:02 UTC
Severity: normal
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#25398: stty: bug or feature?
which was filed against the coreutils package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 25398 <at> debbugs.gnu.org.
--
25398: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=25398
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
On 08/01/17 20:08, Pádraig Brady wrote:
> On 08/01/17 18:14, Dave B wrote:
>> 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 actually in
>> force?
>
> That would be better. It's even mentioned as a FIXME:
> https://github.com/coreutils/coreutils/blob/229431d/src/stty.c#L1182-L1185
Attached patch does that.
cheers,
Pádraig
[stty-validate.patch (text/x-patch, attachment)]
[Message part 5 (message/rfc822, inline)]
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.
This bug report was last modified 8 years and 132 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.