bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in sed that causes configure script problem (Windows NT - cygwin


From: Ken Pizzini
Subject: Re: Bug in sed that causes configure script problem (Windows NT - cygwin)
Date: 26 Sep 2000 05:56:14 GMT
User-agent: slrn/0.9.5.7 (UNIX)

On Mon, 25 Sep 2000 11:44:52 -0400, Clark Cooper <address@hidden> wrote:
>On Windows NT, using cgwin 1.0.6 and sed version 3.02 this script fails since
>sed interprets the carriage return (as part of the CRLF line ending under
>Windows) as an unrecognized operator/flag. I verified this by taking the
>same sed script file and replacing CRLF with just LF. The script then
>worked.
>
>I'm amazed and skeptical that I would be the first to run into this problem.
>Have I perhaps missed some autoconf macro or failed to set up the environment
>on the NT system properly?

GNU sed originally tried its best to be blissfully unaware of
line ending issues, and let the stdio library handle any needed
translations.  I can think of two potential stumbling blocks to
the current revision: first, if you are using a file that has
CRLF endings on a volume which you have CygWin mounted with
options which tell the CygWin libraries to not do CRLF->LF
translations (I think I recall hearing that there is such an
option).  And second, if the autoconf test on NT determines that
it supports the mmap() interface, sed will wind up bypassing
stdio and so CRLF endings suddenly start being an issue which
sed _does_ need to address.


>If not and I'm truly the first to report this, here's a patch to sed
>that should fix the problem. I can't tell if it really fixes the problem
>since sed itself uses a configure script that fails in exactly the same way.

If instances of \r must be taken into account then the inchar()
function in compile.c and the read_pattern_space() function in
execute.c are probably the correct places for the fix.  In both
cases, a \r ought only be stripped if it is immediately followed
by a \n, and the overhead of handling this transform (including
the need to handle the potential case of two pushback characters
when inchar() sees a \r that is not at the end of the line)
should be capable of being configured out (and this should be
the default).

                --Ken Pizzini



reply via email to

[Prev in Thread] Current Thread [Next in Thread]