4 ms·

So if I compile a busybox-like crunched binary with a variety of "do one thing well" UNIX utilities, including sh itself, and then I write a shell function that

So if I compile a busybox-like crunched binary with a variety of "do one thing well" UNIX utilities, including sh itself, and then I write a shell function that only calls this single binary it its various incantations and uses pipes and temporary files residing on tmpfs or mfs (instead of reading entire files into memory the way perl does), and this binary used like this can do all that Perl can do, why should I use Perl? That's my question.

chromatic 15y ago
* [If] ... this binary used like this can do all that Perl can do...* If you can do that, great! Do it. That's a big job though, and it's not worth my time even to consider how much work it is. That's why I don't bother.
- 101000101 15y ago
  It's actually a very small job. The hard part I guess is learning to do things with the shell and UNIX utilities instead of Perl. And simplifying what you do and how you do it. If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities becomes a prohibitively painful exercise. I want to learn Perl. But I just cannot find the motivation because I never need more than what UNIX gives me.
  - Mithaldu 15y ago
    You wrote a website with only the shell and unix utilities?
    - 101000101 15y ago
      I write small, simple shell functions using a single busybox-like binary that do the same things as Perl modules. I store the shell functions in a local repository and load/unload them as needed. I make "programs" by combining different functions.
  - ccashell 15y ago
    > If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities becomes a prohibitively painful exercise. Here again, your ignorance is showing, and you are projecting your own limitation onto others. You suggest that someone who uses Perl feels the need to use it everywhere, that it's more complex than shell tools, and that Perl somehow becomes a crack-like addiction, forcing you to never use command line tools again. That's just plain silly. There are tons of people who make heavy use Unix tools and Perl. This isn't an either-or situation like you seem to be pushing. They're all just tools for solving problems. The smart thing is to recognize when each tool is appropriate, and then use them properly. For example, the other day I was working with a log file. Initially, I was beating on it with command line tools: find, grep, cut, sed, sort, uniq, wc, etc. Eventually, I got what I needed out of it, but knew I was going to need something more to present to my team, so I pulled out awk, and I wrote a little script to extract the data and generate a simple report. A few days later, management saw the report, and liked it. But, they wanted some additional features added, and some changes to the processing. I could have hacked what they wanted into the awk script, but the processing had gotten complex enough that I knew I was better off making the jump to Perl. So, I rewrote it in Perl, and got everything they wanted. Additionally, it had the flexibility with Perl that the next two feature requests that management made were implemented in just a few minutes each. Also, in case you weren't aware of it, Perl integrates and happily makes use of external commands. If there's a tool out there that will do some heavy lifting for you, Perl makes it trivial to call out to that command (just like backticks or $(/bin/foo) in bash). If you really want to do complex scripting with Unix tools, then you're either limiting yourself to pretty trivial work, or you're making things a lot harder on yourself than they need to be. Perl was created for a reason, and it's a good one. Small scripts or glue to tie things together, use a shell script and Unix tools. Complex scripts, use a real scripting language, make things easier on yourself, and get more work done in a faster, better way.
