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

251–260 of 272 posts

Re: Things I Wish I'd Known About Bash

#251

Post by Sir_Cmpwn »

v_lisivka wrote: post #245
Sir_Cmpwn wrote: post #167

Earlier quoted context omitted.

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.

I'm author of bash-modules project. It's my attempt to create set of libraries for easier scripting on bash in strict mode. Most bash libraries are not designed for strict mode, so I created my own. If you prefer sh over bash so much, you can help me to make it compatible with sh, or just fork it. See https://github.com/vlisivka/bash-modules

Or option three: not care about your project because bash sucks and continue to write sh without it.

Re: Things I Wish I'd Known About Bash

#252

Post by tux1968 »

MPSimmons wrote: post #210
chriswarbo wrote: post #175

For me, the biggest gotcha in bash is whether or not a sub-process/shell will be invoked, which can affect things like mutable variables and the number of open file handles. For example: COUNT=0 someCommand | while read -r LINE do COUNT=$(( COUNT + 1 )) done echo "$COUNT" This will always print `0`, since the `COUNT=` line will be run in a sub-process due to the pipe, and hence it can't mutate the outer-process's `CO…

let COUNT=COUNT+1 is all you need

or:

let count++

Re: Things I Wish I'd Known About Bash

#253

Post by walshemj »

taormina wrote: post #114
walshemj wrote: post #111

Interesting but from a modern perspective is not perl a better scripting language to learn. I have never used bash scripts professionally i.e. as a language rather than a simple script with just a command in. Like wise back in 87 or so I got trained in sed and I have only used it once since, and that was when I was playing around with early linix's (when it came on a huge number of floppys)

You have a terminal if you're on a Mac or Linux machine. It takes bash commands by default. Knowing perl is good, but knowing more bash is always good. I hadn't known that <(echo "hi") is treated as a file with the contents of stdout, which simplifies commands that take files as arguments.

I meant using bash as a scripting language not as a shell.

Re: Things I Wish I'd Known About Bash

#254

Post by aplorbust »

kinkrtyavimoodh wrote: post #128
pritambaral wrote: post #92

Earlier quoted context omitted.

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 agree. And I agree with your bash 'whitelist'. I'd also add a hard blacklist for any serious string manipulation. A series of awks and seds look clever but they are quite annoying to deal with. If it's just a bunch of cuts or tr , sure.

"A series of awks and seds look clever but they are annoying to deal with."

Would the following be annoying for you to deal with?

   #!/bin/sh
   sed 's/#.*//' \
   | sed 's/:/#/g' \
   | cat AMD64 - \
   | ./qhasm-ops \
   | ./qhasm-regs \
   | ./qhasm-fp \
   | ./qhasm-as \
   | sed 's/%32/d/g' \
   | sed 's/%raxd/%eax/g' \
   | sed 's/%rbxd/%ebx/g' \
   | sed 's/%rcxd/%ecx/g' \
   | sed 's/%rdxd/%edx/g' \
   | sed 's/%rsid/%esi/g' \
   | sed 's/%rdid/%edi/g' \
   | sed 's/%rbpd/%ebp/g'
where qhasm-as and qhasm-fp are each awk scripts (222 and 427 lines, respectively).

source: http://cr.yp.to/qhasm/qhasm-20061116.tar.gz qhasm-20061116/qhasm-amd64

Re: Things I Wish I'd Known About Bash

#255

Post by khedoros1 »

Pete_D wrote: post #142
khedoros1 wrote: post #136

Earlier quoted context omitted.

For bash: 'i' gives me "no indices found" and 'I' says "no index". I can do a '/' search, which finds some "-p" strings, but "n" doesn't work to find the next. From some other comments, it sounds like "info" uses emacs at its core? So I suppose I'd have to learn some emacs commands, if that's the case.

info works without emacs, but some people prefer emacs' info viewer to the console one. The console viewer does have some idiosyncratic keybindings - for example, "n" means "next node at same level", and "}" means "search for next occurrence". "H" will give you a quick overview. I'm surprised indexes aren't working for you - unfortunately I don't know of any suggestions to fix that.

Thank you for the comment! I've always been aware of the info pages, but it's honestly been years since I've tried to use them.

This thread is a good reminder to give it another go.

Re: Things I Wish I'd Known About Bash

#256

Post by Goladus »

mkesper wrote: post #250
Goladus wrote: post #244

Earlier quoted context omitted.

Subprocess.run is Python 3+ only. If we're talking about replacing bash, Python 2.7 (possibly with 2.6 compatibility) is the more reasonable target. CentOS 7 and Debian 8 (I've not used 9 yet) still ship with Python 2.7. Also, who is to say what I should be using "99% of the time?" Each problem has different constraints and different priorities.

Please have a look at https://pythonclock.org/ and stop riding dead horses.

The domain under discussion is scripting and specifically comparisons with Bash. Python 3 has not achieved anywhere close to the platform deployment that Python 2.7 has. When the common OS distributions you're likely to need to script on ship with Python 3 as the default rather than python 2.7, we can start using Python 3 in random comparisons with shell scripts. Until then, Python 2.7 is the language for comparison no matter what rhetoric you want to employ.

Re: Things I Wish I'd Known About Bash

#257

Post by theptip »

Goladus wrote: post #256
mkesper wrote: post #250

Earlier quoted context omitted.

Please have a look at https://pythonclock.org/ and stop riding dead horses.

The domain under discussion is scripting and specifically comparisons with Bash. Python 3 has not achieved anywhere close to the platform deployment that Python 2.7 has. When the common OS distributions you're likely to need to script on ship with Python 3 as the default rather than python 2.7, we can start using Python 3 in random comparisons with shell scripts. Until then, Python 2.7 is the language for comparison…

Most distros ship with python3 (though `python` will refer to python2).

Is there a reason you cannot just say `#!/usr/bin/env python3` in your scripts? I don't see why you require python3 to be the default, am I missing something here?

Re: Things I Wish I'd Known About Bash

#258

Post by williamdclt »

zbentley wrote: post #207

The thing I wished I had learned earlier is "quick and dirty assertions". If you write lots of functions in Bash, you quickly end up getting tripped up by cases where an argument is omitted and the function does something totally batshit given the missing (empty string) argument. Now, the canonical way to handle this is to put validators on your input, (and make sure those validators don't crash with cryptic errors i…

I usually do something like that:

    [ -z "$1" ] && echo "Invalid first parameter!" >&2 && exit 127
as a precondition. I must admit that it's longer to write, but I can write a bunch of preconditions for my function then write the logic with an appeased mind

Re: Things I Wish I'd Known About Bash

#260

Post by koala_man »

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…

My favorite advice was from a search giant's dev infra engineer who said that "any Python script over 100 lines should be rewritten in Bash, because at least that way you're not kidding yourself into thinking it's production quality"
Post reply on HN