Earlier quoted context omitted.
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…
The second thing is not more portable than the first (unfortunately).
Shell Style Guide
111–120 of 336 posts
Re: Shell Style Guide
#112Earlier quoted context omitted.
> 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…
> Bash is nowhere close for being de facto default shell for Linux.
Oh, yes it is. Every important distribution uses bash as the default.
Re: Shell Style Guide
#113>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…
Nobody cares about non-bash shells if they're not dealing with legacy systems. (And if you are, you have bigger problems)
Re: Shell Style Guide
#114I 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.
And on Windows there is something better than Bash, called PowerShell.
I'm a huge PS fan and like to stay as far away as possible from Bash but still, I wouldn't call it better than Bash. At least not always and everywhere. More like different. Both come with a list of advantages and disadvantages. And once you learnt one, the list of disadvantages of the other probably seems too big to even start with it, at least that's what it is now for me.
Re: Shell Style Guide
#115Earlier 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…
Its possible to write 2-3 compatible Python code. Furthermore, for basic "scripting" its reasonable to assume no external dependencies, so no need to worry about packaging, pip, pipenv, etc. The major disadvantage of any "comfortable" language aside from Python is that they aren't installed by default on nearly every distribution of every OS. This is why, for example, Ansible only requires Python 2.6 on managed nodes…
> This is why, for example, Ansible only requires Python 2.6 on managed nodes, allowing literally zero installation on almost any host you want to manage.
Yes, Ansible transfers everything. It's ugly and slow :(
I pretty much gave up on [vanilla] OpenStack because their idea of DevOps is custom python script generated Ansible plays.
Re: Shell Style Guide
#116Earlier quoted context omitted.
This document agrees with you. - If you find you need to use arrays for anything more than assignment of ${PIPESTATUS}, you should use Python. - If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date.
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…
Personally I've found myself writing lots of simple command line utilities in Go. YMMV but the standard library handles file IO, network stuff, running external commands and a bunch of standard encodings really well. It also has static typing, and awesome concurrency features.
It's obviously not perfect, but it has replaced lots of Bash scripts for me.
Re: Shell Style Guide
#117i'm surprised it doesn't recommend using set -e /other flags. [ http://redsymbol.net/articles/unofficial-bash-strict-mode/ ] maybe it is not covered because it is not considered 'style' but i think those flags are some of the most important things you can set when writing a bash script. i guess if you are writing scripts that start other things, and then check their error codes it can be annoying because you have tur…
`set -e` is basically a way to find where you need better error-handling, not a way to make scripts safe. I'd much rather a crummy script run into trouble calling some new featuref, shrug, and move on to the core business-critical code, instead of erroring out and triggering a bunch of pages.
Re: Shell Style Guide
#118Earlier quoted context omitted.
Not to put too fine a point on it, but that's nonsense. Historically, PowerShell was supposed to be a replacement for cmd.exe and roughly equivalent to bash, yet suitable for the Windows environment. They tried early on to port some of the UNIX & Linux tools to Windows and it didn't fly, so this is what we're left with. Although parts of Powershell are open source now, I suspect the mere existence of WSL means that M…
> Not to put too fine a point on it, but that's nonsense. In PowerShell you pass structured data around instead of globs of text, which is much more maintainable. Using Bash on Windows is like going backwards, and it's sad that most developers don't even realize it. > Historically, PowerShell was supposed to be a replacement for cmd.exe and roughly equivalent to bash, yet suitable for the Windows environment. They tr…
I used Powershell extensively before I ever had experience with a linux or unix shell. I still have more experience with Powershell than bash or zsh, but I can't imaging going back. I'm already much more capable in a *nix shell.
There are advantages to having a pipe based on structured data, but that also means you have to know what structure to expect at ever step of the way and whether or not other tools can work with that structure. There are also tons of little quirks about Powershell; enough so that I eventually just started writing most stuff in C# and then just using the Powershell scripts as glue.
Passing text means that every single one of the thousands and thousands of unix cli tools that accept stdio will work in your pipeline.
I think this industry needs to get away from the terrible/horrible, absolute thinking. Most tools have positive and negative
Re: Shell Style Guide
#119I'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.
It is, but don't forget it's a guide for Google engineers on the Google machines. People who share code for the world to use should use: - `#!/usr/bin/env bash` - or `#!/bin/sh` for POSIX shell scripting
/bin/sh is most often either the C shell, Dash, or Ash, not the Bourne shell. Bourne shell extensions will cause the script to fail.
edit: bourne again shell
Re: Shell Style Guide
#120>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…
Nobody cares about non-bash shells if they're not dealing with legacy systems. (And if you are, you have bigger problems)
Wrong. *BSD are not legacy systems, and many Linux installs don't have Bash. On top of that, new systems can't really implement Bash (because bash is defined by the implementation) but could easily implement POSIX sh (because POSIX sh is defined by the standard).