From Newsgroup: comp.unix.shell

Hi,

wanted to learn shell using sed and awk as in the O'Reilly book.

I am working on scripts in Common Lisp using shell inside,
here's the link to the code, it's GPL2 :

http://sf.net/projects/lisp-scripts

Zara
--
My software & art company : http://ko-fi.com/brandywine9
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-02-09, zara <johan@freecol.be> wrote:

Hi,

wanted to learn shell using sed and awk as in the O'Reilly book.

It will work better if you learn the shell language using
a shell.

sed and awk commands have a lot of details that are particular
to those utilities.

When invoking those utilities from a shell command, you have to
understand how to quote the body of the awk or sed program properly so
that it's handled intact as a single argument, without the shell itself interpreting any special characters.

I am working on scripts in Common Lisp using shell inside,
here's the link to the code, it's GPL2 :

http://sf.net/projects/lisp-scripts

In 2025, nobody is going to download and unpack tarballs you posted to sourceforge to look at your code.

You might as well scratch it on the wall of your cave with a piece of
charcoal, and invite people to peruse it by the light of a torch.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-02-09, zara <johan@freecol.be> wrote:

[...]

I am working on scripts in Common Lisp using shell inside,
here's the link to the code, it's GPL2 :

http://sf.net/projects/lisp-scripts

In 2025, nobody is going to download and unpack tarballs you posted to sourceforge to look at your code.

You might as well scratch it on the wall of your cave with a piece of charcoal, and invite people to peruse it by the light of a torch.

Consider putting your code on GitHub instead.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-02-09, Keith Thompson wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-02-09, zara <johan@freecol.be> wrote:

[...]

I am working on scripts in Common Lisp using shell inside,
here's the link to the code, it's GPL2 :

http://sf.net/projects/lisp-scripts

In 2025, nobody is going to download and unpack tarballs you posted to
sourceforge to look at your code.

You might as well scratch it on the wall of your cave with a piece of
charcoal, and invite people to peruse it by the light of a torch.

Consider putting your code on GitHub instead.

So that it's harder to read or download without git or specific
browsers, or even without JavaScript; or has SourceForge reached that
level of unusability now too?

I mean, while I could understand SourceForge being not recommended for
some reasons (which ones?), it strikes me as unlikely that GitHub is a
good option, given how they've been progressively rendering it unusable
on the web (three years ago or so it was different in this regard), and
I guess/hope that, for the git part, there would be other alternatives
there, or there really are none?
--
Nuno Silva
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <voa4fr$k88l$1@dont-email.me>,
Nuno Silva <nunojsilva@invalid.invalid> wrote:
...

So that it's harder to read or download without git or specific
browsers, or even without JavaScript; or has SourceForge reached that
level of unusability now too?

I mean, while I could understand SourceForge being not recommended for
some reasons (which ones?), it strikes me as unlikely that GitHub is a
good option, given how they've been progressively rendering it unusable
on the web (three years ago or so it was different in this regard), and
I guess/hope that, for the git part, there would be other alternatives
there, or there really are none?

Well, do consider the source. Consider that it *was* KT who made that recommendation.
--
Trump is so much smarter than anyone who voted for him. His IQ must be at least 100. It's too bad that he believes in vaccines. He keeps getting
those shots and they're obviously contributing to his severe cognitive
decline.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-02-09, Nuno Silva <nunojsilva@invalid.invalid> wrote:

I mean, while I could understand SourceForge being not recommended for
some reasons (which ones?), it strikes me as unlikely that GitHub is a
good option, given how they've been progressively rendering it unusable
on the web (three years ago or so it was different in this regard), and
I guess/hope that, for the git part, there would be other alternatives
there, or there really are none?

Codeberg.org "is a non-profit, community-led effort that provides
Git hosting and other services for free and open source projects".
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

zara <johan@freecol.be> writes:

Hi,

wanted to learn shell using sed and awk as in the O'Reilly book.

I am working on scripts in Common Lisp using shell inside,
here's the link to the code, it's GPL2 :

http://sf.net/projects/lisp-scripts

Didn't look.

