\n or \r\n?
Petr Stehlik
Hi,
I don't know if this is related to that recent fputc() patch, but an
output of simple printf("First line\nSecond line"); looks differently
under MiNT and TOS. Under TOS it does not return the carriage :-)
However the same program compiled under PureC works fine under TOS.
Shouldn't the MiNTlibs do automatic CR->CRLF translation on output
(under TOS at least)?
Petr
--
E-mail: ste...@cas3.zlin.vutbr.cz PARCP developer
WWW: http://cas3.zlin.vutbr.cz/~stehlik/ MiNTOS/Linux user
mirror: http://users.zln.cz/~pstehlik/ Atari 800XL emulation
mirror: http://www.stehlik.cyberstrider.org/ Atari Falcon040
Yves Pelletier
On Sun, 17 May 1998, Petr Stehlik wrote:
> output of simple printf("First line\nSecond line"); looks differently
> under MiNT and TOS. Under TOS it does not return the carriage :-)
> However the same program compiled under PureC works fine under TOS.
>
> Shouldn't the MiNTlibs do automatic CR->CRLF translation on output
> (under TOS at least)?
I would support a new library function for EOLN translation. I
still don't think it belongs in fputc().
Is there a reasonable way EOLN translation could be turned on or
off depending on whether or not we run under MiNT?
Yves
Tamminen Eero
> > output of simple printf("First line\nSecond line"); looks differently
> > under MiNT and TOS. Under TOS it does not return the carriage :-)
> > However the same program compiled under PureC works fine under TOS.
> >
> > Shouldn't the MiNTlibs do automatic CR->CRLF translation on output
> > (under TOS at least)?
CR is Mac newline, LF unix one... :-)
> I would support a new library function for EOLN translation. I
> still don't think it belongs in fputc().
>
> Is there a reasonable way EOLN translation could be turned on or
> off depending on whether or not we run under MiNT?
Why not just use \r\n on programs which are supposed to (= can) run
under both plain TOS and MiNT?
- Eero
Petr Stehlik
On Tue, 19 May 1998 01:21:25 +0200 (EET DST), Tamminen Eero wrote:
TE>> > under MiNT and TOS. Under TOS it does not return the carriage :-)
TE>> > However the same program compiled under PureC works fine under TOS.
TE>> >
TE>> > Shouldn't the MiNTlibs do automatic CR->CRLF translation on output
TE>> > (under TOS at least)?
TE>
TE>CR is Mac newline, LF unix one... :-)
Sure I meant LF->CRLF
TE>> I would support a new library function for EOLN translation. I
TE>> still don't think it belongs in fputc().
I didn't say it belongs to fputc(), I just think it would be OK if
simple printf("1\n2") would do the expected thing under TOS.
TE>> Is there a reasonable way EOLN translation could be turned on or
TE>> off depending on whether or not we run under MiNT?
TE>
TE>Why not just use \r\n on programs which are supposed to (= can) run
TE>under both plain TOS and MiNT?
As I pointed out: the same object code linked with PureC libs does
different thing than when linked with MiNTlibs. That should be fixed in
MiNTlibs, not by rewritting every possible source code.
Guido Flohr
> > Is there a reasonable way EOLN translation could be turned on or
I think no matter whether we run under MiNT or not \r\n is the
worst solution of the three possibilities... ;-)
Actually the UNIXMODE environment variable should control
that. If it contains a `b' files should be opened always
in binary mode (i.e. \n only) if not it is the default
TOS mode (\r\n).
You have to distinguish whether a regular file or a terminal
device is written. For regular files LF should never cause
problems because most editors accept it. For terminal devices
this is actually a terminal setting for the terminal driver.
Maybe the MiNTLib should check somehow if it deals with
a terminal that respects the IGNCR resp. ONLCR flags. If not
it should automatically do the conversion when writing
to a terminal (because then it is very likely to be the
console).
> Why not just use \r\n on programs which are supposed to (= can) run
> under both plain TOS and MiNT?
Because many of them would cause big big difficulties under
MiNT. Perl5.004 for example doesn't use getcwd() but takes
the output of the pwd command to retrieve the current
directory. It then discards the last character (which is
guaranteed to be a newline) and then expects a valid
pathname. If the pathname was terminated with \r\n (like
the K[GE]MD pwd does) this doesn't work because the extra
CR messes everything up.
Besides, many, many tools (including bash, gcc, ...) can't
handle input files which are CRLF terminated.
Ciao
Guido
--
http://stud.uni-sb.de/~gufl0000
mailto:gufl...@stud.uni-sb.de
Michael Schwingen
On Wed, May 20, 1998 at 10:54:41PM +0100, Petr Stehlik wrote:
> As I pointed out: the same object code linked with PureC libs does
> different thing than when linked with MiNTlibs. That should be fixed in
> MiNTlibs, not by rewritting every possible source code.
Agreed.
PureC *does* CRLF->LF->CRLF conversion in the library unless the files
were opened with "b" mode ("rb", "wb+" etc.). That way, programs behave like
they should (they never get to see the CR when processing ASCII files), yet
you get correct CRLF-terminated files.
Some MSDOS libraries seem to do the same thing. And as the programmer should
know if he is dealing with ASCII or binary files, there is no problem with
that conversion, so IMHO the Mintlib should do it, too.
cu
Michael
Julian Reschke-FJR010
I think this is what ANSI defines as the correct behaviour on a system
which has a character sequence as line termination.
Regards, jr
Tamminen Eero
> > Why not just use \r\n on programs which are supposed to (= can) run
> > under both plain TOS and MiNT?
>
> Because many of them would cause big big difficulties under
> MiNT. Perl5.004 for example doesn't use getcwd() but takes
> the output of the pwd command to retrieve the current
> directory. It then discards the last character (which is
> guaranteed to be a newline) and then expects a valid
> pathname. If the pathname was terminated with \r\n (like
> the K[GE]MD pwd does) this doesn't work because the extra
> CR messes everything up.
Ahem, I should have said "use \r\n when you *have to* run under TOS
(too)". Who would want to run shell or shell utils on plain TOS?
You seem to be suggesting that /every/ libc stream function should
/always/ check:
1) FILE* is not opened with the binary flag OR
2) isatty(FILE*) is true / terminal has suitable flags set.
3) scan read / written string / chars for whether threre's an \n.
4) It's not preceded with \r (not as nasty as it sounds as I
think that streams always store the last char so we don't
have to hit disk again if \n is first char & buffer is flushed).
Then you'll insert \r before every suitable instance of \n.
Am I right?
Is it worth the troubles ([1] would probably break some unix programs as
'b' has no meaning with single-char-newline-enviroment and therefore 'b'
might not be always used)?
Does PureC implement the \r -> \r\n conversions completely or is it just
a broken hack?
- Eero
Howard Chu
Y'know, the last time I checked, the MiNTlibs already work this way...
I.e., when you fopen a file for read, using "r" gives you \r\n -> \n
translation. Using "rb" gives you the exact contents of the file,
with no modification. Likewise for writing - open with "w" mode, and
writing \n is translated to \r\n on output. With "wb" mode, no modification
is done. What's the problem?
Under MiNT, since we have actual tty device drivers, output to the console
will be determined by the settings in the driver (termio stuff). At one
time,
(I haven't looked recently) the MiNTlib contained tty emulation code for
TOS,
that would at least keep track of echo, binary, and a couple other basic
settings, so that \n and other special characters would still be handled
as intended. If this has broken recently, then I would guess that some of
the "crufty old baggage" that was thrown out from recent library overhauls
should not have been removed...
Julian Reschke-FJR010
t15...@students.cc.tut.fi%INTERNET wrote:
>
> > > Why not just use \r\n on programs which are supposed to (= can) run
> > > under both plain TOS and MiNT?
> >
> > Because many of them would cause big big difficulties under
> > MiNT. Perl5.004 for example doesn't use getcwd() but takes
> > the output of the pwd command to retrieve the current
> > directory. It then discards the last character (which is
> > guaranteed to be a newline) and then expects a valid
> > pathname. If the pathname was terminated with \r\n (like
> > the K[GE]MD pwd does) this doesn't work because the extra
> > CR messes everything up.
>
> Ahem, I should have said "use \r\n when you *have to* run under TOS
> (too)". Who would want to run shell or shell utils on plain TOS?
I do. Sometimes. Then, I also run shells and utilities under MagiC.
> You seem to be suggesting that /every/ libc stream function should
> /always/ check:
> 1) FILE* is not opened with the binary flag OR
> 2) isatty(FILE*) is true / terminal has suitable flags set.
> 3) scan read / written string / chars for whether threre's an \n.
> 4) It's not preceded with \r (not as nasty as it sounds as I
> think that streams always store the last char so we don't
> have to hit disk again if \n is first char & buffer is flushed).
>
> Then you'll insert \r before every suitable instance of \n.
> Am I right?
>
> Is it worth the troubles ([1] would probably break some unix programs as
> 'b' has no meaning with single-char-newline-enviroment and therefore 'b'
> might not be always used)?
>
> Does PureC implement the \r -> \r\n conversions completely or is it just
> a broken hack?
As far as I can decide, it's everywhere and working perfectly.
Regards, jr