12 ms·
For me, it has nothing to do with the number of lines, but the amount of actual computation I am doing. If all I need to do is wire up the inputs and outputs of
by chrismonsanto 13y ago
For me, it has nothing to do with the number of lines, but the amount of actual computation I am doing. If all I need to do is wire up the inputs and outputs of X commands, then shell script is the best tool for the job.
If I actually need to do something with an input or output before sending it to the next command, I'll switch to Python.
For CLI tasks in Python, http://docopt.org/ http://docopt.org/ and http://shell-command.readthedocs.org/en/latest/ http://shell-command.readthedocs.org/en/latest/ are invaluable tools. Yes, I know about Envoy, but shell_command is much nicer to use in my opinion. Envoy doesn't automatically escape arguments, which is annoying for all the reasons that SQL injections are annoying.
- dllthomas 13y agoThat's more true of python than perl, I think - my recollection is that python adds slightly more syntax on top of running external commands. That said, I happily assemble shell scripts of tens (or occasionally hundreds) of lines when it's a good fit...
- barrkel 13y agoIf I actually need to do something with an input or output before sending it to the next command, I'll switch to Python. If it's not something that can be done trivially with sed or awk, I'll consider whether it's something that can be implemented in a generic way to be used elsewhere, in which case I'll write that specific utility, and insert it into the pipeline (with appropriate arguments). Only if it's fairly specific, or I need to package it for distribution, will I consider trying to rewrite everything in a single language script.