I once spent a week converting a LOT of sed/awk to Perl.
I turned a complicated mess into something any programmer
could readily understand. (And actually worked.)

Now I'd use Python.
--
Dan Espen
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 09.02.2025 11:26, Keith Thompson wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-02-09, zara <johan@freecol.be> wrote:

[...]

I am working on scripts in Common Lisp using shell inside,
here's the link to the code, it's GPL2 :

http://sf.net/projects/lisp-scripts

In 2025, nobody is going to download and unpack tarballs you posted to
sourceforge to look at your code.

You might as well scratch it on the wall of your cave with a piece of
charcoal, and invite people to peruse it by the light of a torch.

:-)

Consider putting your code on GitHub instead.

On 09.02.2025 07:28, Kaz Kylheku also wrote:

In 2025, nobody is going to download and unpack tarballs youposted to sourceforge to look at your code.

In my opinion, if some code is advertised in Usenet then there should
be sufficiently complete information about it posted here to know what
any remote link is (and less of "I've done something, and you find it
there").

If you have enough information about the advertised product it's IMO a
still not unimportant but secondary question where it's placed.

And if there's enough information here I can decide whether I take the
burden to access Github or anything else.

I ignore such posts that contain only links and spare the information (including rationales etc.).

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <voajsf$nd2k$1@dont-email.me>,
Dan Espen <dan1espen@gmail.com> wrote:
...

... to Perl.
... something any programmer could readily understand.

I'm sure opinions will vary on that.

Now I'd use Python.

Gotta keep up with the fashion world, doncha?
--
Kenny, I'll ask you to stop using quotes of mine as taglines.

- Rick C Hodgin -

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

gazelle@shell.xmission.com (Kenny McCormack) writes:

In article <voajsf$nd2k$1@dont-email.me>,
Dan Espen <dan1espen@gmail.com> wrote:
...

... to Perl.
... something any programmer could readily understand.

I'm sure opinions will vary on that.

They guy that wrote the sed/awk stuff agreed.

Now I'd use Python.

Gotta keep up with the fashion world, doncha?

Oh, I'm hurt.
--
Dan Espen
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 09.02.2025 18:21, Dan Espen wrote:

gazelle@shell.xmission.com (Kenny McCormack) writes:

In article <voajsf$nd2k$1@dont-email.me>,
Dan Espen <dan1espen@gmail.com> wrote:
...

... to Perl.
... something any programmer could readily understand.

I'm sure opinions will vary on that.

They guy that wrote the sed/awk stuff agreed.

Curious; do you mean the authors of those languages or the
authors (pl.) of that unspecific mentioned "sed & awk" book?

Given clarity/cryptically of syntax (and their semantics)
these three languages (Awk, Perl, Sed) for sure vary a lot!

Janis

Now I'd use Python.

Gotta keep up with the fashion world, doncha?

Oh, I'm hurt.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

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

On 09.02.2025 18:21, Dan Espen wrote:

gazelle@shell.xmission.com (Kenny McCormack) writes:

In article <voajsf$nd2k$1@dont-email.me>,
Dan Espen <dan1espen@gmail.com> wrote:
...

... to Perl.
... something any programmer could readily understand.

I'm sure opinions will vary on that.

They guy that wrote the sed/awk stuff agreed.

Curious; do you mean the authors of those languages or the
authors (pl.) of that unspecific mentioned "sed & awk" book?

Given clarity/cryptically of syntax (and their semantics)
these three languages (Awk, Perl, Sed) for sure vary a lot!

This was an app developed by one of my co-workers.
The app consisted of many shell scripts and many invocations of
awk and sed. There were dozens of files in the app. I was trying to
fix it and worked on it for quite some time before I decided it was too
many files and too many different languages being used.

I ended up re-writing the whole thing as a single Perl script.
The whole thing was all in one file and much easier to understand.
As I said, the original author agreed.

Perl can be cryptic if you use the cryptic parts of the language.
I don't.
--
Dan Espen
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Sun, 09 Feb 2025 11:07:43 -0500, Dan Espen wrote:

I once spent a week converting a LOT of sed/awk to Perl. I turned a complicated mess into something any programmer could readily understand.
(And actually worked.)

I have pointed out several times that Perl does everything awk can do, at least as concisely, and a lot more besides. Which is why I never bothered
to learn awk.

Some people get annoyed every time I say that.

Now I'd use Python.

With Perl, I was never quite sure I fully understood what was going on.
There was always some hint of magic lurking just behind the scenes. Also
the core language ends up quite large, with all the built-in features
packed into it.

(Those two characteristics are probably related.)

With Python, I always felt that I understood what I was doing. And I kept
that feeling as I got into more complex features like descriptors and metaclasses. It is, for the most part, a language whose growth has been carefully managed, so that the language core remains compact and cohesive
and yet remains an incredibly powerful base to build on (as the standard library demonstrates).
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Sun, 09 Feb 2025 11:44:59 +0000, Nuno Silva wrote:

So that it's harder to read or download without git or specific
browsers ...

GitHub works fine as a source for git-clone and git-fetch commands,
without any browser being involved. And you can push to it, if you have an account. Yes, there are plenty of alternatives for Git repo hosting.
Someone else mentioned Codeberg; there are also GitLab and BitBucket.

(I think all of these require a browser interface for tasks like setting
up a repo in the first place.)

BitBucket started out hosting only Mercurial repos; then market pressures forced it to add Git as an option; then the Mercurial business proved
unviable and was dropped altogether.

SourceForge also does Git now, but I donrCOt think that makes it much more attractive. ;)

