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…
> 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.
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…
Doesn’t xargs also die at too many files? Fact is, bash manages to have more footguns than goddamn C, which is telling something
> 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 "+"
> 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. is this a cloud AMD64 opinion that ignores the 2 trillion devices which Gartner predicts will never run python? I recently finished a ~600 lines ash script and the kids at work which just graduated complained that *"Y u n…
How is bash performant? It is literally interpret by lines , and starting a whole process per if statements..
Guessing: Automatic parallelization in pipelines, just as long as there isn't a wall that has to consume all its input like "sort".
My preferred way under those conditions would be more along the lines of "see if a safe command fails, do the desired command if not", like: if ls *.yaml > /dev/null; then the_tool *.yaml fi
That only looks simple because we don't know what problem was being solved. Is it really right to not process any files just because one of them just disappeared? In general, situations like this suffer from race conditions and time-of-check/time-of-use problems.
> Is it really right to not process any files just because one of them just disappeared?
No idea what you mean here, the glob can expand to one or many.
> In general, situations like this suffer from race conditions and time-of-check/time-of-use problems.
I mean, that's a problem in every version presented so far, one that I don't think can be fixed externally without something extra like hardlinking to a new directory, because "the_tool" apparently can't handle missing files and they can go missing when "the_tool" starts up. That's why I didn't even bother.
We had some problem, roughly, "run a tool on all YAML files in the directory" or something. The first attempt that led to a production outage: (It is late, bash examples are approximate. Don't sweat the syntax.) the_tool *.yaml There weren't any YAML files, so argv[1] was literally "*.yaml", which then wasn't found, leading to errors, etc. shopt -s nullglob the_tool *.yaml (Don't even get me started on how there's sh…
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…
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.
`-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 "+"
> Without much real work, it’s easy to replace shell scripts with Python code. The revised code is easier to read and maintain, runs a little faster, and can have a proper unit test suite.
> It's also why it won't go away. Python 2 went away in macOS. Bash still exists.
https://www.python.org/downloads/release/python-2718/ There's still a macOS installer for the latest release of Python2.7 (4/20/2020).
The discussion was around longevity, and Python 2 is dead as of January 2020 [0]. Installer might exist, but it has already become more difficult to maintain Python 2. It will become even more difficult in time. Bash, on the other hand, will more likely to be around for longer.
> It's also why it won't go away. Python 2 went away in macOS. Bash still exists.
Did it really? `/usr/bin/python` invokes Python 2.7.18 on my just-bought Macbook Pro 14 running MacOS 12.2. Maybe that's because I installed the Xcode command line tools?
IIRC, Apple announced that Python 2 will be removed in a future version of macOS, without specifying a version. Looks like they removed it in macOS 12.3 [0].