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

171–180 of 336 posts

Re: Shell Style Guide

#171

Post by kazinator »

no_wizard wrote: post #156

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

> due to the fact that it’s [sic] creators are very much of the old 1970s and 1980s Unix mindset

Firstly, Bash is relied upon to conform to a standard; it's not an exploratory project which expresses the maintainers' views about what a shell should look like.

Secondly, Stallman didn't start Bash because he loved Unix. It was a pragmatic choice. Stallman really wanted a free platform based on Lisp. He went with cloning the Unix user space because that was becoming a dominant OS. It was proprietary software, and he wanted to replace that directly with workalike free software, rather than to provide incompatible free software and then have to evangelize not only freedom, but also a different platform at the same time.

There were some technical reasons. Stallman rejected the idea of copying the Lisp Machine approach:

https://www.gnu.org/gnu/rms-lisp.en.html

At first, I thought of making a Lisp-based system, but I realized that wouldn't be a good idea technically. To have something like the Lisp machine system, you needed special purpose microcode. That's what made it possible to run programs as fast as other computers would run their programs and still get the benefit of typechecking. Without that, you would be reduced to something like the Lisp compilers for other machines. The programs would be faster, but unstable. Now that's okay if you're running one program on a timesharing system — if one program crashes, that's not a disaster, that's something your program occasionally does. But that didn't make it good for writing the operating system in, so I rejected the idea of making a system like the Lisp machine.

I decided instead to make a Unix-like operating system that would have Lisp implementations to run as user programs. The kernel wouldn't be written in Lisp, but we'd have Lisp.

https://www.gnu.org/gnu/thegnuproject.en.html

For example, we developed the GNU C library because a Unix-like system needs a C library, BASH because a Unix-like system needs a shell, and GNU tar because a Unix-like system needs a tar program. The same is true for my own programs—the GNU C compiler, GNU Emacs, GDB and GNU Make.

Re: Shell Style Guide

#172

Post by School-Cotton »

raarts wrote: post #112
orzen wrote: post #62

Earlier quoted context omitted.

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.

Ubuntu has dash as /bin/sh.

Re: Shell Style Guide

#173

Post by School-Cotton »

falsedan wrote: post #130
moviuro wrote: post #55

Earlier quoted context omitted.

bash is completely out of date on macOS (GPL2 vs. GPL3), and not shipped on any *BSD AFAICT. Some Linux distro don't ship it either (void, alpine IIRC). And, most of the time, bash is used because people don't know any better, see e.g. https://github.com/OpenRA/OpenRA/pull/8405/files

> bash is completely out of date on macOS I love finding and removing all the GNU/Linux-ism in my bash code when I move it from a dev host to my personal laptop. macOS coreutils don't have GNU longopts, surprise!

In case you didn't know: if you really need some GNU tool, you can do `brew install coreutils` (assuming you use Homebrew).

The installed binaries will have their names prefixed with `g`; e.g. `gdate` instead of `date`.

If something you want isn't part of coreutils, you can often install it directly; e.g. `brew install gawk` or the weirdly-named `brew install gnu-sed` (which names its installed binary `gsed`... go figure.)

Re: Shell Style Guide

#174

Post by cowmoo728 »

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

I once triggered an automatic deploy that ran a bash script that minified a bunch of css/html/js assets and pushed them to S3, at some path like `/assets/vX.X.X/whatever.css`. Unfortunately, a few of our deploy boxes had Dash instead of Bourne shell, and when it ran on dash it failed to parse the version tag to push and ended up pushing an empty dir to /assets - deleting everything. Fun experience.

Re: Shell Style Guide

#175

Post by oblio »

rkeene2 wrote: post #143
TheCondor wrote: post #102

Earlier quoted context omitted.

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…

Tcl meets all of these requirements. I have a Linux distribution whose PID 1 is a Tcl shell and I can setup everything from there without spawning any new processes.

Yeah, but Tcl is old and quite crufty. The docs are a mess, everything is a string, a lot of concepts it uses are not very familiar and/or mainstream (upvar?).

A modern take on Tcl is what we need, in my opinion.

Surely we should be able to build something nicer 30 years after the first release of Tcl.

Re: Shell Style Guide

#176

Post by squeaky-clean »

bm1362 wrote: post #82
jerf wrote: post #75

Earlier quoted context omitted.

It's a 10-20 line Python script if you write it without any support code. If you're writing any amount of Python code that does shell things, you should either write or get an existing library. Also, it really isn't 10-20 lines to spit out the contents of some files in Python: >>> filelist = ["tmp.pl", "tmp.go", "Tmp.hs"] >>> for f in filelist: ... print(open(f).read()) It's trivial to code golf that down to 1 line,…

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.

That's just one personal anecdote though. I can do the Python example from memory but not the bash example.

Re: Shell Style Guide

#177

Post by simias »

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

Let's be clear, I'm not a huge fan of python or exception-based error handling either but I'll take it any day over... whatever you want to call shell ad-hoc error handling or lack thereof.

Trap is not like an exception, it's more like "atexit" or a signal handler. You can't really nest them, you can't really recover from them. So I definitely disagree that error handling is about the same, python's a lot better.

>there's no compiler, nor type (or other magical) system, that'd warn you if you have missed something.

Well that's the whole static vs. dynamic debate but that's a different story. Use C# or Rust or whatever you feel like if you really can't stand python or scheme. Maybe there's a niche to be filled for statically typed scripting languages, there are no popular ones that I'm aware of.

Still, that's besides the point, while I personally prefer static typing like you there's really no contest between dynamic typing and "everything is a string and you can only concatenate them" typing.

Re: Shell Style Guide

#178

Post by danmg »

no_wizard wrote: post #156

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

Because python was the cool thing a few years ago, and it managed to get traction in a lot of places because it was pretty easy and included a lot of tools. It's also taught as an intro language now. So now you have to deal with people who are poopooing it because it doesn't have enough nerd cred like some like some other dynlang.

Shell scripting has some other issues though. While most Bourne derived shells look similar, they have different extensions and capabilities. So only a subset of scripts will work everywhere.

Re: Shell Style Guide

#179

Post by jhasse »

Sir_Cmpwn wrote: post #39
wildmusings wrote: post #34

Earlier quoted context omitted.

Competing implementations sounds like a potential downside to me. That’s just more possible configurations where a bug could be hiding. Even if you use standard posix shell, you’d be wise to target a single implementation and stick to it.

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…

> competition between gcc and clang is harmful to the C and C++ ecosystems?

Yes. GCC will die eventually.

Post reply on HN