On Sat, 21 Dec 2024 08:13:52 -0600, Ed Morton wrote:

> for anything else you should just use awk ...

If you want to suggest Awk, you might as well use Perl. That does
everything Awk does, just as concisely, and plenty more besides.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 21.12.2024 13:17, Salvador Mirzo wrote:
[...]
> As previously mentioned, 'sed' might not be the best choice for
> developing such scripts; you might want to consider to learn 'awk'.
>
>> $ git log --oneline | head -1 | awk '{print $1}'
>> 2566d31
>
> With Awk you don't need 'head', it can be done like this
>
> $ git log --oneline | awk 'NR==1 {print $1}'
>
> (For long input files you may want an early exit
> ...| awk 'NR==1 { print $1 ; exit(0) }'
> but that just as an aside.)
[...]

This raises another issue: it's often possible to replace a command in a
pipeline that filters output with an option to the command that does the
same thing. There's no general rule for how to do this, since different
commands do things differently, but for the example above:

git log --oneline -n 1 | awk '{print $1}'

or even:

git log -n 1 --format=%h

I haven't memorized the "--format" option, so I don't generally us it in
ad-hoc one-liners, but I do use it in scripts. Note both of the above
commands avoid generating the entire list of log entries, which could
save significant time on a large repo.

Using unnecessary commands in pipelines is Mostly Harmless, but IMHO
it's good to think about how to do things more efficiently. See also
"Useless use of cat" (UUOC).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

In article <20241220184059.820@kylheku.com>,
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>> The goal of writing in sed is not to solve the problem, and to
>> communicate with
>> future users of the program so that they can adapt it to changing needs; the
>> goal is to puzzle out what it takes to solve it in Sed, and to show: "Hey,
>> look, I did this in Sed! Isn't it amazing? (And, by extension, aren't I?)"

Just like APL.
- "can you figure out what this one-line program does?"
- "can you think of a way to do this in fewer characters?"

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 21.12.2024 15:38, Janis Papanagnou wrote:
>> On 21.12.2024 04:57, Kaz Kylheku wrote:
>>>
>>> Sometimes that puzzled out stuff people do in their spare time is really cool!
>>>
>>> This just appeared on HackerNews:
>>>
>>> https://github.com/izabera/pseudo3d
>>>
>>> A raycast first-person maze navigator, written in Bash.
>>
>> Wasn't there a similar code in Awk mentioned some time ago?
>
> I found it (fps.awk) on my file system; ~650 LOC - too long to post?
> (I see it uses some GNU Awk features.)
> To support searches for it, it says: #Copyright (c) 2016 Fedor Kalugin

https://github.com/patsie75/awk-fps

I don't think this is the same thing; there's no copyright and the file
names don't match.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On 21.12.2024 23:23, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 21.12.2024 15:38, Janis Papanagnou wrote:
>>> On 21.12.2024 04:57, Kaz Kylheku wrote:
>>>>
>>>> Sometimes that puzzled out stuff people do in their spare time is really cool!
>>>>
>>>> This just appeared on HackerNews:
>>>>
>>>> https://github.com/izabera/pseudo3d
>>>>
>>>> A raycast first-person maze navigator, written in Bash.
>>>
>>> Wasn't there a similar code in Awk mentioned some time ago?
>>
>> I found it (fps.awk) on my file system; ~650 LOC - too long to post?
>> (I see it uses some GNU Awk features.)
>> To support searches for it, it says: #Copyright (c) 2016 Fedor Kalugin
>
> https://github.com/patsie75/awk-fps

It's something different. - But thanks for the link!

> I don't think this is the same thing; there's no copyright and the file
> names don't match.

I don't know the original filename; I might have changed it on download.

I've put the source version I meant here: volatile.gridbug.de/fps.awk

Janis

