2 ms·
> but on my system for example, it's 128k. Never ran into this problem. That may be because of decades of defence against it. For example, the naive way to run
by Someone 5y ago
> but on my system for example, it's 128k. Never ran into this problem.
That may be because of decades of defence against it. For example, the naive way to run foo on all your .c files in one go is:
find . -type f -name "*.c" -exec foo {} \+
(aside: also note that I had to escape the + at the end of the command. RANT: of course, man find doesn’t mention that, as that’s a shell issue that has nothing to do with find. Technically correct, but beginning users will be baffled)
In my home directory, that’s about a megabyte of arguments, so I have to fall back to
find . -type f -name "*.c" -exec foo {} \;
which calls foo thousands of times, to invoking xargs, or to some other workaround. Either way, foo is called more than once, so the result may not be what I expected.
For real-world examples, see
- https://stackoverflow.com/questions/55453993/argument-list-too-long-error-for-find-command https://stackoverflow.com/questions/55453993/argument-list-t...
- https://www.linuxquestions.org/questions/linux-software-2/argument-list-too-long-why-am-i-getting-this-with-the-find-command-585622/ https://www.linuxquestions.org/questions/linux-software-2/ar...
- https://www.baeldung.com/linux/argument-list-too-long-error https://www.baeldung.com/linux/argument-list-too-long-error
> You'd probably make it so that it has its own parsing too in that case, so you can do calc '3 * 4 + 5’
That’s what you would do, yes, but that’s not ideal, and won’t work well if you want to write a one-liner for a tool whose language can contain single quotes, such as sed/awk/perl/….
> Hmmm, does it create the output file first and then expand the arguments?
Yes, it does.
It all works, but isn’t ideal, and I think using a library to do argument parsing would help here (variable expansion may be a problem when doing that, though, as postponing that till after the tool runs may introduce a race condition when running a tool in the background. If that is a problem at all, I think that’s solvable, though)
- iforgotpassword 5y ago> For example, the naive way to run foo on all your .c files in one go is: find . -type f -name "*.c" -exec foo {} \+ That would break on Windows much earlier, the limit there is 32k as the article mentions. This example has nothing to do with globbing, you're recursively enumerating all .c files in the find process and building the command's arguments. On Windows, likewise, find would build a huge command line that exceeds 32k chars and fail. For this example to make sense, you'd need a recursive glob (which can be enabled in bash) but on Windows yet again the actual tool you're invoking would need to implement that. I wouldn't bet too many do that. > It all works, but isn’t ideal, and I think using a library to do argument parsing would help here (variable expansion may be a problem I mean, we basically have that on Windows since NT, but as the article shows, people/compilers do whatever. It wouldn't be any better on Linux I can tell you. :) Also, variable Expansion would be impossible in a library that's used by the invoked tool, as they never leave the shell for security reasons if you don't make them part of the environment. EDIT: copied the wrong find example earlier
- psd1 5y agoFascinating to read through this, I feel sorry for people who can't use powershell.