0

I remember working on an old midrange in ksh and dynamically building commands that ran over the 2kb I had available in the buffer.

I recently came upon an issue where one possible easy fix might create very long commands with lots of long arguments. A coworker asked what the limit was in modern bash, and it occurred to me that I have no idea. Searches all seem to get sidetracked into the number of lines in the history buffer, but that's not relevant here.

So I ran some tests (please check my logic here...)

time echo $( printf "%01024d" $( seq 1 $max ) ) | wc -c

I ran a few simple tests with great success. Even on my laptop's git bash emulation, if I run this with max=32 I get 

$: time echo $( printf "%01024d" $( seq 1 $max ) ) | wc -c
32769

real    0m0.251s
user    0m0.061s
sys     0m0.215s

That's an echo followed by 32 1kb strings as space-delimited arguments, piped to wc -c reporting an appropriate number of bytes received, in about a quarter second. Needless to say I was pleased and surprised, so I started doubling max looking for the cap... and failed. Look at this.

max=40960
$: time echo $( printf "%01024d" $( seq 0 40960 ) ) | wc -c
41944065

real    0m10.985s
user    0m4.117s
sys     0m7.565s

Eleven seconds to process, but that's a single command line of 41MB, successfully created, loaded, executed and parsed.

Holy crap... What's the upper end of this spec???

And/or is there some reason this test isn't a good proof that I could build an almost arbitrarily long command?

Paul Hodges
  • 13,382
  • 1
  • 17
  • 36
  • 1
    [This](https://www.in-ulm.de/~mascheck/various/argmax/) might be relevant here. – Benjamin W. May 01 '19 at 18:12
  • Almost certainly a duplicate, thanks for the link. Relevant takeaway - the problem is less about line length than number of arguments. On my laptop `getconf ARG_MAX` returns `32000`, but I can set `max=256000` and `/bin/echo $( seq 1 $max ) | wc -w` gives me `256000`, though at `512000` I get `0`... – Paul Hodges May 01 '19 at 18:24
  • Since you agree it's a duplicate, I'll go ahead and vote to close as such. Either way, glad you found the answer you needed. – Mike Holt May 01 '19 at 18:26
  • Yep, Thanks! (I'm easy, lol) – Paul Hodges May 01 '19 at 18:27

1 Answers1

-1

A short answer for the main question is:

The limit for the length of a command line is not imposed by the shell, but by the operating system. This limit is usually in the range of hundred kilobytes.

Rakan Ajlouni
  • 16
  • 5
  • 1
    This seems sensible - why the downvote? (Yes, I actually am curious about the spec, but this is still relevant.) – Paul Hodges May 01 '19 at 18:11
  • This appears to be a verbatim quote of [this answer](https://stackoverflow.com/a/19355351/3307686), which is not even your own answer. Instead of reposting someone else's answer as your own, you should just comment and point out that the question is a duplicate, and link to the existing answer. – Mike Holt May 01 '19 at 18:12
  • This is my first answer to a question i just started using this website. So it's my bad if i did it the wrong way – Rakan Ajlouni May 01 '19 at 18:15
  • @RakanAjlouni That's understandable. In the future, please provide a comment saying "possible duplicate of ..." and provide a link to the existing answer. Also, copying someone else's words verbatim without attribution is generally frowned upon, not only on StackOverflow, but pretty much everywhere. – Mike Holt May 01 '19 at 18:19
  • Indeed that's true, how can i exactly provide a hyper link like you did "this answer"? – Rakan Ajlouni May 01 '19 at 18:21
  • 1
    See here: [markdown help](https://stackoverflow.com/editing-help). – Mike Holt May 01 '19 at 18:23