Using Tcl, how can I gets() terminal input longer than 256 characters?
Rebecca Bergersen
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.
Thanks,
Becky
Bryan Oakley
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....@iona.com> wrote in message
news:385E80E8...@iona.com...
Rebecca Bergersen
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! %*\
--Becky
Volker Hetzer
> 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!
Alexandre Ferrieux
>
> 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
Don Libes
> 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"
Don
Jeffrey Hobbs
>
> 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.
Rebecca Bergersen
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! :*)
Thanks,
Becky
Peter V. Morch
Rebecca Bergersen wrote:
> Besides, I have faith that you will find the bug and squash it! :*)
Well I don't think that it is a tcl bug. Take a look at Don Libes' post
again. This is a limitation of the terminal, not tcl.
On a Sun SPARC, I tried this incredibly simple C program:
#include <stdio.h>
int main(void) {
char str[10000];
printf("Input str: ");
gets(str);
printf("str: %s, len=%i\n", str, strlen(str));
}
Try it out - This C program won't let you input anything longer than 256
characters either.
And then it doesn't really matter what Tcl does, the limitation is still
gonna be there. ;-)
Peter
Rebecca Bergersen
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.
-Becky
Peter V. Morch
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:
$ cat test | myprogram
Input str: str:
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd,
len=560
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.
Are you convinced yet?
Peter
Rebecca Bergersen
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.
Thanks for your insight!
--Becky
Berry Kercheval
> 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 :-)
Alexandre Ferrieux
>
> Do you suppose using getc() for the input loop would run into
> the same limitation when input is from the keyboard?
Yes !
> Is this a driver issue?
Yes, one of the pseudoterminal driver/module/whatever of the system. Or
maybe the rlogind/telnetd, because this crosses rlogin/telnet.
> Since some of the responses indicated that systems other than Sun were
> exhibiting the same behavior,
I've made more experiments:
1. The same bug appears without using any C nor Tcl:
# cat > foobar
aaaaaaaaaaaaaaaa... (try to type or Paste 260 of them)
BEEEP !
2. It occurs on OSF Dec alphas, and on Sol2.7 suns (but not 2.5.1 !).
BTW, do you have real good reasons to use Solaris>2.5 ? I'm sincerely
trying to see any added value (amongst the marketing
stuff).
-Alex
Rebecca Bergersen
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
Jeffrey Hobbs
>
> Just to be sure, I'll recompile the kernels of our Linux, HP, IBM and
> MicroSoft systems too!
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).
> Berry Kercheval wrote:
...
> > 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 :-)
--
Andrew Tannenbaum
Jeffrey Hobbs <jeffre...@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.