4 ms·

Pretty sure that limit doesn't exist anymore.

by chungy 4y ago

deathanatos 4y ago
I think it does. The man page for execve(2) documents it. On my system, the documented limit is 2 MiB. OTOH, I do sort of see the argument for "why is there an arbitrary limit here?", beyond just "it's limited by available memory". OTOH, what on Earth is one doing, passing more than 2 MiB of arguments to a program? Surely one would be better served with piped input, at that point…
- amelius 4y ago
  > OTOH, what on Earth is one doing, passing more than 2 MiB of arguments to a program? Simplest example is: mv * /some/place/ in a folder with a lot of files. Also, if Python had a limit of 2M bytes in e.g. a list, then all hell would break loose. Yet, Bash is some people's Python, under some circumstances (and in Bash you're more likely to run into this problem).
- hermitdev 4y ago
  I've hit command line length limits on both Windows and Linux (and they're different lengths). Typically when I've run into it, it's been with build systems, especially those built around make/gnumake. Have a set of object files that need linking, what do you do? Typically, just expanding the variable holding the list as an argument list to ld or whatever works just fine. Until the project grows substantially and you're linking hundreds or thousands of object files. And what if they're in a different path? A subfolder? What if you're using absolute paths to object file locations? These things can blow up in weird and surprising ways and it's not always obvious what the cause is. Thankfully, most tools used to build software typically have a mechanism to read arguments from a file that doesn't suffer from this limitation. Also, as a sibling comment mentions: globs expansions. Typically done by the shell, then passed to the invocation target. Better to pass the glob in quoted and have invoked program do the expansion... Just a couple places I've seen the problem.

Pretty sure that limit doesn't exist anymore.

by chungy 4y ago

Pretty sure that limit doesn't exist anymore.

I think it does. The man page for execve(2) documents it. On my system, the documented limit is 2 MiB. OTOH, I do sort of see the argument for "why is there an arbitrary limit here?", beyond just "it's limited by available memory". OTOH, what on Earth is one doing, passing more than 2 MiB of arguments to a program? Surely one would be better served with piped input, at that point…

amelius 4y ago
> OTOH, what on Earth is one doing, passing more than 2 MiB of arguments to a program? Simplest example is: mv * /some/place/ in a folder with a lot of files. Also, if Python had a limit of 2M bytes in e.g. a list, then all hell would break loose. Yet, Bash is some people's Python, under some circumstances (and in Bash you're more likely to run into this problem).
hermitdev 4y ago
I've hit command line length limits on both Windows and Linux (and they're different lengths). Typically when I've run into it, it's been with build systems, especially those built around make/gnumake. Have a set of object files that need linking, what do you do? Typically, just expanding the variable holding the list as an argument list to ld or whatever works just fine. Until the project grows substantially and you're linking hundreds or thousands of object files. And what if they're in a different path? A subfolder? What if you're using absolute paths to object file locations? These things can blow up in weird and surprising ways and it's not always obvious what the cause is. Thankfully, most tools used to build software typically have a mechanism to read arguments from a file that doesn't suffer from this limitation. Also, as a sibling comment mentions: globs expansions. Typically done by the shell, then passed to the invocation target. Better to pass the glob in quoted and have invoked program do the expansion... Just a couple places I've seen the problem.