On 2024-12-18 2:46 p.m., Salvador Mirzo wrote:

(*) Summary

I wrote a sed script that makes a line replacement after it finds the
right spot. So far so good. Then I added quit command after the
change, but the quit does not seem to take effect---violating my
expectation. I'll appreciate any help on understanding what's going on.

[snip]

So far so good. I decided to try it on longer files and I wanted to see
the change more quickly (without long files scrolling past my terminal),
so I decided to add a /q/ command right after the c commmand. I
thought---it will make sed quit right after making the change, so I can
see it works as desired and then I remove the /q/ and release it to production. But that did not happen.

[snip]

I failed the exercise I gave myself. Can you help me to understand why
the q command isn't stopping sed as I thought it would? I'd like to get
a better intuition.

By default sed prints the "pattern space", i.e. all lines in the file.
You can suppress that with the "-n" option to sed. (In other words, use
"sed -n" instead of plain "sed" in your script.)

The man page for GNU sed 4.9 says about the "q" command:

"Immediately quit the sed script without processing any more input,
except that if auto-print is not disabled the current pattern space will
be printed."

So the behaviour you're seeing without the "-n" option is to be
expected: pattern space still gets auto-printed after the "q" command.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Salvador Mirzo wrote:

I failed the exercise I gave myself. Can you help me to understand why
the q command isn't stopping sed as I thought it would? I'd like to get
a better intuition.

The specification in https://pubs.opengroup.org/onlinepubs/9799919799/
says at the end of the c command "Start the next cycle."
So any commands following it won't be executed.
The rationale does not mention the reason for the behavior specified.

Here, replacing the single-line c command with s/.*/$tag/ would do it.
If you needed a range of lines to be changed, that might become tricky.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ralf Damaschke <rwspam@gmx.de> writes:

Salvador Mirzo wrote:

I failed the exercise I gave myself. Can you help me to understand why
the q command isn't stopping sed as I thought it would? I'd like to get
a better intuition.

The specification in https://pubs.opengroup.org/onlinepubs/9799919799/

That's the home page. I believe you meant to link the sed page
directly. When copying URLs from the specification, we need to copy the
framed URL, otherwise we always end up at the home page. The framed sed
page is at

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html

says at the end of the c command "Start the next cycle."
So any commands following it won't be executed.
The rationale does not mention the reason for the behavior specified.

Interesting. Thanks for mentioning. I wonder if I understand the
information. I tried to change a line and then append another. In both FreeBSD's and GNU's sed, I the append takes place (and I thought they
would not if they were to obey the specification).

$ cat x.txt
a line
x
more lines
more lines

$ sed '/^x/{c\
hello
a\
hi
}' x.txt
a line
hello
hi
more lines
more lines
$

Here, replacing the single-line c command with s/.*/$tag/ would do it.
If you needed a range of lines to be changed, that might become tricky.

I don't need a range of lines to be changed, but I'd like to replace the
string only in the second line of the narrow region of interest. I
tried your idea and it works, so I guess that way I can be POSIX-compliant.

--
Thanks!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Salvador Mirzo wrote:

Ralf Damaschke <rwspam@gmx.de> writes:

The specification in https://pubs.opengroup.org/onlinepubs/9799919799/

That's the home page. I believe you meant to link the sed page
directly. When copying URLs from the specification, we need to copy the framed URL, otherwise we always end up at the home page. The framed sed
page is at

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html

Actually I considered that. But I felt that the top page might be of more
value since it is easy to find "Shell & Utilities" and "Utilities" in the frames at the left, whereas the HOME link at the subframe leads to a very detailed table of content where I would have to use the browser's find
command to locate the specs of other commands.

I tried to change a line and then append another. In both
FreeBSD's and GNU's sed, I the append takes place (and I thought they
would not if they were to obey the specification).

$ sed '/^x/{c\
hello a\
hi }' x.txt a line hello hi more lines more lines $
$ sed '/^x/{c\
hello
a\
hi
}' x.txt

For GNU sed that might be a version issue.
On my system with sed version "sed (GNU sed) 4.9" the copied&pasted
command only prints "hello" for "x" and ignores the append command.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <lsjtj8F2r8aU1@mid.individual.net>,
Salvador Mirzo wrote:
...

$ sed '/^x/{c\
hello a\
hi }' x.txt a line hello hi more lines more lines $
$ sed '/^x/{c\
hello
a\
hi
}' x.txt

