7 ms·

Shell scripts have their use but at the point when your script needs output coloring or printing debug information, it is time to switch to Python. Edit: Place

• mhd 13y ago
  Or Perl, of course. Although I've seen some pretty big collections of shell scripts used for deployment, configuration etc, and all that in a rather heterogeneous Unix environment. Then again, that was Korn Shell, which supports larger programs a bit better than plain bash.
  • cbsmith 13y ago
    Korn shell really ought to be considered "Bourne shell compatible Perl". ;-)
• fizerkhan 13y ago
  Yes, you are correct. But some people crazy to write everything in shell scripts.
  • Fuxy 13y ago
    I find shell scripts confuses the heck out of me whenever they try to do something a little more complicated the piping. Even this left me a but confused like how do the functions get the input parameters does the * in echo -e "$RED$*$NORMAL" have something to do with it? There's just so many obscure ways of doing the same thing not to mention there's very few good places to teach you shell scripting and shell scripting best practices. I'd rather just go with python. It's easier to read.
    • coolj 13y ago
      http://www.tldp.org/LDP/abs/html/ http://www.tldp.org/LDP/abs/html/ TLDP's Advanced Bash-Scripting Guide is a great resource for learning bash. For example, this section talks about the meaning of "$*": http://www.tldp.org/LDP/abs/html/internalvariables.html#ARGLIST http://www.tldp.org/LDP/abs/html/internalvariables.html#ARGL...
      • barrkel 13y ago
        Free advice: you almost never want $. Almost always what you want is $@, usually in the form "$@". It doesn't matter for this example, but $ is usually a code smell.
    • unhammer 13y ago
      http://mywiki.wooledge.org/BashGuide http://mywiki.wooledge.org/BashGuide is the ultimate bash guide, along with http://mywiki.wooledge.org/BashFAQ http://mywiki.wooledge.org/BashFAQ For learning the differences between POSIX sh and bash (which can trip you up if you want to run on systems without bash, or if you simply don't know that #!/bin/sh is different from #!/bin/bash), see http://mywiki.wooledge.org/Bashism http://mywiki.wooledge.org/Bashism And regarding how to parse your example, the $* in a string expands to all input parameters to the function, separated by the first character of the IFS variable (e.g. space).
    • unhammer 13y ago
      Also, there's no reason to use uppercase for all variables, it's just that environment variables are by convention uppercase so people seem to think their local vars need to be uppercase too.
  • 616c 13y ago
    Of course, there are also some people crazy enough to write web apps in C, C++, or dare I say Haskell! The latter has become popular, but every tool has a purpose, and every tool can be re-invented, like if you are a garbage social app so popularly social you compile your PHP into C++ and give it a music genre name. I am sure no one will get that reference. :-)
    • cgag 13y ago
      What's crazy about using an extremely high level language (haskell) for web dev?
      • 616c 13y ago
        It isn't as far as I am concerned, but it might upset some people.
• 616c 13y ago
  I get what you mean, but there are reasons for shell scripts to stay shell scripts, and not move to Python. One such project [0] is patching Android to allow for a privacy framework. What would Python offer me for diffing and patching that cleanly written shell scripts would not? Shell is still good for one thing: piping commands together. You can do that in Python, but I think even complicated output coloring and debugging scripts should stick to shell when the focus is piping utilities in and out of each other. Python can do that, but it is not its sweet spot, in my opinion. I am sure others disagree. Different tools for different jobs, blah blah. [0] https://github.com/mateor/auto-patcher https://github.com/mateor/auto-patcher
  • praptak 13y ago
    Agreed. Piping and a few of the other syntax niceties ('&&' for conditionally chaining processes is my favorite) are a hard match for even the best process-management library you might have in a general purpose language. Maybe a Lisp DSL could match that, I don't know.
    • klibertp 13y ago
      Check it out and say for yourself - I didn't try it yet, but as a Lisp fan I certainly will: http://www.scsh.net/docu/docu.html http://www.scsh.net/docu/html/man-Z-H-3.html#node_chap_2 I especially love the acknowledgements section :) http://www.scsh.net/docu/html/man.html
      • 616c 13y ago
        Does it still work well? I am very interested in this. I really like Chicken Scheme because it compiles to portable C, and I was wondering why there has not yet been a Scheme shell this morning. Guess I was naive to think there was not without a proper Google-fu session. UPDATE: I take that back, it appears some still works on it. That page just seems outdated, by a while now. https://github.com/scheme/scsh/commits/master https://github.com/scheme/scsh/commits/master
        • 13y ago
