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

Things I Wish I'd Known About Bash

zwischenzugs.com

Post reply on HN
Print view View original

231–240 of 272 posts

Re: Things I Wish I'd Known About Bash

#231

Post by ilyash »

Goladus wrote: post #62
sethrin wrote: post #30

I wrote a book on Bash too. The most important thing for anyone to know about Bash is that it's intended as a command language, not a general purpose scripting language. If it's longer than 10 lines, or if it uses two or more variables, you should probably have written it in something other than Bash.

I disagree. Here's how I decide: Do I need to manipulate rich data structures like hash-maps or nested lists? That sort of thing tends to stretch the capabilities of Bash to its limits and I tend to set the bar fairly low here. Is the program oriented around commands? If I'm gluing executable scripts and binaries, using bash is often superior to a scripting language. Argument passing is more natural and convenient an…

[shameless]

> Do I need to manipulate rich data structures like hash-maps or nested lists? That sort of thing tends to stretch the capabilities of Bash

> If I'm gluing executable scripts and binaries, using bash is often superior to a scripting language

The two points above resonate with my view that there is a missing piece. On one hand we have bash which is optimized for being the glue (second point). On the other hand we have Ruby, Python, Perl, Go, etc which are good for first point. What I think is missing is newer, more powerful shell, which supports both use cases and more. I'm working on it:

https://github.com/ilyash/ngs

Please note that I'm not the only one that thinks there is room for more powerful shells. See the readme for links to other projects.

Re: Things I Wish I'd Known About Bash

#232

Post by Too »

Goladus wrote: post #217
kinkrtyavimoodh wrote: post #86

Earlier quoted context omitted.

As someone who has to occasionally modify 100+ line bash scripts written by Coworkers from Christmas Past which matched your spec in terms of what they had to do, please please just use Python (or similar). Yes, you will have a few extra lines but it will be vastly more readable and maintainable. And yes, I know I will get the standard the person who wrote the script did a bad job but at some point it should be okay…

> As someone who has to occasionally modify 100+ line bash scripts written by Coworkers from Christmas Past which matched your spec in terms of what they had to do, please please just use Python (or similar). As someone who has inherited thousand-line shell scripts, and had to debug many 3rd party scripts, I stand by my assertion. > Yes, you will have a few extra lines but it will be vastly more readable and maintain…

subprocess.run does exactly what your wrapper does, subprocess.check_output returns stdout only and automatically throws exception on non-zero return code, this is the function you should be using 99% of the time. Those functions both accept a string as stdin-parameter.

Re: Things I Wish I'd Known About Bash

#233

Post by Too »

grzm wrote: post #202
gbacon wrote: post #199

Earlier quoted context omitted.

This is what Perl is designed to be. Perl unlike the others is almost certain to be on any Unix or Linux installation. Several commenters leaving out Perl in discussions of the next step up from bash scripts is truly strange. I suppose being ignored beats the typical herp-derp anti-Perl bigotry, but I’d prefer all-around civility.

> "Several commenters leaving out Perl in discussions of the next step up from bash scripts is truly odd." I'm having a hard time following you here. Do you think that they're doing so for any other reason that Perl is no longer their go-to tool? There are communities where Perl is still used: PostgreSQL for example uses Perl for some of its scripting, as well as its build farm tool, in particular because of its port…

Well said, perl might be the theoretically best match in specifically this problem domain but the thing is there are only so many programming languages one can learn.

If i had to choose only one of ruby/python or perl i would choose the former and it would be able to cover my base both as glue-code and for more programs. Perl would maybe make the glue code a bit easier but instead i would be much less employable and have a much harder time finding other people who can read the glue. I'm not qualified to have an opinion on perls capabilities for other programs but i'm sure there are valid reasons most people prefer other alternatives.

Re: Things I Wish I'd Known About Bash

#234

Post by MichaelMoser123 »

kinkrtyavimoodh wrote: post #86
Goladus wrote: post #62

Earlier quoted context omitted.

I disagree. Here's how I decide: Do I need to manipulate rich data structures like hash-maps or nested lists? That sort of thing tends to stretch the capabilities of Bash to its limits and I tend to set the bar fairly low here. Is the program oriented around commands? If I'm gluing executable scripts and binaries, using bash is often superior to a scripting language. Argument passing is more natural and convenient an…