Isn't this about the time where we give the caution about "Don't use sed
for anything beyond the s/foo/bar/g stage" ?

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

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

--
The whole aim of practical politics is to keep the populace alarmed (and hence clamorous
to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary.

H. L. Mencken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18.12.2024 20:46, Salvador Mirzo wrote:

(*) Summary

I wrote a sed script that makes a line replacement after it finds the
right spot. So far so good. Then I added quit command after the
change, but the quit does not seem to take effect---violating my
expectation. I'll appreciate any help on understanding what's going on.

First (before I forget it) change your string comparison '<' to the
numerical comparison operator '-lt' as in: test $# -lt 2 && usage
Otherwise, if you get used to using the wrong operator, you may get
subtle errors in future if you continue that habit.

Also note that using $* may not work correctly (e.g. depending on
filenames [containing spaces] used). The safe form is a quoted "$@"

(Then I was tempted to make a similar comment as Kenny. But...)

WRT your question I'd be interested to understand more about the
intention of your original question...

I mean if you don't trust your 'sed' command just pipe it though
'less'; there's no need to change the 'sed' program just for that.

Personally I'd try whether it works (by adding "something" before
and also after the desired place in your sample.txt to be sure the
other occurrences were not changed), and then just call

sed -e '/<<Release>>=/,+1s/something/sth else/' sample.txt

to see it working.

Janis

(*) A detailed description

I wrote this program:

--8<-------------------------------------------------------->8---
%cat make-release
#!/bin/sh
usage()
{
printf '%s tag file\n' $0
exit 1
}
test $# '<' 2 && usage
tag="$1"
shift
sed "/<<Release>>=/ {
n;
c\\
$tag
}" $*
--8<-------------------------------------------------------->8---

Here's how I use it. My objective with it is to replace that
/something/ in the text file with a new argument.

--8<-------------------------------------------------------->8---
%cat sample.txt
Lorem ipsum dolor...

<<Release>>=
something
@

... sit a met [...]
%
--8<-------------------------------------------------------->8---

Here's how I invoke it:

--8<-------------------------------------------------------->8---
%sh make-release release1 sample.txt
Lorem ipsum dolor...

<<Release>>=
release1
@

... sit a met [...] --8<-------------------------------------------------------->8---

So far so good. I decided to try it on longer files and I wanted to see
the change more quickly (without long files scrolling past my terminal),
so I decided to add a /q/ command right after the c commmand. I
thought---it will make sed quit right after making the change, so I can
see it works as desired and then I remove the /q/ and release it to production. But that did not happen.

--8<-------------------------------------------------------->8---
%cat make-release
#!/bin/sh
usage()
{
printf '%s tag file\n' $0
exit 1
}
test $# '<' 2 && usage
tag="$1"
shift
sed "/<<Release>>=/ {
n;
c\\
$tag
q}" $*
--8<-------------------------------------------------------->8---

I still see the whole file:

--8<-------------------------------------------------------->8---
%sh make-release release1 sample.txt
Lorem ipsum dolor...

<<Release>>=
release1
@

... sit a met [...]
%
--8<-------------------------------------------------------->8---

I failed the exercise I gave myself. Can you help me to understand why
the q command isn't stopping sed as I thought it would? I'd like to get
a better intuition.

I've been reading Dale Dougherty and Arnold Robin's ``sed & awk'' book.
If you have any recommended sed-related bibliography, I'd appreciate it,
too.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Kenny McCormack schrieb:

Isn't this about the time where we give the caution about "Don't use sed
for anything beyond the s/foo/bar/g stage" ?

Simply because you cannot imagine how to use it? No!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-21, Ralf Damaschke <rwspam@gmx.de> wrote:

Kenny McCormack schrieb:

Isn't this about the time where we give the caution about "Don't use sed
for anything beyond the s/foo/bar/g stage" ?

Simply because you cannot imagine how to use it? No!

He explained the "because", in the immediately following text that you snipped:

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

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

The reasoning doesn't quite match up with the characterization "can't imagine how to use it". Kenny need not imagine; he has seen examples of how to
use Sed in ways beyond s/x/y/g, and has the above remarks about that.

Sed is one of the so-called "esolangs" which some people use for puzzling.
For instance, here is a kind of Lisp interpreter written in Sed:

