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/>
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.

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

On Sat, 23 Mar 2024 07:52:29 +0100, Janis Papanagnou wrote:

> But it also makes sense to remind the tool developers of their duties!

Some tools offer the option of JSON output. And there is “jq” for
performing manipulations on such JSON streams
<https://manpages.debian.org/1/jq.en.html>.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> This article
> <https://arstechnica.com/gadgets/2021/09/command-line-wizardry-part-two-variables-and-loops-in-bash/>
> continues the author’s intro to basic command-line concepts. But it
> repeats a failing I see all too often in shell scripting:

Here's another thing I often see in web writers. If they're teaching
you something, there's a high probability they have just learned it---or
so they think they did.

On 3/23/24 00: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.

Yes.

> This article
> <https://arstechnica.com/gadgets/2021/09/command-line-wizardry-part-two-variables-and-loops-in-bash/>
> 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.

Keep in mind that some such authors have been working with a command for
a very long time and that there is chances that the command has evolved
since they started using it.

Once a process has been learned, it is slow to evolve until it no longer
works properly.

> Sure, it’s fun to write code. But it can be even more fun to _avoid_
> writing code. RTFM helps.

I'm the epitome of lazy Unix admin. I try to avoid doing things,
especially repetitive things, if I can. I'd much rather spend some time
streamlining -> automating something if I know that I'm going to end up
doing it many times.

But, sometimes it's also good to go through an exercise. Especially if
some of those exercises are to teach / refresh someone, possibly
yourself, on a concept that they aren't as fresh on as they possibly
want to be.

--
Grant. . . .

On 3/23/24 04:34, Johanne Fairchild wrote:
> Here's another thing I often see in web writers. If they're teaching
> you something, there's a high probability they have just learned
> it---or so they think they did.

I don't have any problem with "Hey, look what I just learned!" type
articles.

I do object when such articles are disguised as experts in the subject.

--
Grant. . . .

Grant Taylor <gtaylor@tnetconsulting.net> writes:

> On 3/23/24 04:34, Johanne Fairchild wrote:
>> Here's another thing I often see in web writers. If they're
>> teaching you something, there's a high probability they have just
>> learned it---or so they think they did.
>
> I don't have any problem with "Hey, look what I just learned!" type
> articles.

On the contrary---we encourage such articles.

> I do object when such articles are disguised as experts in the subject.

Indeed. More often than not (of course), many such bloggers actually
think that they know what's going on. So on average the web is a poor
source of the information.

On 23.03.24 19:19, Grant Taylor wrote:
> On 3/23/24 00: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.
>
> Yes.
>
>> This article
>> <https://arstechnica.com/gadgets/2021/09/command-line-wizardry-part-two-variables-and-loops-in-bash/> 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.
>
> Keep in mind that some such authors have been working with a command for
> a very long time and that there is chances that the command has evolved
> since they started using it.

Keep also in mind that MAYBE not all incarnations of a command may have
this feature, so resorting to a generic solution that works on all
versions of the command may be a virtue.

Josef

On 3/24/24 13:30, Josef Moellers wrote:
> Keep also in mind that MAYBE not all incarnations of a command may have
> this feature, so resorting to a generic solution that works on all
> versions of the command may be a virtue.

Yep.

Keeping (some) scripts portable has virtue.

But not all scripts need to be portable.

Scripts managing systesmd almost certainly won't be used on non-Linux
systems. ;-)

--
Grant. . . .

On Sun, 24 Mar 2024 19:30:44 +0100, Josef Moellers wrote:

> ... MAYBE not all incarnations of a command may have
> this feature ...

Except this particular “feature” came from a single vendor, who developed
all the associated tooling as well.