Which CR/LF & EOF text file convention does Android use?

I know the carriage return plus line feed and end of file characters
are *different* for *.txt text files between Windows and Linux.

Which CR/LF & EOF text file convention does Android use?

Vincent Cheng Hoi Chuen wrote on 12/17/2015 2:24 PM:
I know the carriage return plus line feed and end of file characters
are *different* for *.txt text files between Windows and Linux.

Which CR/LF & EOF text file convention does Android use?

I use Fastnote on Android and I've move the files from there to Windows and continue without any problem. I do use
Notepad++ rather than notepad. And that might be a fix. Notepad seems to want to get sticky with those CR/LF issues
where notepad++ seems to just truck through it.

Vincent Cheng Hoi Chuen wrote:

I know the carriage return plus line feed and end of file characters
are *different* for *.txt text files between Windows and Linux.

Which CR/LF & EOF text file convention does Android use?

https://en.wikipedia.org/wiki/Androi...ting_system%29
So it is a Linux variant.

That does not mean all *applications* will default to the Linux standard
of just using the CR for the end of line marker. It is up the
application to decide what it will use.

EOF (End of File) is *not* the same as EOL aka newline (for which there
is no ASCII character but a generic term used to represent the
character(s) used to delineate a line). But then there is no ASCII
character for EOF. There is for EOT (End of Transmission, use to be End
of Tape, dec or hex 4). I suspect you meant newline (assigned to dec 12
which used to be LF) instead of EOF.

https://en.wikipedia.org/wiki/Newline

While the unidentified app you use might use a particular char string
for newline, it might support multiple char strings for compatibility
across different operating systems (e.g., Unix and Windows). You'll
need a hex editor to see what your unidentified app uses for the docs
that it creates, or it might be configurable.

| I suspect you meant newline (assigned to dec 12
| which used to be LF) instead of EOF.
|
| https://en.wikipedia.org/wiki/Newline
|

I've never heard of that. 12 is form feed. 10
is line feed. (LF) I haven't seen any chr12 returns.
Files downloaded from Unix/Linux servers generally
use only Chr10 as a return, while Windows uses
13-10.

Mayayana wrote:
added the omitted below attribution line

VanguardLH wrote:

I suspect you meant newline (assigned to dec 12 which used to be LF)
instead of EOF.

https://en.wikipedia.org/wiki/Newline

I've never heard of that. 12 is form feed. 10 is line feed. (LF) I
haven't seen any chr12 returns. Files downloaded from Unix/Linux
servers generally use only Chr10 as a return, while Windows uses
13-10.

My typo. Decimal 12 is *form* feed, not line feed. Decimal 10 is for
newline aka line feed. Got the character correct but the wrong decimal
value. The wiki article is correct.

En el artículo , Vincent Cheng Hoi Chuen
escribió:

Which CR/LF & EOF text file convention does Android use?

Android *is* Linux. so it uses the *nix convention.

But this has bugger all to do with Windows 7. FUs set.

--
(\_/) Tyson Fury: #homophobe #bigot #throwback #missinglink
(='.'=) #neanderthal #misogynist #redneck #dickhead
(")_(")

Big Al wrote in
:

Vincent Cheng Hoi Chuen wrote on 12/17/2015 2:24 PM:
I know the carriage return plus line feed and end of file
characters are *different* for *.txt text files between
Windows and Linux.

Which CR/LF & EOF text file convention does Android use?

I use Fastnote on Android and I've move the files from
there to Windows and continue without any problem. I do
use Notepad++ rather than notepad. And that might be a
fix. Notepad seems to want to get sticky with those CR/LF
issues where notepad++ seems to just truck through it.

I second the Notepad++ recommendation.

Windows Notepad is very dumb.

While Notepad correctly identifies and processes a CR/LF, it doesn't understand LF/CR.

On Thu, 17 Dec 2015 19:24:07 +0000 (UTC), Vincent Cheng Hoi Chuen wrote:

the carriage return plus line feed and end of file characters
are *different* for *.txt text files between Windows and Linux.

Heck, the CR/LF newline conventions are already different *within* Windows:
often a text file in Notepad has all lines totally run-on, while in Wordpad
it's nicely laid out with well-formatted lines; sometimes that's the other
way around; and still others look good either way.

I suspect it comes down to whether it was [CR] (^M), [LF] (^J), or [CR][LF]
that was being used as line terminator (or newline indicator).

Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

tlvp wrote:
On Thu, 17 Dec 2015 19:24:07 +0000 (UTC), Vincent Cheng Hoi Chuen wrote:

the carriage return plus line feed and end of file characters
are *different* for *.txt text files between Windows and Linux.

