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

61–70 of 336 posts

Re: Shell Style Guide

#61

Post by Sir_Cmpwn »

anothergoogler wrote: post #57
Sir_Cmpwn wrote: post #3

>Bash is the only shell scripting language permitted for executables. Whelp, wrong right off the bat. I'm gonna get down my my knees here and beg everyone reading: use POSIX shell. Do not write scripts with bash. Do not write scripts with zsh. Do not write scripts with fish. Use POSIX shell. sh has a really bad interactive mode (so does bash), so I'm not gonna give anyone a hard time for using another shell as their…

Truly portable shell scripts cannot define functions. Have you ever seen autotools' output? No thanks, I'll be impure and wrong and get the job done. Also your comment is off-topic... not sure why you see every thread about Bash as the right place to start this pedantic flameskirmish.

Of course portable shell scripts can define functions. What are you talking about? Shell functions are defined in POSIX. Maybe you should consult the standard before you proceed:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...

Re: Shell Style Guide

#62

Post by orzen »

thankthunk wrote: post #42
Sir_Cmpwn wrote: post #3

>Bash is the only shell scripting language permitted for executables. Whelp, wrong right off the bat. I'm gonna get down my my knees here and beg everyone reading: use POSIX shell. Do not write scripts with bash. Do not write scripts with zsh. Do not write scripts with fish. Use POSIX shell. sh has a really bad interactive mode (so does bash), so I'm not gonna give anyone a hard time for using another shell as their…

> Do not write scripts with bash. It's a bit too late for that. Bash is pretty much the de facto default shell for linux. Telling people not to use bash scripts is like telling web devs not to use javascript or OS devs not to use C. It may change in the future, but bash is so entrenched, it's going to take an extraordinary use case for people to move from bash.

Bash is nowhere close for being de facto default shell for Linux. This is a bad analogy. In this case it is more like telling people that want to code Javascript to only write it in React. You got to go from something generic to something specific. Scripts written with bash will often rely on bash-specifics and can therefore only be interpreted by bash. There are entire projects dedicated to stop this plague. If you want to write portable shell scripts, use dash.

https://linux.die.net/man/1/checkbashisms https://mywiki.wooledge.org/Bashism https://wiki.ubuntu.com/DashAsBinSh https://en.wiktionary.org/wiki/bashism

Re: Shell Style Guide

#63

Post by empath75 »

jrs95 wrote: post #4
empath75 wrote: post #2

> Shell should only be used for small utilities or simple wrapper scripts. Oh you mean we weren’t supposed to write an etl solution in bash?

I’ve actually seen this happen. It’s terrifying.

As have I. It actually worked for a one time migration, but it required a lot of handholding.

Re: Shell Style Guide

#64

Post by mort96 »

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…

If you find yourself compiling Google-stuff a lot on Arch, you might find this useful: https://github.com/mortie/nixConf/blob/master/bin/py2

I wrote that script exactly because of the issue you described, and I got tired of changing what /usr/bin/python is symlinked to constantly. With that script, I just run `py2 gn gen out/Debug` or whatever, and my /usr/bin/python stays intact so everything else which expects python3 works, and only the `gn` process and all subprocess sees python2.

This definitely doesn't excuse Google's behavior, but I don't expect it to be fixed soon. My bug report about it (https://bugs.chromium.org/p/webrtc/issues/detail?id=7376) was closed as wontfix (though I'm not entirely sure the person who closed it understood that I was asking for the python scripts to explicitly use python 2, not for them to port the scripts to python 3).

Re: Shell Style Guide

#65

Post by Sir_Cmpwn »

wildmusings wrote: post #54
Sir_Cmpwn wrote: post #39

Earlier quoted context omitted.

So you think that competition between gcc and clang is harmful to the C and C++ ecosystems? If you find bugs in an implementation of POSIX sh, you should report it to that implementation. Multiple competing implementations is a sign of a good standard, it proves the standard's correctness and demonstrates its maturity. There is no standard to hold bash to. Any strange behavior of it might be decided as by design and…

