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

21–30 of 56 posts

Re: Debugging Bash Like a Sire (2023)

#21

Post by mjd »

orhmeh09 wrote: post #4
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…

Because it's better at the task than Python is.

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

Re: Debugging Bash Like a Sire (2023)

#22

Post by hn92726819 »

mjd wrote: post #21
orhmeh09 wrote: post #4

Earlier quoted context omitted.

Because it's better at the task than Python is.

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 there because half of the time, the >n metric does not work for me at all. My shell scripts range from ~5-150 lines while python are 100+

Re: Debugging Bash Like a Sire (2023)

#24

Post by hn92726819 »

> I tend to skip the -u flag as bash scripts often interact with global variables that are set outside my scripts.

What? If globals are set outside the scripts, -u still works. If the author means they may or may not be defined outside the script, the ${VAR:-} construct allows it to expand to nothing if unset (just throw VAR=${VAR:-} at the top if you don't want to edit the body)

Also, I do not like the function return based on error code:

    function ... {
      ...
      (( check_level >= current_level ))
    }
Unless I'm reading this wrong, this is a bad idea if using set -e. This is a function and it should instead:

    return $(( check_level

Re: Debugging Bash Like a Sire (2023)

#25

Post by jahsome »

latexr wrote: post #13
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 sh…

When it comes to shell scripting, I personally avoid golf at all costs. I'll take an extra verbose, easy script to parse (for a human) any day of the week when it comes to operations.

Yes it's a tradeoff. Every line of code is a liability. Powershell or python are probably "slower" which in my use case is negligible and almost never relevant. On the other hand, I can't help but view the often esoteric and obscurely clever bash mechanisms as debt.

Re: Debugging Bash Like a Sire (2023)

#26

Post by latexr »

jahsome wrote: post #25
latexr wrote: post #13

Earlier quoted context omitted.

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 sh…

When it comes to shell scripting, I personally avoid golf at all costs. I'll take an extra verbose, easy script to parse (for a human) any day of the week when it comes to operations. Yes it's a tradeoff. Every line of code is a liability. Powershell or python are probably "slower" which in my use case is negligible and almost never relevant. On the other hand, I can't help but view the often esoteric and obscurely c…

I’m not talking about code golf. Verbosity and clarity are not directly correlated. The examples I’m talking about are also often easier to read as shell scripts.

For example, let’s take a file as input, filter for every "mypattern" line, then output them sorted.

Python example:

  import sys
  print(*sorted(line for line in open(sys.argv[1]) if 'mypattern' in line), sep='')
Shell example:

  grep 'mypattern' "${1}" | sort
The shell version is shorter, easier to read, easier to understand, easier to search for, and an order of magnitude faster. You can certainly make the Python version more verbose, yet it’ll never reach the same level of clarity and immediacy as the shell version.

Re: Debugging Bash Like a Sire (2023)

#27

Post by coderatlarge »

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…

i once wrote a whole data processing library in bash because i didn’t want people at my then workplace to extend and continue developing it. it was needed for a narrow purpose which it served well (details lost). ultimately people ported it to python and kept developing it anyway.

Re: Debugging Bash Like a Sire (2023)

#28

Post by imglorp »

latexr wrote: post #13
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 sh…

I'll put a point on the "it depends" bit.

If you have a standard-ish environment, you'll have an array of Unix tools to compose together, which is what a shell is best at. Even a minimal image like busybox will have enough to do serious work. Golfing in shell can be a pipeline of tools: lately "curl | jq | awk" does a lot of lifting for me in a one-liner.

As soon as you say "switch to (favorite decent scripting environment)", you're committing to (a) many megs of its base install, (b) its package management system, (c) whatever domain packages you need for $work, and (d) all the attendant dependency hells that brings along. Golfing in a scripting environment is composing a bunch of builtin operations.

Re: Debugging Bash Like a Sire (2023)

#29

Post by cassianoleal »

> I tend to skip the -u flag as bash scripts often interact with global variables that are set outside my scripts.

That's throwing the baby out with the bathwater. Instead, default the optional global variables with something like:

    "${GLOBAL_VAR:-}"
That will satisfy the optionality of the variable whilst keeping the check for the cases you actually want them.

Re: Debugging Bash Like a Sire (2023)

#30

Post by johnisgood »

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…

If you have to call out to many external programs, might as well use Bash. I use Bash in such cases.
Post reply on HN