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…
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.
Shell Style Guide
291–300 of 336 posts
Re: Shell Style Guide
#292Earlier quoted context omitted.
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…
You seem to be imagining some sort of situation where bash is used to deal with input from customers (random users). You do not use bash for that. Filenames with spaces (lol) do not happen unless you do it yourself. Bash is useful for productivity when getting stuff done. For the work I do (where code never comes close to a customer and one-off tasks are common), if a candidate were to write a python script for the e…
This attitude is where it brings unexpected bugs in the long run. Don't expect but just be sure.
Re: Shell Style Guide
#293I 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.
Well, I love and hate bash at the same time. I love the way of writing scripts. You start with a simple command and keep piping and saving the output to other functions and commands until you reach the desired outcome. While doing so, you can simply wrap every command into wrapper functions and have the entire arsenal of cli applications at you disposal. While not having to care about such esoteric/complicated/effici…
Sure, you'd enjoy for the first few lines of bash code.
Re: Shell Style Guide
#294I'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
Doesn't explain why Google wouldn't use env unless there's a good reason to avoid env.
Re: Shell Style Guide
#295Earlier quoted context omitted.
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.
> 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. Its not a ruby thing, its the way you're supposed to write portable scripts where the location of the executable might not be predetermined. Lets say you're on a distribution where bash is in /us…
Funny that if env is such a crucial part of the OS, why isn't it in /bin?
Re: Shell Style Guide
#296Earlier quoted context omitted.
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.
> It's less portable than /bin/bash in my experience /bin/bash breaks on FreeBSD, which installs Bash at /usr/local/bin/bash. /usr/bin/env bash works though. > You also can't pass command line arguments. Are you sure about that? Given this script: #!/usr/bin/env bash echo "args: $@" it outputs: $ ./foo 1 2 3 args: 1 2 3 Is that what you meant?
[deleted]
Re: Shell Style Guide
#297Earlier quoted context omitted.
People rag on bash a lot, but it now forms the core of a major deployment system I built at work. I'm not happy that it's in bash, but every other solution was worse, and it calls out to other tools (e.g. Ansible and Terraform) when they're appropriate. People have forgotten the subtle art of realizing what tool is best for the job. If all you're doing is stitching together other tools and doing some logging, bash is…
^ this! Bash is the best stitching together language you'll get. Sure it sucks at scripting.. So stitch a script in there for God's sake!
Fish shell?
Re: Shell Style Guide
#298I write long bash and perl scripts. I keep things neat and tidy most of the time. My "temporary workarounds" are still in use today, in production, so I must have written them well enough for people to understand. I see a lot of debate around preferences at the risk of becoming a funny title on n-gate. Just use whatever languages you know best. If it follows the best practices of that language, someone can port it to…
My "temporary workarounds" are still in use today, in production, so I must have written them well enough for people to understand. Maybe the reason the temporary workarounds persist is because nobody understands them well enough to replace them ;)
I completely understand. In my case, every one of my scripts has my name and email in it. They won't hesitate to reach out to me if something is broken. :-)
Re: Shell Style Guide
#299Earlier quoted context omitted.
> 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 fi…
I know this; but can I teach every potential user of my scripts this same fact through documentation I have to maintain? What if: I write the code so that documenting it is easier?
Re: Shell Style Guide
#300Earlier quoted context omitted.
`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.
Do you normally protect every command with || exit? cd foobar || exit It's those really small failures that cause shell scripts to do crazy things without set -e.
Why wouldn't I rewrite the script to avoid the cd instead? The point of `set -e` isn't to insert all those pointless guards, it's to point out "hey this might fail, so think of a way to do this that doesn't rely on cd".
For your extremely thin example, if it (say) removed some files, I would only remove the files from the current directory or an absolute path.