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

41–50 of 56 posts

Re: Debugging Bash Like a Sire (2023)

#41

Post by kjellsbells »

Curious that after 30 years the idea of a CPAN-like bash repository hasnt taken root. How many personal reimplementations of logging in bash are there by now?

I suppose what is really tripping people up is that bash can show up on all kinds of runtimes, some of which have the external tools one might need (jq, logger, etc) and some of which don't. So then you go searching for a minimum standard that can be expected to be present. Maybe POSIX or gnu coreutils. Reminds me of the shell horrors of the late 1990s where every script had to figure out if sh was really ksh and what variant of UNIX it was running on, and therefore what commands and options were available. I swear this was one of the great things about Perl when it came along, it just worked.

In 2025, I kind of see the attraction of single binaries like Go does. Ship the binary and be done. It is very un-UNIX I suppose (not so much golfing as having the beer cart drive you to the hole) but then again its not 1985 any more.

Re: Debugging Bash Like a Sire (2023)

#42

Post by latexr »

thaumasiotes wrote: post #36
latexr wrote: post #34

Earlier quoted context omitted.

> OK, but isn't jq just an example of a favorite scripting environment with a multi-meg install and a dependency system? No? jq is a single binary a little over half a MB with no runtime dependencies. You can simply download it and use it. And you only need that if it’s not already included in whatever system you’re using, which it likely is. It even comes with macOS these days, which is more than what you can say fo…

> No? jq is a single binary a little over half a MB with no runtime dependencies. I just downloaded it to see what size it was, and it's 2200 KB. > Pretty sure they meant it as in builtin with the system, not the language. As per their first paragraph: >> Even a minimal image like busybox will have enough to do serious work. Busybox doesn't include curl or jq. They aren't builtins by any standard. This becomes obviou…

> I just downloaded it to see what size it was, and it's 2200 KB.

We both saw different versions. You looked at the Linux one, but I looked at the macOS one. The version which ships with macOS is smaller than the one on the website, but even so the website version is under one MB.

I’m intrigued by what causes the large difference.

> Busybox doesn't include curl or jq.

Thank you for the correction. In that case I don’t know what the other user meant. Perhaps they’ll come back and can clarify.

Re: Debugging Bash Like a Sire (2023)

#43

Post by esafak »

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.

https://www.nushell.sh/ is next level when it comes to pipes:

    ls | where size > 10mb | sort-by modified

Re: Debugging Bash Like a Sire (2023)

#44

Post by hiAndrewQuinn »

darkwater wrote: post #38
cerved wrote: post #20

Earlier quoted context omitted.

They are not the author of fzf

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.

Re: Debugging Bash Like a Sire (2023)

#45

Post by hiAndrewQuinn »

pdimitar wrote: post #8
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/

You have my admirations for fzf, it helps me dozens of times every day. And I do understand that authors of such prominent tools will want to have tamed integrations with people's shells, makes perfect sense. That being said, as a guy who does not have big prominent OSS tools under his belt, I am slowly but surely migrating away from shell scripts and changing them to short Golang programs. Already saved my sanity a…

Sorry, I was accidentally unclear in my writing. 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.

Re: Debugging Bash Like a Sire (2023)

#46

Post by pdimitar »

hiAndrewQuinn wrote: post #45
pdimitar wrote: post #8

Earlier quoted context omitted.

You have my admirations for fzf, it helps me dozens of times every day. And I do understand that authors of such prominent tools will want to have tamed integrations with people's shells, makes perfect sense. That being said, as a guy who does not have big prominent OSS tools under his belt, I am slowly but surely migrating away from shell scripts and changing them to short Golang programs. Already saved my sanity a…

Sorry, I was accidentally unclear in my writing. 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.

Seems we both screwed up. :D

Thanks for the clarification.

Re: Debugging Bash Like a Sire (2023)

#47

Post by cerved »

chasil wrote: post #10

It is always helpful in recording if any bash behavior changes when it is not running in POSIX mode. This is most common in Debian and Ubuntu, where ash is /bin/sh, and /bin/bash does not run in POSIX mode by default. Some behavior of legacy bash of the '80s, prior to POSIX.2, can be surprising. https://w3.pppl.gov/info/bash/Bash_POSIX_Mode.html

(D)ash is not bash --posix

Re: Debugging Bash Like a Sire (2023)

#48

Post by gkfasdfasdf »

Why not leverage the bash 'caller' builtin? It's meant for printing stack traces, e.g.

    #!/bin/bash
    
    die() {
      local frame=0
      while caller $frame; do
        ((++frame));
      done
      echo "$*"
      exit 1
    }
    
    f1() { die "*** an error occured ***"; }
    f2() { f1; }
    f3() { f2; }
    
    f3


 Output
    
    
    12 f1 ./callertest.sh
    13 f2 ./callertest.sh
    14 f3 ./callertest.sh
    16 main ./callertest.sh
    *** an error occured ***
Via: https://bash-hackers.gabe565.com/commands/builtin/caller/

Re: Debugging Bash Like a Sire (2023)

#49

Post by gkfasdfasdf »

bmoyles wrote: post #40

You can also skip the subshell invocation of date by using %(fmt)T from bash's printf : %(fmt)T -output the date-time string resulting from using FMT as a format string for strftime(3) The man page provides a bit more detail: %(datefmt)T causes printf to output the date-time string resulting from using datefmt as a format string for strftime(3). The corresponding argument is an integer representing the number of seco…

That would indeed be faster, looks like it requires bash 4.2+

Re: Debugging Bash Like a Sire (2023)

#50

Post by bigstrat2003 »

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.

The only thing bash is better at than Python is very short scripts, like 10ish lines. Everything else it sucks at, due to the horrible syntax and various bash footguns.
Post reply on HN