I reckon youll still be fighting with the shell syntax
I can type find | xargs pipes in my sleep.
doublechecking that the switches and utilities you got so used to in bash are actually present in the shell you need to run it on
Present in the shell? They’re external binaries; which shell you’re using is irrelevant. Maybe “present on the system,” except that if find, xargs and rm are not present, that is one very broken system. And the -print0/-0 switches are available on these commands on all Unixoid systems where I cared to look.
And all that is far more likely to be around than perl, in any case.
If your portability argument concerns moving between Windows and Unix, well, I can see how someone working on Windows would prefer to always use Perl… :-)
Makeshifts last the longest.
| [reply] |
Well, since you are being snarky I'll respond in kind: I doubt it, i reckon youll still be fighting with the shell syntax, and doublechecking that the switches and utilities you got so used to in bash are actually present in the shell you need to run it on. And even then you still wont be 100% confident that it will all work as expected.
Bollocks. find | xargs has worked on every Unix system I've used for the last 30 years. Out of the box. In any shell, as the only 'shell' thing here is the pipe, which is universal. It has worked long before Larry released perl1.0, and it will continue to work long after perl5 will be a distant memory.
Which to me is the reason that perl scripts beat shell scripts hands down pretty well every time. I can use the same perl script on every shell and OS I can find pretty much. Your shell script will only work on a small subset of them, and will require massive changes for some of them.
The shell solution will work on at least anything that's POSIX compliant. Will your Perl program work in perl6? How would you know - it may work on todays version of perl6, but maybe not on next weeks. As for Perl being present on the OS by default, for many OSses, it's only quite recent that their OS came with some version of perl5 installed.
Shell scripts are only worth thinking about if you are a monoculture programmer. Since I'm not I view them mostly with contempt. Who needs shell scripts when you have perl scripts instead?
So, you do everything with Perl scripts, so you're not a monoculture programmer? Interesting. What's your definition of monoculture then?
But you're right. Once you have a truck, you have no need for a bicycle. It's much easier to start up the truck and find a parking spot, just to get a newspaper from the shop around the corner. It's cheaper as well. Bicyclists are monoculture traffic participants - none of them know how to drive a car.
| [reply] |
So, you do everything with Perl scripts, so you're not a monoculture programmer? Interesting. What's your definition of monoculture then?
Yes, pretty well anything I write that has to be run on multiple enviorments (which in theory is most of what I do) is written in perl.
Monoculture to me is writing code that expects to be run on/in a certain OS/Shell/Architecture.
But I will say that your bike/truck point is a powerful one.
---
$world=~s/war/peace/g
| [reply] |
"Monoculture" should not include "shell" any more than it should include "perl". Both are just interpreters that one may use to write the programs we're referring to.
Besides, I write perl to run on only three more platforms than I write for shell. I write cross-platform shell at work for AIX (4, 5), Sun (5-9), HP/PARISC (10+), HP/ia64 (11.23+), and Linux for ia32, ia64, x86-64, ppc, and s390/s390x. Add Windows for ia32, ia64, and x86-64 to get my perl list. I write both production and tooling in both languages for all platforms. And I have over 10,000 lines of production code that I've written and/or maintain in each language.
I dispute any attempt to claim cross-platform problems in shells at any significant difference from perl. Core tools, much like core perl, is pretty much ubiquitous. Non-core tools, which perl would often need to use system() to call anyway, won't be any more difficult in shell than perl.
In fact, the only reason why we don't actually ship perl scripts (we only use them for development) but we do ship shell scripts is trying to convince management to rely on a decent version of perl being installed everywhere. We have no problems with being convinced of Bourne Shell syntax everywhere (although we actually use bash on Linux). The version dependancies in shell are way less than we've had with perl where multiple times we've needed upgrades to handle things. Shell has just worked.
For minor, one-off scripts, I still fall back to shell. For complex things, I move over to perl. But even then, there are just some limitations. Such as trying to have a simple command to effect great changes to one's environment. Perl just can't do it without spawning a subshell, or running inside a shell 'eval' statement, both of which have annoyances/limitations. Contrast with the shell's limitation on compile-time checking (there is none) or lexical variables (again, no such thing), and you end up with reasons to keep both tools in one's toolchest.
For me, learning both tools (shell and perl) has made me more efficient on all platforms. Especially unix/linux. Knowing their limitations allows me better access to each of their strengths.
| [reply] |