Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Safe ways to do things in bash

github.com

Post reply on HN
Print view View original

191–200 of 255 posts

Re: Safe ways to do things in bash

#191

Post by [deleted] »

h1d wrote: post #158
LeoPanthera wrote: post #80

Earlier quoted context omitted.

Because it is ubiquitous. You can virtually guarantee that bash will be found on any arbitrary unix-like system.

I keep seeing this statement but this absolutely does not apply to everybody. How often can you just install fish or use other programming language instead of being forced to use bash? It's sad people keep using the default just because of being afraid that the next system you touch might not have it and you waste tremendous amount of productivity without using something better. I know a guy who used vim with default…

[deleted]

Re: Safe ways to do things in bash

#192

Post by znpy »

h1d wrote: post #172
zingmars wrote: post #170

Earlier quoted context omitted.

I think a big issue is that bash is available everywhere, while fish might not be. There's also the fact that a lot of us have fancy dotfiles for our work/home computers, and switching to another shell would mean having to rewrite them in the target shell language.

So, you'd rather use something that is decades old because you can't/don't want to (ask to) install 1 new program on the server and take a weekend to rebuild your config file? You can simply import aliases as is and in some cases, you may be able to even simplify parts of your config. Personally, it was easy for me as I'm administering the servers and it was all just installing fish on every servers. (some dozens.)

> So, you'd rather use something that is decades old because you can't/don't want to (ask to) install 1 new program on the server and take a weekend to rebuild your config file?

Absolutely, yes. Because long story short, bash is TriedAndTrue® technology. Stuff that works.

It takes a bit of dedication to be mastered at a decent level but it pays off immensely. It's so ubiquitous it is one of those tools that you can learn once, use for the rest of your life, and use in a lot of contexts.

It's so widespread that it can bring you very far with very little.

All this being said, as someone who used to write code for a living (and now works as a System Engineer, using the bash shell everyday) I must say that if you do not do input verification (according to the language of your choice) and something goes wrong then it's your fault.

Re: Safe ways to do things in bash

#193

Post by elbear »

I notice a pattern in all articles about BASH. Some people say it should die. Others praise its ubiquity and versatility at handling certain tasks. Of course, both sides are right.

From my point of view, BASH will never disappear, because it's not a living thing that runs out of food or habitat and dies. That doesn't happen, unless there's a major revolution in computing that makes current paradigms obsolete, something on the scale of the disappearance of the dinosaurs.

Until that happens, I welcome any projects that aim to decrease the amount of buggy BASH in the wild. I avoid it as much as possible, but if someone's going to use it, at least they'll have safety nets to reduce the possible damage.

PS: I have a feeling my metaphors are all over the place, but I hope that doesn't detract from the message.

Re: Safe ways to do things in bash

#195

Post by znpy »

h1d wrote: post #158
LeoPanthera wrote: post #80

Earlier quoted context omitted.

Because it is ubiquitous. You can virtually guarantee that bash will be found on any arbitrary unix-like system.

I keep seeing this statement but this absolutely does not apply to everybody. How often can you just install fish or use other programming language instead of being forced to use bash? It's sad people keep using the default just because of being afraid that the next system you touch might not have it and you waste tremendous amount of productivity without using something better. I know a guy who used vim with default…

No one ever thinks of interoperability between people. Bash is known, to a variable depth, by pretty much every sysadmin (and a big part of being a sysadmin is being able to write shell scripts).

