This must be a frequent question, but I couldn't find anything about it in the FAQ. I'm using gets() to read from stdin, but if the line is longer than 256 characters, the first 256 characters are ignored and it starts evaluating the line at the 257th character. I'm cutting-and-pasting some data to the terminal input that is about 280 characters long. I'm using tcl8.2.1 on a Sun running Solaris 7.
Could it be that your cut and pasting operation is adding a newline? Have you tried (tedious, but potentially interesting) pressing a key 260 times or so to see if you get the same result? Or past 250 characters then type in the rest by hand.
Tcl, as a general rule, has no such limits. There is probably something else going on somewhere.
"Rebecca Bergersen" <rebecca.berger...@iona.com> wrote in message
> This must be a frequent question, but I couldn't find anything about it in the > FAQ. I'm using gets() to read from stdin, but if the line is longer than 256 > characters, the first 256 characters are ignored and it starts evaluating the > line at the 257th character. I'm cutting-and-pasting some data to the terminal > input that is about 280 characters long. I'm using tcl8.2.1 on a Sun running > Solaris 7.
I have tried exactly what you suggested. If the input is less than 256 characters, Tclsh takes it just fine. If the input goes over, all the characters from 0 to 255 are lost in the ether and Tcl responds as if the command began with the 257th character (invalid command name "xxxxx").
Try just entering tclsh straight ($ tclsh) and then, at the prompt, type: (% set exes xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...250.more...xxxxxxxxxxxx)
The line wraps, everything looks fine until I hit enter. Then, 'invalid command name "xxxxxxxxxxxx"'. The same thing happens if I put double quotes or braces around the xxxxxxxxs.
There's no need to tediously hit the key 260 separate times - just hold it down until you have about three and a half full lines of 'x'.
Give it a try and let me know if it's just me! %*\
> Could it be that your cut and pasting operation is adding a newline? Have > you tried (tedious, but potentially interesting) pressing a key 260 times or > so to see if you get the same result? Or past 250 characters then type in > the rest by hand.
> Tcl, as a general rule, has no such limits. There is probably something else > going on somewhere.
> "Rebecca Bergersen" <rebecca.berger...@iona.com> wrote in message > news:385E80E8.16BF4806@iona.com... > > This must be a frequent question, but I couldn't find anything about it in > the > > FAQ. I'm using gets() to read from stdin, but if the line is longer than > 256 > > characters, the first 256 characters are ignored and it starts evaluating > the > > line at the 257th character. I'm cutting-and-pasting some data to the > terminal > > input that is about 280 characters long. I'm using tcl8.2.1 on a Sun > running > > Solaris 7.
Rebecca Bergersen wrote: > Try just entering tclsh straight ($ tclsh) and then, at the prompt, type: > (% set exes xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...250.more...xxxxxxxxxxxx)
> The line wraps, everything looks fine until I hit enter. Then, 'invalid > command name "xxxxxxxxxxxx"'. The same thing happens if I put double quotes > or braces around the xxxxxxxxs.
Same for me. However, if I create a tcl script with the long set command everything works fine. I suspect xterm.
Greetings! Volker -- Hi! I'm a signature virus! Copy me into your signature file to help me spread!
> Try just entering tclsh straight ($ tclsh) and then, at the prompt, type: > (% set exes xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...250.more...xxxxxxxxxxxx)
> The line wraps, everything looks fine until I hit enter. Then, 'invalid > command name "xxxxxxxxxxxx"'.
> Give it a try and let me know if it's just me! %*\
Funny: 8.2.2 on a Dec Alpha (OSF) has a similar (but less buggy) behavior: when I try to type over ca. 256 characters, I get a beep from the terminal. This also happens over telnet and rlogin !
Alexandre Ferrieux <alexandre.ferri...@cnet.francetelecom.fr> writes: > Rebecca Bergersen wrote: > > Try just entering tclsh straight ($ tclsh) and then, at the prompt, type: > > (% set exes xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...250.more...xxxxxxxxxxxx)
> > The line wraps, everything looks fine until I hit enter. Then, 'invalid > > command name "xxxxxxxxxxxx"'. > Funny: 8.2.2 on a Dec Alpha (OSF) has a similar (but less buggy) > behavior: when I try to type over ca. 256 characters, I get a beep from > the terminal. This also happens over telnet and rlogin !
> -Alex
Try this script (from page 275 of Exploring Expect):
spawn /bin/sh expect "\\$ " ;# match literal $ in shell prompt for {set i 0} 1 {incr i} { send "/" expect "\007" break "/" } puts "terminal driver accepted $i characters"
> This must be a frequent question, but I couldn't find anything about it in the > FAQ. I'm using gets() to read from stdin, but if the line is longer than 256 > characters, the first 256 characters are ignored and it starts evaluating the > line at the 257th character. I'm cutting-and-pasting some data to the terminal > input that is about 280 characters long. I'm using tcl8.2.1 on a Sun running > Solaris 7.
This is an interesting problem. I can't find anywhere in how the std input loop is handled that has some sort of limitation set on the input line size. You could instead try TkCon, which will alleviate this limitation: http://www.purl.org/net/hobbs/tcl/script/tkcon/
-- Jeffrey Hobbs The Tcl Guy jeffrey.hobbs at scriptics.com Scriptics Corp.
I spent an hour or so looking through the generic/tclIO.c file to see if there was anything I could set. While the code was fairly hairy (all things to all channel types) nothing jumped out at me - nothing I could set, not any indicator of why the original 256 characters disappeared and why 256. The number makes me think there must be some ms-dos legacy hiding in there someplace.
TkCon looks like something I should check out, but I don't think I can apply it to the project I'm doing right now. I need something that will give me a script interface and a command line interface and a shell interface, but no GUI. It's got to run now on several flavors of Unix and on NT and potentially everything else in the world! I noted in your limitations section on TkCon that there is no way to handle stdin input, so Tcl (still) seems to be the best for the job.
Besides, I have faith that you will find the bug and squash it! :*)
> > This must be a frequent question, but I couldn't find anything about it in the > > FAQ. I'm using gets() to read from stdin, but if the line is longer than 256 > > characters, the first 256 characters are ignored and it starts evaluating the > > line at the 257th character. I'm cutting-and-pasting some data to the terminal > > input that is about 280 characters long. I'm using tcl8.2.1 on a Sun running > > Solaris 7.
> This is an interesting problem. I can't find anywhere in how the > std input loop is handled that has some sort of limitation set on > the input line size. You could instead try TkCon, which will > alleviate this limitation: > http://www.purl.org/net/hobbs/tcl/script/tkcon/
> -- > Jeffrey Hobbs The Tcl Guy > jeffrey.hobbs at scriptics.com Scriptics Corp.
As Peter indicates, the c library function gets() seems to be limited to 256 characters. I don't presume to know the best way for Tcl to implement its functionality, but a different mechanism might be more robust - maybe fgets()? I didn't take the time to trace precisely what they did do, deep down there, but there is a slew of possibilities that may not be similarly limited. If there is an unintended restriction on a piece of functionality, is it a bug? I'm just glad that Scriptics is looking into the problem.
Rebecca Bergersen wrote: > As Peter indicates, the c library function gets() seems to be limited to 256 > characters.
<snip>
No, the *TERMINAL* is limited to 256 characters. Not gets(). Not anything in myprogram.
> maybe fgets()?
I don't think calling fgets() will help, because it is a limitation below whatever application is running. Try it. The application itself doesn't get more than 256 characters so it doesn't matter how you code it. Scriptics can't fix it, because it isn't a Tcl bug, but a terminal limitation.
Let me put it another way. Do you know of *any* program written by whoever coded in whatever program you choose, where you can enter more then 256 characters on a single line (and that doesn't use curses)?
Here is something you can try: With vi or whatever, create a file with exactly one line in it, and have that line contain more than 256 characters. I called that file test. Also, the C-program from my previous test I called myprogram. Now do:
As you can see, gets() can handle lines longer than 256 characters no problem. myprogram doesn't know, that stdin has been redirected, as this is done by the OS, so the 256 limitation is not in myprogram.
I think if you want this fixed, you should contact Sun to have it "fixed" in Solaris 7. Maybe there is an OS setting you can change or something like that. Just don't wait around for Scriptics to "fix the bug", because they can't, because there is no bug in Tcl.
I noticed that directing the input from something other than the keyboard worked just fine, so I noted this as a limitation in our software (I'm used to dealing with guilt) and kept on developin'. I have such a tight deadline that I'm skipping meals (which is goodness :*) and don't have time to explore the alternatives. I very much appreciate your efforts and I'm finding them illuminating. Do you suppose using getc() for the input loop would run into the same limitation when input is from the keyboard? Is this a driver issue? Since some of the responses indicated that systems other than Sun were exhibiting the same behavior, I wonder where the limitation is really coming from? I'm not interested in assigning blame, nor in waiting for someone to fix the problem - I just need to identify it, work around it somehow, and move on.
> Rebecca Bergersen wrote: > > As Peter indicates, the c library function gets() seems to be limited to 256 > > characters. > <snip>
> No, the *TERMINAL* is limited to 256 characters. Not gets(). Not > anything in myprogram.
> > maybe fgets()?
> I don't think calling fgets() will help, because it is a limitation > below whatever application is running. Try it. The application itself > doesn't get more than 256 characters so it doesn't matter how you code > it. Scriptics can't fix it, because it isn't a Tcl bug, but a terminal > limitation.
> Let me put it another way. Do you know of *any* program written by > whoever coded in whatever program you choose, where you can enter more > then 256 characters on a single line (and that doesn't use curses)?
> Here is something you can try: With vi or whatever, create a file with > exactly one line in it, and have that line contain more than 256 > characters. I called that file test. Also, the C-program from my > previous test I called myprogram. Now do:
> As you can see, gets() can handle lines longer than 256 characters no > problem. myprogram doesn't know, that stdin has been redirected, as this > is done by the OS, so the 256 limitation is not in myprogram.
> I think if you want this fixed, you should contact Sun to have it > "fixed" in Solaris 7. Maybe there is an OS setting you can change or > something like that. Just don't wait around for Scriptics to "fix the > bug", because they can't, because there is no bug in Tcl.
> As you can see, gets() can handle lines longer than 256 characters no > problem. myprogram doesn't know, that stdin has been redirected, as this > is done by the OS, so the 256 limitation is not in myprogram.
> I think if you want this fixed, you should contact Sun to have it > "fixed" in Solaris 7. Maybe there is an OS setting you can change or > something like that. Just don't wait around for Scriptics to "fix the > bug", because they can't, because there is no bug in Tcl.
In Solaris 2.6, the limits.h file has
#define MAX_CANON 256 /* max bytes in line for canonical processing */
So that's all you can get on an input line. To increase it, change MAX_CANON and recompile the kernel :-)
Just to be sure, I'll recompile the kernels of our Linux, HP, IBM and MicroSoft systems too!
So, to summarize the discussion, it seems that the point of difficulty lies in the os, maybe in the terminal driver, and the MAX_CANON limit of 256 is the source of the buffer size. It doesn't explain why the first 256 characters just disappear and only characters 257+ get through, but that probably is a bug in the driver or somewhere far outside my control.
Thanks, everybody, for your help and patience, --Becky
> "Peter V. Morch" <pmo...@cisco.com> writes: > > As you can see, gets() can handle lines longer than 256 characters no > > problem. myprogram doesn't know, that stdin has been redirected, as this > > is done by the OS, so the 256 limitation is not in myprogram.
> > I think if you want this fixed, you should contact Sun to have it > > "fixed" in Solaris 7. Maybe there is an OS setting you can change or > > something like that. Just don't wait around for Scriptics to "fix the > > bug", because they can't, because there is no bug in Tcl.
> In Solaris 2.6, the limits.h file has
> #define MAX_CANON 256 /* max bytes in line for canonical processing */
> So that's all you can get on an input line. To increase it, change > MAX_CANON and recompile the kernel :-)
In article <3861091D.66969...@scriptics.com>, Jeffrey Hobbs <jeffrey.ho...@scriptics.com> wrote:
> Actually, this is one point where MS wins, becaue the MS command > prompt doesn't have this limitation (at least not at 256 chars on > NT).
Not so fast.
The 256 character limitation is old-school UNIX. UNIX has always liked byte streams with 80-column (or so) lines broken up with newlines. GNU reimplementations of the common UNIX utilities remove many of these restrictions, but the UNIX filter paradigm works nicely with screen- width lines, and heavy processing can still be accomplished within these constraints, using protocols like MIME.
Some will argue that the astute programmer writes code using dynamic data structures. I would argue back that this very thread is evidence enough that there are many programmers out there who don't even have a solid grasp of the layers of code that carry the bytes from their keyboards to their programs, and aren't wary of the pitfalls, so safety nets like MAX_CANON may avoid more trouble than they cause.
I am not advocating fixed length buffers, I'm just saying that there are advantages to both methods.
