Hacker News Reader

Comment by japhyr | Hacker News Reader

I think I might have accidentally down voted you. That was helpful feedback for me.

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.

File 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 :(

Here 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.

> 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?

  $ 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.

> 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.)

TIL. Thank you very much! :)

A basic technique in bash is "UMQ": Use More Quotes

Reply on news.ycombinator.com