https://github.com/shinh/sedlisp/blob/master/sedlisp.sed

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 the goal of solving a Sudoku isn't to get 9 digits in every row, colum and box. That's the ostensible goal within the puzzle. The actual goal
of the puzzler is to engage in puzzle solving.

The given text processing problem to be solved in Sed serves a similar purpose to the 9 digit constraint rules in Sudoku: it just creates the pretext for entertaining puzzle solving, and is not the actual goal.

People looking for solutions in their production workflow do not want
"hey, look, this can be done in Sed!" type stuff. While people /can/
ramp up on it and easily become proficient, the only ones ever to do so are going to be engineers looking to waste time on puzzles.

Engineers not looking for puzzing won't ramp up on stuff like this because
it provides no value outside of puzzing. For production work, you need
a language which not only orchestrates the needed computation on the machine, but also captures the requirements in a way that communicates to people. Programming languages are a form of documentation!

Nobody wants to write cryptic gobbledygook just for shits and giggles, only to then have to write an accompanying ream of boring to try to bring it up to the same communication standard that comes from just writing nothing but code in an expressive language.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 18.12.2024 20:46, Salvador Mirzo wrote:

(*) Summary

I wrote a sed script that makes a line replacement after it finds the
right spot. So far so good. Then I added quit command after the
change, but the quit does not seem to take effect---violating my
expectation. I'll appreciate any help on understanding what's going on.

First (before I forget it) change your string comparison '<' to the
numerical comparison operator '-lt' as in: test $# -lt 2 && usage Otherwise, if you get used to using the wrong operator, you may get
subtle errors in future if you continue that habit.

Changed. Why is it the wrong operator? It seems it's not the standard one---checking just now on the POSIX.1 spec. I think I just tried it
out and given it worked as expected, I didn't think of checking it. I'm
new to the whole thing.

Also note that using $* may not work correctly (e.g. depending on
filenames [containing spaces] used). The safe form is a quoted "$@"

I learned something here.

--8<-------------------------------------------------------->8---
$ cat script.sh
#!/bin/sh
echo dollar-star $*
./script dollar-star $*

echo quoted-dollar-star "$*"
./script "$*"

echo dollar-at $@
./script $@

echo quoted-dollar-at "$@"
./script "$@"

$ cat script.c
#include <stdio.h>

int main(int argc, char *argv[]) {
printf("\nfull cmdline: ");
for (int i = 0; i < argc; ++i) {
printf("%s ", argv[i]);
}
printf("\nargs: %d\n", argc);
for (int i = 0; i < argc; ++i) {
printf("arg %d: %s\n", i, argv[i]);
}
return 0;
}
--8<-------------------------------------------------------->8---

$ ./script.sh 1 2 "th ree"
dollar-star 1 2 th ree

full cmdline: ./script dollar-star 1 2 th ree
args: 6
arg 0: ./script
arg 1: dollar-star
arg 2: 1
arg 3: 2
arg 4: th
arg 5: ree
quoted-dollar-star 1 2 th ree

full cmdline: ./script 1 2 th ree
args: 2
arg 0: ./script
arg 1: 1 2 th ree
dollar-at 1 2 th ree

full cmdline: ./script 1 2 th ree
args: 5
arg 0: ./script
arg 1: 1
arg 2: 2
arg 3: th
arg 4: ree
quoted-dollar-at 1 2 th ree

full cmdline: ./script 1 2 th ree
args: 4
arg 0: ./script
arg 1: 1
arg 2: 2
arg 3: th ree
$

(Then I was tempted to make a similar comment as Kenny. But...)

I'm studying and I often go back to the past to see what life was I
like. I initially tried to solve the problem with /ed/, but did not
find a way to insert a string coming from the a shell script's cmdline.
Then I thought that /sed/ was there to make /ed/ more scriptable.

WRT your question I'd be interested to understand more about the
intention of your original question...

The intention is mostly in the paragraph above, but the way I study is
to put things in real-world practice as much as possible. (When I
realize the solution is indeed too old to make sense, I replace it.
Otherwise I stick with it.) I have a literate programming file that
contains a chunk that's the version of the program I'm writing. So when
you ask the program its version, the information is included in the
executable, an idea which I like. I get the version with a git command
such as

$ git log --oneline | head -1 | awk '{print $1}'
2566d31

