Re: binfmt_script and ^M

[Richard B. Johnson]

On Tue, 6 Mar 2001, Thorsten Glaser Geuer wrote:

> ----- Original Message ----- 
> From: "Jesse Pollard" <pollard@tomcat.admin.navo.hpc.mil>
> To: <kodis@mail630.gsfc.nasa.gov>; "Richard B. Johnson" 
> <root@chaos.analogic.com>
> Cc: <linux-kernel@vger.kernel.org>; <bug-bash@gnu.org>
> Sent: Monday, 5. March 2001 19:14
> Subject: Re: binfmt_script and ^M
> 
> 
> > John Kodis <kodis@mail630.gsfc.nasa.gov>:
> > > On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
> > > 
> > > > Somebody must have missed the boat entirely. Unix does not, never
> > > > has, and never will end a text line with '\r'.
> > > 
> > > Unix does not, never has, and never will end a text line with ' ' (a
> > > space character) or with \t (a tab character).  Yet if I begin a shell
> > > script with '#!/bin/sh ' or '#!/bin/sh\t', the training white space is
> > > striped and /bin/sh gets exec'd.  Since \r has no special significance
> > > to Unix, I'd expect it to be treated the same as any other whitespace
> > > character -- it should be striped, and /bin/sh should get exec'd.
> > 
> > Actually it does have some significance - it causes a return, then the
> > following text overwrites the current text. Granted, this is only used
> > occasionally for generating bold/underline/... 
> > 
> > This is used in some formatters (troff) occasionally, though it tends to
> > use backspace now.
> 
> Less supports it, but ^H is quite more oftenly used.
> ISO_646.irv:1991 aka ISO-IR-6 aka US-ASCII-7 _also_ defines
> it, and we're going to be not ASCII-compatible any longer if we
> aren't going to support CRLF line endings.
> I also oftenly have the other problem round: LF endings in files which
> are to be viewed under DOS. I use a 15-year-old text editor from
> Digital Research (yes, DOS 3.41) which still is fine under W** and
> DOSEMU, it looks like jstar only that I miss find and replace.
> IMHO those problems could be solved with programmes/kernels/libs
> accepting LF as line ending and CRLF (and possibly CRCRLF ...)
> as a synonyme for LF, but treat CR non-LF differently. I have seen
> this behaviour quite often in the past and am using it for myself, too
> (except for native assembly progs).
> 
> > \r is not considered whitespace, though it should be possible to define
> > it that way. A line terminator is always \n.
> ACK
> 
> > Another point, is that the "#!/bin/sh" can have options added: it can be
> > "#!/bin/sh -vx" and the option -vx is passed to the shell. The space is
> > not just "stripped". It is used as a parameter separator. As such, the
> > "stripping" is only because the first parameter is separated from the
> > command by whitespace.
> 
> That's why I suggest treating CRLF (and only CR only-LF) as LF.
> 
> -mirabilos
> 
> 
[Not on "the list"]

I knew that once Linux caught on, a lot of DOSers and Windozers
would start to complain about the stream-LF files that are used
for text.

In fact, in the "Unix world", we use filters to convert anything
to anything.

You can make a dos2Unix and unix2dos filter in a few minutes. When
you need to work cross-platform, you do:

        cat /dos/drive_C/dos.txt | dos2unix >unixfile

... and vice-versa.

        cat unixfile | unix2dos >/dos/drive_C/dos.txt



/*
 * Simple and free program to convert most of the worlds text files
 * which contain CR/LF pairs to signal the end of each line, to the
 * Unix format which skips the CR and makes life miserable.
 */

#include <stdio.h>
#include <unistd.h>

int main(void);
int main()
{
    char buffer;
    int len;
    while((len = read(STDIN_FILENO, &buffer, sizeof(char))) > 0)
    {
        if(buffer == 0x1a)
            break;
        if(buffer == '\r')
            continue;
        write(STDOUT_FILENO, &buffer, len);
    }
    return 0;
}

/*
 * Simple and free program to convert Unix text files which contain only
 * a LF to signal the end of a line, to the world standard of CR/LF pairs.
 * The end of the text file contains a ^Z as has also been standard for
 * over 30 years.
 */

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

const char crlf[] = {'\r', '\n'}; 

int main(void);
int main()
{
    char buffer;
    int len;

    __FD_CLR(STDIN_FILENO, stdin);
    __FD_CLR(STDOUT_FILENO, stdout);

    while((len = read(STDIN_FILENO, &buffer, sizeof(char))) > 0)
    {
        if(buffer == '\n')
            write(STDOUT_FILENO, crlf, sizeof(crlf));
        else
            write(STDOUT_FILENO, &buffer, len);
    }
    buffer = 0x1a;
    write(STDOUT_FILENO, &buffer, sizeof(char));
    return 0;
}




Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.