• kamaal 13y ago
  Python is an ideal replacement for small Java programs, not Shell. The moment your script needs any more than 10 regular expressions, or dealing with >3 files all in a complex interplay- use of Perl becomes inevitable. And that is something like the very utmost basic thing you can do with Perl. Python is more like tried-to-be-scripting-but-is-a-web-framework language.
  • rubinelli 13y ago
    I agree that Python is a general-purpose language that could replace much of the Java code you see around, but I never got the feeling that it is particularly well-suited for the web. For one thing, with significant whitespace, it's harder to embed snippets of code in HTML or vice versa, so you have to work with a templating library right from the beginning. Some will see this as a blessing in disguise, but for very small projects or mostly self-contained components, having logic and presentation in one file is much more productive.
    • kamaal 13y ago
      Ironically bulk of all the Python out there is web code. In fact Django, Twisted and Zope is all the Python code there is. Scripting was never Python's forte. Scripting is all about succinctness, power and providing as much power with fewer constructs and restrictions. Which happens to be exactly the very opposite of Python goals, and some thing which more or less as a mission statement Python tries to achieve. This is why Python will likely never be a very successful scripting language. Python was always a web language for frustrated java programmers who couldn't put with java's problems anymore. Much of Python's success is in web frame work area. Which was previously Java's territory.
      • PommeDeTerre 13y ago
        Yes, Python is obviously used for web development. But it's very short-sighted, and even absurd, to claim that the "bulk of all the Python out there is web code". It's even more absurd to claim that "Django, Twisted and Zope is all the Python code there is." That's utter nonsense, in fact. There are numerous non-web applications that use Python extensively, whether they're partially or fully implemented in Python, or whether they can be scripted using Python. Then there are the numerous libraries and frameworks for Python, from GUI toolkits through to scientific computation packages. Many, many organizations use Python internally for a very wide variety of tasks and systems, without broadcasting such use loudly, if at all. This ranges from one-off scripts up to entire multi-million-line software systems. I sure hope that you're joking, but it just isn't coming across as a joke. Nobody can seriously claim that "Python will likely never be a very successful scripting language" when it has undoubtedly been one of the most successful, and versatile, programming and scripting languages around for many years now.
• noonespecial 13y ago
  I use these languages in ascending order for sys-admin/config: shell -> perl -> python. On OpenWRT systems, sometimes even microperl won't fit. All you've got is shell. (and sh only, none of this fancy bash stuff(1)) Its good to be able to do things at many levels. (1) http://stackoverflow.com/questions/5725296/difference-between-sh-and-bash* http://stackoverflow.com/questions/5725296/difference-betwee...
  • Torgo 13y ago
    At my first "real" job I used to work on a RS-6000, a couple hundred-grand machine. The admin wouldn't install _anything_ non-stock other than a JVM on it. It taught me how to get around using only BSD Unix tools and Bourne Shell. It was an enormous pain in the butt, but what I learned has been utterly invaluable over the course of my career.
  • reidrac 13y ago
    Well, it's more like: shell -> awk -> perl -> python. I use awk from time to time, specially when I need to process a file line by line and the task is too simple to use python (ie. an awk one-liner will do!).
    • noonespecial 13y ago
      Very true. I really need to sharpen my awk/sed/grep skills, but damn, some of those 400 character awk "one-liners" hurt my brain. Perl regexes are rightfully known for being cryptic but those awk statements make me cry for my mama.
• michaelry 13y ago
  True if python is available, but on a small embedded system this is not always the case.
• unhammer 13y ago
  I tend to think of colouring and debug output as standard shell script boilerplate. I typically switch to Python (or similar) when I need something like multidimensional arrays / dicts (not portable in awk), or in general want to run more complex parsing or transformations on input. The more advanced string functions of bash I always have to look up (is it ## or %% that removes from the start of the string?), and for/while loops are in general a lot slower. But for file system operations, stringing together commands, keeping track of backgrounded commands (using multiple threads without even thinking about it), and even turning arbitrary programs into "daemons" (using fifo's), nothing beats shell scripting.
  • jzwinck 13y ago
    You say nothing beats shell scripting for: - Filesystem operations. How many times have we seen programs using "ls * .foo" when they needed to use "find -name '*.foo'" to avoid command-line length limits? I answered this very question on StackOverflow this week. How many seemingly-capable software shops will churn out shell scripts which misbehave when a path has a space or other "weird" character in it? Even Apple fell prey to that one, about ten years ago, and destroyed some users' data. - Stringing together commands. This encourages abominations like "cat myfile | grep foo | awk '...'". Just use awk if you're into that, but the shell has a knack for "tricking" people into spawning extra processes that are not really needed (indeed this is one of the most frequent performance sinks in shell scripts). And what about error handling for the several subprocesses? It's usually ignored for N-1 of them. - Keeping track of backgrounded commands (using multiple threads without even thinking about it). Yes, you can use multiple cores without thinking--that can be cool. But what if you want to do N units of work on many fewer than N cores? You ought to use a pool, but there's no such thing in Bash. Maybe you're clever and use "xargs -P" for this, but most people don't. - Turning arbitrary programs into "daemons". I use start-stop-daemon for that (it's included in Debian, and I easily wrote a workalike in Python when I had to use a system that didn't support it natively). Just about the only thing here that shell scripts are really good for is doing things "without even thinking about it." Once when I was asked why shell scripting was not a good idea for production programs, I reviewed a smallish sample Bash script that had been deployed. I found a dozen latent bugs, 50% of which would have never have happened with Python (or Go, or...).
• Millennium 13y ago
  Python is great for many things, but sometimes you need something lighter. That's not to say that Python is heavy -Java is heavy- but there are environments so constrained that even Python is not light enough. This is where shell scripts can come in handy.