As someone who has to occasionally modify 100+ line bash scripts written by Coworkers from Christmas Past which matched your spec in terms of what they had to do, please please just use Python (or similar). Yes, you will have a few extra lines but it will be vastly more readable and maintainable. And yes, I know I will get the standard the person who wrote the script did a bad job but at some point it should be okay…

problem is that it is difficult to anticipate; It may look like a simple 'glue the commands together' task, but it may turn out to be more tricky.

Re: Things I Wish I'd Known About Bash

#235

Post by jmiserez »

dorfsmay wrote: post #171
jmiserez wrote: post #121

Earlier quoted context omitted.

You should try hstr ( https://github.com/dvorka/hstr ). It replaces CTRL-R with a full page interactive history search that really works. Demo GIF here: https://unix.stackexchange.com/a/375914

If you use either vim or emacs, there's something to be said about using that knowledge for your command line history.

hstr has a vi mode.

Re: Things I Wish I'd Known About Bash

#236

Post by mbrock »

IshKebab wrote: post #177
JepZ wrote: post #122

Earlier quoted context omitted.

I disagree too. Bash has many downsides, but there are very few languages out there which have the ability to 'connect' different programs so easily. Bash scripts are slow as hell (as most commands have to spawn new processes), it is hard to write "secure" code (if even possible), handling whitespaces can be a pain in the * and the amount of repetition is awful. If your kid has done something wrong, just tell it to w…

The reason it can connect programs so "easily" is because it basically ignores errors and robustness - it really relies on there being a user looking at the output and going "hmm that looked like it failed". Doing things properly in Python or Go may take a few more lines (not much more really) but it is 100 tones more robust, and you need that if you are writing anything more than a 10-line one-off hack.

No, it doesn't. Unix error codes are extremely well understood. Tell the Git maintainers that their program ignores errors and robustness—they'll be surprised.

Re: Things I Wish I'd Known About Bash

#237

Post by mbrock »

sethrin wrote: post #126
chucknelson wrote: post #45

Earlier quoted context omitted.

Would you consider non-trivial install scripts as an exception to this general rule? I mean, you wouldn't write some install script in ruby or python, right?

I would not consider those an exception, and would typically prefer to see the use of some other language. Bash is excellent at dealing with semi-structured text, and as part of a command pipeline, and if you have no alternative than to write POSIX sh, well, it exists. Bash does not have niceties like typed variables or named function arguments, and arrays are best avoided. Even parsing command line arguments is more…

I say please don't write any goddamned software at all.

Re: Things I Wish I'd Known About Bash

#239

Post by natecavanaugh »

mkl wrote: post #201
natecavanaugh wrote: post #195

Earlier quoted context omitted.

I think this might help others, but ShellCheck[0] is a good place to start to help eliminate poor shell scripting. And I would make an argument though that even large shell scripts in bash have their place. I often write scripts in either Node or Python, but only when I need things bash is bad about (any sort of proper data structure beyond strings or arrays). But there are just so many things bash makes insanely eas…

[0] https://www.shellcheck.net/

Whoops! Thanks for that

Re: Things I Wish I'd Known About Bash

#240

Post by viraptor »

mbrock wrote: post #236
IshKebab wrote: post #177

Earlier quoted context omitted.

The reason it can connect programs so "easily" is because it basically ignores errors and robustness - it really relies on there being a user looking at the output and going "hmm that looked like it failed". Doing things properly in Python or Go may take a few more lines (not much more really) but it is 100 tones more robust, and you need that if you are writing anything more than a 10-line one-off hack.

No, it doesn't. Unix error codes are extremely well understood. Tell the Git maintainers that their program ignores errors and robustness—they'll be surprised.

Even when well understood, it doesn't mean easy to work with. If you're lucky, the app you're calling only has two states: success+result, or failure+error message. But working with text commands, one day you'll get a "skipped file Xyz" somewhere in the output, because it's neither an error not a success. If you're very lucky, you'll get it in stderr, otherwise it will be mixed with the output. If you're not lucky, the command will print out the error and exit with 0 anyway. What crazy app would do that? For example standard initctl on Ubuntu: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/55278...

Exit codes are a poor substitute for proper error handling with verbose error reports. They do the job most of the time, as long as you remember exactly which command behaves which way. And that's a clear path to mistakes :-(

Post reply on HN