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

151–160 of 336 posts

Re: Shell Style Guide

#151

Post by hamandcheese »

pas wrote: post #115
hamandcheese wrote: post #101

Earlier quoted context omitted.

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.

Slow? Maybe. Ugly? I find it rather elegant.

Re: Shell Style Guide

#152

Post by joshuamorton »

Sir_Cmpwn wrote: post #134
joshuamorton wrote: post #128

Earlier quoted context omitted.

That, unfortunately, only works if you don't need to maintain backwards compatibility with older systems. `python` will exist and point to python2 on any system. `python2` may not if it predates or ignores the PEP. `python3` didn't even come installed by default on a lot of nixes until recently, making it the worst of option of the three.

Of course, it will take time for this to become effective. But this is the portable solution. Systems for which this does not work are broken and should be fixed, software should not be updated to accomodate for broken systems.

>software should not be updated to accomodate for broken systems.

Its not. The software was written, and maintains, backwards compatibility with systems that predate or partially predate the spec. The spec was written to be backwards compatible with those systems. Using the backwards compatibility option is correct if you wish to maintain backwards compatibility. Consider that Arch also technically violates Pep 394,

> for the time being, all distributions should ensure that python, if installed, refers to the same target as python2

We shouldn't update the shebangs in all of our software ever to accommodate a misbehaving, spec-non-compliant distro, should we?

Re: Shell Style Guide

#153

Post by pas »

Sir_Cmpwn wrote: post #126
pas wrote: post #103

Earlier quoted context omitted.

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…

>but then what kind of script you'd want to run there? Okay, maybe all of them I think you answered your own question here. I can elaborate, though. bash isn't portable, it uses Glibc-isms. It has to be explicitly ported to new platforms. I also pointed out elsewhere that the value-add of bash is dubious at best - if you need to use bashisms you're better off not writing a shell script at all. So really, the question…

The mentioned "file transfer shell-program" somehow was so important that it has to run on AIX and Linux and every other OS under the sun, yet it was somehow not important enough to be written in non-sh.

And I feel the same with targeting POSIX sh.

Unless you have a really good business niche - like the aforementioned ftp script, use a proper language.

Yes, sysadmins were opposed to installing Bash. But if your core product depends on Bash and only on Bash, maybe I'd be opposed to everything about that deployment too.

And at the same time, I understand that there are IT tasks well suited to be solved with a script. But those don't seem to be the ones that require uber-portability.

If I need to setup something on a fleet of VMS-es, I'll use whatever I can get away with (including a lot of controlled substances to handle the dread of handling VMS), and won't think about what happens if we port this to HP-UX in the year 2525.

Re: Shell Style Guide

#154

Post by pas »

nurettin wrote: post #27
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?

Probably because he can't use bash code in his BusyBox based router

And what's the magically amazing script that anyone would like to run on routers and AIXes alike, that it has to be POSIX portable? :)

Re: Shell Style Guide

#155

Post by chronial »

pas wrote: post #125
simias wrote: post #87

Earlier quoted context omitted.

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…

> trap I don't have more faith in Python's except than in Bash's trap. If you use 3rd party code or a subprocess, then both are pretty weak compared to something kernel enforced. > makes it massively easier to handle errors and give decent diagnostics to the user. I don't really find that. You have to fight for input/output for subprocesses in Python. Sure, logging is easier in Python/perl/PHP/whatever, than in Bash,…

> You have to do everything manually

You are aware that error handling is done via exceptions python?

Re: Shell Style Guide

#156

Post by no_wizard »

I don’t understand all the hate for bash or python in this thread.

These are programming languages. Like all programming languages one must understand how to deploy them and use them properly. Yes bash has faults absolutely. It can be very arcane and esoteric and I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset and largely bash tools still feel like they work the way they did back then

Python is also a tool. I have written scripts in python to manage processes do forking etc and it too has some warts. It is also used by companies tohat deploy thousands of lines of code or more. Yes it isn’t statically typed and yes you can get into a box but guys no single language is objectively superior to another.

So learn them like you would any other tool and move on.

Re: Shell Style Guide

#157

Post by hrktb »

icebraining wrote: post #71
hrktb wrote: post #17

Earlier quoted context omitted.

Then a lot of people don’t understand the limits of what they’re doing. For instance piping though commands works fine until one character sequence is interpreted as EOF. The fun part is it will work most of the time, and when it fails nobody will understand why (“we didn’t touch anything”), and rewriting the thing will be a political nightmare (“it was working before and was only 3 lines, why you need so much time t…

one character sequence is interpreted as EOF I know this is just an example, but how would that happen?

You can hit EOF or EOT in a stream of UTF-8 or other multi-byte encoding as part of a character. There must be ways to have it handled through something that understands character encodings and workaround the issue, but I know that dumb shell piping will fumble on those.

Re: Shell Style Guide

#158

Post by Too »

jerf wrote: post #122
bm1362 wrote: post #82

Earlier quoted context omitted.

for i in ‘ls /tmp/foo’; do echo $i | grep bar | cut -d’-‘ -f3,4; done Is just so much easier to remember than Python’s OS library, right? I can intuitively string that together but can’t write python without looking up the docs and reading a paragraph about idiosyncrasies.

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…

It's hilarious in these discussions that every time someone comes to show how they can do the equivalent code in much less lines of bash there are always always always bugs of these sorts.

And then the parent even specifically pointed out that files with spaces would be a minefield.

Also complaining about looking up docs is just a matter of where you have your knowledge. I would have the opposite problem to understand the "idiosyncrasies" of what the -d flag into cut does whereas I know the python standard library by heart.

Re: Shell Style Guide

#159

Post by [deleted] »

peterwwillis wrote: post #119
moviuro wrote: post #96

Earlier quoted context omitted.

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

[deleted]

Re: Shell Style Guide

#160

Post by Sir_Cmpwn »

pas wrote: post #153
Sir_Cmpwn wrote: post #126

Earlier quoted context omitted.

>but then what kind of script you'd want to run there? Okay, maybe all of them I think you answered your own question here. I can elaborate, though. bash isn't portable, it uses Glibc-isms. It has to be explicitly ported to new platforms. I also pointed out elsewhere that the value-add of bash is dubious at best - if you need to use bashisms you're better off not writing a shell script at all. So really, the question…

The mentioned "file transfer shell-program" somehow was so important that it has to run on AIX and Linux and every other OS under the sun, yet it was somehow not important enough to be written in non-sh. And I feel the same with targeting POSIX sh. Unless you have a really good business niche - like the aforementioned ftp script, use a proper language. Yes, sysadmins were opposed to installing Bash. But if your core…

There are many, many cases where a shell script is appropriate. I don't see a shell script as inherently evil, especially if you use one as conservative as POSIX sh. I ship shell scripts with my software often and for a wide variety of tasks.
Post reply on HN