Open doctorpangloss opened 1 month ago
This is the same as in upstream busybox.
I'm guessing it's controlled by the config value CONFIG_FEATURE_EDITING_MAX_LEN, which defaults to 1024.
So you can build bb-w32 yourself with a bigger configured value, or maybe the default for windows can be increased a bit, but keep in mind that the line edit in busybox (including -w32) is not the most efficient, especially when it spans multiple lines, so placing such a long input at the line-edit prompt is sub-optimal anyway.
But yeah, increasing it to 2048 for instance would probably be OK.
(there's an additional internal limit that the config value can be at most a bit nore than 32000)
Is there any reason CONFIG_FEATURE_EDITING_MAX_LEN
can't be a really, really large number?
Is there any reason
CONFIG_FEATURE_EDITING_MAX_LEN
can't be a really, really large number?
I'm guessing memory usage and efficiency of the editing algorithms, but it's a complete guess.
Why won't you build it with the maximum size (about 32700) and report back if you observe any issues when placing many KB of text at the prompt?
@doctorpangloss It depends what you mean by really, really large. How big is that, exactly?
In practical terms there's little point in going above 32KB, though quite a bit less than that is probably enough for most people.
I wonder what are the practical use cases for pasting several KB into the shell prompt.
The most I can think of is e.g. a huge URL which one intends to use with curl or wget, for instance, though URLs are typically also limited in length by browsers and possibly other tools (e.g. in Chrome and Edge it's 2K, though other browsers have higher limit).
Another thing, maybe, is pasting a big script snippet which one wants to execute at the current shell, but it's quite ill-advised to do that.
What other practical use cases are there?
Also, worth keeping in mind that bb ash doesn't have bracketed paste, so accidentally pasting huge text can be painful even with 1K paste limit - as ash tries to execute each line, but it becomes more painful the bigger the limit.
So I don't think raising it to the maximum possible is good.
I'd say it would be useful to imagine the biggest practical use case currently, and set the limit to twice that to keep some headroom.
I was about to paste on cmdline a json strong of length of 2176 to testing my parsing function and got truncated, isn't possible to increase the dafault value of max length to 8191 to match the limit of the command prompt in Windows?
According to this document the limit of normal command prompt is 8191: https://learn.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/command-line-string-limitation
We don't really care what the Windows command prompt does, but since nobody has suggested a concrete value to use I've set the buffer size to 8192 bytes. This happens to be the maximum the BusyBox configuration allows (though that's neither here nor there, we could use something bigger if we wanted).
If you want a prerelease, PRE-5439 or above is the one to go for.
Pasting small but long lines of text fails frequently.
Reproduction:
Observe the last character is
1
.1
is missing at the end of the paste. This should not happen.