Live data from Hacker News

Things I Wish I'd Known About Bash

zwischenzugs.com

161–170 of 272 posts

Re: Things I Wish I'd Known About Bash

#161
post #122
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 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…

"Bash is the glue which keeps everything working together. Please don't build a complete cathedral out of glue."

--JepZ

Re: Things I Wish I'd Known About Bash

#162
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'd make the limit a lot more than 10 lines.

I certainly prefer Perl for large scripts (Python is good too but I happen to know Perl better), but I often have to write scripts for targets that have bash but don't have Perl or Python. Since I've been forced to use bash, I've found it to be a better scripting language than I expected it to be.

Re: Things I Wish I'd Known About Bash

#163

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 also has to semi-frequently modify 100+ lines bash scripts written by others, I'd suggest every serious bash scripter read the bash man page. It is much smaller than any book on Python. For scripts written in Python, I'd use a similar argument and suggest every serious Python scripter to learn Python. As for Perl, or Ruby, or Julia, or anything really. It's just that learning bash from its man page is,…

i'd argue that it's much easier to write bad Bash than bad Python

Re: Things I Wish I'd Known About Bash

#164

Earlier quoted context omitted.

So you use python instead of sh, but you argue that we should use sh instead of bash, perl, or python. I'm not convinced. IMHO, we should use proper tool for the job instead of making artificial limitations. Bash is proper tool in lot of cases, unless old proprietary OS or very limited embedded OS are targeted.

I see so many #!/bin/sh scripts with bashisms in them. These scripts are broken and will cause errors. /bin/sh is not always Bash even on Linux systems. It definitely is not on BSDs. There is no reason to use Bash for shell scripts when you can do the same thing portably.

Your example shows that advise to "use /bin/sh" doesn't help but creates problem. If someone wants to write portable script, then he must test it on significant subset of target systems.

Re: Things I Wish I'd Known About Bash

#165

Earlier quoted context omitted.

So you use python instead of sh, but you argue that we should use sh instead of bash, perl, or python. I'm not convinced. IMHO, we should use proper tool for the job instead of making artificial limitations. Bash is proper tool in lot of cases, unless old proprietary OS or very limited embedded OS are targeted.

>So you use python instead of sh That's not what I said >we should use proper tool for the job This is the implication of what I said. I do not think that bash is the proper tool in most cases.

So it boils down to your personal taste.

Re: Things I Wish I'd Known About Bash

#167

Earlier quoted context omitted.

>So you use python instead of sh That's not what I said >we should use proper tool for the job This is the implication of what I said. I do not think that bash is the proper tool in most cases.

So it boils down to your personal taste.

For most workloads where bash is suited, so is sh. For workloads where sh is insufficient, bash probably is too and you should just use a higher level language.

Chill. You don't have to hold bash so close to your heart.

Re: Things I Wish I'd Known About Bash

#169
post #162
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'd make the limit a lot more than 10 lines. I certainly prefer Perl for large scripts (Python is good too but I happen to know Perl better), but I often have to write scripts for targets that have bash but don't have Perl or Python. Since I've been forced to use bash, I've found it to be a better scripting language than I expected it to be.

10 lines is a rule which is meant to be broken. Rules exist to guide the novice, and to inform the expert. Bash is an extremely useful tool, but not one which should be employed carelessly or casually.

Re: Things I Wish I'd Known About Bash

#170

Can someone explain :h as the article's description was not clear at all to me what was going on there.

Yes, the article is flat out wrong there. Probably a typo or pasto though.

Instead of

    ls /long/path/to/some/file/or/other.txt:h
it should be

    ls !:$:h
which would produce

    other.txt
Post reply on HN