It is also easy for you to publish your own repos on your own server,
through a tool as simple as Gitolite.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 09.02.2025 22:56, Dan Espen wrote:

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

On 09.02.2025 18:21, Dan Espen wrote:

gazelle@shell.xmission.com (Kenny McCormack) writes:

In article <voajsf$nd2k$1@dont-email.me>,
Dan Espen <dan1espen@gmail.com> wrote:
...

... to Perl.
... something any programmer could readily understand.

I'm sure opinions will vary on that.

They guy that wrote the sed/awk stuff agreed.

Curious; do you mean the authors of those languages or the
authors (pl.) of that unspecific mentioned "sed & awk" book?

Given clarity/cryptically of syntax (and their semantics)
these three languages (Awk, Perl, Sed) for sure vary a lot!

This was an app developed by one of my co-workers.
The app consisted of many shell scripts and many invocations of
awk and sed. There were dozens of files in the app. I was trying to
fix it and worked on it for quite some time before I decided it was too
many files and too many different languages being used.

Ah, now I see what you meant...

I ended up re-writing the whole thing as a single Perl script.
The whole thing was all in one file and much easier to understand.
As I said, the original author agreed.

...the author of that project, obviously.

Yes, we can often observe that projects grow that way and that there
are often far too many individual tools involved, and unnecessarily.
If you use Awk anyway there's absolutely no need for using Sed. And
with Perl you can also avoid the Shell/Awk glue and stay within one
language.

Reasons for Shell & Awk are that these are Unix standard and can be
expected to exist "everywhere" to create portable scripting software.
And Awk is also advantageous for its much clearer syntax (as opposed
to Perl), but Shell as well cat gen quite messy if you want to write
scripts functionally correct.

(Python, that I think you mentioned elsthread, has it's own inherent
quirks and has the same non-standard property as Perl.)

It's the projects' choice to select the appropriate tool in any given
context.

Perl can be cryptic if you use the cryptic parts of the language.
I don't.

Perl has some inherent cryptic syntax; something that other languages (including Awk) don't have. And Sed is anyway "applied cryptography"
par excellence.

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 10.02.2025 02:06, Janis Papanagnou wrote:

[...], but Shell as well cat gen quite messy if you want to write [...]

So far for applied cryptography; that should have been

[...], but Shell as well can get quite messy if you want to write [...]

Janis
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Nuno Silva <nunojsilva@invalid.invalid> writes:

On 2025-02-09, Keith Thompson wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-02-09, zara <johan@freecol.be> wrote:

[...]

I am working on scripts in Common Lisp using shell inside,
here's the link to the code, it's GPL2 :

http://sf.net/projects/lisp-scripts

In 2025, nobody is going to download and unpack tarballs you posted to
sourceforge to look at your code.

