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

Debugging Bash Like a Sire (2023)

blog.brujordet.no

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Debugging Bash Like a Sire (2023)

#51

Post by bigstrat2003 »

hn92726819 wrote: post #22
mjd wrote: post #21

Earlier quoted context omitted.

That's just the problem! It is better at the task. Until it isn't, and "isn't" comes much too soon.

I've seen this sentiment a lot here. "Once shell is >n lines, port to python". My experience has been different. Maybe half of the scripts I write are better off in python while the other half are exponentially longer in python than bash. For example, anything to do with json can be done in 1 line of readable jq, while it could be 1, 5, or 20 lines in python depending on the problem. I'd just like to put that out the…

> For example, anything to do with json can be done in 1 line of readable jq, while it could be 1, 5, or 20 lines in python depending on the problem.

I don't agree that there exists such a thing as "readable jq" to start with. It's very arcane and difficult to follow unless you live and breathe the thing (which I don't). Furthermore, jq may or may not be present on the system, whereas the json package is always there in Python. Finally, I don't think having more lines is bad. The question is, what do you get for the extra lines? Python might have 5 lines where bash has 1, but those 5 lines will be far easier to read and understand in the future. That's a very worthwhile trade-off in my opinion.

Re: Debugging Bash Like a Sire (2023)

#52

Post by hn92726819 »

bigstrat2003 wrote: post #51
hn92726819 wrote: post #22

Earlier quoted context omitted.

I've seen this sentiment a lot here. "Once shell is >n lines, port to python". My experience has been different. Maybe half of the scripts I write are better off in python while the other half are exponentially longer in python than bash. For example, anything to do with json can be done in 1 line of readable jq, while it could be 1, 5, or 20 lines in python depending on the problem. I'd just like to put that out the…

> For example, anything to do with json can be done in 1 line of readable jq, while it could be 1, 5, or 20 lines in python depending on the problem. I don't agree that there exists such a thing as "readable jq" to start with. It's very arcane and difficult to follow unless you live and breathe the thing (which I don't). Furthermore, jq may or may not be present on the system, whereas the json package is always there…

> It's very arcane and difficult to follow unless you live and breathe the thing

I used to think this before I actually read how it worked. If you know shell, jq is extremely easy to pick up. It acts the exact same way, but pipes JSON entities instead of bytes ("text") like shell does.

Like the Unix philosophy, every filter does exactly one thing very well. Like shell, you write it incrementally, one filter at a time.

Genuinely, I do not blame you for thinking it's complex. I have never seen a concise, correct explanation of how jq works that builds an intuitive understanding. I have a near-complete one, and it's on my todo list to eventually publish it.

Anyway, I don't mean to say more lines is always worse, but that it is worse about half the time. Python is certainly more readable, but I'd rather spend 60 seconds making a long pipeline than 10 minutes making it work in python.

Want to count lines in a file? wc -l. Compress a directory? tar -zcf. Send that compressed file somewhere? Pipe it to ssh. Each of those is an ordeal in python and it's around 10 keystrokes in shell.

Re: Debugging Bash Like a Sire (2023)

#53

Post by darkwater »

hiAndrewQuinn wrote: post #44
darkwater wrote: post #38

Earlier quoted context omitted.

Tbh the sentence + the link URL also tricked me into thinking that initially.

Argh, not my intention at all. fzf was written by https://github.com/junegunn , I merely wrote a tutorial on it that got unexpectedly popular on here some years back. I'm sorry Junegunn! I would never dream of stealing that kind of valor. I'll remember to flag [1] as a tutorial I wrote explicitly in the future.

I didn't mean it was intentional, but the URL and the context ("I wrote this ", where "this" is not clear) made me think you were the author of fzf.

Re: Debugging Bash Like a Sire (2023)

#54

Post by HankB99 »

ygritte wrote: post #15
Y_Y wrote: post #6

I find that `bash -x` actially gives such a good trace that I rarely need anything else. Coupled with the ancient wisdom "bash for quick and dirty, once it gets too fancy switch to python", I use bash a lot and find it manages really well without external tools. Shoutouts to shellcheck though, for catching a lot of edge cases.

Yep, shellcheck + syntastic in vim makes for a great bash "IDE".

https://github.com/vim-syntastic/syntastic looks like it is no longer maintained. Is there something more recent for syntastic?

Agreed WRT shellcheck.

Re: Debugging Bash Like a Sire (2023)

#55

Post by naruhodo »

Since no commenter has remarked upon it yet, I draw your attention to the reddit comment [1] mentioned in the article. It is received wisdom that you should begin your scripts with "set -euo pipefail", and that turns out to be a footgun.

[1] https://www.reddit.com/r/commandline/comments/g1vsxk/the_fir...

Re: Debugging Bash Like a Sire (2023)

#56

Post by dcassett »

HankB99 wrote: post #54
ygritte wrote: post #15

Earlier quoted context omitted.

Yep, shellcheck + syntastic in vim makes for a great bash "IDE".

https://github.com/vim-syntastic/syntastic looks like it is no longer maintained. Is there something more recent for syntastic? Agreed WRT shellcheck.

It mentions ALE [1] as the logical successor to syntastic. I've been using ALE for many years.

[1] https://github.com/dense-analysis/ale

Post reply on HN