To be more precise, my point was that you should only be targeting one of the implementations anyway. I don't see how it's a good use of people's time to be testing their scripts against every shell that claims to be sh-compatible, especially at a place like Google where the scripts are almost all being written to run on completely Google-controlled environments. But I didn't think about the bug vs. by-design issue a…

>If you only target standards, the lowest-common-denominator of functionality, you will be poorer for it.

In this case, you won't. I addressed this a few comments ago:

>By the time you need the things bash offers you might as well not use a shell script at all

Re: Shell Style Guide

#66

Post by [deleted] »

thankthunk wrote: post #42
Sir_Cmpwn wrote: post #3

>Bash is the only shell scripting language permitted for executables. Whelp, wrong right off the bat. I'm gonna get down my my knees here and beg everyone reading: use POSIX shell. Do not write scripts with bash. Do not write scripts with zsh. Do not write scripts with fish. Use POSIX shell. sh has a really bad interactive mode (so does bash), so I'm not gonna give anyone a hard time for using another shell as their…

> Do not write scripts with bash. It's a bit too late for that. Bash is pretty much the de facto default shell for linux. Telling people not to use bash scripts is like telling web devs not to use javascript or OS devs not to use C. It may change in the future, but bash is so entrenched, it's going to take an extraordinary use case for people to move from bash.

[deleted]

Re: Shell Style Guide

#67

Post by empath75 »

tootie wrote: post #18

I absolutely hate coding in bash or looking at bash or suddenly being in Windows and being up a tree because bash isn't supported well (it is now if you install WSL). I only use bash to set environment variables and maybe string together 2 or 3 build commands. If I need so much as an if statement, I'm going to switch to a real programming language.

I'll write fairly long bash scripts from time to time, but my rule is more: "Do I plan on running this next week?" or "Do intend this for anybody else to run?", and not so much "How many lines is this".

Re: Shell Style Guide

#68

Post by anothergoogler »

Sir_Cmpwn wrote: post #61
anothergoogler wrote: post #57

Earlier quoted context omitted.

Truly portable shell scripts cannot define functions. Have you ever seen autotools' output? No thanks, I'll be impure and wrong and get the job done. Also your comment is off-topic... not sure why you see every thread about Bash as the right place to start this pedantic flameskirmish.

Of course portable shell scripts can define functions. What are you talking about? Shell functions are defined in POSIX. Maybe you should consult the standard before you proceed: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...

I'm technically wrong per POSIX but practically right per your principle motivation of portability: https://www.gnu.org/software/autoconf/manual/autoconf-2.66/h...

> Unfortunately, even in 2008, where shells without any function support are far and few between, there are pitfalls to avoid when making use of them. Also, finding a Bourne shell that accepts shell functions is not trivial, even though there is almost always one on interesting porting targets.

Re: Shell Style Guide

#69

Post by _arvin »

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.

Re: Shell Style Guide

#70

Post by chrisfinazzo »

SOLAR_FIELDS wrote: post #53
cellard00r wrote: post #32

Earlier quoted context omitted.

Often times it's easier to use binaries and manage their input/output through shell code. Having a good understanding of shell code will also allow you to easily write slick one-liners that will save you lots of time.

For basic file system operations it’s a necessity. Write 10-20 line python script or type a one line grep/awk/sed piipeline to spit out the contents of some files?

There's a great talk by bwk where he complains about exactly this kind of behavior...before admitting that anything useful in a language will be abused in order to do silly things.

https://www.youtube.com/watch?v=Sg4U4r_AgJU

I'll admit, I'm no fan of Python, but this has little to do with the language itself. I found Bash and Ruby first, so Python just seems like too much work to get right.

Requisite xkcd: https://xkcd.com/1987/

Post reply on HN