You might as well scratch it on the wall of your cave with a piece of
charcoal, and invite people to peruse it by the light of a torch.

Consider putting your code on GitHub instead.

So that it's harder to read or download without git or specific
browsers, or even without JavaScript; or has SourceForge reached that
level of unusability now too?

I personally find GitHub more usable than SourceForge. GitHub lets me
brows the code in my web browser and/or download it as a git repository.
I don't use SourceForge much, but I've found its web interface clunky
and difficult to navigate. I find the automatic "Your download will
start shortly" with a 5-second countdown particularly obnoxious; I'd
much rather have just a link that I can download on a system other than
the one my browser is running on.

I don't know whether GitHub's browsing functionality requires
JavaScript to be enabled, since I haven't bothered to disable
JavaScript myself. I suppose it probably does. And I'm a heavy
user of git, so that's not a problem for me; if a repo looks
interesting, I'm more likely to clone it than browse it online.
If you dislike JavaScript and/or git, then GitHub probably wouldn't
be a good choice for you.

I have no opinion on which you should prefer.

I mean, while I could understand SourceForge being not recommended for
some reasons (which ones?), it strikes me as unlikely that GitHub is a
good option, given how they've been progressively rendering it unusable
on the web (three years ago or so it was different in this regard), and
I guess/hope that, for the git part, there would be other alternatives
there, or there really are none?

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

From Newsgroup: comp.unix.shell

On Sun, 09 Feb 2025 17:10:57 -0800, Keith Thompson wrote:

I find [SourceForgerCOs] automatic "Your download will start shortly" with
a 5-second countdown particularly obnoxious ...

Every excuse to show you ads. And the ads are often hard to tell from the
real link(s). This happens with search results, too.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-02-10, Lawrence D'Oliveiro wrote:

On Sun, 09 Feb 2025 11:44:59 +0000, Nuno Silva wrote:

So that it's harder to read or download without git or specific
browsers ...

GitHub works fine as a source for git-clone and git-fetch commands,
without any browser being involved. And you can push to it, if you have an account. Yes, there are plenty of alternatives for Git repo hosting.
Someone else mentioned Codeberg; there are also GitLab and BitBucket.

(I think all of these require a browser interface for tasks like setting
up a repo in the first place.)

It's good to have some suggestions flowing, but a couple notes on these:

GitLab at gitlab.com also requires (or required?) agreeing to a rather
broad "indemnification" clause. Other services may have such clauses
too, but GitLab's one is quite broad and unbounded.

(At least GitLab and GitHub require specific browsers nowadays, too,
even for reading without participating.)

BitBucket started out hosting only Mercurial repos; then market pressures forced it to add Git as an option; then the Mercurial business proved unviable and was dropped altogether.

SourceForge also does Git now, but I donrCOt think that makes it much more attractive. ;)

It is also easy for you to publish your own repos on your own server, through a tool as simple as Gitolite.

--
Nuno Silva
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-1109145954-1739186632=:16712
Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT



On Mon, 10 Feb 2025, Nuno Silva wrote:

On 2025-02-10, Lawrence D'Oliveiro wrote:

On Sun, 09 Feb 2025 11:44:59 +0000, Nuno Silva wrote:

So that it's harder to read or download without git or specific
browsers ...

GitHub works fine as a source for git-clone and git-fetch commands,
without any browser being involved. And you can push to it, if you have an >> account. Yes, there are plenty of alternatives for Git repo hosting.
Someone else mentioned Codeberg; there are also GitLab and BitBucket.

(I think all of these require a browser interface for tasks like setting
up a repo in the first place.)

It's good to have some suggestions flowing, but a couple notes on these:

GitLab at gitlab.com also requires (or required?) agreeing to a rather
broad "indemnification" clause. Other services may have such clauses
too, but GitLab's one is quite broad and unbounded.

(At least GitLab and GitHub require specific browsers nowadays, too,
even for reading without participating.)

BitBucket started out hosting only Mercurial repos; then market pressures
forced it to add Git as an option; then the Mercurial business proved
unviable and was dropped altogether.

SourceForge also does Git now, but I donrCOt think that makes it much more >> attractive. ;)

