Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shell Style Guide

google.github.io

Post reply on HN
Print view View original

231–240 of 336 posts

Re: Shell Style Guide

#231

Post by thankthunk »

dang wrote: post #200
thankthunk wrote: post #167

Earlier quoted context omitted.

> This is nonsense. I am very familiar with web browsers. Javascript is standardized as ECMAScript: As I said, it is standardized as SQL is "standardized", but every browser implements their own flavor just like every database server. You aren't familiar with anything. That much is obvious. > You're off your rocker. It's funny how my comments are flagged but not yours when you've been spouting nonsense. > Here is a d…

We've banned this account for repeatedly breaking the site guidelines. Would you please not create accounts to do that with? If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. https://news.ycombinator.com/newsguidelines.html

Oh fuc you.

Re: Shell Style Guide

#232

Post by jolmg »

nvarsj wrote: post #105
_arvin wrote: post #69

I'm really surprised they went with: #!/bin/bash as opposed to: #!/usr/bin/env bash the latter feels more flexible and dependable for a script to be passed around.

I really don't like the `/usr/bin/env bash` approach (it came from the ruby world I think?). It's less portable than /bin/bash in my experience - I've been in environments, usually older ones, where it doesn't work at all. But /bin/bash works everywhere. You also can't pass command line arguments. And it's slightly more complex than just invoking /bin/bash.

It didn't work because there was no /usr/bin/env in these systems, or because you wanted a bash different from what was found with $PATH to execute? What were these systems?

Re: Shell Style Guide

#233

Post by GavinAnderegg »

fernandotakai wrote: post #60
ma2rten wrote: post #56

Earlier quoted context omitted.

All Google style guides use two spaces.

not the python one! https://google.github.io/styleguide/pyguide.html anything other than 4 spaces for python look out of place for me.

I've seen a lot of Python from Google using two spaces, which I find very hard to read. Many of the samples here use two-space indentation: https://github.com/google/google-api-python-client/blob/mast...

Here's a specific example: https://github.com/google/google-api-python-client/blob/mast...

Re: Shell Style Guide

#234

Post by jessaustin »

jolmg wrote: post #222
jessaustin wrote: post #210

Earlier quoted context omitted.

Is this a problem with env? What does the "-e" flag do anyway? "man bash" proved unenlightening.

It's not because of env. It's just that shebangs are limited to passing one optional argument to the executable specified. The way they're parsed is the executable path, and if there's a space, then the rest of the line (including any additional spaces) is interpreted as 1 argument to the executable. EDIT: -e causes bash to exit on the first command that returns with an error (returns with a non-zero return code). It…

Thanks for clarifying. In that case, one could imagine an env capable of parsing its single argument into the multiple intended arguments? I admit that I never dreamed that the "set" builtin would have the information about "bash -e" while the initial "OPTIONS" section did not. Why not look under the "cd", "echo", "fc", "read", or "ulimit" builtins? Somewhat helpfully, the "COMMAND EXECUTION ENVIRONMENT" section talks about how "-e" is inherited but not what it means. Ah, man pages.

Re: Shell Style Guide

#235

Post by hyperpape »

Sir_Cmpwn wrote: post #21
jon-wood wrote: post #10

Earlier quoted context omitted.

I'm genuinely curious, why? If you're writing generic scripts designed to run across multiple platforms then fine, but in the context of Google (or most other companies) they'll have a standard set of tooling available on all their machines, which presumably includes Bash if they're making that statement. What about POSIX shell makes it superior for scripting?

Google also makes it difficult to compile Chromium on platforms where /usr/bin/python is python 3, because their shebangs are: #!/usr/bin/env python Rather than the more portable: #!/usr/bin/env python3 Notably this causes problems for people on Arch Linux, and in the near future, Fedora. This post is presented as a style guide that others should adopt. Google may have bash ubiquiotously available internally, but the…

I believe your claim that

  /bin/sh
is standardized is incorrect, though I don't know how many actual systems fail to have it present. Source: https://news.ycombinator.com/item?id=17069408 (I checked the 2018 version of the spec, and it says the same).

Re: Shell Style Guide

#236

Post by jolmg »

tomc1985 wrote: post #230
nvarsj wrote: post #105

Earlier quoted context omitted.

I really don't like the `/usr/bin/env bash` approach (it came from the ruby world I think?). It's less portable than /bin/bash in my experience - I've been in environments, usually older ones, where it doesn't work at all. But /bin/bash works everywhere. You also can't pass command line arguments. And it's slightly more complex than just invoking /bin/bash.

/usr/bin/env anything is a pain to use with cronjobs

I don't have much experience with cronjobs, but is $PATH not set-up properly in their environment?

Re: Shell Style Guide

#237

Post by assafmo »

When breaking a pipe into two lines, I find it cleaner to end the first line with pipe instead of backslash. Then I indent the second line. Bash knows a command cannot end with pipe, therefore it's syntactically ok.

E.g.

  cmd1 |
    cmd2
Instead of:

  cmd1 \
    | cmd2

Re: Shell Style Guide

#238

Post by jerf »

bm1362 wrote: post #146
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…

Sorry I wrote that in a taxi from my phone, not a serious usecase but that’s beside the point I was trying to make- I personally have a hard time using python over bash. Thanks for pointing out the security aspect, I don’t typically think about that.

I figured; you clearly knew enough bash to know what the real backticks are. Those... frontticks?... aren't even on most keyboards.

On the plus side, when I fixed the typographical issues, it did work. I'm pretty sure I could do this more-or-less first-time right in Python, too, but it clearly took me longer to get there.

Re: Shell Style Guide

#239

Post by cma »

tomc1985 wrote: post #228
arca_vorago wrote: post #189

Earlier quoted context omitted.

It's because so many here on hn are the compsci theoritical programmer, sysadmins are dying devops is everything, kind of people who don't actually support production systems other than maybe their particular depts single page webapp, etc... Hn has a problem with people living in the SV filter bubble seeing everything through that lens... in the real world, bash is still a king. When your devs shit out some bad code…

Shell code can run in a whole bunch of environments that even getting python into can be tricky. initramfs before your drives are mounted, for example... A lot of the discussion on here is mind-blowing, so many pushing to throw out perfectly good tech because it doesn't fit their (limited) worldview.

Micropython can fit :P

Re: Shell Style Guide

#240

Post by jerf »

Nimitz14 wrote: post #183
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…

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…

My real point about security is not that it is always in play per se, but that the naive Python will tend to do the right thing and the naive bash will not, and that's a non-trivial difference between the two. It goes beyond security. Generally as soon as you step out of bash into perl/python/ruby/whatever, you get an immediate boost to correctness of all kinds, unless you go out of your way to be sloppy. Yes, even Perl is an instant correctness boost.

As for file names not having spaces in them, after I said I personally don't use spaces in my file names,

    find -name '* *' | wc -l
on my home directory here yielded 12985. Uncompressed archives I'm not the source of. Dot directions I did not creat. Some tmp files. Probably the majority of my media files, which are the bulk of that number, named in all sorts of different ways that only share in common that I didn't pick them. An Anki directory. Yeah. They happen.

(Also, because I know someone's gonna try to go for the zinger here, I am not being hypocritical. I do not have an objection to one-off scripting jobs, especially ones like this that are read-only so there is no permanent consequence for error.)

Post reply on HN