Heck, the CR/LF newline conventions are already different *within* Windows:
often a text file in Notepad has all lines totally run-on, while in Wordpad
it's nicely laid out with well-formatted lines; sometimes that's the other
way around; and still others look good either way.

I suspect it comes down to whether it was [CR] (^M), [LF] (^J), or [CR][LF]
that was being used as line terminator (or newline indicator).

POSIX defines things like this:

Line:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206

Text file:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_397


[Xpost and Fup2 alt.os.linux (I don't read the other groups)]

In message , tlvp
writes:
On Thu, 17 Dec 2015 19:24:07 +0000 (UTC), Vincent Cheng Hoi Chuen wrote:

the carriage return plus line feed and end of file characters
are *different* for *.txt text files between Windows and Linux.

Heck, the CR/LF newline conventions are already different *within* Windows:
often a text file in Notepad has all lines totally run-on, while in Wordpad
it's nicely laid out with well-formatted lines; sometimes that's the other
way around; and still others look good either way.

The basic Notepad either doesn't _have_ "line wrap", or has it turned
off by default, I can't remember; Wordpad and higher wordprocessors have
it on by default (and set to the width of "paper" you're using). So a
long line (paragraph) with no newlines can look like one line in
Notepad. (I don't think I've seen a file that is readable without
horizontal scrolling in Notepad but isn't in a higher WP.)

I suspect it comes down to whether it was [CR] (^M), [LF] (^J), or [CR][LF]
that was being used as line terminator (or newline indicator).

Or [LF][CR].

Cheers, -- tlvp
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

What has happened since 1979, I suspect, is that the spotting of mistakes has
become entirely associated with mean-spiritedness, snobbishness and
judgementalism. But...can be...funny and interesting.
Lynn Truss, RT 2015/2/21-27

En el artículo , J. P. Gilliver
(John) escribió:

The basic Notepad either doesn't _have_ "line wrap"

It has "word wrap", which does what you want (breaks a long line over
the width of the window and adjusts as the window width is resized.)

--
(\_/)
(='.'=) Bunny says: Windows 10? Nein danke!
(")_(")

On 2015-12-19, tlvp wrote:
On Thu, 17 Dec 2015 19:24:07 +0000 (UTC), Vincent Cheng Hoi Chuen wrote:

the carriage return plus line feed and end of file characters
are *different* for *.txt text files between Windows and Linux.

Heck, the CR/LF newline conventions are already different *within* Windows:
often a text file in Notepad has all lines totally run-on, while in Wordpad
it's nicely laid out with well-formatted lines; sometimes that's the other
way around; and still others look good either way.

Actually many "text editors" assume that it is the display that will
determine the line breaks, and thus do not want any except at the end of
paragraphs. Ie, they are not line breaks but paragraph breaks.

But yes, then one has a whole variety of possibilities.Also {LF}{CR} is
sometimes used (MACs?)

I suspect it comes down to whether it was [CR] (^M), [LF] (^J), or [CR][LF]
that was being used as line terminator (or newline indicator).

Cheers, -- tlvp

In alt.os.linux William Unruh wrote:
But yes, then one has a whole variety of possibilities.Also {LF}{CR} is
sometimes used (MACs?)

Mac OS used to use [CR] only, but I do not know if that has changed
since OS/X (which is unix-based - BSD, not SysV).
And a lot of C-library implementations (for non-Unix) will silently
drop a [CR] at the end of a line (but NOT at the beginning) and when
writing a line will then add it again, that is: \n is translated to
[CR][LF] on Windows-like OS'es).
[LF][CR] has never been supported, as far as I know.

PS: the CR/LF sequence comes from the analogy with a typewriter, for
which you'll move first the carriage/print head back to the beginning
and THEN put the roll onto the next line - first computer terminals
(teletype's, the device name tty still derives from them) were
essentially typewriter-like devices (with PAPER!).

Eef Hartman writes:
William Unruh wrote:
But yes, then one has a whole variety of possibilities.Also {LF}{CR} is
sometimes used (MACs?)

Mac OS used to use [CR] only, but I do not know if that has changed
since OS/X (which is unix-based - BSD, not SysV).

OSX uses LF.

--
http://www.greenend.org.uk/rjk/

On 2015-12-19 12:29, Eef Hartman wrote:

PS: the CR/LF sequence comes from the analogy with a typewriter, for
which you'll move first the carriage/print head back to the beginning
and THEN put the roll onto the next line - first computer terminals
(teletype's, the device name tty still derives from them) were
essentially typewriter-like devices (with PAPER!).

Correct. And emulating that allowed plain text programs in MsDOS to
display progress bars that overwrote the same line many times, using a
CR alone on each "line", without using anything that positions the
cursor at will. Just plain "text" :-)

Most printers I know differentiate CR and LF.

--
Cheers, Carlos.