So I wanted to include such string in the literate programming file. At
first I wrote a solution in the programming language I'm using, but I
remember seeing many older software using sed for something like that,
so I decided to study sed a bit. I read the sed part of Dale Dougherty
and Arnold Robbins's book "sed & awk", second edition, and I thought sed
was quite neat and sensible. What I'm noticing now is that there are
too many different sed behavior out there to make it sensible to use.
UNIX systems as a whole are like that, so I'm used to reminding myself
of using the common subset of everything. Perhaps the common subset of
sed is too small. If I have to use it just for search and replace, then perhaps it's not really worth it.

I mean if you don't trust your 'sed' command just pipe it though
'less'; there's no need to change the 'sed' program just for that.

Personally I'd try whether it works (by adding "something" before
and also after the desired place in your sample.txt to be sure the
other occurrences were not changed), and then just call

sed -e '/<<Release>>=/,+1s/something/sth else/' sample.txt

to see it working.

Thanks for the excellent instruction!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21.12.2024 04:09, Kaz Kylheku wrote:

On 2024-12-21, Ralf Damaschke <rwspam@gmx.de> wrote:

[...]

[...]

People looking for solutions in their production workflow do not want
"hey, look, this can be done in Sed!" type stuff. While people /can/
ramp up on it and easily become proficient, the only ones ever to do so are going to be engineers looking to waste time on puzzles.

I like your comparison with puzzles, specifically this essence.

Janis

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/12/2024 12:17, Salvador Mirzo wrote:

I'm studying and I often go back to the past to see what life was I
like. I initially tried to solve the problem with /ed/, but did not
find a way to insert a string coming from the a shell script's cmdline.
Then I thought that /sed/ was there to make /ed/ more scriptable.

I think the other contributors are somewhat harsh on Sed. For
those who started on V6 Unix, there was just Ed, and, as you thought,
Sed was added in V7 as a scripting improvement to Ed. Awk also came
in with V7. Some people adopted Awk with enthusiasm, but the early
versions were quite limited/buggy, partly thanks to the limitations of
the PDP-11; Sed was pretty reliable even in those days. So at least
some users tried and failed with Awk, but found Sed usable with very
little to learn, thanks to the relationship with Ed. The arcana of
Sed are much easier to understand if you are/were a regular user of Ed,
whereas Awk requires you to learn a whole new language [I'm not in any
way suggesting that that is unusually difficult].

So students will normally no longer learn or use Ed/Sed, apart
perhaps from "s/foo/bar/" and similar; it makes more sense to learn a
visual editor and Awk. But for older hands, and for those interested
in the history, there is still a use for Sed. Personally, I know my
way around Sed much better than Awk. So, again personally, Sed is my
stream editor of choice for tasks somewhat harder than "s ...", but not
so hard that I need to do some serious programming and checking of the documentation. [YMMV, and I'm certainly not trying to persuade any Awk
users that they should learn to use Sed instead.]

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Paderewski

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21.12.2024 13:17, Salvador Mirzo wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 18.12.2024 20:46, Salvador Mirzo wrote:

(*) Summary

I wrote a sed script that makes a line replacement after it finds the
right spot. So far so good. Then I added quit command after the
change, but the quit does not seem to take effect---violating my
expectation. I'll appreciate any help on understanding what's going on.

First (before I forget it) change your string comparison '<' to the
numerical comparison operator '-lt' as in: test $# -lt 2 && usage
Otherwise, if you get used to using the wrong operator, you may get
subtle errors in future if you continue that habit.

Changed. Why is it the wrong operator? It seems it's not the standard one---checking just now on the POSIX.1 spec. I think I just tried it
out and given it worked as expected, I didn't think of checking it. I'm
new to the whole thing.

If you're new be very cautious with Shell; it looks easy to handle
but has a lot subtleties!

You have two sets of comparison operators in Unix shell; strangely
the ones we'd expect to compare numerically (=, !=, <, <=, >, >=)
instead do string comparisons (order of characters). And for the
numeric comparison there's other (-eq, -ne, -lt, -le, -gt, -ge)
operators.

The difference can be observed when comparing numbers in strings
like, say, 11 and 2.
[ 11 -lt 2 ] # returns false (numeric 11 is greater than 2)
[ 11 '<' 2 ] # returns true (string 11 comes before string 2)
The first is a comparison [of strings] interpreted as a numeric
entity, the second is a comparison [of strings] as a string with
lexicographic ordering.

