4 ms·

Good points, some more or less relevant. > - it’s easy to hit a Unix command line length limit when a single * argument expands into many arguments. xargs solv

Good points, some more or less relevant. > - it’s easy to hit a Unix command line length limit when a single * argument expands into many arguments. xargs solves that, but it shouldn’t be necessary. Not on Linux. It used to be a single page (so in practice 4k), but on my system for example, it's 128k. Never ran into this problem. > Unix tools cannot discriminate between * and the list of arguments it expands to. Consequently, rm cannot know whether you typed a single * or the specific list it expands into, so it cannot ask silently accept the latter and ask ‘are you sure’ for the former. Fair point. I like to alias rm to rm -i for that reason, which is sometimes inconvenient too of you actually want to delete a lot of files, so I have to pass -f again to undo it... > “cat paper* > paper.all” or “grep foo > foos” fill up your disk Hmmm, does it create the output file first and then expand the arguments? Otherwise the output file has to already exist, which would create the same problem on Windows, or Linux with a glob syscall, unless you explicitly check if stdout is redirected to a file, and that file is one of your input files. I guess in windows this cannot happen in practice as you cannot open a file twice for reading and writing, but then this has nothing to do with command line handling anymore. > calc 3 * 4 + 5 You'd probably make it so that it has its own parsing too in that case, so you can do calc '3 * 4 + 5'. There are ugly situations with the Linux or really shell way, and after having switched to Linux a long time ago I might be biased towards it, but I really think I had greater wtf moments with command line handling on Windows.

jcelerier 5y ago
> It used to be a single page (so in practice 4k), but on my system for example, it's 128k. Never ran into this problem. that's fairly reachable with some complicated compiler command lines where things are 8-levels deep in some random embedded SDK
- Hello71 5y ago
  but that's not relevant to the original question of *
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

jcelerier 5y ago

> It used to be a single page (so in practice 4k), but on my system for example, it's 128k. Never ran into this problem. that's fairly reachable with some complicated compiler command lines where things are 8-levels deep in some random embedded SDK

Hello71 5y ago
but that's not relevant to the original question of *

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