Shell Style Guide

Post by Lio » Tue, May 15, 2018, 5:21 PM UTC

bm1362 wrote: post #82

jerf wrote: post #75

Earlier quoted context omitted.

It's a 10-20 line Python script if you write it without any support code. If you're writing any amount of Python code that does shell things, you should either write or get an existing library. Also, it really isn't 10-20 lines to spit out the contents of some files in Python: >>> filelist = ["tmp.pl", "tmp.go", "Tmp.hs"] >>> for f in filelist: ... print(open(f).read()) It's trivial to code golf that down to 1 line,…

for i in ‘ls /tmp/foo’; do echo $i | grep bar | cut -d’-‘ -f3,4; done Is just so much easier to remember than Python’s OS library, right? I can intuitively string that together but can’t write python without looking up the docs and reading a paragraph about idiosyncrasies.

Post by computerfriend » Tue, May 15, 2018, 5:24 PM UTC

chrisfinazzo wrote: post #94

pas wrote: post #81

Earlier quoted context omitted.

Exchanging Bash for Python is a folly. Python seems to handle complexity better, but only on the surface. (Basically Python has nice data structures, great string formatting, and .. that's it.) Setting up the Python environment requires something, because Python comes in many flavors (2 vs 3, system installed, user installed, /usr/local) and there are a bunch of factors (pip, pyenv, pipenv, PYTHONPATH, current direct…

I would be remiss if I didn't mention shellcheck, which will also warn you against doing stupid things. Very useful when debugging. https://github.com/koalaman/shellcheck

Post by adrianhel » Tue, May 15, 2018, 5:25 PM UTC

nameless912 wrote: post #161

gre wrote: post #127

> If performance matters, use something other than shell. I wrote a script that wrapped compiler calls to make dummy output files to debug a huge compilation. Since startup time was the most important metric, bash actually had by far the best performance.

People rag on bash a lot, but it now forms the core of a major deployment system I built at work. I'm not happy that it's in bash, but every other solution was worse, and it calls out to other tools (e.g. Ansible and Terraform) when they're appropriate. People have forgotten the subtle art of realizing what tool is best for the job. If all you're doing is stitching together other tools and doing some logging, bash is…

Post by bm1362 » Tue, May 15, 2018, 5:30 PM UTC

Too wrote: post #158

jerf wrote: post #122

Earlier quoted context omitted.

I said Python wasn't going to be more concise. I said it has a variety of other useful properties. For instance, at least as I write this, you have "cut -d’-‘"; I assume you meant apostrophes (something getting too polite in a c&p, I assume) but the apostrophes are unnecessary, but you're so used to the compromises in shell I talked about you probably put those in there automatically. I'm not criticizing that; it's a…

It's hilarious in these discussions that every time someone comes to show how they can do the equivalent code in much less lines of bash there are always always always bugs of these sorts. And then the parent even specifically pointed out that files with spaces would be a minefield. Also complaining about looking up docs is just a matter of where you have your knowledge. I would have the opposite problem to understan…

Post by Nimitz14 » Tue, May 15, 2018, 5:34 PM UTC

saagarjha wrote: post #216

Nimitz14 wrote: post #183

Earlier quoted context omitted.

You seem to be imagining some sort of situation where bash is used to deal with input from customers (random users). You do not use bash for that. Filenames with spaces (lol) do not happen unless you do it yourself. Bash is useful for productivity when getting stuff done. For the work I do (where code never comes close to a customer and one-off tasks are common), if a candidate were to write a python script for the e…

> Filenames with spaces (lol) do not happen unless you do it yourself. This is a cop out. File names can totally contain spaces, and the difference between the Bash and Python solution is that one will continue to work when a file with spaces inevitably shows up and one will fail, possibly silently.