On 20.05.2021 17:44, Janis Papanagnou wrote:
> On 20.05.2021 17:10, Ed Morton wrote:
>> On 5/18/2021 2:33 PM, Chris Roberts wrote:
>>> Using AWK, I am unable to insert a newline "\n"
>>> Nothing I try seems to work here.
>>> Not sure why it makes it all into a single line like this.
>>> Does anyone know of a simple way to fix this?
>>> And/Or an explanation?
>>>
>>> #ls -l
>>> total 276
>>> -rwxrwxrwx 1 crzzy1 crzzy1 211456 Sep 1 2020 NppToolBucket.dll
>>> -rwxrwxrwx 1 crzzy1 crzzy1 212 Sep 3 2020 backup
>>> -rwxrwxrwx 1 crzzy1 crzzy1 0 May 18 15:03 badip
>>> -rwxrwxrwx 1 crzzy1 crzzy1 1399 May 11 11:53 ccc
>>> -rwxrwxrwx 1 crzzy1 crzzy1 1622 Nov 2 2020 ccclab
>>> -rwxrwxrwx 1 crzzy1 crzzy1 2217 May 7 13:09 cccp
>>>
>>> #a=`ls -l | awk '{print $8"\n"}'
>>> #echo $a
>>> 2020 2020 15:03 11:53 2020 13:09
>>
>> Copy/paste your 2-line script into http://shellcheck.net and it'll tell
>> you what the problems are with it.
>
> Isn't the shell-checker's suggestion:
> "Use find instead of ls to better handle non-alphanumeric filenames."
> rather strange (to say the least)?

Another interesting test case is replacing the 'ls' by a 'ps' command;
the tool doesn't see any problems with parsing 'ps' output.

But suggesting 'find', in the first place, is already quite arguable;
find produces other output. You have to define e.g. -maxdepth, then
the list of files needs additional post-processing, one might want to
get rid of the '.' directory, the spurious './' file path prefixes
needs handling, and last but not least is 'ls' output sorted, but not
'find's, and the shell coder (novice or else) might be just wondering.

> (Shouldn't a shell-checker focus on the shell and not on used external
> or compound commands? That it obviously cannot semantically grasp.)
>
> Janis
>
>>
>> Ed.
>>
>

In article <s8ac15$kfg$1@news-1.m-online.net>,
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>On 22.05.2021 07:59, some weirdo wrote:
>> On 5/21/2021 7:20 PM, Janis Papanagnou wrote:
>>> On 22.05.2021 01:36, Kenny McCormack wrote:
>> <snip>
>>>> It also complains about things like:
>>>>
>>>> gawk '{ print $1 }'
>>
>> Not it doesn't.
>
>I haven't verified Kenny's example, but I've just tried the statement
>
> gawk "{ print $1 }"
>
>which also gives no warning.

It turns out that shellcheck does, indeed, "know" about "awk" (and "gawk")
as being "special". So, Janis is correct - that invoked as "gawk", it
doesn't complain. However, as it happens, in my coding environment,
whenever I invoke AWK, it is as "gawk4" and, not surprisingly, shellcheck
doesn't recognize that as being a flavor of AWK.

Which is a long-winded way of saying that if you try the above example
using, say, "gawk4", instead of just plain "gawk", it (shellcheck) *will*
flag it.

So, what it boils down to is: Should a tool like shellcheck "know" about
the semantics of the things we generally call "shell tools" (things like
AWK, ls, find, Perl, etc) ? On the one hand, aesthetically, the answer to
this should be "no", because it just feels like a "slippery slope". This
seems to be Janis's position (his original objection to the tool telling
you to use "find" instead of "ls"). Intuitively, the tool *should* be
agnostic w.r.t. choice of tools. I think we can all agree on this -
intuitively.

However, on the other hand, we can all recognize that the usefulness of the
tool is greatly diminished if it doesn't have such knowledge. This seems
to be the position held by that other poster. And, in fact, this is the
position I originally espoused, w.r.t. AWK - that shellcheck *should*
understand about AWK command line scripts and realize that they are
generally single (not double) quoted for a good reason.

Which it, in fact, does. Provided you invoke AWK via a recognized command
name (a set of which "gawk4" is, alas, not a member).

P.S. All comments by in regards to the shellcheck tool are based on my
experience with the normal, downloadable version - which I have used on
some of my own scripts. I have no knowledge or experience with any
"online" version. I assume, however, that they are basically the same.

--
Men rarely (if ever) manage to dream up a God superior to themselves.
Most Gods have the manners and morals of a spoiled child.