5 ms·
No problem... the way I think about is that Python/Perl/Ruby are for data structures, logic and control flow; while shell is for configuration and data flow. A
by chubot 13y ago
No problem... the way I think about is that Python/Perl/Ruby are for data structures, logic and control flow; while shell is for configuration and data flow.
As mentioned above, things that belong in shell, and NOT in Python:
- file system paths (these are parameters to Python scripts, not hard coded)
- port numbers
- user names
- other config values
- concurrency -- you can get really far with xargs -P, and sometimes &
- pipelines (try doing this in Python without shelling out; it's horrible)
Things that belong in Python and NOT shell:
- complex control flow (e.g. I rarely write loops in bash; never a nested loop)
- data structures (bash has hash tables, but I never use them)
- arithmetic
- parsing and cleaning individual lines or fields of data
Basically it's policy vs mechanism. They really are mutually exclusive, and work well together.
- rix0r 13y agoFile system paths may belong in the shell, but what about paths with spaces? To be honest, I trust myself more manipulating paths in a language like Python than to put all quotes in the correct places in Bash :(
- chubot 13y agoHere are the quoting rules I use: - Avoid paths with spaces :) - If you have to handle paths with spaces, use double quotes everywhere, e.g. "$pidfile". - Always use "$@". I've never found a reason to use $@ or $* unquoted. I also write unit tests (in shell) if there is something unusual I know I have to handle. That's it. I don't think it's hard at all, although you will certainly see scripts in the wild where the author was confused about quoting, and quoting hacks pile upon hacks. If you use a consistent style, it's very smiple. There is a learning curve like there is with any language, but it's totally worth it. Shell is an extremely powerful language, and saves you MANY lines of Python code. I would say Python is definitely the easiest language to learn, but bash is not harder than say JavaScript.
- onli 13y ago> If you have to handle paths with spaces, use double quotes everywhere, e.g. "$pidfile". I'd like to add: Always use double quotes around paths. Or is there something I'm missing here?
- claudius 13y ago$ ls -l "*" ls: cannot access *: No such file or directory Of course, you might want that exact behaviour, but sometimes you want e.g. all .table files in a path with a space. I believe $ ls -l "path with/lots of spaces/"* is the correct solution, but it seems silly. I'm not entirely sure why variable expansion works inside double quotes but wildcard expansion doesn’t.
- elwin 13y ago> I'm not entirely sure why variable expansion works inside double quotes but wildcard expansion doesn’t. That's because a double-quoted expression is supposed to evaluate to a single word. Wildcard expansion can result in multiple words, but parameter expansion doesn't. (Except for things like "$@". With bash, the rules always have exceptions.)
- claudius 13y agoTIL. Thank you very much! :)
- rhizome 13y agoA basic technique in bash is "UMQ": Use More Quotes