[Implemented] PrintN() should produce #CRLF$

[Trond]

Can you please exlain what that means for the problem I posted?

I think Rings means that CR+LF is a Windows only solution and wouldn't be considered crossplatform.

LF is a linux only solution and wouldn't be considered crossplatform either.

Actually <LF> is a Linux and Unix and BSD (which therefore presumably includes OSX) - so IMO <LF> is the standard and <CRLF> (Windows) or <CR> MacOS are the non-standard exceptions.

That's just crazy thinking. You say that because one family of operating systems uses LF, that's standard. While most everyone else use CRLF, including:
The Windows family (which has >90% of the desktop market)
DEC RT-11 (which was first released 1 year before the first publication describing UNIX)
CP/M
ATARI (Tower-less hardware design (just the keyboard and the monitor, no box), mouse and graphical environment 6 years before Linux was even started)

[blueznl]

LF is about as wrong as one can get

Listen to the oldies:

LF = LineFeed, it should just shift up the output one line, or in CRT terms: move the cursor one step down, it's not supposed to change the horizontal position.

CR = CarriageReturn, it would move the printer head back to the start of the line, as such it's not supposed to change the vertical position.

For once, Windows got it right and Linux got it oh so wrong!

[djes]

LF is about as wrong as one can get

Listen to the oldies:

LF = LineFeed, it should just shift up the output one line, or in CRT terms: move the cursor one step down, it's not supposed to change the horizontal position.

CR = CarriageReturn, it would move the printer head back to the start of the line, as such it's not supposed to change the vertical position.

For once, Windows got it right and Linux got it oh so wrong!

+1

[Psychophanta]

LF is about as wrong as one can get

Listen to the oldies:

LF = LineFeed, it should just shift up the output one line, or in CRT terms: move the cursor one step down, it's not supposed to change the horizontal position.

CR = CarriageReturn, it would move the printer head back to the start of the line, as such it's not supposed to change the vertical position.

For once, Windows got it right and Linux got it oh so wrong!

Yeah! That's the only right point, coz the computers keyboard consoles are an inheritance of the old typewriter machines.

1. - How do you tell to linux to do a Line Feed (no Carriage Return command, but just one line feed)?
2. - How do you tell to macs to do a Carriage Return (no Line Feed command, but just one Carriage Return)?

Only MicroSoft makes your life easier

[naw]

Can you please exlain what that means for the problem I posted?

I think Rings means that CR+LF is a Windows only solution and wouldn't be considered crossplatform.

LF is a linux only solution and wouldn't be considered crossplatform either.

Actually <LF> is a Linux and Unix and BSD (which therefore presumably includes OSX) - so IMO <LF> is the standard and <CRLF> (Windows) or <CR> MacOS are the non-standard exceptions.

That's just crazy thinking. You say that because one family of operating systems uses LF, that's standard. While most everyone else use CRLF, including:
The Windows family (which has >90% of the desktop market)
DEC RT-11 (which was first released 1 year before the first publication describing UNIX)
CP/M
ATARI (Tower-less hardware design (just the keyboard and the monitor, no box), mouse and graphical environment 6 years before Linux was even started)

Well the crazy thing is that for something so simple there wasn't/isn't a defacto standard but back in the 1970's interoperability wasn't such an issue. I guess maybe the extra byte used by a CRLF as opposed to just CR was considered important 37 years ago. Today, we don't really care to the same degree.

As I recall, UNICS (a development of MULTICS ann 1964) was announced in 1969, UNIX in 1970, RT-11 in 1973, CP/M in 1974, BSD (Unix derivative) in 1977, MS-DOS in 1981, TOS 1982, the Amiga 1983, Linux in 1991.

So, yes, I agree that CR+LF is more sensible in the way we use it today, but then UNIX was around 10 years before IBM built the PC as a spoiling tactic against CBMs Pet and Apples II/IIe and comissioned MS to knock out a Quick and Dirty OS. Today, nearly 30 years later, we still have the legacy of an OS that was knocked together in 6 weeks to save buying a CP/M licence :-\

[naw]

1. - How do you tell to linux to do a Line Feed (no Carriage Return command, but just one line feed)?

2. - How do you tell to macs to do a Carriage Return (no Line Feed command, but just one Carriage Return)?

Only MicroSoft makes your life easier

1. use tput cr or /r
2. use tput lf or /l

Unix makes it easy and repeatable

Basically, though for any UNIX derivative OS, you should be using the TPUT command which has a translation file (/usr/lib/terminfo) for every device - printers, ASCII Terminals, xterms etc.

eg:

Code: Select all

tput cup 10 10

- repositions cursor

Code: Select all

tput clear

- clears a screen or forces a Page Feed

Code: Select all

tput cr

- carriage return

Code: Select all

tput lf

- line feed

Code: Select all

tput nel

- NewLine (CR+LF)

I found this documentation :
http://www.ncsa.uiuc.edu/UserInfo/Resou ... HDRA72P01A

or you can just embed /r /l /f to produce CR / LF / FF in your code which will be correctly translated to any device.

or you can embed control characters directly, but different devices may interpret differently - for instance in the vi editor, embedding ^M is equivalent to a UNIX <CR> / ^L is a Form Feed, ^J is a Form Feed.

To do this in vi, press:
<ESC>i (to enter insert mode)
<CTL>V (to prepare vi to accept control characters)
<CTL>M/L/J (to insert CR/LF/FF)

[Trond]

Naw, you say that on unix you just use tput lf to get a linefeed without a carriage return. That's wrong, you actually get both.

[naw]

hi trond,
well it depends how the terminfo DB interprets it for the particular device you're using - but since the convention in Unix is to use a single CR to perform a CRLF, then I'm sure you're right on an ASCII terminal or in an xterm, is it the same for a printer device?

Check the terminfo DB entry for your particular device, I bet you'll see something like

Code: Select all

lf=^J,

which you can obviously change to ^L and recompile with

Code: Select all

tic

thats the beauty of Unix & Linux systems, when you start poking around beneath the surface of the GUI and the shell, you'll find everything is configurable, you can even write your own device drivers (sort of)...

[blueznl]

And all this about CR vs LF

[Trond]

but since the convention in Unix is to use a single CR to perform a CRLF

No, it's LF for CRLF. CR means nothing.

[pdwyer]

I changed it to CRLF for windows.

Does that mean you fixed it? I'm using 4.1 and I just tripped over this. (ie it's not fixed)

Diffinately disagree with rings comments. The compiler is cross platform so it should handle this such that each OS get's what it needs.

It's like saying MessageRequester doesn't call the Messagebox_ API in windows because it can't do it in Linux. It does what it needs to do on that platform.

Workaround is use:

Print(Mytext + #CRLF$)

but this should be in the docs at the very least.

[Trond]

In 4.2 beta 1 it's not LF, it's LFCR instead of CRLF.

[pdwyer]

oops!

What's that for? BeOS?

[freak]

In 4.2 beta 1 it's not LF, it's LFCR instead of CRLF.

oops. fixed.

What's that for? BeOS?

Its for Vista. You know... for "security"

[pdwyer]

It's a feature,

Most languages are still doing it the old CRLF way for windows but PB has leveraged the advanced and performance enhanced LFCR (TM) specification to line breaks. It was felt that since they were so common in files that enormous benfits would be had if this minor improvement were made to add to the experience of the platform



(I read this kind of crap all day :roll: )