Sujet : Re: Over-Elaborate Shell Scripting
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.unix.shellDate : 23. Mar 2024, 07:52:29
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <utlu7f$3gail$1@dont-email.me>
References : 1
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 23.03.2024 06:38, Lawrence D'Oliveiro wrote:
When using a computer, laziness is a virtue. This is why we have
command lines, to help automate the boring and repetitive tasks.
This article
<https://arstechnica.com/gadgets/2021/09/command-line-wizardry-part-two-variables-and-loops-in-bash/>
(Not really sophisticated written shell code samples.)
It seems his focus was about "Variables and loops in Bash", though,
not primarily about ZFS output parsing. (He could certainly have
chosen another example and solution.)
continues the author’s intro to basic command-line concepts. But it
repeats a failing I see all too often in shell scripting: doing complex
parsing of the output of some command, when the command itself offers an
option to produce something closer to the exact output you need.
In this case, he is extracting the names of datasets from the “zfs
list” command. And while I have zero experience with ZFS, I can look at
documentation
<https://docs.oracle.com/cd/E18752_01/html/819-5461/gazsu.html>, and
discover that the command offers the “-o” option where you can select
exactly that information you want it to output. It even has “-H” to
simplify the output format right down, specifically to make it easier
to parse.
Sure, it’s fun to write code. But it can be even more fun to _avoid_
writing code. RTFM helps.
Yes.
But it also makes sense to remind the tool developers of their duties!
I recall the first sensible tool to follow (or invent?) the option for
output format definition to have been AIX's 'ps' command; that was in
the early 1990's. Since then at times only few tools followed that path.
IMO such an option (where appropriate) should be standard.
It's even worse where the same attribute changes its format, depending
on other conditions, like 'ls' time information depending on file age;
meanwhile there were some also non-standard approaches to handle that
(like GNU's 'ls --full-time', which is certainly not a handy format but
at least provides a consistent output).
Some commands change output format depending on the locale; which may
also be an issue for tools that don't consider that.
Janis