thanks Terrence
this issue isn't how to read long lines
but rather how to prevent a simple program that reads lines from
being a denial of service
On Tue, 06 Dec 2011 06:23:59 -0600 Terrence J. Doyle wrote:
> If you really want to read very long lines without truncation, you might
> try this:
> function readll
> {
> typeset char
> unset LINE
> while read -rn1 char
> do
> [[ "$char" == $'\n' ]] && { true; return; }
> LINE+="$char"
> done
> false
> }
> A line of input, very long or otherwise, will be returned in $LINE. This
> might be made more efficient by reading more than one character at a
> time. However, that's going to make end-of-line-processing in the
> function a bit more complicated.
> I haven't tried this on lines as long as those you've tried. What's
> more, I don't know what would happen if the limit (if there is any) on
> the number of bytes stored in a variable is reached.
> Also, this doesn't seem to work with my latest version of ksh: Version M
> 93t 2008-11-04. It does work in prior versions. The problem in ksh-t
> appears to be that the input pointer is never advanced, so the read
> command reads the first character of input over and over again. I assume
> this has been fixed in ksh-u.
> Terrence Doyle
> j. van den hoff wrote:
> > I've originally sent this on nov. 22, but it seems that it did not
> > make it to the list (I don't see it in the archive). so second try
> > (with minor modifications):
> >
> > I stumbled over the following problem with the `read' builtin of ksh93
> > (Version JM 93u 2011-02-08).
> >
> > short version:
> > ==============
> > the `read' built-in is supposed to read a single input line (up to a
> > linefeed). it does'nt work correctly with very long input lines but
> > rather
> > returns a truncated string of length 253952 without any notification
> > (e.g., via return status).
> >
> >
> > long version:
> > =============
> > try this:
> >
> > 1. generate a file `longline.txt' containing some very long string, e.g.
> > with:
> >
> > =====CUT=====
> > #!/bin/ksh
> >
> > if (($# == 0)); then
> > imax=262144 # i.e. 2^18
> > else
> > imax=$1
> > fi
> >
> > print "just a moment..."
> > for ((i=1;i<$imax;i++)); do buf="${buf}."; done
> > buf="${buf}+"
> >
> > print $buf > longline.txt
> > =====CUT=====
> >
> > which generates a file with a single line of 262143 repeated `.'
> > characters plus a single `+' (that is 2^18 chars (plus a \n)).
> >
> > at this point, `wc longline.txt' yields 262145 chars (=2^18 + 1 due to
> > trailing \n).
> >
> > now, in `ksh' from the command line, do
> >
> > read a < longline.txt
> > echo $? ### yields `0', i.e. "no error"
> > echo ${#a} ### yields a string length of 253952
> > echo $a ### shows that truncation is occurring
> >
> > 253952 thus is the length of the returned truncated string for an actual
> > line length > 2^18 (including trailing \n). to make it a bit more
> > confusing, shortening the line by a single character to a length of
> > 262143
> > characters (i.e. total length 2^18 due to the trailing \n) leads to
> > correct reading, i.e.
> >
> > echo ${#a} ###yields string length 2621413 = 2^18 - 1
> >
> > now, 2621414-253952=8192, so it seems that the input buffer length is
> > 8192
> > bytes and if the input line length does not exceed the sum of 253952 plus
> > buffer length, the reading still works as expected.
> >
> > =====
> >
> > I've seen this with Version JM 93t+ 2010-06-21 under MacOS as well as
> > ubuntu and with Version JM 93u 2011-02-08 under MacOS (ubuntu not
> > tested).
> > I find this behavior nowhere documented and presume it's a bug.
> >
> > since there seems no way to discriminate whether a truncated or a
> > complete
> > line has been read (and, if truncated, whether truncation occurred in the
> > middle of a (IFS separated) field or not), it seems not even possible
> > to circumvent the problem with successive reads from the same input file
> > since one does not know how to patch the successively read-in parts
> > together correctly.
> >
> > I would appreciate any feedback whether this behavior is known/can be
> > confirmed (did'nt find anything on the net), whether it's really a bug
> > (or
> > whether I am making some stupid error), and, ideally, how it can be
> > fixed upstream
> > or locally.
> >
> >
> > thanks,
> >
> > joerg
> >
> > ps: in `bash' and `zsh' everything just works as expected.
> > _______________________________________________
> > ast-users mailing list
> > [email protected]
> > https://mailman.research.att.com/mailman/listinfo/ast-users
> _______________________________________________
> ast-users mailing list
> [email protected]
> https://mailman.research.att.com/mailman/listinfo/ast-users
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
