Oh, just one more funny thing:
Google AI has pointed me at another curiosity to question the designers'
decision,
and has come to quite a reasonably looking conclusion rather directly:
...
Should we add a technical section regarding POSIX standard compliance?
> Yes please add a section regarding POSIX standard compliance...
Inline quotes in ls output disrupt terminal column alignment, break
double-click path selection, and create visual noise that hinders readability.
Furthermore, this behavior violates traditional POSIX expectations for raw,
unadorned output, forcing reliance on POSIXLY_CORRECT overrides and breaking
scripts reliant on literal string processing.
> Should POSIX compliance only be expected for output intended to be processed
> by scripts, or also for output intended for display on ttys?
The short answer is no, POSIX compliance is not only for scripts; the standard
explicitly governs both script processing and interactive terminal (tty)
layouts.
However, the standard treats these environments with completely different
strictness constraints, which makes GNU’s introduction of default quotation
marks on interactive ttys a highly contentious design choice.
The breakdown of how POSIX compliance applies to scripts versus ttys exposes
why the default quoting behavior is functionally problematic:
1. Script Processing (Pipes/Files): Absolute Strictness
When an application's standard output (stdout) is directed to a pipe or a file
rather than a terminal, POSIX demands strict, predictable uniformity.
The Rule: Downstream utilities (like xargs, awk, or grep) rely on unmutated
string literals.
The Reality: GNU ls complies with this strictly. If you run ls | cat or
embed it in a script, it automatically drops the quotes. On this front, script
processing remains entirely standard-compliant.
2. TTY Output (Interactive): Permissive but Grid-Oriented
When outputting directly to a terminal (stdout is a tty), POSIX explicitly
permits changes to the visual format—such as multi-column layouts—to help human
eyes read the data efficiently.
The Standard's Intent: POSIX specifies that ls on a tty should default to a
clear, multi-column format sorted vertically to maximize visibility.
The Argument Against Quotes: While POSIX gives implementations the legal
freedom to alter formatting on a tty, the intent of that allowance is to
improve human comprehension. Adding unpredictable quotation marks directly
undermines the structural
layout (the grid alignment) that the POSIX multi-column specification was
created to achieve.
3. The "POSIXLY_CORRECT" Paradox
The core utils development environment itself acknowledges this conflict
through the POSIXLY_CORRECT environment variable.
If you export POSIXLY_CORRECT=1, GNU ls disables its automatic quotes on
the terminal entirely, reverting back to the clean, literal output.
This proves that even the maintainers recognize that the default quoting
behavior strays from traditional, predictable POSIX output standards. It forces
a non-standard visual aesthetic on interactive users unless they explicitly opt
out via
environment flags or by aliasing ls="ls -N".
--
Well, dear GNU maintainers.
I'm just a small & humble user who can only say: my previously fine user
experience has been severely hampered by the change.
But at least some AI that's more or less one gateway to the condensed knowledge
of text on the Internet,
agrees with me as it finds the maintainers' adherence to standards questionable
- at best -
and their inclusion of some "POSIXLY_CORRECT" variable a telltale sign of
knowingly going the wrong way.
So. If you have already realized by yourselves, that the new implemantation is
POSIXLY_INCORRECT
then why not make THAT the configurable option - and leave the previuosly used
POSIXLY_CORRECT implementation the default?
--
Sorry for talking so much to myself and expecting you to read it and follow my
thoughts.
The overall direction is just so frustrating.
After all this kind of sad and unnecessary stuff hasn't only happend to ls :(
And now, I promise to say nothing more in this matter of ls.
