[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input
From: |
L A Walsh |
Subject: |
bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input |
Date: |
Mon, 09 Jan 2017 13:22:09 -0800 |
User-agent: |
Thunderbird |
Eric Blake wrote:
On 01/09/2017 02:35 PM, L A Walsh wrote:
I also stand for it being strongly against GNU
standards to add more such behaviors.
'ls' did not recently add any more cases where tty output differs from
non-tty output when all other things are equal in the default state.
All that changed was that tty output is formatted differently than it
has been in the past.
----
That is not the case.
Created dir with common files w/spaces in them from people's
Doc dirs. I also replaced the space in "My Pictures w/a tab to
see the effect -- though it wasn't necessary.
ls
All Settings My Pictures Show Desktop.scf browser - logitech
Bluetooth Software My Documents Start Menu
Local Settings Saved Games Virtual Machines
Then I did ls the standard way:
All Settings
Bluetooth Software
Local Settings
My Pictures
My Documents
Saved Games
Show Desktop.scf
Start Menu
Virtual Machines
browser - logitech
===
And quoted way:
'All Settings'
'Bluetooth Software'
'Local Settings'
'My'$'\t''Pictures'
'My Documents'
'Saved Games'
'Show Desktop.scf'
'Start Menu'
'Virtual Machines'
'browser - logitech'
I cut & pasted into bash, and read them into array vars using
readarray -t std
<paste>
<ctl-d>
and the same for the quoted version but
to "readarray -t quoted".
Now I look for the files 1 at a time in a loop:
First old way (using -gG to shorten line):
-rw-rw-r-- 1 0 Jan 9 13:06 All Settings
-rw-rw-r-- 1 0 Jan 9 13:06 Bluetooth Software
-rw-rw-r-- 1 0 Jan 9 13:06 Local Settings
-rw-rw-r-- 1 0 Jan 9 13:06 My Pictures
-rw-rw-r-- 1 0 Jan 9 13:06 My Documents
-rw-rw-r-- 1 0 Jan 9 13:06 Saved Games
-rw-rw-r-- 1 0 Jan 9 13:06 Show Desktop.scf
-rw-rw-r-- 1 0 Jan 9 13:06 Start Menu
-rw-rw-r-- 1 0 Jan 9 13:06 Virtual Machines
-rw-rw-r-- 1 0 Jan 9 13:06 browser - logitech
---
And now the new way that you claim is "the same output":
ls: cannot access 'All Settings': No such file or directory
ls: cannot access 'Bluetooth Software': No such file or directory
ls: cannot access 'Local Settings': No such file or directory
ls: cannot access 'My'$'t''Pictures': No such file or directory
ls: cannot access 'My Documents': No such file or directory
ls: cannot access 'Saved Games': No such file or directory
ls: cannot access 'Show Desktop.scf': No such file or directory
ls: cannot access 'Start Menu': No such file or directory
ls: cannot access 'Virtual Machines': No such file or directory
ls: cannot access 'browser - logitech': No such file or directory
your claim that ls' behavior is non-standard has been proven to be
false; I quoted the line from POSIX that explicitly permits ls
---
By permitting it as an exception, you are admitting it
is non-standard compared to other programs.
implementation-defined behavior when outputting to a terminal, and if it
is permitted by the standard, then the behavior can't be considered
non-standard. It may not be what you want, but that does not make it
non-standard.
---
Now you are excluding a fact. POSIX _does_ state that the output of
'ls' when targetting a tty is implementation-defined,
---
I'm not quoting posix -- I'm quoting the GNU
standards you mention.
Anyway, as demonstrated above, the output is not the same and
varies based on whether or not the destination is a tty.
Your claim that the output is the same is demonstrably false.
They are not functionally equivalent.
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, (continued)
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Paul Eggert, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Paul Eggert, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Eric Blake, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Paul Eggert, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Eric Blake, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input,
L A Walsh <=
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Eric Blake, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Eric Blake, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Pádraig Brady, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Eric Blake, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Eric Blake, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09