It is also easy for you to publish your own repos on your own server,
through a tool as simple as Gitolite.

I host my source code myself on a VM in a fossil repository. It works
great!
--8323328-1109145954-1739186632=:16712--
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

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

On Sun, 09 Feb 2025 11:07:43 -0500, Dan Espen wrote:

I once spent a week converting a LOT of sed/awk to Perl. I turned a
complicated mess into something any programmer could readily understand.
(And actually worked.)

I have pointed out several times that Perl does everything awk can do, at least as concisely, and a lot more besides. Which is why I never bothered
to learn awk.

When I started the project mentioned above, I only knew a little Perl
and a litte more Awk. As I read about Awk, I read about a2p. I thought, wait a
minute, this fairly primitive Awk can be converted by a program into
a full blown programming language? Why would I want to wear handcuffs?

Some people get annoyed every time I say that.

Probably because we're on comp.unix.shell.

Now I'd use Python.

With Perl, I was never quite sure I fully understood what was going on. There was always some hint of magic lurking just behind the scenes. Also
the core language ends up quite large, with all the built-in features
packed into it.

(Those two characteristics are probably related.)

With Python, I always felt that I understood what I was doing. And I kept that feeling as I got into more complex features like descriptors and metaclasses. It is, for the most part, a language whose growth has been carefully managed, so that the language core remains compact and cohesive and yet remains an incredibly powerful base to build on (as the standard library demonstrates).

I was happily using Perl for a GUI I wrote using Perl/GTK.
As GTK evolved, the Perl support got worse and worse. Eventually
forcing me to move to Python/GTK.

Since then I've found the number of interfaces from Python to other
packages is just amazing. I've currently using Pychromecast to
interface to Google Nest Speakers.

I've found, you really do have to stay with the times.
--
Dan Espen
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Sun, 09 Feb 2025 11:44:59 +0000, Nuno Silva wrote:

I guess/hope that, for the git part, there would be other alternatives
there, or there really are none?

And I guess getting the zip link from the html is too much work to do?
--
Order! Order in the group!
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Mon, 10 Feb 2025 11:14:13 -0500, Dan Espen wrote:

I was happily using Perl for a GUI I wrote using Perl/GTK.
As GTK evolved, the Perl support got worse and worse. Eventually
forcing me to move to Python/GTK.

My first shot at GUI programming on Linux was using Tcl with Tk. This was
just a bit before I discovered Python. I reworked that app to use Python
with GTK, and it worked so much better, I never went back to Tcl again.

Tk is still available for use with Python, and it still works through a
Tcl layer to get there. That can be useful for some simple jobs, in spite
of TkrCOs deficiencies as a GUI toolkit.

Since then I've found the number of interfaces from Python to other
packages is just amazing.

I think there is something about the design of Python that encourages the proliferation of such interfaces. The core language is compact (a fraction
the size of Java, for example), yet versatile enough to be specialized for many domain-specific uses (e.g. it includes user-defined operator
overloads, which Java had to leave out).

And then there is the ctypes module, which lets you directly interface to compiled libraries written for C or other such low-level languages, just
using pure Python code. And you can construct conveniently high-level rCLPythonicrCY interfaces, to make it look like the library was written for use from Python, when it was not.

There was a time when Perl was the go-to language for this sort of thing.
I think Python won out because it managed to make the whole job easier.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

"Kenny" == Kenny McCormack <gazelle@shell.xmission.com> writes:

Kenny> In article <voajsf$nd2k$1@dont-email.me>,
Kenny> Dan Espen <dan1espen@gmail.com> wrote:
Kenny> ...

... to Perl.
... something any programmer could readily understand.

Kenny> I'm sure opinions will vary on that.

If they don't understand the Perl code, I could recommend a couple of
good books...
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Dart/Flutter consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-02-13, Randal L. Schwartz <merlyn@stonehenge.com> wrote:

"Kenny" == Kenny McCormack <gazelle@shell.xmission.com> writes:

Kenny> In article <voajsf$nd2k$1@dont-email.me>,
Kenny> Dan Espen <dan1espen@gmail.com> wrote:
Kenny> ...

