Hacker News Reader

Comment by Arnavion | Hacker News Reader

    find . -maxdepth 1 -name '*.yaml' -print0 | xargs -r0 the_tool

>To say "you're holding it wrong" is just folly. Bash is worthy of the same treatment that "A Fractal of Bad Design" gave PHP, and it has no place in anything that wants to call itself engineering.

If you have a problem that involves "run a command with a list of parameters but not if the list is empty" and you don't immediately think of `xargs -r`, then consider that it's because you don't understand the tools, not because the tools are bad.

View on HN

> If you have a problem that involves "run a command with a list of parameters but not if the list is empty" and you don't immediately think of `xargs -r`, then consider that it's because you don't understand the tools, not because the tools are bad.

find has -exec, xargs isn't necessary.

`-exec` would run the command for each file separately, which isn't what the original problem wanted, and I didn't want to assume that it would be equivalent.

It runs them separately if you end the exec with ";", it appends as many as possible to the same command if you end it with "+"

Ah yes, I always forget about that.

I'll submit that that's a solution.

But it's like, I have to turn my head around and stop doing one thing (globs), and switch over to another thing (find, xargs). The language has baited me down one way of doing it, when I shouldn't be doing it that way. I'm well aware of xargs (but not the -r flag). I typically avoid xargs, as our code has to¹ work on macOS & Linux, and xargs is one of those utilities whose available options differ between the two for even simple use cases. (Such as here, for the "does it exec on no args?".)

But it still proves the point: the equivalent Python is just so much more straight-forward, easier to read, and not apt to shoot me at a moments notice, and doesn't have bugs. A reader only familiar with Python's syntax can read and understand Python, and can write Python that is correct. Not so with bash, you have to understand, "oh, no, globs will screw you here, you need this flag from this utility" — no, it's lunacy.

Like, I can go down the road you're suggesting (and in the past, I did) and keep learning the nooks and crannies and intricacies of bash, each one adding to the nightmare fuel that is my understanding of shell. I can keep tweaking the script around various failure modes, letting each line fail in prod 3 different ways. Or, I can just re-write it in Python, or Rust, or any other sane language and have it never fail again, for reasons that would also either apply to bash, or apply and have worse consequences than bash. (E.g., the Python would raise, bash would just plow on with it.)

Your response is exactly the same as my response before I saw the light on PHP, C, etc.: "you're holding it wrong". No, it's a bad tool that guiles the user into holding it wrong. There are better tools that are easier to hold.

¹b/c despite all work being done for Linux, devs get MBPs, b/c the company can't manage more than exactly 1 type of machine, for everyone.

Bash is amazing at being expressive and allowing for a ton of common things sysadmins / Devops / power users need to do with just one or a few lines of code vs a “proper” language that might require libraries, compiling stuff, or just a ton more SLOC + time debugging. If you don’t know what a glob is going to match, try it first. Understand the semantics. If you need portability, do that too, but a ton of what I end up using bash for is along the lines of slicing up poorly formatted inconsistent lists and running tools against stuff, possibly in conjunction with args from those lists, and for that it’s amazing. Stuff like jq helps a lot, and tools like xmlstarlet before that were great too. I remember trying to rewrite a script that was getting long and AWKward in Python and getting pretty frustrated with how explicit and error-prone it was there. Sure, the result was probably more robust, but it came at the expense of an order of magnitude more dev / debugging time. That’s not always necessary; sometimes “good enough” is good enough, and usually bash is good enough.

Also, how much code would it take to do the same thing in python?

Probably something along the line of

  Popen(["the_tool"] + list(Path().glob("*.yml")))

This is reasonable in general, though in this case, I think this will replicate the problem of the second Bash version, as the problem there is with the_tool requiring at least one argument.

While dethanatos's point about Bash's default behavior with a non-matching glob is on target, the remainder of the example demonstrates a problem in the_tool, which will need to be worked around regardless of how you invoke it.

Doesn’t xargs also die at too many files? Fact is, bash manages to have more footguns than goddamn C, which is telling something

>Doesn’t xargs also die at too many files?

No?

Reply on news.ycombinator.com