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

101–110 of 336 posts

Re: Shell Style Guide

#101

Post by hamandcheese »

pas wrote: post #81
bitlax wrote: post #49

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

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, allowing literally zero installation on almost any host you want to manage.

If you already have a good mechanism for packaging and distributing software to all your machines (which I think is a reasonable expectation for Google) then go ahead and use whatever language you're well equipped for. But know you'll be sacrificing the easy and wide distribution that using Bash or Python brings you.

Re: Shell Style Guide

#102

Post by TheCondor »

pas wrote: post #81
bitlax wrote: post #49

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

You’ve hit most of it. The desire is a lowest common denominator. Python, Ruby, etc would be great except that in some of the places there arent current versions and beyond the most mundane you end up wanting 3rd party packages, which complicates your packaging or removes that lowest common denominator property.

What it begs is for a new tool. A single file, statically linked “super shell” that lets you do structured scripting and has builtins for a bunch of common things (reading in addresses, daemonizing processes, reading the process table, etc. and that tool needs to be build able on nearly everything. Now I like rust and the attention it is getting and the interest in safety and correctness. I can’t think of many places where I’d reach for bash but be happier writing rust, a lot of it is 15minute disposable programming jobs. At a glance, I think I’d trade 5minutes of set -e to find some error I skipped for 45 minutes of trying to rejigger things to properly borrow some shared value.

Re: Shell Style Guide

#103

Post by pas »

Sir_Cmpwn wrote: post #46
reacweb wrote: post #43

Earlier quoted context omitted.

I have the opposite opinion. I have seen developers proudly putting /bin/sh instead of /bin/bash, without any other shell to test. When the script was run on ubuntu instead of redhat, this called dash and we discovered that the script was finally not compliant on subtle details. Writing POSIX compliant scripts is harder. Where is the reward when bash is present (almost) everywhere?

>Where is the reward when bash is present (almost) everywhere? It's really not. It's only present on some desktop Linux distributions. It's not present on almost any other OS or anywhere in the embedded space. POSIX shell, on the other hand, is everywhere.

Why wouldn't you install Bash then, if you want to run shell scripts on those platforms?

I mean, what are the use cases? Where universality is important (so let's say when someone embeds scripts in Makefiles), I understand the need for POSIX, but other that I can't even come up with a good use case for having sh as default. (Maybe to save space, you ship the embedded device or Docker container with sh, sure, but then what kind of script you'd want to run there? Okay, maybe all of them, but then even on alpine installing bash is one quick command.)

Re: Shell Style Guide

#104

Post by joshuamorton »

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…

The second thing is not more portable than the first (unfortunately).

Re: Shell Style Guide

#105

Post by nvarsj »

_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.

Re: Shell Style Guide

#106

Post by pas »

TheCondor wrote: post #102
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…

You’ve hit most of it. The desire is a lowest common denominator. Python, Ruby, etc would be great except that in some of the places there arent current versions and beyond the most mundane you end up wanting 3rd party packages, which complicates your packaging or removes that lowest common denominator property. What it begs is for a new tool. A single file, statically linked “super shell” that lets you do structured…

I thought of Rust because of the strict typing. If something TypeScript-like could compile to Bash, that'd be amazing. (Maybe there's something like that already.)

But now, to think of it, just using Node + TS (+ yarn) sounds better than Python.

Re: Shell Style Guide

#107

Post by jve »

chrisfinazzo wrote: post #58
NiveaGeForce wrote: post #37

Earlier quoted context omitted.

And on Windows there is something better than Bash, called PowerShell.

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…

> Historically, PowerShell was supposed to be a replacement for cmd.exe and roughly equivalent to bash

What? PowerShell has radically different ideology. Plus it is super consistent (helps discover commands), extensible and works with objects rather plain strings, use .NET functions or call custom .dll functions...

> They tried early on to port some of the UNIX & Linux tools to Windows and it didn't fly

Actually they just use aliases to map well-known unix commands to powershell counterparts. It is not expected to have command switches work like that etc. Just a convenience for folks used to rm, ls, tee, wget, whatever. Maybe bad decision because of confusion, maybe a good one because helps people get started with PowerShell.

For me as a Windows admin, PowerShell is one of the best things within Windows Ecosystem.

Re: Shell Style Guide

#108

Post by liveoneggs »

reacweb wrote: post #43
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…

I have the opposite opinion. I have seen developers proudly putting /bin/sh instead of /bin/bash, without any other shell to test. When the script was run on ubuntu instead of redhat, this called dash and we discovered that the script was finally not compliant on subtle details. Writing POSIX compliant scripts is harder. Where is the reward when bash is present (almost) everywhere?

bash is slower and having it as /bin/sh was how so many (so so many) servers were taken over via shellshock

Re: Shell Style Guide

#109

Post by falsedan »

chrisfinazzo wrote: post #58
NiveaGeForce wrote: post #37

Earlier quoted context omitted.

And on Windows there is something better than Bash, called PowerShell.

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…

Powershell on Windows is better than bash on Windows.

Re: Shell Style Guide

#110

Post by pas »

coldtea wrote: post #100
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…

> Python seems to handle complexity better, but only on the surface. (Basically Python has nice data structures, great string formatting, and .. that's it.) It's a complete scripting language, with tons of features, from a comprehensive standard library with something for most needs, to a packaging system, isolated environments, async io, and more. And lots of expressivity in structuring your program (including optio…

> not sure what the above "and that's it" means. That it's not Haskell? Yes, it's not.

That scripting in Python is pretty bad. It makes thing harder and at the same time you still have to think a lot about what can go wrong, because there's no enforced error handling.

Post reply on HN