bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input

[Paul Eggert]

L A Walsh wrote:


Having 'ls' show different output through a pager
than it does when scrolling off the screen is not a standard
feature


Sure it is. 'ls' has done that since then 1980s. 'ls' shows multicolumn output 
when the output is a tty, and single-column output when piped into a pager.

bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input

[L A Walsh]

Andreas Schwab wrote:

On Jan 06 2017, L A Walsh  wrote:

The new ls doesn't maintain backwards compatibility.
The default options now add extraneous quotes to
some filenames.

---

Does it?

$ touch 'a b'
$ ls -1 | grep "'"


Sorry, you are right.

The problem is 'ls' doesn't show the same
information on the screen when it is passed through
a pager like "less" or "more".  


In all but the smallest of directories, it's virtually
a requirement to page directory output using 'more' or 'less'.

Having 'ls' show different output through a pager
than it does when scrolling off the screen is not a standard
feature.  The user has no idea how to page through 'ls's 
output as they saw it scroll by on the screen.  It's 
inconsistent with any other tools that work with pagers as
well as being inconsistent with itself in how it handles 
COLOR options.


'ls' should default to its regular behavior and
only engage quoting when asked to.  


Let distros and users decide what to enable
to add new behaviors -- like the various color options.
My distro added color by default in their defaults
w/it only on when output is not a pipe.

I changed it on my machine to put out color
even if through a pipe as I usually am piping it through
'less' and I want to see the color.  If I want no color --
I can get the normal text by adding a backslash before
the command.

The new quoting also messes up copy/pasting into
any place other than the shell.  I tend to copy/paste 
between a shell and gvim when doing script development.
I wouldn't mind having such a switch as an option, 
but it is usually the case that I can copy/paste between

windows and have it pick up whether or not a tab or a space
was used.  Having tabs converted to a shell code would
prevent them being expanded anyplace but in the same shell.

Follow the example of COLOR and let users (including distros)
decide what to enable. It will let those who want such
to have it on, but not cause confusion or compatibility
problems.

bug#25398: stty: bug or feature?

[Pádraig Brady]

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

>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 +
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 (, );
-  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 

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.

bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input

[Andreas Schwab]

On Jan 06 2017, L A Walsh  wrote:

> The new ls doesn't maintain backwards compatibility.
> The default options now add extraneous quotes to
> some filenames.
>
> Anyplace one uses 'ls -1' to read 1 file/line
> now breaks.
>
> This is a regression as it breaks existing
> scripts and behavior.

Does it?

$ touch 'a b'
$ ls -1 | grep "'"

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."