Note also that in modern shells there's also $((...)) and ((...))
(arithmetic expansion and the [non-standard] arithmetic command)
available which support a syntax that is less surprising; e.g.

$ echo $(( 11 < 2 ))
$ (( 11 < 2 )) && ...

(without quoted operator and with numerical semantics).

Also note that using $* may not work correctly (e.g. depending on
filenames [containing spaces] used). The safe form is a quoted "$@"

I learned something here.

The point with spaces in filenames is also something elementary
to know; that's why the "$@" needs quoting (and quoted variables
is the rule of thumb for variable expansions [for most cases]).

[snip code]

(Then I was tempted to make a similar comment as Kenny. But...)

I'm studying and I often go back to the past to see what life was I
like. I initially tried to solve the problem with /ed/, but did not
find a way to insert a string coming from the a shell script's cmdline.
Then I thought that /sed/ was there to make /ed/ more scriptable.

I very very rarely use 'ed' but I recall to have used it feeding
input from stdin to it, so it is in principle possible to also
feed in expanded shell variables as part of the 'ed' input.

WRT your question I'd be interested to understand more about the
intention of your original question...

The intention is mostly in the paragraph above, but the way I study is
to put things in real-world practice as much as possible. (When I
realize the solution is indeed too old to make sense, I replace it.
Otherwise I stick with it.) I have a literate programming file that
contains a chunk that's the version of the program I'm writing. So when
you ask the program its version, the information is included in the executable, an idea which I like. I get the version with a git command
such as

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

So I wanted to include such string in the literate programming file. At first I wrote a solution in the programming language I'm using, but I remember seeing many older software using sed for something like that,
so I decided to study sed a bit. I read the sed part of Dale Dougherty
and Arnold Robbins's book "sed & awk", second edition, and I thought sed
was quite neat and sensible. What I'm noticing now is that there are
too many different sed behavior out there to make it sensible to use.
UNIX systems as a whole are like that, so I'm used to reminding myself
of using the common subset of everything. Perhaps the common subset of
sed is too small. If I have to use it just for search and replace, then perhaps it's not really worth it.

Awk has a powerful large common subset and its base is standardized.
(GNU Awk as a prevalent variant has a couple interesting extensions.)
Since your book covers Awk you should have a look into it. (Arnold
has also another book solely on Awk published, the GNU Awk Manual,
which is also available online.)

I mean if you don't trust your 'sed' command just pipe it though
'less'; there's no need to change the 'sed' program just for that.

Personally I'd try whether it works (by adding "something" before
and also after the desired place in your sample.txt to be sure the
other occurrences were not changed), and then just call

sed -e '/<<Release>>=/,+1s/something/sth else/' sample.txt

to see it working.

Thanks for the excellent instruction!

You're welcome.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21.12.2024 16:34, Andy Walker wrote:

On 21/12/2024 12:17, Salvador Mirzo wrote:

I'm studying and I often go back to the past to see what life was I
like. I initially tried to solve the problem with /ed/, but did not
find a way to insert a string coming from the a shell script's cmdline.
Then I thought that /sed/ was there to make /ed/ more scriptable.

I think the other contributors are somewhat harsh on Sed. For
those who started on V6 Unix, there was just Ed, and, as you thought,
Sed was added in V7 as a scripting improvement to Ed.

If all you have is Sed, Sed may look fine.

If you had invested a lot time to learn or master Sed you're of course
less objecting to Sed.

Awk also came
in with V7. Some people adopted Awk with enthusiasm, but the early
versions were quite limited/buggy, partly thanks to the limitations of
the PDP-11; Sed was pretty reliable even in those days.

You should mention that you are speaking of the 1977 version of AT&T
Awk (released in 1979); that [buggy] version appeared 45 years ago!

The Awk standard (1992) is based on the 1985 version (released 1987);
yet also already 37 years ago, the Awk POSIX standard 32 years ago.

The GNU Awk version was introduced 1986; it is continuously supported
(and is meanwhile available in version 5.x).

So at least some users tried and failed with Awk,

(There was obviously plenty of time to not need to stick to Sed.)

but found Sed usable with very
little to learn, thanks to the relationship with Ed. The arcana of
Sed are much easier to understand if you are/were a regular user of Ed, whereas Awk requires you to learn a whole new language [I'm not in any
way suggesting that that is unusually difficult].