On 21.12.2024 22:41, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 21.12.2024 13:17, Salvador Mirzo wrote:
> [...]
>> As previously mentioned, 'sed' might not be the best choice for
>> developing such scripts; you might want to consider to learn 'awk'.
>>
>>> $ git log --oneline | head -1 | awk '{print $1}'
>>> 2566d31
>>
>> With Awk you don't need 'head', it can be done like this
>>
>> $ git log --oneline | awk 'NR==1 {print $1}'
>>
>> (For long input files you may want an early exit
>> ...| awk 'NR==1 { print $1 ; exit(0) }'
>> but that just as an aside.)
> [...]
>
> This raises another issue: it's often possible to replace a command in a
> pipeline that filters output with an option to the command that does the
> same thing. There's no general rule for how to do this, since different
> commands do things differently, but for the example above:
>
> git log --oneline -n 1 | awk '{print $1}'

Yes. - I just used the OP's presented sample to show the principle
(and not make up an own example to illustrate the case).

In practice it goes even farther; with Awk typical pipeline command
sequences that use utilities like cat, head, tail, grep, cut, sed,
tr, wc, seq, tee, etc. can typically all be represented and combined
by Awk. There's also the additional effect that if you want to pass
some context information from a tool near the front of the pipe to
a tool near the other end it's possible to maintain arbitrary state
information within the Awk program.

Of course, if you can _reduce_ the amount of data at an early stage
(like in your 'git -n 1' sample) the earlier the better! (My 'git',
BTW, doesn't seem to support an option '-n'; which might be another
reason to let a standard tool like Awk do the task for which it has
been defined, text-processing.)

>
> or even:
>
> git log -n 1 --format=%h
>
> I haven't memorized the "--format" option, so I don't generally us it in
> ad-hoc one-liners, but I do use it in scripts. Note both of the above
> commands avoid generating the entire list of log entries, which could
> save significant time on a large repo.
>
> Using unnecessary commands in pipelines is Mostly Harmless, but IMHO
> it's good to think about how to do things more efficiently. See also
> "Useless use of cat" (UUOC).

Janis

On 21.12.2024 22:09, Lawrence D'Oliveiro wrote:
> On Sat, 21 Dec 2024 08:13:52 -0600, Ed Morton wrote:
>
>> for anything else you should just use awk ...

(I wouldn't formulate it that way. - Just for the record.)

> If you want to suggest Awk, you might as well use Perl.

(Unfortunately no.)

> That does
> everything Awk does, just as concisely, and plenty more besides.

(Features are not the whole story.)

The advantage of Awk is that it's standard on Unix systems and can
thus also be used in restricted professional environments (that are
not uncommon as I experienced).

There's yet more advantages, like (compared to Perl) legible syntax
and being a terse language that you can quickly learn (and master).
(I've elsethread mentioned R.Loui's examination of learning curves;
he compared Perl and Awk in that respect, and Perl was, expectedly,
much worse concerning that.)

I know you're a fan of Perl, so I finish my post with the comment
that Perl has other strengths. (Or Python, or <insert your favorite
tool here>, etc.)

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
> Of course, if you can _reduce_ the amount of data at an early stage
> (like in your 'git -n 1' sample) the earlier the better! (My 'git',
> BTW, doesn't seem to support an option '-n'; which might be another
> reason to let a standard tool like Awk do the task for which it has
> been defined, text-processing.)

What version of git are you using?

Note that "-n 1" is an argument to "git log", not to "git".
"git -n 1" is an error, as is "git -n 1 log". "git log -n 1" should work.

The "-n" option can also be given as just the number:

git log -1

or as a long option:

git log --max-count=1

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On Sun, 22 Dec 2024 01:02:03 +0100, Janis Papanagnou wrote:

> The advantage of Awk is that it's standard on Unix systems ...

On my Debian system:

ldo@theon:~> apt-cache rdepends gawk | wc -l
89
ldo@theon:~> apt-cache rdepends perl | wc -l
1121

Let’s just say, you’re more likely to find Perl than Awk on a Linux
system ...

On Sun, 22 Dec 2024 00:50:45 +0100, Janis Papanagnou wrote:

> In practice it goes even farther; with Awk typical pipeline command
> sequences that use utilities like cat, head, tail, grep, cut, sed, tr,
> wc, seq, tee, etc. can typically all be represented and combined by Awk.

Another counterexample to the hoary old “do one thing and do it well”
trope ...

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sun, 22 Dec 2024 01:02:03 +0100, Janis Papanagnou wrote:
>> The advantage of Awk is that it's standard on Unix systems ...
>
> On my Debian system:
>
> ldo@theon:~> apt-cache rdepends gawk | wc -l
> 89
> ldo@theon:~> apt-cache rdepends perl | wc -l
> 1121
>
> Let’s just say, you’re more likely to find Perl than Awk on a Linux
> system ...

I don't see how your conclusion follows from the data (of how many
packages depend on gawk and perl, respectively). I'd be surprised to
see *any* Linux distribution (other than small embedded systems) that
doesn't include awk (either gawk or mawk, or even busybox awk) by
default.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On 22.12.2024 01:26, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> [...]
>> Of course, if you can _reduce_ the amount of data at an early stage
>> (like in your 'git -n 1' sample) the earlier the better! (My 'git',
>> BTW, doesn't seem to support an option '-n'; which might be another
>> reason to let a standard tool like Awk do the task for which it has
>> been defined, text-processing.)
>
> What version of git are you using?
>
> Note that "-n 1" is an argument to "git log", not to "git".

