Stuff like this does a huge amount of unintentional damage. Every crappy company in the world thinks they're Google and tries to copy them. Google-caliber people might be able to be reasonable about this, but ordinary employees come across something like this and interpret it to mean "bash is evil" and ostracize everyone who tries to write a bash script for anything, no matter how sensible.

At work lately, there's been a spate of contorted "just why?" Python scripts that could've been accomplished elegantly in a handful of lines of shell. While no one would select shell languages as the ideal for a lot of complex logic, data parsing, etc., there's no competition for a shell when you need to do what shells are meant to do: chaining invocations, gluing and piping output, and so on.

Just because they write crappy Python doesn't mean they'd write good shell scripts. For me it indicates the opposite.

As Gary Bernhardt said, and I quote often, it makes sense when it’s right half of the ass.

https://youtube.com/watch?v=ZQnyApKysg4

wow, have seen many of Gary's talks but not this one until now; clearly I missed a gem

> Google-caliber people might be able to be reasonable about this...

I'm not sure about that. Google certainly has some very talented people among their developers, but most of them are so bad at programming that they had to invent their own heavily watered down programming language.

Shell is brilliant until you need to keep a filename in a variable. Or, worse, read filenames from the output of a command. Since basically everything except '/' and '\0' is a valid filename character, the potential for mishaps or exploits is huge.

That's where we came in with the need to use "$@" vs the unsafe-by-default bare $@.

> here's no competition for a shell when you need to do what shells are meant to do: chaining invocations, gluing and piping output, and so on

There is no reason this shouldn't be easy to do in Python too, if it is then it is something a library should fix.

But bash IS evil.

I mostly agree, but it's sometimes a necessary evil. There's a reason I praised shell languages in general rather than bash specifically; fish shell, for instance, is much more comfortable.

Why?

In most languages, you don't need to know/understand this much minutiae about string handling; as an example, I've been doing open source dev for years now in Bash and I never knew the distinction OP posted.

Related, the longer your shell script gets, the greater potential for accumulated foot-guns. When you finally do the rewrite, will you be bug-compatible? And once discovered, will you be confident on which side the bug lies?

An aside: when did the phrase "foot-guns" become a thing.

Cuz I've never heard it until this thread, where it pops up multiple times. Great phrase but went 0-60 in usage.

I'm pretty sure it's at least as old as usenet and mail lists

"If you are writing a script that is more than 100 lines long, you should probably be writing it in Perl instead."

This is true, especially of Python scripts.

That way, it will never be rewritten again; because nobody will be able to read it.

Edit: Getting some downvotes, so to clarify, I am indeed saying that concerting something from Python to Perl has a high likelihood of making it for less maintainable. I get that people can write good perl. As someone who has had to maintain perl in the past; the fact is that it's far more common for the end result to be horrible perl. I have some issues with Python, but it is FAR more maintainable than perl.

Let me drag this to something concrete: if you are interviewing, it is almost impossible to pass an amateur "Perl screen".

Every single person who doesn't use Perl every day, professionally knows a different subset of Perl. This is one of the few times where being more knowledgeable than the interviewer is also a problem. You will write something, and the interviewer will question you on it because he has never seen it.

I finally solved this problem by bringing one of my personal programs written in Perl and also rewritten in Python so we could talk about it. Now, the interviewer is in MY subset of Perl AND can't argue because I have working Perl code in front of him. This was back in the 1990's when everybody in VLSI design expected you to know Perl.

Because of this "different subset" issue, if you want to maintain a Perl script, you have to basically know the entire language. This is what makes maintaining Perl scripts so difficult.

This "different subset" problem is the whole reason I left the Perl ecosystem back in 1996(!) at the height of Perl's popularity and never looked back.

> This is one of the few times where being more knowledgeable than the interviewer is also a problem

I have actually found that is pretty much always a problem. If you pull out something the interviewer is unfamiliar with they will often assume you are full of it. I have had such people refuse perfectly good explanations for things they haven't heard of because they assume incompetence before that possibility.

That's a sign of a bad interviewer and thus also an indicator of potential bad management.

I'd take those experiences as a blessing rather than a curse.

Indeed. I've "failed" interview screens because the reviewer's Python installation was broken, and rather than reading the traceback and realizing this, they just assumed the candidate's code was broken.

Last I knew, that position was still open almost a year after the fact.

As an experienced Perl programmer, what's your opinion of Raku? Is it a worthwhile replacement or too little too late?

> As an experienced Perl programmer, what's your opinion of Raku?

Perl5 still works fine, and is maintained.

> Is it a worthwhile replacement or too little too late?

False dichotomy - see above.

It's been too little too late for many years, while it was still named Perl 5 for so long.

Raku is the new name for Perl 6, not Perl 5.

> back in the 1990's ... everybody in VLSI design expected you to know Perl.

Has this changed at all?

Dunno. I finally left VLSI design because it was effectively a career dead end. Sense a trend? :)

While I still regard myself as a vastly better VLSI designer than programmer, my ability to wrangle software the whole way from assembly language on a chip to just shy of the top of a full web stack pays far better than my ability to wrangle transistors. And, in my opinion, attacks far more interesting problems.