Re: FW: Re: Why is my executabel in DOS file format?

[DJ Delorie <dj at redhat dot com>]

> Are you sure /n = is turing into a line feed ?  I don't think it is,
> thus I wouldn't need to run DOS2UNIX. I just tried it with the HEX
> values and /n etc. I found /n on my linux box is a CR and LF.

In C, '\n' means "newline".  If you're outputting a text file, that
means whatever line ending the host OS expects (for DJGPP, for
example, it's "\r\n").  However, BFD opens files in binary mode.  In
that case, the C idiom '\n' means character 0x0a (ASCII LF).

Note that '\n' on your Linux box should be just ASCII LF, no CR should
be present.  It is only on DOS or Windows systems that the tools
automatically put the CR in when '\n' is given in the source, and even
then only when the file is opened in text mode.  Even DJGPP puts just
LF for '\n' when opened in binary mode.

The only way to get ASCII "CR CR LF" is to print a "\r\n" on a DOS
system with a file opened in text mode.  Or do one too many unix to
dos conversions while copying the file around.

> Ian, I am not sure why you keep replying saying it is not a text
> file when I have QUOTED right out of the SPEC it is a text file -
> ASCII READABLE!

A file can be readable ASCII without being a text file.  All "readable
ASCII" means is that it's restricted to the bytes 0x20 through 0x7e
(possibly 0x7f too, although technically that's an anti-character),
and the well-defined control codes CR, LF, FF, and HT (or so).  It
does *not* mean that the file uses the OS's native convention for line
endings (CRLF on dos, LF on unix, CR on mac).