From unknown Fri Jun 20 05:28:44 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#25398 <25398@debbugs.gnu.org> To: bug#25398 <25398@debbugs.gnu.org> Subject: Status: stty: bug or feature? Reply-To: bug#25398 <25398@debbugs.gnu.org> Date: Fri, 20 Jun 2025 12:28:44 +0000 retitle 25398 stty: bug or feature? reassign 25398 coreutils submitter 25398 Dave B severity 25398 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 08 13:51:59 2017 Received: (at submit) by debbugs.gnu.org; 8 Jan 2017 18:51:59 +0000 Received: from localhost ([127.0.0.1]:47111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQIZT-0006Kg-2T for submit@debbugs.gnu.org; Sun, 08 Jan 2017 13:51:59 -0500 Received: from eggs.gnu.org ([208.118.235.92]:53169) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQIOL-0004LG-OG for submit@debbugs.gnu.org; Sun, 08 Jan 2017 13:40:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cQIOF-0007eh-Lu for submit@debbugs.gnu.org; Sun, 08 Jan 2017 13:40:24 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: *** X-Spam-Status: No, score=3.3 required=5.0 tests=BAYES_50,FREEMAIL_FROM, RECEIVED_FROM_WINDOWS_HOST autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:57281) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cQIOF-0007ed-Iz for submit@debbugs.gnu.org; Sun, 08 Jan 2017 13:40:23 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44140) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cQIOE-0003lA-50 for bug-coreutils@gnu.org; Sun, 08 Jan 2017 13:40:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cQIOB-0007bw-33 for bug-coreutils@gnu.org; Sun, 08 Jan 2017 13:40:22 -0500 Received: from [217.69.47.227] (port=58860 helo=uk1mail2473.eechost.net) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cQIOA-0007bN-OE for bug-coreutils@gnu.org; Sun, 08 Jan 2017 13:40:19 -0500 Received: from [192.168.1.103] (UnknownHost [212.225.126.106]) by uk1mail2473.eechost.net with SMTP; Sun, 8 Jan 2017 18:14:46 +0000 To: bug-coreutils@gnu.org From: Dave B Subject: stty: bug or feature? Message-ID: <34e868d4-eeac-298e-ca86-25e88a6f3d39@uku.co.uk> Date: Sun, 8 Jan 2017 18:14:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 08 Jan 2017 13:51:58 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 08 15:08:37 2017 Received: (at 25398) by debbugs.gnu.org; 8 Jan 2017 20:08:37 +0000 Received: from localhost ([127.0.0.1]:47155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQJld-000384-0m for submit@debbugs.gnu.org; Sun, 08 Jan 2017 15:08:37 -0500 Received: from midir.magicbluesmoke.com ([82.195.144.46]:58980 helo=mail.magicbluesmoke.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQJlb-00037v-7B for 25398@debbugs.gnu.org; Sun, 08 Jan 2017 15:08:35 -0500 Received: from [192.168.1.80] (unknown [109.79.108.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.magicbluesmoke.com (Postfix) with ESMTPSA id 4B2029865; Sun, 8 Jan 2017 20:08:33 +0000 (GMT) Subject: Re: bug#25398: stty: bug or feature? To: Dave B , 25398@debbugs.gnu.org References: <34e868d4-eeac-298e-ca86-25e88a6f3d39@uku.co.uk> From: =?UTF-8?Q?P=c3=a1draig_Brady?= Message-ID: Date: Sun, 8 Jan 2017 20:08:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <34e868d4-eeac-298e-ca86-25e88a6f3d39@uku.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 25398 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On 08/01/17 18:14, Dave B wrote: > 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’ ) That's because your kernel doesn't carry this patch: https://lwn.net/Articles/293523/ That is available on RHEL6, though not on Centos 7 (I don't have access to RHEL7). > Plus, is the cdtrdsr parameter actually allowed to b negated, as > specified in the man pages. The man pages (and stty --help) were improved recently to not mention options not supported on the system > 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? That would be better. It's even mentioned as a FIXME: https://github.com/coreutils/coreutils/blob/229431d/src/stty.c#L1182-L1185 > 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. There seems to be some default kernel timing involved here, which might be controlled with `setserial close_delay ...`. Another option might be to hack a cable to connect DTR to CTS etc. to allow using CTS/RTS hardward flow control settings to control things? cheers, Pádraig From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 08 19:32:06 2017 Received: (at 25398-done) by debbugs.gnu.org; 9 Jan 2017 00:32:06 +0000 Received: from localhost ([127.0.0.1]:47272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQNsb-0004jN-W5 for submit@debbugs.gnu.org; Sun, 08 Jan 2017 19:32:06 -0500 Received: from midir.magicbluesmoke.com ([82.195.144.46]:60390 helo=mail.magicbluesmoke.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQNsZ-0004jE-T7 for 25398-done@debbugs.gnu.org; Sun, 08 Jan 2017 19:32:04 -0500 Received: from [192.168.1.80] (unknown [109.79.108.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.magicbluesmoke.com (Postfix) with ESMTPSA id 2E2F39865; Mon, 9 Jan 2017 00:32:00 +0000 (GMT) Subject: Re: bug#25398: stty: bug or feature? To: Dave B , 25398-done@debbugs.gnu.org References: <34e868d4-eeac-298e-ca86-25e88a6f3d39@uku.co.uk> From: =?UTF-8?Q?P=c3=a1draig_Brady?= Message-ID: <9bd374de-1f08-e8d8-f9e0-744993b21901@draigBrady.com> Date: Mon, 9 Jan 2017 00:31:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------77310AA24E09975CD049DF65" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 25398-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) This is a multi-part message in MIME format. --------------77310AA24E09975CD049DF65 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 --------------77310AA24E09975CD049DF65 Content-Type: text/x-patch; name="stty-validate.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="stty-validate.patch" >From 9c0a3a27f70bbb27e839404571922b0f8f0d48da Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Mon, 9 Jan 2017 00:07:42 +0000 Subject: [PATCH] stty: ensure no side effects from invalid options * src/stty.c (apply_settings): A new function refactored from main() that is used to both check and apply options. (main): Call apply_settings before we open the device, so all validation is done before interacting with a device. * NEWS: Mention the improvement. * tests/misc/stty.sh: Add a test case. --- NEWS | 5 + src/stty.c | 358 +++++++++++++++++++++++++++++------------------------ tests/misc/stty.sh | 8 ++ 3 files changed, 209 insertions(+), 162 deletions(-) diff --git a/NEWS b/NEWS index 9ee0c58..9e0aaf4 100644 --- a/NEWS +++ b/NEWS @@ -13,6 +13,11 @@ GNU coreutils NEWS -*- outline -*- depending on the size of the first file processed. [bug introduced in coreutils-8.24] +** Improvements + + stty now validates arguments before interacting with the device, + ensuring there are no side effects to specifying an invalid option. + * Noteworthy changes in release 8.26 (2016-11-30) [stable] diff --git a/src/stty.c b/src/stty.c index f8aefff..4f911a0 100644 --- a/src/stty.c +++ b/src/stty.c @@ -1077,143 +1077,21 @@ settings, CHAR is taken literally, or coded as in ^c, 0x37, 0177 or\n\ exit (status); } -int -main (int argc, char **argv) -{ - /* Initialize to all zeroes so there is no risk memcmp will report a - spurious difference in an uninitialized portion of the structure. */ - static struct termios mode; - - enum output_type output_type; - int optc; - int argi = 0; - int opti = 1; - bool require_set_attr; - bool speed_was_set _GL_UNUSED; - bool verbose_output; - bool recoverable_output; - int k; - bool noargs = true; - char *file_name = NULL; - const char *device_name; - - initialize_main (&argc, &argv); - set_program_name (argv[0]); - setlocale (LC_ALL, ""); - bindtextdomain (PACKAGE, LOCALEDIR); - textdomain (PACKAGE); - - atexit (close_stdout); - - output_type = changed; - verbose_output = false; - recoverable_output = false; - - /* Don't print error messages for unrecognized options. */ - opterr = 0; - - /* If any new options are ever added to stty, the short options MUST - NOT allow any ambiguity with the stty settings. For example, the - stty setting "-gagFork" would not be feasible, since it will be - parsed as "-g -a -g -F ork". If you change anything about how - stty parses options, be sure it still works with combinations of - short and long options, --, POSIXLY_CORRECT, etc. */ - - while ((optc = getopt_long (argc - argi, argv + argi, "-agF:", - longopts, NULL)) - != -1) - { - switch (optc) - { - case 'a': - verbose_output = true; - output_type = all; - break; - - case 'g': - recoverable_output = true; - output_type = recoverable; - break; - - case 'F': - if (file_name) - die (EXIT_FAILURE, 0, _("only one device may be specified")); - file_name = optarg; - break; - - case_GETOPT_HELP_CHAR; - - case_GETOPT_VERSION_CHAR (PROGRAM_NAME, AUTHORS); - default: - /* Consider "drain" as an option rather than a setting, - to support: alias stty='stty -drain' etc. */ - if (! STREQ (argv[argi + opti], "-drain") - && ! STREQ (argv[argi + opti], "drain")) - noargs = false; +/* Apply specified settings to MODE, and update + SPEED_WAS_SET and REQUIRE_SET_ATTR as required. + If CHECKING is true, this function doesn't interact + with a device, and only validates specified settings. */ - /* Skip the argument containing this unrecognized option; - the 2nd pass will analyze it. */ - argi += opti; - - /* Restart getopt_long from the first unskipped argument. */ - opti = 1; - optind = 0; - - break; - } - - /* Clear fully-parsed arguments, so they don't confuse the 2nd pass. */ - while (opti < optind) - argv[argi + opti++] = NULL; - } - - /* Specifying both -a and -g gets an error. */ - if (verbose_output && recoverable_output) - die (EXIT_FAILURE, 0, - _("the options for verbose and stty-readable output styles are\n" - "mutually exclusive")); - - /* Specifying any other arguments with -a or -g gets an error. */ - if (!noargs && (verbose_output || recoverable_output)) - die (EXIT_FAILURE, 0, - _("when specifying an output style, modes may not be set")); - - /* FIXME: it'd be better not to open the file until we've verified - that all arguments are valid. Otherwise, we could end up doing - only some of the requested operations and then failing, probably - leaving things in an undesirable state. */ - - if (file_name) - { - int fdflags; - device_name = file_name; - if (fd_reopen (STDIN_FILENO, device_name, O_RDONLY | O_NONBLOCK, 0) < 0) - die (EXIT_FAILURE, errno, "%s", quotef (device_name)); - if ((fdflags = fcntl (STDIN_FILENO, F_GETFL)) == -1 - || fcntl (STDIN_FILENO, F_SETFL, fdflags & ~O_NONBLOCK) < 0) - die (EXIT_FAILURE, errno, _("%s: couldn't reset non-blocking mode"), - quotef (device_name)); - } - else - device_name = _("standard input"); - - if (tcgetattr (STDIN_FILENO, &mode)) - die (EXIT_FAILURE, errno, "%s", quotef (device_name)); - - if (verbose_output || recoverable_output || noargs) - { - max_col = screen_columns (); - current_col = 0; - display_settings (output_type, &mode, device_name); - return EXIT_SUCCESS; - } - - speed_was_set = false; - require_set_attr = false; - for (k = 1; k < argc; k++) +static void +apply_settings (bool checking, const char *device_name, + char * const *settings, int n_settings, + struct termios *mode, bool *speed_was_set, + bool *require_set_attr) +{ + for (int k = 1; k < n_settings; k++) { - char const *arg = argv[k]; + char const *arg = settings[k]; bool match_found = false; bool not_set_attr = false; bool reversed = false; @@ -1238,8 +1116,8 @@ main (int argc, char **argv) { if ((mode_info[i].flags & NO_SETATTR) == 0) { - match_found = set_mode (&mode_info[i], reversed, &mode); - require_set_attr = true; + match_found = set_mode (&mode_info[i], reversed, mode); + *require_set_attr = true; } else match_found = not_set_attr = true; @@ -1257,15 +1135,15 @@ main (int argc, char **argv) { if (STREQ (arg, control_info[i].name)) { - if (k == argc - 1) + if (k == n_settings - 1) { error (0, 0, _("missing argument to %s"), quote (arg)); usage (EXIT_FAILURE); } match_found = true; ++k; - set_control_char (&control_info[i], argv[k], &mode); - require_set_attr = true; + set_control_char (&control_info[i], settings[k], mode); + *require_set_attr = true; break; } } @@ -1274,27 +1152,31 @@ main (int argc, char **argv) { if (STREQ (arg, "ispeed")) { - if (k == argc - 1) + if (k == n_settings - 1) { error (0, 0, _("missing argument to %s"), quote (arg)); usage (EXIT_FAILURE); } ++k; - set_speed (input_speed, argv[k], &mode); - speed_was_set = true; - require_set_attr = true; + if (checking) + continue; + set_speed (input_speed, settings[k], mode); + *speed_was_set = true; + *require_set_attr = true; } else if (STREQ (arg, "ospeed")) { - if (k == argc - 1) + if (k == n_settings - 1) { error (0, 0, _("missing argument to %s"), quote (arg)); usage (EXIT_FAILURE); } ++k; - set_speed (output_speed, argv[k], &mode); - speed_was_set = true; - require_set_attr = true; + if (checking) + continue; + set_speed (output_speed, settings[k], mode); + *speed_was_set = true; + *require_set_attr = true; } #ifdef TIOCEXT /* This is the BSD interface to "extproc". @@ -1303,6 +1185,9 @@ main (int argc, char **argv) { int val = ! reversed; + if (checking) + continue; + if (ioctl (STDIN_FILENO, TIOCEXT, &val) != 0) { die (EXIT_FAILURE, errno, _("%s: error setting %s"), @@ -1313,29 +1198,35 @@ main (int argc, char **argv) #ifdef TIOCGWINSZ else if (STREQ (arg, "rows")) { - if (k == argc - 1) + if (k == n_settings - 1) { error (0, 0, _("missing argument to %s"), quote (arg)); usage (EXIT_FAILURE); } ++k; - set_window_size (integer_arg (argv[k], INT_MAX), -1, + if (checking) + continue; + set_window_size (integer_arg (settings[k], INT_MAX), -1, device_name); } else if (STREQ (arg, "cols") || STREQ (arg, "columns")) { - if (k == argc - 1) + if (k == n_settings - 1) { error (0, 0, _("missing argument to %s"), quote (arg)); usage (EXIT_FAILURE); } ++k; - set_window_size (-1, integer_arg (argv[k], INT_MAX), + if (checking) + continue; + set_window_size (-1, integer_arg (settings[k], INT_MAX), device_name); } else if (STREQ (arg, "size")) { + if (checking) + continue; max_col = screen_columns (); current_col = 0; display_window_size (false, device_name); @@ -1345,40 +1236,183 @@ main (int argc, char **argv) else if (STREQ (arg, "line")) { unsigned long int value; - if (k == argc - 1) + if (k == n_settings - 1) { error (0, 0, _("missing argument to %s"), quote (arg)); usage (EXIT_FAILURE); } ++k; - mode.c_line = value = integer_arg (argv[k], ULONG_MAX); - if (mode.c_line != value) - error (0, 0, _("invalid line discipline %s"), quote (argv[k])); - require_set_attr = true; + mode->c_line = value = integer_arg (settings[k], ULONG_MAX); + if (mode->c_line != value) + error (0, 0, _("invalid line discipline %s"), + quote (settings[k])); + *require_set_attr = true; } #endif else if (STREQ (arg, "speed")) { + if (checking) + continue; max_col = screen_columns (); - display_speed (&mode, false); + display_speed (mode, false); } else if (string_to_baud (arg) != (speed_t) -1) { - set_speed (both_speeds, arg, &mode); - speed_was_set = true; - require_set_attr = true; + if (checking) + continue; + set_speed (both_speeds, arg, mode); + *speed_was_set = true; + *require_set_attr = true; } else { - if (! recover_mode (arg, &mode)) + if (! recover_mode (arg, mode)) { error (0, 0, _("invalid argument %s"), quote (arg)); usage (EXIT_FAILURE); } - require_set_attr = true; + *require_set_attr = true; } } } +} + +int +main (int argc, char **argv) +{ + /* Initialize to all zeroes so there is no risk memcmp will report a + spurious difference in an uninitialized portion of the structure. */ + static struct termios mode; + + enum output_type output_type; + int optc; + int argi = 0; + int opti = 1; + bool require_set_attr; + bool speed_was_set _GL_UNUSED; + bool verbose_output; + bool recoverable_output; + bool noargs = true; + char *file_name = NULL; + const char *device_name; + + initialize_main (&argc, &argv); + set_program_name (argv[0]); + setlocale (LC_ALL, ""); + bindtextdomain (PACKAGE, LOCALEDIR); + textdomain (PACKAGE); + + atexit (close_stdout); + + output_type = changed; + verbose_output = false; + recoverable_output = false; + + /* Don't print error messages for unrecognized options. */ + opterr = 0; + + /* If any new options are ever added to stty, the short options MUST + NOT allow any ambiguity with the stty settings. For example, the + stty setting "-gagFork" would not be feasible, since it will be + parsed as "-g -a -g -F ork". If you change anything about how + stty parses options, be sure it still works with combinations of + short and long options, --, POSIXLY_CORRECT, etc. */ + + while ((optc = getopt_long (argc - argi, argv + argi, "-agF:", + longopts, NULL)) + != -1) + { + switch (optc) + { + case 'a': + verbose_output = true; + output_type = all; + break; + + case 'g': + recoverable_output = true; + output_type = recoverable; + break; + + case 'F': + if (file_name) + die (EXIT_FAILURE, 0, _("only one device may be specified")); + file_name = optarg; + break; + + case_GETOPT_HELP_CHAR; + + case_GETOPT_VERSION_CHAR (PROGRAM_NAME, AUTHORS); + + default: + /* Consider "drain" as an option rather than a setting, + to support: alias stty='stty -drain' etc. */ + if (! STREQ (argv[argi + opti], "-drain") + && ! STREQ (argv[argi + opti], "drain")) + noargs = false; + + /* Skip the argument containing this unrecognized option; + the 2nd pass will analyze it. */ + argi += opti; + + /* Restart getopt_long from the first unskipped argument. */ + opti = 1; + optind = 0; + + break; + } + + /* Clear fully-parsed arguments, so they don't confuse the 2nd pass. */ + while (opti < optind) + argv[argi + opti++] = NULL; + } + + /* Specifying both -a and -g gets an error. */ + if (verbose_output && recoverable_output) + die (EXIT_FAILURE, 0, + _("the options for verbose and stty-readable output styles are\n" + "mutually exclusive")); + + /* Specifying any other arguments with -a or -g gets an error. */ + if (!noargs && (verbose_output || recoverable_output)) + die (EXIT_FAILURE, 0, + _("when specifying an output style, modes may not be set")); + + device_name = file_name ? file_name : _("standard input"); + + if (!noargs && !verbose_output && !recoverable_output) + { + static struct termios check_mode; + apply_settings (/* checking= */ true, device_name, argv, argc, + &check_mode, &speed_was_set, &require_set_attr); + } + + if (file_name) + { + int fdflags; + if (fd_reopen (STDIN_FILENO, device_name, O_RDONLY | O_NONBLOCK, 0) < 0) + die (EXIT_FAILURE, errno, "%s", quotef (device_name)); + if ((fdflags = fcntl (STDIN_FILENO, F_GETFL)) == -1 + || fcntl (STDIN_FILENO, F_SETFL, fdflags & ~O_NONBLOCK) < 0) + die (EXIT_FAILURE, errno, _("%s: couldn't reset non-blocking mode"), + quotef (device_name)); + } + + if (tcgetattr (STDIN_FILENO, &mode)) + die (EXIT_FAILURE, errno, "%s", quotef (device_name)); + + if (verbose_output || recoverable_output || noargs) + { + max_col = screen_columns (); + current_col = 0; + display_settings (output_type, &mode, device_name); + return EXIT_SUCCESS; + } + + speed_was_set = false; + require_set_attr = false; + apply_settings (/* checking= */ false, device_name, argv, argc, + &mode, &speed_was_set, &require_set_attr); if (require_set_attr) { diff --git a/tests/misc/stty.sh b/tests/misc/stty.sh index f6200e7..e549adb 100755 --- a/tests/misc/stty.sh +++ b/tests/misc/stty.sh @@ -22,6 +22,7 @@ print_ver_ stty require_controlling_input_terminal_ require_trap_signame_ +require_strace_ ioctl trap '' TTOU # Ignore SIGTTOU @@ -81,4 +82,11 @@ done stty $(cat $saved_state) +# Ensure we validate options before accessing the device +strace -o log1 -e ioctl stty --version || fail=1 +n_ioctl1=$(wc -l < log1) || framework_failure_ +returns_ 1 strace -o log2 -e ioctl stty -blahblah || fail=1 +n_ioctl2=$(wc -l < log2) || framework_failure_ +test "$n_ioctl1" = "$n_ioctl2" || fail=1 + Exit $fail -- 2.5.5 --------------77310AA24E09975CD049DF65-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 08 23:17:16 2017 Received: (at 25398) by debbugs.gnu.org; 9 Jan 2017 04:17:17 +0000 Received: from localhost ([127.0.0.1]:47328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQROW-0002E5-KX for submit@debbugs.gnu.org; Sun, 08 Jan 2017 23:17:16 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:35538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQROU-0002Dk-Dr; Sun, 08 Jan 2017 23:17:14 -0500 Received: by mail-it0-f65.google.com with SMTP id 203so4943863ith.2; Sun, 08 Jan 2017 20:17:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=HAYfebSXiXrMd23JzEo/xz3U2Rs88cjo5kqvuWyJG8M=; b=q0pag7X5v+CAFRBHgCCBZ3V6B/MhTtI00oUwt/IRhriKqQ+oSHfpeVNM4pkXTt5myM JuQax297fzW8DljE+gpE3aQMCi+9JOShOY4Z2yUXQ1bCGHl4qe/8DkU9cpbDubPphiGb JTQeX8PjMgYDjPLS07x2tPfMW/4SVtELPw+NHuSeNZjaPZbgJFgR5DIQipjHJkyYMgdJ hU07M/LbAZqgfMNJg6z8nYx8GDxDdbImFaiPcTKUsdbGeoyr+kdTZHoOJvFzoWQ+Mjls fPNe0YlQuZNkGK/zOP7S+ufREaq3G9JF9nZiBhXp8SjFWq8YO9VXwfVMsvv9kXnZEmpX z5vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=HAYfebSXiXrMd23JzEo/xz3U2Rs88cjo5kqvuWyJG8M=; b=NZUIErCpNpW8SGpgD7Gobe0VE6zIBN008jnyJeAYHdYpc15g07G2EcXhXOa87mjugN 6qfI+4PYsWEoKZVYv7aG2Q4oxtf9vQjiY98elIt6fE1z67/fDmnzY5zFJ4AcnpVoWDsR HfWs+FYa0sduPpjCuvQW9u0AeNrd+GjPZKxOgr+uaBQNlSs0lByYCp/0ECrzh37RXxS+ caJcg29RKQtVe7GV31wcrkiZ8OpYrzbgAqgN9UijP+pNN6DygxNcxL0gx7d0yrkg4rA3 9lzpRGCcSF3WwoVaul7os0tr0GSL9eTspMs7eerGSOUnb761OG6yITtubA5SQtU07VJG +1oA== X-Gm-Message-State: AIkVDXIicMHiw8ZFqoX3iFQpuBlCQRrz03YV1YmUrdWZkQz2hBKFPB5NL5cczSsg/OR9aRFRbJBaSWJM8NOQ3g== X-Received: by 10.36.5.67 with SMTP id 64mr281431itl.97.1483935428540; Sun, 08 Jan 2017 20:17:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.191.5 with HTTP; Sun, 8 Jan 2017 20:16:47 -0800 (PST) In-Reply-To: <9bd374de-1f08-e8d8-f9e0-744993b21901@draigBrady.com> References: <34e868d4-eeac-298e-ca86-25e88a6f3d39@uku.co.uk> <9bd374de-1f08-e8d8-f9e0-744993b21901@draigBrady.com> From: Jim Meyering Date: Mon, 9 Jan 2017 05:16:47 +0100 X-Google-Sender-Auth: MJduMSpOjQmDJtwMRHCaEZxOZvQ Message-ID: Subject: Re: bug#25398: stty: bug or feature? To: 25398@debbugs.gnu.org, =?UTF-8?Q?P=C3=A1draig_Brady?= , g8kbv@uku.co.uk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 25398 Cc: 25398-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On Mon, Jan 9, 2017 at 1:31 AM, P=C3=A1draig Brady wrote= : > On 08/01/17 20:08, P=C3=A1draig 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 i= n >>> force? >> >> That would be better. It's even mentioned as a FIXME: >> https://github.com/coreutils/coreutils/blob/229431d/src/stty.c#L1182-L11= 85 > > Attached patch does that. Wondered if that FIXME was mine, and it appear so, from 1998 :-) Thank you for addressing it! From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 11 06:25:19 2017 Received: (at 25398) by debbugs.gnu.org; 11 Jan 2017 11:25:19 +0000 Received: from localhost ([127.0.0.1]:49444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRH1r-0003dZ-Ka for submit@debbugs.gnu.org; Wed, 11 Jan 2017 06:25:19 -0500 Received: from midir.magicbluesmoke.com ([82.195.144.46]:41558 helo=mail.magicbluesmoke.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRH1p-0003dQ-Mt for 25398@debbugs.gnu.org; Wed, 11 Jan 2017 06:25:18 -0500 Received: from [192.168.1.80] (unknown [109.76.235.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.magicbluesmoke.com (Postfix) with ESMTPSA id 5126922A; Wed, 11 Jan 2017 11:25:16 +0000 (GMT) Subject: Re: bug#25398: stty: bug or feature? To: Dave B , 25398@debbugs.gnu.org References: <34e868d4-eeac-298e-ca86-25e88a6f3d39@uku.co.uk> <0dc9c4fb-65e7-62b9-1c0d-f13896695fde@uku.co.uk> From: =?UTF-8?Q?P=c3=a1draig_Brady?= Message-ID: Date: Wed, 11 Jan 2017 11:25:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <0dc9c4fb-65e7-62b9-1c0d-f13896695fde@uku.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 25398 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On 11/01/17 10:17, Dave B wrote: > Any idea what sort of time scale (months/years?) It may take for the fix > to propagate (if it would do that) through all the various aggregation > processes so as to appear in the regular system updates for the various > distributions of Linux? I'm fairly sure there are lots of Arduino > users out there who use Linux who would very much appreciate it too, > assuming it does fix the problem... It depends. The fix is isolated and not that risky, so would be a good candidate to backport in distros. This would be a standard procedure for them, so would be a valid request to them. thanks, Pádraig From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 11 11:26:25 2017 Received: (at 25398) by debbugs.gnu.org; 11 Jan 2017 16:26:25 +0000 Received: from localhost ([127.0.0.1]:50067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRLjF-0005H4-7f for submit@debbugs.gnu.org; Wed, 11 Jan 2017 11:26:25 -0500 Received: from [217.69.47.227] (port=62628 helo=uk1mail2473.eechost.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRFyb-0001wd-Pn for 25398@debbugs.gnu.org; Wed, 11 Jan 2017 05:17:54 -0500 Received: from [192.168.2.55] (mail.smartcitizen.net [217.41.35.220]) by uk1mail2473.eechost.net with SMTP; Wed, 11 Jan 2017 10:17:17 +0000 Subject: Re: bug#25398: stty: bug or feature? To: =?UTF-8?Q?P=c3=a1draig_Brady?= , 25398@debbugs.gnu.org References: <34e868d4-eeac-298e-ca86-25e88a6f3d39@uku.co.uk> From: Dave B Message-ID: <0dc9c4fb-65e7-62b9-1c0d-f13896695fde@uku.co.uk> Date: Wed, 11 Jan 2017 10:17:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 08/01/17 20:08, Pádraig Brady wrote: > On 08/01/17 18:14, Dave B wrote: >> 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’ ) > That's because your kernel doesn't carry this patch: > https://lwn.net/Articles/293523/ > That is available on RHEL6, though not on Centos 7 (I don't have access to RHEL7). > >> Plus, is the cdtrdsr parameter [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (g8kbv[at]uku.co.uk) -0.0 SPF_PASS SPF: sender matches SPF record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 25398 X-Mailman-Approved-At: Wed, 11 Jan 2017 11:26:23 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 08/01/17 20:08, Pádraig Brady wrote: > On 08/01/17 18:14, Dave B wrote: >> 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’ ) > That's because your kernel doesn't carry this patch: > https://lwn.net/Articles/293523/ > That is available on RHEL6, though not on Centos 7 (I don't have access to RHEL7). > >> Plus, is the cdtrdsr parameter [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (g8kbv[at]uku.co.uk) -0.0 SPF_PASS SPF: sender matches SPF record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS On 08/01/17 20:08, Pádraig Brady wrote: > On 08/01/17 18:14, Dave B wrote: >> 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’ ) > That's because your kernel doesn't carry this patch: > https://lwn.net/Articles/293523/ > That is available on RHEL6, though not on Centos 7 (I don't have access to RHEL7). > >> Plus, is the cdtrdsr parameter actually allowed to b negated, as >> specified in the man pages. > The man pages (and stty --help) were improved recently > to not mention options not supported on the system > >> 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? > That would be better. It's even mentioned as a FIXME: > https://github.com/coreutils/coreutils/blob/229431d/src/stty.c#L1182-L1185 > >> 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. > There seems to be some default kernel timing involved here, > which might be controlled with `setserial close_delay ...`. > Another option might be to hack a cable to connect DTR to CTS etc. > to allow using CTS/RTS hardward flow control settings to control things? > > cheers, > Pádraig Hi. Just catching up with this. Thanks for the prompt replies everybody, much appreciated and good to know that there is a possible fix. However, from a plain user aspect, who's had his fingers burnt trying this in the past. I'm reluctant to process patches on a working system, mainly because I haven’t a clue know how to go about doing that safely, with a get out of jail card for when it goes bad, as in a bricked OS etc. I've managed to brick things in the past trying to apply patches in the past... That, and I don't have an anyway near enough identical system to experiment on (where, when I break it, it doesn’t matter etc) to test it... Much as I'd like to. Any idea what sort of time scale (months/years?) It may take for the fix to propagate (if it would do that) through all the various aggregation processes so as to appear in the regular system updates for the various distributions of Linux? I'm fairly sure there are lots of Arduino users out there who use Linux who would very much appreciate it too, assuming it does fix the problem... Anyway, thanks again. As before, much appreciated, not that I can do much with it just now. Best Regards All. Dave Baxter (G0WBX) From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 11 14:39:01 2017 Received: (at 25398) by debbugs.gnu.org; 11 Jan 2017 19:39:01 +0000 Received: from localhost ([127.0.0.1]:50202 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cROjc-0001jk-R3 for submit@debbugs.gnu.org; Wed, 11 Jan 2017 14:39:01 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:59344) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cROjb-0001jY-8n for 25398@debbugs.gnu.org; Wed, 11 Jan 2017 14:38:59 -0500 Received: from [192.168.101.10] ([217.86.87.177]) by mrelayeu.kundenserver.de (mreue002 [212.227.15.167]) with ESMTPSA (Nemesis) id 0M48SR-1cieZE07uN-00rqPP; Wed, 11 Jan 2017 20:38:51 +0100 Subject: Re: bug#25398: stty: bug or feature? To: Dave B , =?UTF-8?Q?P=c3=a1draig_Brady?= , 25398@debbugs.gnu.org References: <34e868d4-eeac-298e-ca86-25e88a6f3d39@uku.co.uk> <0dc9c4fb-65e7-62b9-1c0d-f13896695fde@uku.co.uk> From: Bernhard Voelker Message-ID: <718de796-f042-f151-913c-501dc2e1e0cc@bernhard-voelker.de> Date: Wed, 11 Jan 2017 20:38:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <0dc9c4fb-65e7-62b9-1c0d-f13896695fde@uku.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:MPqxJ6S4raJhXuGAFhgGH7Seo9oaqRiMz6syEz4E5daKP5pUsvD cTaJhBWiCJ24Oan0sVXpr2EhYZnzWOmqk5gu12q4i6dINY6+L4xbVjgda/x2xUPTTSy2lBO M+5mFnSakreBoeWOeL7s9NHNm13+nsAHj1Xiiajy/zZadD6UAy9Xvczig3s1EPIkF+iKq+9 BiV1LVl9FaM0Xx/K2MDUg== X-UI-Out-Filterresults: notjunk:1;V01:K0:6xltmOxUQUQ=:nyAYLafKd6jqTk0BpV/q8V 1DSpKNvilEPVYTfDOhKNXyxas09id4vUIP2pwqKFLFVQkTdaJvB4d1oimk41KOcLK3eYtJFtO YB7nJcMxZ6sWh/AkShrRiLmVciOSLq/5RJuWqu5KG9cHF+7kxEjotyPaaPweoNd1yWIzqPx6i D3UQc70fK+K3NqTqe4EXnbD8UfpDNn58CIRmTWAFTJ0lB3E+Y0FwjiyBICmkx/CmBNW/Ejl6v tearGOFWat2kN+W42C96SrdvAMAso2O1qpe+2BzrlzZ1N16bmZthM3uklMjwpBkongPbbzjSB JhB66jJanLQ1I7OAT9khgru8DI4HTASO0NwNDL5ilX33DWucnSQn0TXEUAqPca3yy4JdHmWA0 j0TkJnftnoVFIChC10pO0dVoRXl7G3CROC4GKD+dTD/CGPf1bE3X6qR90R0vsWLjk4ZtCcuT0 /Z1ohZDd/1bZkZaLWJ363FaU3K8paSbhJUifyoDf8CVY/67TXbeMhhvUIDI5h5BNFv1gvLrWa 58A8h84GRNlcK68gd5d+Su31KyCmJlGqexcw+tvjl7Te9DHFQ0cjjQIgpb3c8a/uiMjyyzKdT g1eouq0YqKZ3dVxi+Tdg0Pbks92eGtVF1boYQ3Dkf1pKqRMgLUvF1ZB4gHfEMc22Zj8yOcvLv K3KQaUmNarUzb+ZR64wHG7rrTJDFOiOnrItvEg46N/MkO2EU3JN6MX2xVn/o5cI++hHqKvkoP 5SJ3laiY/yahZVWJ X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 25398 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 01/11/2017 11:17 AM, Dave B wrote: > Any idea what sort of time scale (months/years?) It may take for the fix > to propagate (if it would do that) through all the various aggregation > processes so as to appear in the regular system updates for the various > distributions of Linux? The regular way of getting this as part of a new version into a new release of your distribution greatly depends on the release cycle. Some distributions have a rolling release, some have an annual release cycle, and some even more seldom; so it could take up to ~ 2years. To get this into your distribution as a bug fix as fast as possible, you should simply open a bug report there, and point to this discussion. Have a nice day, Berny From unknown Fri Jun 20 05:28:44 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 09 Feb 2017 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator