Peter Seebach writes:


>I begin to think there's no good solution.  I intuitively object to treating
>any character for which isspace() is non-zero as anything but space.

That may be non-intuitive but at least the SysV man pages make it
clear beyond doubt that the shell doesn't treat any character for
which isspace() return true as white space.

In fact, there's explicit language that space and tab characters
separate words and that a newline character is a synonym for a semicolon.

>BTW, I see several places in which sh's code appears to refer to \t and ' ' as
>such; shouldn't that be something like $IFS?

Maybe, if you can produce a test case where the NetBSD shell behaves
differently then the Bourne shell or where POSIX mandates it.

>Perhaps what Unix needs is "text mode", in which \r's are silently ignored on
>input.  (Obviously, they would not be generated on output.)

Unix *has* a "text mode".  \r's are converted to \n's on input.
Obviously, a \n is converted to a \r\n on output.
-- 
Christoph Badura	bad@flatlin.ka.sub.org

You don't need to quote my .signature.  Everyone has seen it by now.
Besides, it doesn't add anything to the current thread.