Spreading FUD (bugs in the first release, whole new language) is not appropriate here! - Awk is stable now since decades and the language
is extremely terse and with an excellent power/complexity ratio!)

A few more things should be pointed out in that respect...
At Washington University St. Louis there was an examination made how
long it requires to learn Awk; the result was that in one laboratory
50% of the students considered themselves being confident with Awk,
after a week it were 90% of the students.
Awk's syntax is extremely simple. The imperative actions resemble the
"C" language, so they're easy for the many users knowing any language
that was [syntactically] derived from "C" (but far more simple).
The few syntax elements are also readable - no cryptic abbreviations
as in Sed - so they are easily memorable.

I'm sure if one is constantly working with Sed that at some point he
will also have the [cryptic] Sed language incorporated.

So students will normally no longer learn or use Ed/Sed, apart
perhaps from "s/foo/bar/" and similar; it makes more sense to learn a
visual editor and Awk. But for older hands, and for those interested
in the history, there is still a use for Sed. Personally, I know my
way around Sed much better than Awk. So, again personally, Sed is my
stream editor of choice for tasks somewhat harder than "s ...", but not
so hard that I need to do some serious programming and checking of the documentation. [YMMV, and I'm certainly not trying to persuade any Awk
users that they should learn to use Sed instead.]

Fair enough.

For newbies, as the OP seems to be, the personal historic experience
with Sed is not that useful, though. Since he now has the choice he
should take the most appropriate tool.

I also don't think that any of the negative responses concerning Sed
had meant to express any disrespect of Sed users.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Salvador Mirzo <smirzo@example.com>:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 18.12.2024 20:46, Salvador Mirzo wrote:

First (before I forget it) change your string comparison '<' to the
numerical comparison operator '-lt' as in: test $# -lt 2 && usage
Otherwise, if you get used to using the wrong operator, you may get
subtle errors in future if you continue that habit.

Changed. Why is it the wrong operator?

'<' compares two strings lexically, whereas '-lt' compares two
numbers numerically.


Some examples:

1 < 2 ==> true

2 < 2 ==> false

3 < 2 ==> false

10 < 2 ==> true, probably not your intention.

1 -lt 2 ==> true

2 -lt 2 ==> false

3 -lt 2 ==> false

10 -lt 2 ==> false

It seems it's not the standard one---checking just now on the
POSIX.1 spec.

The recent POSIX standard knows of the '<' operator, see
<https://pubs.opengroup.org/onlinepubs/9799919799/utilities/test.html#tag_20_121_05>.

Also note that using $* may not work correctly (e.g. depending on
filenames [containing spaces] used). The safe form is a quoted "$@"

I learned something here.

--8<-------------------------------------------------------->8---
$ cat script.sh
#!/bin/sh
echo dollar-star $*
./script dollar-star $*

echo quoted-dollar-star "$*"
./script "$*"

echo dollar-at $@
./script $@

echo quoted-dollar-at "$@"
./script "$@"

$ cat script.c
#include <stdio.h>

int main(int argc, char *argv[]) {
printf("\nfull cmdline: ");
for (int i = 0; i < argc; ++i) {
printf("%s ", argv[i]);
}
printf("\nargs: %d\n", argc);
for (int i = 0; i < argc; ++i) {
printf("arg %d: %s\n", i, argv[i]);
}
return 0;
}
--8<-------------------------------------------------------->8---

$ ./script.sh 1 2 "th ree"
dollar-star 1 2 th ree

full cmdline: ./script dollar-star 1 2 th ree
args: 6
arg 0: ./script
arg 1: dollar-star
arg 2: 1
arg 3: 2
arg 4: th
arg 5: ree
quoted-dollar-star 1 2 th ree

full cmdline: ./script 1 2 th ree
args: 2
arg 0: ./script
arg 1: 1 2 th ree
dollar-at 1 2 th ree

full cmdline: ./script 1 2 th ree
args: 5
arg 0: ./script
arg 1: 1
arg 2: 2
arg 3: th
arg 4: ree
quoted-dollar-at 1 2 th ree

full cmdline: ./script 1 2 th ree
args: 4
arg 0: ./script
arg 1: 1
arg 2: 2
arg 3: th ree
$

So using "$@" is the only way to have the shell pass its
positional parameters unmodified (i. e. neither glued together
nor split at internal white space (more precise: split according
to the contents of the IFS shell parameter)) to commands it
invokes.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andy Walker <anw@cuboid.co.uk> writes:

On 21/12/2024 12:17, Salvador Mirzo wrote:

I'm studying and I often go back to the past to see what life was I
like. I initially tried to solve the problem with /ed/, but did not
find a way to insert a string coming from the a shell script's cmdline.
Then I thought that /sed/ was there to make /ed/ more scriptable.

I think the other contributors are somewhat harsh on Sed. For
those who started on V6 Unix, there was just Ed, and, as you thought,
Sed was added in V7 as a scripting improvement to Ed. Awk also came
in with V7. Some people adopted Awk with enthusiasm, but the early
versions were quite limited/buggy, partly thanks to the limitations of
the PDP-11; Sed was pretty reliable even in those days. So at least
some users tried and failed with Awk, but found Sed usable with very
little to learn, thanks to the relationship with Ed. The arcana of
Sed are much easier to understand if you are/were a regular user of Ed, whereas Awk requires you to learn a whole new language [I'm not in any
way suggesting that that is unusually difficult].

It doesn't seem difficult to learn, but there could be so many different implementations now that it could be a challenge to write a script and distribute it around.

So students will normally no longer learn or use Ed/Sed, apart
perhaps from "s/foo/bar/" and similar; it makes more sense to learn a
visual editor and Awk. But for older hands, and for those interested
in the history, there is still a use for Sed.

History is my main thing here. I like to know how life was like. I
recently read ``Hackers'' by Steven Levy, 1984. (I was sad it ended.)
I have an open mind about software. I'm here on the USENET because I discovered it in non-standard media. It turns out I find NNTP a much
better medium of discourse than any other. (I'm writing this from a GNU
EMACS buffer and will be send out using Gnus. Gnus can be dramatically uninuitive, but there seems to be no real replacement for it when it
comes to USENET and perhaps mail.) It is noticeable that newer
generations are not really better at writing software compared to
previous generations. I wouldn't change make, for example, for newer
ones. Have you seen Gradle? What was that for? There's a website
whose slogan is ``newer is not always better''.

Personally, I know my way around Sed much better than Awk. So, again personally, Sed is my stream editor of choice for tasks somewhat
harder than "s ...", but not so hard that I need to do some serious programming and checking of the documentation. [YMMV, and I'm
certainly not trying to persuade any Awk users that they should learn
to use Sed instead.]

I actually know awk a little bit. I've read the ``AWK Programming
Language'' by Aho, Kernighan and Weinberger, 1988. I loved it. It
replaced pretty everything I used when shell scripting something. But
it doesn't feel right to ignore ed and sed. I need to know at least how
to use them for the essential cases. These tools incorporate a certain
way of thinking that's very valuable and knowing where they come from is
very valuable.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21.12.2024 19:21, Salvador Mirzo wrote:

[...] I'm here on the USENET because I
discovered it in non-standard media. It turns out I find NNTP a much
better medium of discourse than any other. (I'm writing this from a GNU EMACS buffer and will be send out using Gnus. Gnus can be dramatically uninuitive, but there seems to be no real replacement for it when it
comes to USENET and perhaps mail.) [...]

There's tools like Thunderbird where you can work with Usenet similarly
to using a typical GUI-based email client (it is actually also an email client). If you like historic tools I've heard that there's still 'nn'
around, a text-oriented newsreader that I used in the 1990's (loved it).

I actually know awk a little bit. I've read the ``AWK Programming
Language'' by Aho, Kernighan and Weinberger, 1988. I loved it. [...]

This is an excellent source! So you might want to look into the GNU Awk
Manual just for a contemporary Awk variant, to see a couple more useful features supported in an efficient Awk implementation.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

Seriously, the above looks like gobbledegook compared to the

equivalent in

AWK (or some other normal scripting langugae). "sed" looks like

Intercal

(once you get beyond s/foo/bar/g).

For many people C looks like gobbledegook, too.

I'm sure that whatever it is that OP is trying to do, it could be

easily

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <slrnvmidnd.9vr.apple.universe@freight.zombinet>,
Eric Pozharski <apple.universe@posteo.net> wrote:

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.

Good one. You really got LDO's number to a T.

The funny thing is: I was the one who first brought up: Wouldn't this all
be easier/better/more-maintainable in AWK. And I knew for a dead cold fact that mentioning AWK would bring the Perl nuts out of the woodwork to attack
AWK and say how much better it would be to use Perl.

