To 'get around' the limit, try installing a soft link which points to the directory you are trying to copy to (this should take care of the long directory structure)
I think that you have some other problem. The various limits are found in <limits.h> or "man limits". The max length of a command line is 2048. A posix compliant OS may have a larger limit but it may not have a smaller limit. So you can depend on at least 2048. I often use commands longer than 255 characters on HP-UX.
Care to verify that Perderabo? When I read your post I figured you were correct since I mostly have to deal with Solaris and I know how many differences between the major UNIX brands.
But in trying to enter a continous 255+ command on the command line it dies a horrible death with a quite spectacular sounding of the "keyboard overflow" .... streaming beeps. (Yes, it was on HP-UX 11).
How are you creating 255+ character command lines? (For my education, thank you)
Would the limit you suggest still not have a problem with the find command that the poster submitted?
As I test, I just signed in to an 11.0 box. Then I typed:
echo xxxxxxxxxxxx | wc -c
I actually held the x key for a long time. The result was 1988. I'm surprised that I got that close to 2048, I removed my finger from the x key when I estimated that I had about 500 characters. Oh well.
But maybe you made a similiar error? 255+ is a slippery term. Could you have had very much more than 255?
Even MAX_INPUT is 512. That means that you should be able to pre-type 512 characters and have them laying around in the terminal's input buffer ready to go for the next read the shell issues.
My usual means of generating very long command lines is something like:
gzip *
But I realized that I needed to explicitly type one in to really prove my point.
As for the find command itself, it clearly is ok. The OP had troubles building a subsequent command by cutting and pasting the output from the find command. I have no way of knowing how long the created command was.
Thanks Perderabo. I did two different commands (one to create a directory which I realized may have been a problem other than the 'limit' on command line) but both errored by beeping constantly and giving an error in the middle of the line.
On one, it cut a grep command and came back with "command not found" for "rep" and the other died along the same line (same number of characters).
cat passwd | grep h | grep o | grep m | grep e | grep a | grep i | grep o | grep 8 | grep 1 | grep 3 | grep 2 | grep 9 | grep "-" | grep S | grep b | grep l | grep t | grep L | grep 4 | grep d | grep r | grep 0 | grep V | grep I | grep abal | grep k | grep and | grep ers | grep eit | grep N | grep z | grep w | grep g | grep N
$ V | grep I | grep abal | grep k | grep <
usage: grep [-E|-F] [-c|-l|-q] [-bhinsvx] -e pattern_list...
[-f pattern_file...] [file...]
usage: grep [-E|-F] [-c|-l|-q] [-bhinsvx] [-e pattern_list...]
-f pattern_file... [file...]
usage: grep [-E|-F] [-c|-l|-q] [-bhinsvx] pattern [file...]
Note that when hitting return, it errors and gives back a prompt and includes the rest of the line as a start of a new command ($ V | grep 1 ....).
This is probably some other parameter set differently from one system to the next (or possibly shell) but I figured I would ask about it. I can also get the same response on Solaris even though I found some indication that the same information you suggested was true for it too. Ksh on HP and csh on Solaris. And for some reason I get a few more characters (about 40 ) on Solaris. The whole thing is strange and inconsistant.
That sounds like flow control. Characters are arriving too fast for the driver to read them. Are you using a real terminal? If you're using a network connection, are you using rlogin? If so switch to telnet and repeat your test. Bear in mind that even if flow control is working properly, it is not directly connected to you. All it can do is beep and hope that you stop typing.