Seeker said:
Next thing was, arrays, but someone said "Go learn awk".
You lose associative arrays with
/bin/sh but we can still simulate indexed arrays. look at
expr() for indexed simulation.
Arrays are simulated by the carriage return in the almquist shell. You may learn
awk if you feel you want to but that may be the breaking point into when to use (Ruby|Perl|Python|Lisp|Java|C++|C).
Perl was designed to displace
awk and
sed and was the first "does everything for you the shell already does language" breaking Doug McIlroy's take on UNIX philosophy "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
I personally <3 ruby. It's designed to be the better perl. Ruby is a very decent unix tool indeed and sits right on top of our paradigm with the shell.
Also another perspective is to look at our toolchain and history.
ed() to
grep() to
sed() to
awk() <-- to perl to ruby =)
Initially when the general purpose text processing tools where being created the concept was if the tool didn't exist break out k&r and go break out the compiler and program a tool in c.
This is how they wanted us to use the system. They also didn't want bloat to our utilities and Kernighan complained when
cat() became endowed with the ability to number all output lines which goes beyond the concept of what the tool was originally created for.
As to answer your initial question. Here is my policy in which your mileage may vary so please take it as a suggested use case but also as my own effort to understand myself the question you propose:
USE CASES:
- I would keep my sh scripts simple and task oriented. (does one thing and does it well). As the time needs to build on those scripts I can call or include the functions into a larger script and now I have begun to build a library.
- I want to move mass amount of files either from jails to physical machines one or more times a week and send myself a status email. use posix scripting for portability and if I hit the need for awk reconsider lighter weighted commands (i.e. cut()). the same goes for sed() and tr().
- I need to calculate and process input from various utilities ps(), last() or parse my logs or filter input /etc/passwd and once again piping that input through and email.
- Larger programs can be built on your now created script library. making sure there is a help option as well as input from file/pipe or args will save your ass one day if you build a larger library. any third party software or non posix commands should be documented in the header. oh and don't use xargs() unless absolutely necessary.
- Need a service running all the time. Use cron if you can. If you need real time results you can build a loop inside you script and launch at boot with nice() but using a high level language will give you threading and concurrency. If you need zero latency write your service in c.
- You need a web frontend for your programs on the net. the shell may not be the best tool for that. not saying you can't do it but the right tool for the right job. Use (PHP| Ruby|Perl|Python). You already have a script archive to fall back on for calling from these languages if you ever need it. So now the question becomes reversed when do I rewrite my sh scripts in (PHP| Ruby|Perl|Python)? When you need concurrency or when they stop being fast enough for your load. I would love to advocate the use of ruby on rails to you but it's only fair to be pragmatic as you already hit an apex with php.
- Finally when you need a gui you have even less options for the shell than you have in other languages. Since php is a specialized language for the web it probably wouldn't be the right tool. your mileage may vary from picking an interpreted language vs compiled language for this task.
Finally I digress. As much as I enjoy learning new tools there is nothing wrong with using the tools we already know. If one app can be done in a single language in which you are already acclimated with there is nothing wrong with just using that language whatever it may be.
~
). If you're going to do large-scale scripts that you want to share with people then you should look into something like Python or Perl if you feel things like sh or tcsh don't offer you enough features.