I couldn't have been more prescient.

--
Senator Marsha Blackburn (R-TN), who sits on the Judiciary Committee, said it was
"extremely inappropriate" for the president to nominate a Supreme Court justice on a
day ending with the letter "Y", and she said that "Biden is putting the demands of the
radical progressive left ahead of what is best for our nation."

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-23, Kenny McCormack <gazelle@shell.xmission.com> wrote:

In article <slrnvmidnd.9vr.apple.universe@freight.zombinet>,
Eric Pozharski <apple.universe@posteo.net> wrote:

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.

Good one. You really got LDO's number to a T.

What would his number be good for? Rather, check out what he volunteered about himself in his LinkedIn profile:

- Somehow got a Master's in CS, back when Wham came out with _Make it Big_.

- After a 1-2 year gap, went back to the same school and worked for 11
years in "user support".

- Then, essentially unemployed since 1997.

- Never worked in the actually industry in any role, let alone as a dev.

I don't know which way to call it: trust fund baby, or else burger flipper?

Oh, but he's got opinions on everything, including cockamamie code
formatting conventions everyone should be using, but nobody in their
right mind would.

P.S. Don't forget to wake me up before you go-go.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 23 Dec 2024 07:26:15 -0600, Ed Morton wrote:

Awk is a mandatory POSIX tool (and so available on all POSIX-compliant
Unix-y systems) with a tiny but powerful language focused on just text processing, perl is none of that.

Perl is all of that, and more. Text processing is very much the raison d’être for Perl. Because it turns out it can get quite complicated.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 23 Dec 2024 15:06:39 -0800, Keith Thompson wrote:

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

On Mon, 23 Dec 2024 07:26:15 -0600, Ed Morton wrote:

Awk is a mandatory POSIX tool (and so available on all POSIX-compliant
Unix-y systems) with a tiny but powerful language focused on just text
processing, perl is none of that.

Perl is all of that, and more. Text processing is very much the raison
d’être for Perl. Because it turns out it can get quite complicated.

It's not "all of that". Perl is not a mandatory POSIX tool.

Nobody cares.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

with <vkblqk$22oro$1@news.xmission.com> Kenny McCormack wrote:

In article <slrnvmidnd.9vr.apple.universe@freight.zombinet>,
Eric Pozharski <apple.universe@posteo.net> wrote:

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.

Good one. You really got LDO's number to a T.
The funny thing is: I was the one who first brought up: Wouldn't this
all be easier/better/more-maintainable in AWK. And I knew for a dead
cold fact that mentioning AWK would bring the Perl nuts out of the
woodwork to attack AWK and say how much better it would be to use
Perl.
I couldn't have been more prescient.

Thank you for this clear demonstration of how engagement is laid out.

p.s. You do understand that you don't make sense?

p.p.s. You don't have to! It's engagement!

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 24 Dec 2024 06:20:18 -0600, Ed Morton wrote:

Is perl a mandatory POSIX tool? No.

Nobody cares. POSIX compliance is just a means to an end not an end in
itself. Linux pays attention to POSIX where it matters, and ignores it
where it doesn’t.

This is one case where it doesn’t.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Tue, 24 Dec 2024 06:20:18 -0600, Ed Morton wrote:

Is perl a mandatory POSIX tool? No.

Nobody cares.

That is a false. Enough vendors and system integrators care that you
can hardly log into any Linux box that doesn't have some kind of awk.
Even small IoT devices or consumer routers.

(If it doesn't have Awk, it's almost certainly not going to have Perl.)

The BusyBox project, a popular project that provides userland utilities
for small systems packaged into a single executable, has its own BusyBox
Awk, which is how a good many small embedded systems get their Awk.

BusyBox Awk is implemented in one 100,000 character source file
(that probably relies on some BusyBox library infrastructure.)

There is no BuxyBox Perl and likely won't be any time soon.

POSIX compliance is just a means to an end not an end in
itself. Linux pays attention to POSIX where it matters, and ignores it
where it doesn’t.

That is true, but one area where it matters is in having Awk on a
system, so that shell scripts which rely on Awk do not break.

This is one case where it doesn’t.

That is nothing but a statement of your personal preference or wishful thinking, not reflecting the facts of the world at large: as in,
what is widely deployed out there and can be counted on.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)