Stupid me! - Of course. I need some coffee...

Janis

> [...]

Kaz Kylheku wrote:
> On 2024-12-21, Ralf Damaschke <rwspam@gmx.de> wrote:
>> Simply because you cannot imagine how to use it? No!
>
> He explained the "because", in the immediately following text that you
> snipped:

I don't agree with his explanation.

> KMC> Seriously, the above looks like gobbledegook compared to the
> equivalent in
> KMC> AWK (or some other normal scripting langugae). "sed" looks like
> Intercal
> KMC> (once you get beyond s/foo/bar/g).

For many people C looks like gobbledegook, too.

> KMC> I'm sure that whatever it is that OP is trying to do, it could be
> easily
> KMC> translated to (say) AWK and look much nicer.

That's probably true. I often prefer awk too, but that is not sufficient
to state "don't use sed for anything beyond the s/foo/bar/g stage". There
have been quite some tasks where I used sed.

On 22.12.2024 01:31, Lawrence D'Oliveiro wrote:
> On Sun, 22 Dec 2024 00:50:45 +0100, Janis Papanagnou wrote:
>
>> In practice it goes even farther; with Awk typical pipeline command
>> sequences that use utilities like cat, head, tail, grep, cut, sed, tr,
>> wc, seq, tee, etc. can typically all be represented and combined by Awk.
>
> Another counterexample to the hoary old “do one thing and do it well”
> trope ...

I'm not quite sure what you're aiming at with your statement.

My own stance on that is that this "do one thing and do it well”
is okay in principle, but it's also no dogma for me. - It still
holds in many places.

There's some tools, though, that stuff all sorts of functions
into its own feature set that aren't appropriate. (I had a good
example but it evades me at the moment. - Where's my coffee?! -
Anyway, you may have observed your own examples.)

For the given discussion, Awk's "one thing" is text-processing.
OTOH, 'cut', for example, does one [very primitive] thing, but
it _completely_ *fails* to do it well.

The point is that a pipeline is a very restricted way of data
processing and it quickly turns out in non-trivial applications
that you have your data-processing task split into "elementary
operations" that you clumsily have to glue together with shell,
and some things just can't be reasonably done that way.

I still use 'head' or 'tail' (or even 'cat') if I want to get
a quick look onto some data - I certainly don't use Awk for
that. But as soon as many of your "elementary operations" get
combined (which often can be anticipated) using a better tool
might be appropriate (Awk, Perl, Python, whatever one thinks
fits best).

It's good that we have tools like, e.g., 'sort'. And I'm not
very excited about, say, GNU Awk's various sort() functions.
(But they might come in handy in cases.)

