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

251–260 of 336 posts

Re: Shell Style Guide

#251

Post by jolmg »

jessaustin wrote: post #234
jolmg wrote: post #222

Earlier quoted context omitted.

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 talk…

Well, to be fair, the first sentence in OPTIONS is:

> All of the single-character shell options documented in the description of the set builtin command can be used as options when the shell is invoked.

It's easy to miss though, when one's accustomed to quickly searching with "/".

EDIT: On the imagined env, it might be possible. I wonder what aspects of shebangs are portable across the various unix derived OSs. It may be that there's some systems where it only takes non-whitespace characters as the first argument and drops everything else after encountering another space. There might be also other limitations that one should consider when making more use of shebangs, like the character limit of the lines. For example, I think linux only takes the first 127 characters of the shebang and ignores everything else; other systems might take less. I encountered that limit when writing this answer:

https://unix.stackexchange.com/questions/365436/choose-inter...

EDIT 2: If you were to do such a program, it will probably also need to implement quoting and escaping syntax. The difficult part is that, since it wouldn't be a standard program to have, it'd have to be listed as a dependency of whatever projects you use it in, and I wonder if the benefit really outweighs the cost of having yet another dependency. I can't see something like this gaining wide adoption.

Re: Shell Style Guide

#253

Post by [deleted] »

sametmax wrote: post #131
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…

They have a standard setup everywhere, with the same Python version, and the same libs available. So basically, for them, Python requires no fiddling and works as is. Same for the shell. They say "use [[]]" because they know that compat is not a problem: it's the same bash everywhere. Google has millions of servers, billions of lines of code and surely of lot of experience with deployment, managing complexity and han…

[deleted]

Re: Shell Style Guide

#254

Post by [deleted] »

assafmo wrote: post #237

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

[deleted]

Re: Shell Style Guide

#255

Post by zippitydoodah68 »

endtime wrote: post #204
davvolun wrote: post #190

Earlier quoted context omitted.

The Python hate here is ridiculous. This is Google's [bash] style guide -- Google has chosen to use Python as their general purpose development language so "setting up environments" and pip, virtualenv, pyenv, pipenv all of that stuff is resolved through their standard processes. So, if you're not Google, then replace "Python" with "our organization's general purpose language", whether that's Ruby, C#, PHP or what-ha…

Exhibit A: When I joined Google Fiber, one of my first projects was converting a (POSIX) shell script that had grown to 1200 lines to Python. It became something that anyone could modify, including interns, rather than something that required at least a code review from our L7 tech lead, whose time was better spent elsewhere (he was the author and our only competent shell programmer).

That is mind blowing for me in a couple ways. * You have (at least) seven tiered support structures. * You have only one 'competent' shell programmer in your 'reachable' project scope.

No wonder these types of language policies are in place.

Re: Shell Style Guide

#256

Post by _sdegutis »

simias wrote: post #87
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…

It's really not about data structure or anything like that. The big problem with any large shell script is that it's utterly difficult to do proper error handling. Usually the best you can do is check return values to detect an error and 'exit' immediately, hoping that your "trap" works correctly to clean up behind you. >Python lacks efficient, quick and dirty process control. Yeah, quick and dirty, that's kind of th…

I always add ‘set -ex’ to the top of my bash scripts to exit on any non zero top level return code and to print out all statements being run including expanded variables or inner statements.

Re: Shell Style Guide

#257

Post by JdeBP »

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…

Interestingly, FreeBSD used to allow for multiple arguments.

Re: Shell Style Guide

#258

Post by nvarsj »

jolmg wrote: post #232
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.

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?

I think many lightweight container images don’t have /usr/bin/env for example but they all have /bin/sh. Which I think is the best option for portability.

/usr/bin/env is not POSIX anymore than /bin/bash etc.

Re: Shell Style Guide

#259

Post by davidcuddeback »

jolmg wrote: post #219
davidcuddeback wrote: post #121

Earlier quoted context omitted.

> It's less portable than /bin/bash in my experience /bin/bash breaks on FreeBSD, which installs Bash at /usr/local/bin/bash. /usr/bin/env bash works though. > You also can't pass command line arguments. Are you sure about that? Given this script: #!/usr/bin/env bash echo "args: $@" it outputs: $ ./foo 1 2 3 args: 1 2 3 Is that what you meant?

He probably means you can't: #!/usr/bin/env bash -ex but you can: #!/bin/bash -ex

Ah, makes sense then. Thanks for clarifying.

Re: Shell Style Guide

#260

Post by davidcuddeback »

nvarsj wrote: post #194
davidcuddeback wrote: post #121

Earlier quoted context omitted.

> It's less portable than /bin/bash in my experience /bin/bash breaks on FreeBSD, which installs Bash at /usr/local/bin/bash. /usr/bin/env bash works though. > You also can't pass command line arguments. Are you sure about that? Given this script: #!/usr/bin/env bash echo "args: $@" it outputs: $ ./foo 1 2 3 args: 1 2 3 Is that what you meant?

You can do “/bin/bash -e” but not “/usr/bin/env bash -e”. Same for python etc. Good point about freebsd - I remember running into that exact problem. But I think I just symlinked it. https://unix.stackexchange.com/questions/29608/why-is-it-bet... has more info on the pitfalls. In my experience env causes problems, whereas explicit binary call always works (assuming the path exists). Not sure why I was downvoted.

> You can do “/bin/bash -e” but not “/usr/bin/env bash -e”.

Makes sense. Thanks for clarifying. I had a feeling I wasn't understanding your point.

Post reply on HN