CON: and command line length!

I have just spend a week gathering video clips for a video I'm making and now I'm ready to join all clips only to realize that the Amiga Shell (CON:) can only take a command line of 1024 characters!

KCON: (KingCON) which I normally use is even worse with only 512 bytes length.

Since AmigaDOS now is supposed to have an infinit path length the command length also needs to be infinite, or at least very long. I think Linux uses 32kB which might be a fairly good compromize between a limit and infinity. Should also help when building some ports I guess...

Or is it so that there is a setting somewhere that I have missed? DOS Prefs has a few buffer settings but no command line length.

Edit: WB Execute command has a 256 byte limit apparently.

@Deniil

under KCON
8.Amiga OS 4:S> echo "1231456789012314567890123145678901231456789012314567890123145678901231456789012314567890123145678901231456789012314567890"
1231456789012314567890123145678901231456789012314567890123145678901231456789012314567890123145678901231456789012314567890


How dou you experience those limits?

@Deniil
Btw, for me, in most unixes which i see (and sunos, and freebsd, and irix, and others), almost all the time argument lenght are stripcted to something like 512-1024 bytes usually (in sh/bash/ksh/tch). I think its just to avoid bufferoverflow problems when anyone can crash the programm by long line.

But for example from scripts and programms, you can specify the big line as you can.

@kas1e

Perhaps the workaround is to put the long command line in a script and execute the script instead of trying to copy'n'paste the line into a shell and press enter.

I'll try that.

@Deniil

Yep, i always do it like that. For example pretty offten when you compile something heavy (with many objects and options), you cant put the whole line to shell , and because of it i just create "make.bat", put everything here, and then "execute make.bat".

@Deniil

The command line limit (1024 bytes) is hard coded in the (present) con-handler. Note that this limit applies only to typed input, not to input solicited by a Read operation.

@tonyw

not that I need it personally, but just for curiosity's sake, are there plans to remove this limit in the new CON handler?

greets

@tonyw

Also for curiosity's sake; why is the echo example i gave above working, not only in a KCON shelle but also in a normal shell?

@JosDuchIt

In your echo example 220 bytes (if you post the whole line). Shell limit usually on all oses (include linuxes) 256-1024 bytes.

OR

join 1 2 3 5 5 6 7 8 9 10 to a
join 11 12 13 14 15 16 17 18 19 20 to b
etc
etc
etc
then
join a b c d e f g h i j k to Movie.mpg/avi

There are many many ways of accomplishing all this stuff

well ya probably going to use MEncoder or similair but the principle is the same

@JosDuchIt

[wrong] Because if you just type characters, one at a time, each character is written into the buffer and consumed from it immediately. The limit is only approached if you type ahead.[/wrong]

Edit: That is not quite right, I've just remembered. While you are typing, everything you type or paste goes into the command buffer (including name-completion strings). The command buffer is only emptied when you type Enter and the contents are sent to the Shell. For instance, just hold down any key and watch the repeating characters. After 1024 characters, they will no longer be echoed and any more will be ignored.

@Amigo1

No current plan to increase it, but it could be changed - or made a prefs setting, if it would be useful.

@tonyw
Quote:
I see no reason to not bump it up to at least 4k or so. Ideally it should be dynamic so we don't have to worry about it again.

@ssolie

I am in interest: will the new shell have the same limitation ? I think its CON/KCON limitations, so new shell (if it will based again on CON), will have those limits too (if CON will not overwriting totaly with adding prefs for).