So I might prefer the fish, and who came before me might have had a preference for zsh. So now I have to deal with three different shells: bash (default), fish (for the scripts i'll be writing from now on) and zsh (because of compatibility). Congrats.

> I know a guy who used vim with default config for that reason. Utterly nonsense.

I started using less and less emacs/vi(m) customization and learn more and more of the defaults for the same reason: whenever I log on a client system I am instantly proficient with the editor without stupid complaints like "but on my box is different..." .

Anecdotal: I have seen people losing their editing speed/proficiency because all of a sudden they were in a clean vim session and had no one of their shiny and colorful plugins.

Re: Safe ways to do things in bash

#196

Post by wool_gather »

themodelplumber wrote: post #131
freedomben wrote: post #122

Earlier quoted context omitted.

Haha. Mostly it is dozens, probably hundreds of little things over time when turning to the shell proved highly productive and effective. The shell is surprisingly really, really good at processing text (using the good 'ol unix tools), and it's amazing how often "text processing" type problems come up. Whether you are doing find/replace on source code, looking for where certain strings are used/defined, or curling so…

That's really cool, thanks. It seems that whenever I come across an annoying text-processing problem, it's always really hard or too generic-sounding to get search engine help with potential bash solutions. However I'd somehow like to improve in that area.

Check out the sed and awk tutorials here: http://www.grymoire.com/Unix/Sed.html

sed in particular is really amazing in what it can do, very simply. (Note, depending on your system, you might want to get GNU sed, for "extended" regex support.)

Those pages do a great job breaking down the basic behavior and explaining pitfalls. They're skim-able, and pretty easily searchable after than, so you can come back and remind yourself of the thing you learned last week.

Re: Safe ways to do things in bash

#197

Post by JdeBP »

jwilk wrote: post #149
__blockcipher__ wrote: post #62

Earlier quoted context omitted.

Seconding this. Shellcheck is fucking amazing and whenever I visit the wiki page for a specific issue it's extremely descriptive and helps you understand why the flagged behavior is a problem. Some of the tips are obscure stuff that I never would have realized, like using `command -v` instead of `which` in my (arch) linux install script because command -v is more portable. And then you have the classic stuff like pri…

I'm all for "command -v", but do you know which OSes don't have "which" by default?

A straw man question. That's not the problem with which.

* https://github.com/koalaman/shellcheck/wiki/SC2230

* https://unix.stackexchange.com/questions/85249/

Re: Safe ways to do things in bash

#198

Post by geofft »

coandco wrote: post #143
geofft wrote: post #129

Earlier quoted context omitted.

By "excessive verbosity" I do mean poor readability and poor maintainability. If you're invoking 5 commands and most of your Python code is wiring up the commands to each other right, just write 5 lines of shell, don't make me pull up the subprocess docs to see if your 30 lines of Python are doing the same thing and how to make a small change without risking pipes deadlocking. Python is readable and maintainable when…

I'd recommend checking out Plumbum ( https://plumbum.readthedocs.io ) -- at the very least, it has a solid base for easily setting up pipelines, input/output redirection, and signal handling.

Wow, thanks! I'll have to check this out.

Re: Safe ways to do things in bash

#199

Post by yAnonymous »

monort wrote: post #184
yAnonymous wrote: post #179

Earlier quoted context omitted.

Is there an easy way to run shell commands in Python, like backticks in PERL, Ruby or even PHP? I'd really like to use Python more often, but most of the time it only complicates things with those verbose syscalls.

Check out python sh: https://github.com/amoffat/sh

>sh.ls("-l", "/tmp", color="never")

Nope. I really need to be able to test commands on the terminal and then copy/paste them without any modifications. I won't even try to get used to that stupid syntax.

Re: Safe ways to do things in bash

#200

Post by opinionator1 »

znpy wrote: post #192
h1d wrote: post #172

Earlier quoted context omitted.

So, you'd rather use something that is decades old because you can't/don't want to (ask to) install 1 new program on the server and take a weekend to rebuild your config file? You can simply import aliases as is and in some cases, you may be able to even simplify parts of your config. Personally, it was easy for me as I'm administering the servers and it was all just installing fish on every servers. (some dozens.)

> So, you'd rather use something that is decades old because you can't/don't want to (ask to) install 1 new program on the server and take a weekend to rebuild your config file? Absolutely, yes. Because long story short, bash is TriedAndTrue® technology. Stuff that works. It takes a bit of dedication to be mastered at a decent level but it pays off immensely. It's so ubiquitous it is one of those tools that you can l…

"works"

More like "better the devil you know" (if you can even say that much).

Bash doesn't scale. Every shop larger than 1 has been burned by bash gotchas. Use a real scripting language and shell out to the commands and builtins when necessary.

At my shop bash is strictly disallowed in production environments and we're all better off for it.

Post reply on HN