... to Perl.
... something any programmer could readily understand.

Kenny> I'm sure opinions will vary on that.

If they don't understand the Perl code, I could recommend a couple of
good books...

That makes no sense. Don't you mean Perl books?
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-02-13, Randal L. Schwartz <merlyn@stonehenge.com> wrote:

"Kenny" == Kenny McCormack <gazelle@shell.xmission.com> writes:

Kenny> In article <voajsf$nd2k$1@dont-email.me>,
Kenny> Dan Espen <dan1espen@gmail.com> wrote:
Kenny> ...

... to Perl.
... something any programmer could readily understand.

Kenny> I'm sure opinions will vary on that.

If they don't understand the Perl code, I could recommend a couple of
good books...

That makes no sense. Don't you mean Perl books?

:)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 13/02/2025 22:59, Kaz Kylheku wrote:

On 2025-02-13, Randal L. Schwartz <merlyn@stonehenge.com> wrote:

[...]

If they don't understand the Perl code, I could recommend a couple

good books...

That makes no sense. Don't you mean Perl books?

Do you know who you are addressing?

el
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 10/02/2025 02:00, Lawrence D'Oliveiro wrote:

On Sun, 09 Feb 2025 11:07:43 -0500, Dan Espen wrote:

I once spent a week converting a LOT of sed/awk to Perl. I turned
a complicated mess into something any programmer could readily
understand. (And actually worked.)

I have pointed out several times that Perl does everything awk can
do, at least as concisely, and a lot more besides. Which is why I
never bothered to learn awk.

Some people get annoyed every time I say that.

Now I'd use Python.

[...]

Python, Shmython. It's like whether vi or emacs is the better editor
(of course Sublime Text is the better one :-)-O)

Awk is very good for short one liners on reasonably short input files,
because Perl takes longer to load.

Perl is very good for large input files, a more complete programming
language with gazillions of modules and around for ages.

Python is probably as good as Perl or better and has gazillions of
libraries. However this need for virtual environments and that scripts
stop working after a Python upgrade, make things complicated and has
turned me off from learning it, which I wanted to do as I have
retired.

Don't forget LUA :-)-O

If you are young and want to learn a (new) programming language don't
start with Perl, start with Python.

If you have worked with Perl for ages, carry on I doubt there is
anything in Python that you can't do in Perl.

If there is a need to learn shell then learn shell (bash, zsh or
whatever).

I recently had to come up with a script that takes a DNS zone file, and constructs a really complicated CSV of 79 columns delimited with ';'
and "pivoting" name servers from 'long' to 'wide' (but without
aggregation) with the IP addresses concatenated to the names of the
glue records, some of which didn't even have IP addresses.

Perl script works quite will for smaller zones, but does not scale well.

Bash script with QSV pipelines and DuckDB (for the 'pivoting') is
extremely fast. So fast that I didn't try Perl with DuckDB.

The Bash script is as readable as the Perl script because I tend to
comment so much that I later can figure out what I did and why,
myself :-)-O

That's 11 cents from a retired Gynecologist :-)-O

el
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 14.02.2025 22:51, Eberhard W Lisse wrote:

That's 11 cents from a retired Gynecologist :-)-O

IT folks typically provide only 10 cents.

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <m19r1pFbvn8U1@mid.individual.net>,
Eberhard W Lisse <nospam@lisse.NA> wrote:

On 13/02/2025 22:59, Kaz Kylheku wrote:

On 2025-02-13, Randal L. Schwartz <merlyn@stonehenge.com> wrote:

[...]

If they don't understand the Perl code, I could recommend a couple

good books...

That makes no sense. Don't you mean Perl books?

Do you know who you are addressing?

I'm sure he does, I'm sure it was meant in jest, and
I'm sure that Randal took it as such.

- Dan C.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

"Dan" == Dan Cross <cross@spitfire.i.gajendra.net> writes:

I'm sure he does, I'm sure it was meant in jest, and
I'm sure that Randal took it as such.

I did. Slight chuckle, but I'm nearly blind to any knee-jerk "Perl is
bad" text.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Dart/Flutter consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig
--- Synchronet 3.21b-Linux NewsLink 1.2