In short; it's good to use the appropriate tools, notice if
tools get worse at certain jobs, and change if necessary.

Janis

In article <vk7ar2$7g01$4@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sat, 21 Dec 2024 08:13:52 -0600, Ed Morton wrote:
>
>> for anything else you should just use awk ...
>
>If you want to suggest Awk, you might as well use Perl. That does
>everything Awk does, just as concisely, and plenty more besides.

So does Intercal. Point, set match.

--
There are many self-professed Christians who seem to think that because
they believe in Jesus' sacrifice they can reject Jesus' teachings about
how we should treat others. In this country, they show that they reject
Jesus' teachings by voting for Republicans.

On 22.12.2024 01:28, Lawrence D'Oliveiro wrote:
> On Sun, 22 Dec 2024 01:02:03 +0100, Janis Papanagnou wrote:
>
>> The advantage of Awk is that it's standard on Unix systems ...
>
> On my Debian system:
>
> ldo@theon:~> apt-cache rdepends gawk | wc -l
> 89
> ldo@theon:~> apt-cache rdepends perl | wc -l
> 1121
>
> Let’s just say, you’re more likely to find Perl than Awk on a Linux
> system ...

My comment was on Unix systems (not specifically Linux) and on
the Unix standards (POSIX).

Not sure what you read and understood where I wrote "standard".

Awk is demanded by POSIX, Perl isn't.

So on any standard conforming Unix you are guaranteed to *have*
a 'sh' (POSIX-shell) and an 'awk'. Moreover, even if you are
developing on a system with Perl, but will have to implement
(run) the software in a different environment, you may not be
allowed to install third party software (open or else) with it.

(One may not like such company policies but they are reality.)

Janis

On Sat, 21 Dec 2024 16:36:32 -0800, Keith Thompson wrote:

> I'd be surprised to
> see *any* Linux distribution (other than small embedded systems) that
> doesn't include awk (either gawk or mawk, or even busybox awk) by
> default.

The point being, it would likely be easier to remove Awk than to remove
Perl.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sat, 21 Dec 2024 16:36:32 -0800, Keith Thompson wrote:
>> I'd be surprised to
>> see *any* Linux distribution (other than small embedded systems) that
>> doesn't include awk (either gawk or mawk, or even busybox awk) by
>> default.
>
> The point being, it would likely be easier to remove Awk than to remove
> Perl.

Which is quite different from what you wrote, which was that "you’re
more likely to find Perl than Awk on a Linux system".

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On Sat, 21 Dec 2024 21:09:25 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Sat, 21 Dec 2024 16:36:32 -0800, Keith Thompson wrote:
>>
>>> I'd be surprised to
>>> see *any* Linux distribution (other than small embedded systems) that
>>> doesn't include awk (either gawk or mawk, or even busybox awk) by
>>> default.
>>
>> The point being, it would likely be easier to remove Awk than to remove
>> Perl.
>
> Which is quite different from what you wrote, which was that "you’re
> more likely to find Perl than Awk on a Linux system".

You do know that Linux systems encourage customization, don’t you?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sat, 21 Dec 2024 21:09:25 -0800, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Sat, 21 Dec 2024 16:36:32 -0800, Keith Thompson wrote:
>>>> I'd be surprised to
>>>> see *any* Linux distribution (other than small embedded systems) that
>>>> doesn't include awk (either gawk or mawk, or even busybox awk) by
>>>> default.
>>>
>>> The point being, it would likely be easier to remove Awk than to remove
>>> Perl.
>>
>> Which is quite different from what you wrote, which was that "you’re
>> more likely to find Perl than Awk on a Linux system".
>
> You do know that Linux systems encourage customization, don’t you?

I can no longer keep up with the rapid movement of the goalposts.
I see no point in continuing this discussion.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On Fri, 20 Dec 2024 15:55:12 +0100, Janis Papanagnou wrote:

> you may get subtle errors in future if you continue that habit.

For us newbies, do you have an example?

