On 4/8/22 6:54 PM, Eli the Bearded wrote:
> In comp.os.linux.misc, 25.BX944 <25BZ494@nada.net> wrote:
>> Perl - UGH ! - Why ??? :-)
>>
>> Everybody thinks they have The Better Way. Mostly
>> they DON'T.
>
> Perl was a great improvement over awk/sed/etc of varying degrees of
> bugs. Making the syntax a weird amalgam of awk/sed/C proved to be a
> point of contention.
>
>> In any case the Py2 -> Py3 issue is usually quite
>> trivial. Don't bother with automated 'converters'.
>> 99% of it will be the damned print() statements :-)
>
> Most issues I've run into have been over character encoding changes
> between 2.x and 3.x.

That can be an issue, but again it depends on what
you're trying to do at the moment. Frankly I just
stopped doing PY2 as soon as PY3 seemed up to speed
and my older PY2 scripts kinda needed some updating
and features anyway, so I re-wrote them in PY3 in
an "improvement" state of mind which made it far
easier to bear :-)

Almost everything I do is intended for the USA, so
I stick with straight-up 8-bit ASCII as much as
possible, which makes for fewer unicode issues.
Now sometimes you just can't escape - try using
Python to do a dialog with a 'C' service and you
pretty much HAVE to encode and decode the back
and forth. Not HARD, but it makes it all CLUNKIER.

But shell scripts are certainly no panacea ...

> [I wrote:]
>>> This is why Perl normalized statements like "require 5.20.0;"
>> Great ... what if you wind up with 5.19.9 or 5.20.1 on
>> a box ?
>
> That statemen is a requirement of _minimum_ version. 5.32.0 works for
> "require 5.20.0;". And Perl can easily be installed as multiple
> versions, although #! lines get complicated.
>
> :r! ls /usr/local/bin/perl5*
> /usr/local/bin/perl5
> /usr/local/bin/perl5.00403
> /usr/local/bin/perl5.00502
> /usr/local/bin/perl5.00503
> /usr/local/bin/perl5.10.1
> /usr/local/bin/perl5.14
> /usr/local/bin/perl5.14.1
> /usr/local/bin/perl5.14.2
> /usr/local/bin/perl5.14.4
> /usr/local/bin/perl5.14.4-5.14.4
> /usr/local/bin/perl5.20
> /usr/local/bin/perl5.20.0
> /usr/local/bin/perl5.20.2
> /usr/local/bin/perl5.20.3
> /usr/local/bin/perl5.20.3-5.20.3
> /usr/local/bin/perl5.22
> /usr/local/bin/perl5.22.1
> /usr/local/bin/perl5.22.2
> /usr/local/bin/perl5.22.3
> /usr/local/bin/perl5.22.4
> /usr/local/bin/perl5.22.4-5.22.4
> /usr/local/bin/perl5.22.new
> /usr/local/bin/perl5.24
> /usr/local/bin/perl5.24.1
> /usr/local/bin/perl5.24.1-5.24.1
> /usr/local/bin/perl5.24.3
> /usr/local/bin/perl5.24.3-5.24.3
> /usr/local/bin/perl5.24.new
> /usr/local/bin/perl5.6.0
> /usr/local/bin/perl5.6.1
> /usr/local/bin/perl5.8.8
> /usr/local/bin/perl5.new
>
> (Many of those are symlinks. There's only one 5.22.x installed, but for
> #! lines previously installed names are kept.)

You're making me feel even happier that I never got into Perl
beyond tweaking the odd line in some pre-existing script :-)

>> 5.20.1 may be perfectly compatible with 5.20.0
>> but the installers and other stuff WON'T WORK unless you
>> have an EXACT match - which, with rapid evolution, is
>
> Except it does work, mostly. I've had issues with 5.6.x code breaking on
> newer Perl, but only ten plus years later.
>
>> I don't really love compiling from source ......
>
> I find package managed versions of code often work, except for stuff I
> get from github that needs newer libraries. libharfbuzz has caused me a
> lot of grief in recent years, due to older one being standard on the
> Ubuntu I'm using and wanting tools that need newer versions.
>
>> NOTHING is *completely* stable. Again, I've discovered that
>> avoiding the latest tricks - ie programming in a style a couple of
>> years behind the curve - solves almost all issues.
>
> That's very true.

Every time there's a new minor version - be it Perl or Python
or almost anything - there's always a rush of subversions out
within a month. Sometimes the only way to find out what's wrong
with code is to get lots of people to USE it. Automated error-
guessers can only get you so far ; idiot users are the REAL
error-finders.

So yea, if it's a Very Important App just don't USE those
much-hyped 'improvements'/'features' for a year or two. By
the time you're ready to learn them, they'll have the bugs
worked out and you won't get mystery failures.

The Version Problem IS a great annoyance of Linux/BSD in
general. So often you can't go back the package that worked,
or just GDebi the latest package, because SOME (or many)
libraries are just not QUITE the exact right version, and
if you try to update those THEY have dependency problems
and other apps depend on the current versions and so forth.
For all its horribleness, Winders IS a lot easier in that
respect.

Recently I had a security-cam server that had been running
perfectly for a long time on TumbleWeed. Suddenly it all
went wrong. Why ? OpenSUSE decided to switch to a version
of FFMPEG that didn't support h264 cameras. After playing
library wack-a-mole for hours trying to install the version
that DID, well ... I eventually copied the relevant stuff
and nuked the whole box. It runs Ubuntu Server now, which
has the correct FFMPEG. (actually OS left out a LOT of
Good Old Utilities during that version 'upgrade' - including
some basic utilities I used to monitor the health of the box).

>> YT does this *deliberately* - ie it's intentional sabotage. They
>> REALLY don't want you to download - they want you in the live
>> interface so they can spit ADS at you and SPY on you.
>
> Yeah, I fully understand that. Which is why I really like having a
> downloader that works.

Hard for them to keep up with YT though - esp with freeware
where the developers are working on donations.

And I've seen people BERATE freeware developers because their
app doesn't do this or that ... I'm surprised they don't add
a "Nuke This Idiots PC" module in there ... just press the
Big Red Button and ...... :-)

On 3/28/22 19:25, Andrei Z. wrote:
> "Please stop writing shell scripts"
>
> https://pythonspeed.com/articles/shell-scripts/
>
> "Everything works fine.
>
> And then, one day, your shell script does something completely wrong.
>
> That’s when you realize your mistake: bash, and shell scripting
> languages in general, are mostly broken by default. Unless you are very
> careful from day one, any shell script above a certain complexity level
> is almost guaranteed to be buggy… and retrofitting the correctness
> features is quite difficult."
>

Every software needs to be maintained.
Every software needs to run in the intended context to be useful.

There is nothing inherently wrong with shell scripts. They are a tool as
any other. As long as we are aware of the qualities and weaknesses of
our tools, we can choose the most adequate one for the job.