ccashell 15y ago
So, if I can build a wagon with a lawnmower engine from parts, and it is able to putter down the street (barely) faster than I can walk, why should I use a car? That's my question. I'm a sysadmin. I have been for years. My coworker calls me "the encyclopaedia of Linux", because I know all the command line tools, their functions and features, and how to tie them together. I write one-liners that are 5 lines long. And I like it. I love the Unix philosophy and design and tools. But, that doesn't make it a perfect fit for anything. Shell scripts are very limited and painful for a lot of things. When I'm writing something I expect to be 50 lines or less, shell scripts and *nix utilities will usually (not always, but usually) get the job done (especially if you include sed/awk in there). For anything more than that, I break out Perl and I never regret it. Complicated logic, non-trivial data structures, multiple chains of processing, these are things that just don't do well with shell scripts and tools. It's also a lot cleaner and simpler using a real data structure, instead of forcing everything into pipes and temporary files. Note: Your comment of "instead of reading entire files into memory the way perl does" shows your ignorance. Perl is an immensely flexible tool, and it gives you the ability to process files line-by-line, stream-style, or by reading the entire file into memory. Both methods are trivial, and having the choice means you can use whichever method is appropriate for the task at hand (your comment suggests that reading the whole file is somehow "wrong", but for many tasks it's a faster and cleaner method).

chromatic 15y ago

* [If] ... this binary used like this can do all that Perl can do...* If you can do that, great! Do it. That's a big job though, and it's not worth my time even to consider how much work it is. That's why I don't bother.

101000101 15y ago
It's actually a very small job. The hard part I guess is learning to do things with the shell and UNIX utilities instead of Perl. And simplifying what you do and how you do it. If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities becomes a prohibitively painful exercise. I want to learn Perl. But I just cannot find the motivation because I never need more than what UNIX gives me.
- Mithaldu 15y ago
  You wrote a website with only the shell and unix utilities?
  - 101000101 15y ago
    I write small, simple shell functions using a single busybox-like binary that do the same things as Perl modules. I store the shell functions in a local repository and load/unload them as needed. I make "programs" by combining different functions.
- ccashell 15y ago
  > If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities becomes a prohibitively painful exercise. Here again, your ignorance is showing, and you are projecting your own limitation onto others. You suggest that someone who uses Perl feels the need to use it everywhere, that it's more complex than shell tools, and that Perl somehow becomes a crack-like addiction, forcing you to never use command line tools again. That's just plain silly. There are tons of people who make heavy use Unix tools and Perl. This isn't an either-or situation like you seem to be pushing. They're all just tools for solving problems. The smart thing is to recognize when each tool is appropriate, and then use them properly. For example, the other day I was working with a log file. Initially, I was beating on it with command line tools: find, grep, cut, sed, sort, uniq, wc, etc. Eventually, I got what I needed out of it, but knew I was going to need something more to present to my team, so I pulled out awk, and I wrote a little script to extract the data and generate a simple report. A few days later, management saw the report, and liked it. But, they wanted some additional features added, and some changes to the processing. I could have hacked what they wanted into the awk script, but the processing had gotten complex enough that I knew I was better off making the jump to Perl. So, I rewrote it in Perl, and got everything they wanted. Additionally, it had the flexibility with Perl that the next two feature requests that management made were implemented in just a few minutes each. Also, in case you weren't aware of it, Perl integrates and happily makes use of external commands. If there's a tool out there that will do some heavy lifting for you, Perl makes it trivial to call out to that command (just like backticks or $(/bin/foo) in bash). If you really want to do complex scripting with Unix tools, then you're either limiting yourself to pretty trivial work, or you're making things a lot harder on yourself than they need to be. Perl was created for a reason, and it's a good one. Small scripts or glue to tie things together, use a shell script and Unix tools. Complex scripts, use a real scripting language, make things easier on yourself, and get more work done in a faster, better way.

ccashell 15y ago

So, if I can build a wagon with a lawnmower engine from parts, and it is able to putter down the street (barely) faster than I can walk, why should I use a car? That's my question. I'm a sysadmin. I have been for years. My coworker calls me "the encyclopaedia of Linux", because I know all the command line tools, their functions and features, and how to tie them together. I write one-liners that are 5 lines long. And I like it. I love the Unix philosophy and design and tools. But, that doesn't make it a perfect fit for anything. Shell scripts are very limited and painful for a lot of things. When I'm writing something I expect to be 50 lines or less, shell scripts and *nix utilities will usually (not always, but usually) get the job done (especially if you include sed/awk in there). For anything more than that, I break out Perl and I never regret it. Complicated logic, non-trivial data structures, multiple chains of processing, these are things that just don't do well with shell scripts and tools. It's also a lot cleaner and simpler using a real data structure, instead of forcing everything into pipes and temporary files. Note: Your comment of "instead of reading entire files into memory the way perl does" shows your ignorance. Perl is an immensely flexible tool, and it gives you the ability to process files line-by-line, stream-style, or by reading the entire file into memory. Both methods are trivial, and having the choice means you can use whichever method is appropriate for the task at hand (your comment suggests that reading the whole file is somehow "wrong", but for many tasks it's a faster and cleaner method).