--
Order! Order in the group!

On 22.12.2024 10:19, Ordatious wrote:
> On Fri, 20 Dec 2024 15:55:12 +0100, Janis Papanagnou wrote:
>
>> you may get subtle errors in future if you continue that habit.
>
> For us newbies, do you have an example?

(I had to look up what in my post you were referring to here...)

It was about -lt vs '<' in comparisons of strings and numbers
respectively. - And I had already answered that elsethread.

Depending on the actual value in a string variable you may get
_correct looking_ result for many values but since you're not
using the correct operator you "unexpectedly" may see errors
that you "can't explain".

The OP was comparing the number of arguments against a value
of 2 with the string comparison. Try (for example) the code

for i in a b c d e f g h i j k l m n o p q r s t u v w x y z
do
set $@ $i
if [ $# '<' 2 ]
then echo "$# < 2"
else echo "$# >= 2"
fi
done

and observe the output

1 < 2
2 >= 2
3 >= 2
4 >= 2
5 >= 2
6 >= 2
7 >= 2
8 >= 2
9 >= 2
10 < 2
11 < 2
12 < 2
13 < 2
14 < 2
15 < 2
16 < 2
17 < 2
18 < 2
19 < 2
20 >= 2
21 >= 2
22 >= 2
23 >= 2
24 >= 2
25 >= 2
26 >= 2

So for "typical" argument numbers <=9 you get the correct result,
but once you have more arguments with this program, or if you
have wrongly used '<' in another program that expects "naturally"
more arguments than the OP's sample program you'll get erroneous
behavior (and might not be aware of that if you're used to using
'<').

It makes thus no sense to use the wrong operator only because it
*sometimes* works correctly even for numeric arguments.

HTH.

Janis

On 2024-12-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 21 Dec 2024 08:13:52 -0600, Ed Morton wrote:
>
>> for anything else you should just use awk ...
>
> If you want to suggest Awk, you might as well use Perl. That does
> everything Awk does, just as concisely, and plenty more besides.

Perl certainly does not do everything that Awk does just as concisely.

The sigils on variable names alone make Perl one-liner solutions longer.

So do the extra command line options needed in order to get an Awk-like
implicit input processing loop.

For instance, deduplicate lines:

awk '!s[$0]++'

Larry Wall himself famously said something like "I still say awk
'{ print $1 }' a lot".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-12-21, Lars Poulsen <lars@cleo.beagle-ears.com> wrote:
> In article <20241220184059.820@kylheku.com>,
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>> The goal of writing in sed is not to solve the problem, and to
>>> communicate with
>>> future users of the program so that they can adapt it to changing needs; the
>>> goal is to puzzle out what it takes to solve it in Sed, and to show: "Hey,
>>> look, I did this in Sed! Isn't it amazing? (And, by extension, aren't I?)"
>
> Just like APL.
> - "can you figure out what this one-line program does?"
> - "can you think of a way to do this in fewer characters?"

It's not quite so easy to casually dismiss APL, because if you look past
the reduction in character syntax, it has a powerful array processing
paradigm that made it unique at the time of its inception. APL programs
are actually short in the number of tokens and operations specified, not
just character count.

Sed is more like BrainF##### in just making things stupidly harder;
it's not a notation for something powerful under the hood.

A sed program won't necessarily be shorter than an Awk one. For instance
certainly not if it has to implement integer addition using regexps on
strings, where the Awk program just does a + b.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

with <87msgourzu.fsf@nosuchdomain.example.com> Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Sat, 21 Dec 2024 21:09:25 -0800, Keith Thompson wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> On Sat, 21 Dec 2024 16:36:32 -0800, Keith Thompson wrote:

*SKIP* [ 8 lines 5 levels deep] # there isn't anything to see

> I can no longer keep up with the rapid movement of the goalposts. I
> see no point in continuing this discussion.

Point of this (and many others) discussion is to generate engagement.
Turns out, talking about lizard people doesn't ignite Usenet. Who knew.

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom