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

11–20 of 56 posts

Re: Debugging Bash Like a Sire (2023)

#11

Post by pdimitar »

kajkojednojajko wrote: post #9
mjd wrote: post #3

I've been writing scripts in Bourne shell since the 1980s and in Bash since whenever it came along, and I feel like the most important thing I've learned about it is: don't. Sure, it can be done, and even done well, but why? There are better languages. Every time I write a shell script that grows to more than about 20 lines I curse myself for not having written it in Python. The longer I have waited before throwing i…

> the most important thing I've learned about [bash] is: don't. Sure, it can be done, and even done well, but why? There are better languages. This. Bash gives you all the tools to dig a hole and none to climb out. It's quick and easy to copy commands from your terminal to a file, and it beats not saving them at all. Support for digging: once you have a shell script, adding one more line conditioned on some env var i…

> There is hope that LLMs can be used to convert shell scripts to other languages, because they can make the jump that experienced devs have learned to avoid: rewriting from scratch. What else do you do when refactoring in small steps is not feasible?

There were some languages shown in HN that compile to sh/bash (like oilshell[0]). I would think that's also a viable vector of attack but not sure how viable it actually is i.e. maintainers might have moved on for various reasons.

[0] https://github.com/oils-for-unix/oils

Re: Debugging Bash Like a Sire (2023)

#13

Post by latexr »

mjd wrote: post #3

I've been writing scripts in Bourne shell since the 1980s and in Bash since whenever it came along, and I feel like the most important thing I've learned about it is: don't. Sure, it can be done, and even done well, but why? There are better languages. Every time I write a shell script that grows to more than about 20 lines I curse myself for not having written it in Python. The longer I have waited before throwing i…

As someone who has been writing shell scripts for a few decades (though not as long as you), I’d instead recommend “learn what your tools are appropriate for and use them that way”. There are plenty of cases where shell scripts are the right tool for the job.

I can’t even tell how many times I’ve seen multi-line Python scripts which could instead have been a shell one-liner. Shorter and faster.

I have also written shell scripts with hundreds of lines, used by thousands of people, which work just fine and would be more complicated and slower in other languages.

I firmly disagree with the all too pervasive blanket statement of “there are better languages”. It depends. It always does.

Re: Debugging Bash Like a Sire (2023)

#14

Post by oneshtein »

t43562 wrote: post #2

I never thought of the idea of printing out a stack trace. A logging function is an example of such a good idea that is so obvious that I didn't think of it :-) I use -e sometimes but I really dislike scripts that rely on it for all error handling instead of handling errors and logging them. https://www.shellcheck.net/ ^^ this tool has proven very useful for avoiding some of the most silly mistakes and making my scri…

You can use bash-modules if you like stack traces in bash.

Re: Debugging Bash Like a Sire (2023)

#15

Post by ygritte »

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".

Re: Debugging Bash Like a Sire (2023)

#16

Post by jeffrallen »

mjd wrote: post #3

I've been writing scripts in Bourne shell since the 1980s and in Bash since whenever it came along, and I feel like the most important thing I've learned about it is: don't. Sure, it can be done, and even done well, but why? There are better languages. Every time I write a shell script that grows to more than about 20 lines I curse myself for not having written it in Python. The longer I have waited before throwing i…

An excellent use case for AI coders today is, "change this she'll script that's gotten too big into python". :)

Re: Debugging Bash Like a Sire (2023)

#19

Post by jelder »

hiAndrewQuinn wrote: post #5
mjd wrote: post #3

I've been writing scripts in Bourne shell since the 1980s and in Bash since whenever it came along, and I feel like the most important thing I've learned about it is: don't. Sure, it can be done, and even done well, but why? There are better languages. Every time I write a shell script that grows to more than about 20 lines I curse myself for not having written it in Python. The longer I have waited before throwing i…

It won't be surprising since I wrote [1], but I mostly write bash when I want to create complicated pipelines with fzf, and I don't want to write Go code to go the same thing. [1]: https://andrew-quinn.me/fzf/

This is an excellent point about pipes. There seems to be no other language which lets you stitch together pipes like Bash does. It's incredibly powerful, and worth putting up with all of Bash's warts.

Thanks for fzf, by the way. Always one of the first things I install in a new environment.

Re: Debugging Bash Like a Sire (2023)

#20

Post by cerved »

jelder wrote: post #19
hiAndrewQuinn wrote: post #5

Earlier quoted context omitted.

It won't be surprising since I wrote [1], but I mostly write bash when I want to create complicated pipelines with fzf, and I don't want to write Go code to go the same thing. [1]: https://andrew-quinn.me/fzf/

This is an excellent point about pipes. There seems to be no other language which lets you stitch together pipes like Bash does. It's incredibly powerful, and worth putting up with all of Bash's warts. Thanks for fzf, by the way. Always one of the first things I install in a new environment.

They are not the author of fzf
Post reply on HN