Dear GNU Coreutils maintainers,
I am writing to propose a backward-compatible enhancement that could
improve modern scripting enviroments while maintaining complete
compatiblily with existing workflows without any impact on performance. PROBLEM:
Although the output of coreutils are meant to be human readable
only, many scripts today use/pipe them to other commands for various
kinds of automation. This leads to brittle solutions involving
complex awk/sed/grep gymnastics that break when the output format
changes slightly. While "everything is text" philosophy has served GNU/Unix/Linux well, structured data processing has become important in
modern computing.
Even Microsoft people recognized this more than 20 years ago and added
built in structured output into MS Powershell from day one completely eliminating text parsing entirely. Cloud tools like Docker, kubectl, MS
Github, Google Gcloud and increasing number of cli tools are providing
JSON output options as flags, as well as shells like Nushell, who have reimplemented most of the coreutils to output structured data. This is
not unpresidented in the industry.
PROPOSAL: stdoutm and stderrm
I would like to propose the addition of two new optional machine
readable output streams (in addition to already present human readable streams):
- stdout (fd 1): human readable output
- stderr (fd 2): human readable errors
- stdoutm (fd 3): machine readable output (NEW)
- stderrm (fd 4): machine readable errors (NEW)
The machine readable output format and conventions needs to be
established. JSON is the most obvious choice with battle-tested parsers
and tools, and immediately available for the scripting ecosystem. This
could be implemented incrementally, starting with "high-usage" commands
like (ls, ps, df, du) and then gradually expand coverage.
If the structured output is generated only when fd3/4 are open, there
should be not performance penalty and all existing behavior will
identical. It also doesn't require any flags or arguments.
EXAMPLES:
# Traditional usage - UNCHANGED
ls -l
# Structured output
ls 3>&1 1>/dev/null > metadata.json
# Structured output scripting
ls 3>&1 1>/dev/null | fx 'this.filter(x => x.size > 1048576)'
ls 3>&1 1>/dev/null | jq '.[] | select(.size > 1048576)'
# Traditional brittle approach (unreadable)
ls -la | awk '$5 > 1048576 {print $9}' | grep -v '^d'
# Structured error handling
find / -name "*.txt" 4>&1 3>/dev/null | jq '.[] | select(.error == "EACCES")'
This eliminates unreliable fragile regex based approaches, provides
structured error handling, integrated with already present tools like
fx, jq and python scripts making sure existing scripts are not affected
at all (while gradually transitioning to structured output).
Would the maintainer team be interested in discussing further?
Thank you for your time and considerations.
Annada
--- Synchronet 3.20a-Linux NewsLink 1.2

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

I like this idea, Annada :-) .

=2D-=20
The pioneers of a warless world are the youth that
refuse military service. ~ Albert Einstein

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJKBAEBCgA0FiEEOVeKaEm0xBhCsMmYlk/BEMQK1XUFAmhEXloWHGtleWJvYXJk YW5AdGlsZGUuY2x1YgAKCRCWT8EQxArVddKWEAC9ENyToucDnj7ivsXc+MO+xlVk l9bgt4of02W7eWS5RQ/ViqVPA9D2oF6j4iv4mz48Pm/Q9Ye1K6qfCTUoLuTPBBdS 8N4YGXq670x4o/jVsr5Emk/MYLa2SQK7jw7zYCKgfrjAikBI1O0hbvePg4qMAqTt 7KtkAxRmtl6VlaxdjkAR2WLSqf5LqAmGOviBH1oMgHZjGx0JDZ07+Nb8tn/B2Kyv pGYU7/gDwHbJ89ysT/t8aPINRrUX2/dzoShuEEPjjuFv3euO3NwZfnfMHFUof3Tt 0jmD8Hirh9adQjTrJqhWtztCBRSuyuKMmWhm0YPgHmWZCEmlY1COl2zO3ue98poo Z/HedA21KsL/HrVu0FJj3KiWbsORJYhZ7fsbWezsXdojW5/ZL/0Mr0oJ5a+rcISB BAU75Yb+Cxh09ynHsAJoCC1aZn7Zz7wIxFiEaEDIEt+equbY+VFS920WK/7lra5W 9xTVcauX0yQFDiuIFizZWelBZNNCcCgeYzePWQE3EFEVfafccAWPd387wxWSrIEA xBFgnOAOYLUpCr5aNih2RFV10omv6XV2V98jLBPMXc6MjN09qPUu/1htTn8lHW9A FL79fqPeSlnvhro9I6OCxUsNU5q8PTeS7Z6QhjduXYBZI28xseru8aHj/s5MNzLS 9X9ytzH4zsEFz3Tmcw==
=tYMW
-----END PGP SIGNATURE-----
--=-=-=--
--- Synchronet 3.20a-Linux NewsLink 1.2