cr, lf, and reading in terminals/vim

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode

I’ve tried every combination of cr, lf, and crlf, but whenever I assemble into a file, I get something that neither the OSX terminal or vim recognizes as having lf in it

I build a set of commands in mrgCmds, appending cr as I go, but I get a bunch of ^M in the otherwise uninterrupted stream with vi and less, while cat shows me the last line (presumably, as it keeps writing it over.

The code in question is

put "outFil=open(theOutPdf, 'wb')" & cr after mrgCmds

put "outFil.write(theOutPdf)" & cr after mrgCmds

put "quit" & cr after mrgCmds

replace cr with crlf in mrgCmds

open file fldr & "/theCmds.py" for write

write mrgCmds to file fldr & "/theCmds.py"

close file fldr & "/theCmds.py"


please, someone help, before the termcap flashbacks tern me into a quivering blob of fear!

Richard E. Hawkins, Esq.
The Hawkins Law Firm
3430 E. Flamingo Rd.
Suite 232
Las Vegas, NV  89121
(702) 508-8462

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
I am not sure, if this will help with your task, but if i want to  avoid that the os replaces the line breaks with it´s default i am writing a binary file instead of a text file.  So in your case you would open the file for "binary write".

Regards,
Matthias

Matthias Rebbe

free tools for Livecoders:
InstaMaker <https://instamaker.dermattes.de/>
WinSignMaker Mac <https://winsignhelper.dermattes.de/>

> Am 30.10.2019 um 22:28 schrieb Dr. Hawkins via use-livecode <[hidden email] <mailto:[hidden email]>>:
>
>
> I’ve tried every combination of cr, lf, and crlf, but whenever I assemble into a file, I get something that neither the OSX terminal or vim recognizes as having lf in it
>
> I build a set of commands in mrgCmds, appending cr as I go, but I get a bunch of ^M in the otherwise uninterrupted stream with vi and less, while cat shows me the last line (presumably, as it keeps writing it over.
>
> The code in question is
>
> put "outFil=open(theOutPdf, 'wb')" & cr after mrgCmds
>
> put "outFil.write(theOutPdf)" & cr after mrgCmds
>
> put "quit" & cr after mrgCmds
>
> replace cr with crlf in mrgCmds
>
> open file fldr & "/theCmds.py" for write
>
> write mrgCmds to file fldr & "/theCmds.py"
>
> close file fldr & "/theCmds.py"
>
>
> please, someone help, before the termcap flashbacks tern me into a quivering blob of fear!
> —
> Richard E. Hawkins, Esq.
> The Hawkins Law Firm
> 3430 E. Flamingo Rd.
> Suite 232
> Las Vegas, NV  89121
> (702) 508-8462
>
> _______________________________________________
> use-livecode mailing list
> [hidden email] <mailto:[hidden email]>
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode
Hi Richard,

> Am 30.10.2019 um 22:28 schrieb Dr. Hawkins via use-livecode <[hidden email]>:
>
> I’ve tried every combination of cr, lf, and crlf, but whenever I assemble into a file, I get something that neither the OSX terminal or vim recognizes as having lf in it
>
> I build a set of commands in mrgCmds, appending cr as I go, but I get a bunch of ^M in the otherwise uninterrupted stream with vi and less, while cat shows me the last line (presumably, as it keeps writing it over.
>
> The code in question is
> put "outFil=open(theOutPdf, 'wb')" & cr after mrgCmds
> put "outFil.write(theOutPdf)" & cr after mrgCmds
> put "quit" & cr after mrgCmds
> replace cr with crlf in mrgCmds
> open file fldr & "/theCmds.py" for write
> write mrgCmds to file fldr & "/theCmds.py"
> close file fldr & "/theCmds.py"
>
> please, someone help, before the termcap flashbacks tern me into a quivering blob of fear!
> —
> Richard E. Hawkins, Esq.

I remember that a very, very long time ago I was advised to use numtochar(8)
as a "line delimiter" for macOS shell scripts written to disk.

At least worth a try...


Best

Klaus

--
Klaus Major
https://www.major-k.de
[hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode

On Oct 30, 2019, at 2:42 PM, Matthias mentioned

> I am not sure, if this will help with your task, but if i want to  avoid that the os replaces the line breaks with it´s default i am writing a binary file instead of a text file.  So in your case you would open the file for "binary write".


Bingo!   That did it.

klaus kicked

>I remember that a very, very long time ago I was advised to use numtochar(8)
>as a "line delimiter" for macOS shell scripts written to disk.

Isn’t that a backspace?



Richard E. Hawkins, Esq.
The Hawkins Law Firm
3430 E. Flamingo Rd.
Suite 232
Las Vegas, NV  89121
(702) 508-8462

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
Hi Richard,

> Am 30.10.2019 um 22:55 schrieb Dr. Hawkins via use-livecode <[hidden email]>:
>
> On Oct 30, 2019, at 2:42 PM, Matthias mentioned
>> I am not sure, if this will help with your task, but if i want to  avoid that the os replaces the line breaks with it´s default i am writing a binary file instead of a text file.  So in your case you would open the file for "binary write".
> Bingo! That did it.
> klaus kicked
>> I remember that a very, very long time ago I was advised to use numtochar(8)
>> as a "line delimiter" for macOS shell scripts written to disk.
> Isn’t that a backspace?

no idea, but it worked for me years ago. :-)

> —
> Richard E. Hawkins, Esq.

Best

Klaus
--
Klaus Major
https://www.major-k.de
[hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode

On Oct 30, 2019, at 2:57 PM, Klaus major-k via use-livecode <[hidden email]> wrote:
>
> no idea, but it worked for me years ago. :-)


which is the ultimate test . . . and, now that you mention it, *far* for the oddest fix . . .

Richard E. Hawkins, Esq.
The Hawkins Law Firm
3430 E. Flamingo Rd.
Suite 232
Las Vegas, NV  89121
(702) 508-8462

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode
In case your python file becomes a bit more complicated, you
shouldn't use workarounds as using backspace to come to a
binary format, because you then need exact indents (could be
tabs).

Better use (without replacing anything in mrgCmds) Matthias'
answer to use binary write.

Or the usual variant of that
put mrgCmds into url("binfile:" & fldr & "/theCmds.py")

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
The reason for the difficulty is that internally LC uses LF as the line
ending.  The cr, lf, and return constants all actually map to LF.  When you
write a text file, LC will convert line endings to the native format.  So
for Windows you get CRLF, Linux gets LF, and Mac gets CR.  I take issue
with this because as of OS X the native line ending for the OS is actually
now LF (although most of the stuff built in will handle either LF or CR).
As a result, I always will generate my text files using binary mode,
encoded as UTF8 on the Mac.  I will read everything using file to get the
automatic conversion to LF though.  This does complicate making cross
platform code that generates text files since you have to check the OS and
either handle Windows or Mac differently.

On Wed, Oct 30, 2019 at 6:39 PM hh via use-livecode <
[hidden email]> wrote:

> In case your python file becomes a bit more complicated, you
> shouldn't use workarounds as using backspace to come to a
> binary format, because you then need exact indents (could be
> tabs).
>
> Better use (without replacing anything in mrgCmds) Matthias'
> answer to use binary write.
>
> Or the usual variant of that
> put mrgCmds into url("binfile:" & fldr & "/theCmds.py")
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
Brian Milby wrote:

 > The reason for the difficulty is that internally LC uses LF as the
 > line ending.  The cr, lf, and return constants all actually map to LF.
 > When you write a text file, LC will convert line endings to the native
 > format.  So for Windows you get CRLF, Linux gets LF, and Mac gets CR.
 > I take issue with this because as of OS X the native line ending for
 > the OS is actually now LF...

Agreed.

The hard question is: What shall we do about it?

On the one hand, we have millions of lines of code in our community that
use CR, and a certain percentage of those are dependent on CR having a
specific value (even if that value is inconsistent with the true ASCII
value).

On the other hand, we have a constant that suggests it's one thing when
it's really something else, and at this point that design decision
benefits no one and confuses many.

Favor backward compatibility, or language learnability/usability?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
My suggestion is to just bite the bullet and build LC where 'file' exports
using LF on Mac.  The change required is literally a couple of characters
in one file (maybe two files to include the server default, but you can
already change it there on demand).  Leave the constants as they are (LF).
It could be announced as something for 9.6 to give the community time to
test.  The only way it would be a problem is if you were exporting a text
file on a Mac that was going to be consumed by a program that depended on
CR line endings.

Since LC consumes all 3 formats equally well, it would be no issue on the
read side.

Internally the concern is the build tools/environment.  I've built LC with
it changed (actually submitted it as part of a PR, but had to reverse it)
before 9 was GM.  It passed the automated tests when I did it.

On Wed, Oct 30, 2019 at 10:28 PM Richard Gaskin via use-livecode <
[hidden email]> wrote:

> Brian Milby wrote:
>
>  > The reason for the difficulty is that internally LC uses LF as the
>  > line ending.  The cr, lf, and return constants all actually map to LF.
>  > When you write a text file, LC will convert line endings to the native
>  > format.  So for Windows you get CRLF, Linux gets LF, and Mac gets CR.
>  > I take issue with this because as of OS X the native line ending for
>  > the OS is actually now LF...
>
> Agreed.
>
> The hard question is: What shall we do about it?
>
> On the one hand, we have millions of lines of code in our community that
> use CR, and a certain percentage of those are dependent on CR having a
> specific value (even if that value is inconsistent with the true ASCII
> value).
>
> On the other hand, we have a constant that suggests it's one thing when
> it's really something else, and at this point that design decision
> benefits no one and confuses many.
>
> Favor backward compatibility, or language learnability/usability?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   ____________________________________________________________________
>   [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode
Interesting. This may be why when I copy code from the SE and paste it into an email I get double line spacing.

Bob S


> On Oct 30, 2019, at 19:08 , Brian Milby via use-livecode <[hidden email]> wrote:
>
> The reason for the difficulty is that internally LC uses LF as the line
> ending.  The cr, lf, and return constants all actually map to LF.  When you
> write a text file, LC will convert line endings to the native format.  So
> for Windows you get CRLF, Linux gets LF, and Mac gets CR.  I take issue
> with this because as of OS X the native line ending for the OS is actually
> now LF (although most of the stuff built in will handle either LF or CR).
> As a result, I always will generate my text files using binary mode,
> encoded as UTF8 on the Mac.  I will read everything using file to get the
> automatic conversion to LF though.  This does complicate making cross
> platform code that generates text files since you have to check the OS and
> either handle Windows or Mac differently.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode
Not to disagree, but just to mention this is not exclusive to LC. If I download the address book of a Toshiba copier, then just OPEN it with Microsoft Office ot TextEdit, then close without saving, I can no longer import that file into the copier again.

Upon examining the ascii value of every line terminator I discovered something, perhaps the OS or the software itself, converted the terminators to something else. I also find this practice to be not just confusing, but reprehensible. I'm sure it was done as an easy fix to some other text display problem, but developers have no license to change the data in a file without the user's knowledge and approval.

That being said, I also use open binary for write to get around this limitation. As long as I don't put data into a text field as temporary storage, in other words just memory, then the line endings are preserved no matter what OS I run on.

Bob S


> On Oct 30, 2019, at 19:27 , Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> Brian Milby wrote:
>
> > The reason for the difficulty is that internally LC uses LF as the
> > line ending.  The cr, lf, and return constants all actually map to LF.
> > When you write a text file, LC will convert line endings to the native
> > format.  So for Windows you get CRLF, Linux gets LF, and Mac gets CR.
> > I take issue with this because as of OS X the native line ending for
> > the OS is actually now LF...
>
> Agreed.
>
> The hard question is: What shall we do about it?
>
> On the one hand, we have millions of lines of code in our community that use CR, and a certain percentage of those are dependent on CR having a specific value (even if that value is inconsistent with the true ASCII value).
>
> On the other hand, we have a constant that suggests it's one thing when it's really something else, and at this point that design decision benefits no one and confuses many.
>
> Favor backward compatibility, or language learnability/usability?
>
> --
> Richard Gaskin


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode
> My suggestion is to just bite the bullet and build LC where 'file' exports
> using LF on Mac

Oh please yes!

It's been 18 years since the Mac standardised on LF. (And AFAIK Metacard only
started supporting the Mac eight years before that, so
Metacard/Revolution/LiveCode has already been writing the 'wrong' files for
twice as long as it was writing the 'right' ones.)

As you say, it's moot on import to LC; so the only instance where this change
could cause a compatibility issue would be where an LC-based tool is
generating files for consumption by some other system which is dependent on
them being CR format. Such a tool is presumably going to be Mac based - a
Windows or *nix system would be more likely to reject that format than depend
on it, if it accepts the format it's probably sophisticated enough to accept
LF as well. So we're talking about a Mac based system which is still running
but which in 18 years hasn't been updated to at least also accept the native
format of the OS that it runs on. And this will only be an issue if someone
updates their app producing these files to the latest version of LC (in which
case they will surely anyway be having to take special precautions and write
the file as binary to avoid confusing an ancient system with UTF8??). I don't
know if such a case exists; I certainly doubt if there are very many such.

Brian - what would be required before you could submit your work as a PR again?

Ben


On 31/10/2019 03:26, Brian Milby via use-livecode wrote:

> My suggestion is to just bite the bullet and build LC where 'file' exports
> using LF on Mac.  The change required is literally a couple of characters
> in one file (maybe two files to include the server default, but you can
> already change it there on demand).  Leave the constants as they are (LF).
> It could be announced as something for 9.6 to give the community time to
> test.  The only way it would be a problem is if you were exporting a text
> file on a Mac that was going to be consumed by a program that depended on
> CR line endings.
>
> Since LC consumes all 3 formats equally well, it would be no issue on the
> read side.
>
> Internally the concern is the build tools/environment.  I've built LC with
> it changed (actually submitted it as part of a PR, but had to reverse it)
> before 9 was GM.  It passed the automated tests when I did it.
>
> On Wed, Oct 30, 2019 at 10:28 PM Richard Gaskin via use-livecode <
> [hidden email]> wrote:
>
>> Brian Milby wrote:
>>
>>   > The reason for the difficulty is that internally LC uses LF as the
>>   > line ending.  The cr, lf, and return constants all actually map to LF.
>>   > When you write a text file, LC will convert line endings to the native
>>   > format.  So for Windows you get CRLF, Linux gets LF, and Mac gets CR.
>>   > I take issue with this because as of OS X the native line ending for
>>   > the OS is actually now LF...
>>
>> Agreed.
>>
>> The hard question is: What shall we do about it?
>>
>> On the one hand, we have millions of lines of code in our community that
>> use CR, and a certain percentage of those are dependent on CR having a
>> specific value (even if that value is inconsistent with the true ASCII
>> value).
>>
>> On the other hand, we have a constant that suggests it's one thing when
>> it's really something else, and at this point that design decision
>> benefits no one and confuses many.
>>
>> Favor backward compatibility, or language learnability/usability?
>>
>> --
>>    Richard Gaskin
>>    Fourth World Systems
>>    Software Design and Development for the Desktop, Mobile, and the Web
>>    ____________________________________________________________________
>>    [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
Hi Ben,

> Am 31.10.2019 um 16:16 schrieb Ben Rubinstein via use-livecode <[hidden email]>:
>
>> My suggestion is to just bite the bullet and build LC where 'file' exports
>> using LF on Mac
> Oh please yes!
> It's been 18 years since the Mac standardised on LF. (And AFAIK Metacard only started supporting the Mac eight years before that, so Metacard/Revolution/LiveCode has already been writing the 'wrong' files for twice as long as it was writing the 'right' ones.)

The first Mac and Win version of Metacard came out in 1999.

> ...
>
> Ben

Best

Klaus

--
Klaus Major
https://www.major-k.de
[hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode
Ben Rubinstein wrote:

 > Brian Milby wrote:
 >> My suggestion is to just bite the bullet and build LC where 'file'
 >> exports using LF on Mac
 >
 > Oh please yes!

Seconded.

Containing the scope of the remedy to text writes should affect very
few, and those affected will probably welcome the change.

What needs to be done to move this forward?


Bob Sneidar  wrote:
 > Upon examining the ascii value of every line terminator I discovered
 > something, perhaps the OS or the software itself, converted the
 > terminators to something else. I also find this practice to be not
 > just confusing, but reprehensible.

LC supports two write modes: text and binary.  Perhaps the editor you'd
used supports the equivalent of LC's text mode, where the data is indeed
altered to provide greater convenience for cross-platform line-endings,
replacing NULLs with spaces, etc.  This is consistent with how HyperTalk
established writes, and I've seen some text editor packages do similar
things.

When you need to preserve data as-is, use binary mode.

Thankfully LC provides both.  HyperCard provided only text mode, and
SuperCard only binary mode.  I like being able to use each depending on
what I'm doing.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
I’ll submit a PR tonight.

Thanks,
Brian
On Oct 31, 2019, 12:26 PM -0400, Richard Gaskin via use-livecode <[hidden email]>, wrote:

> Ben Rubinstein wrote:
>
> > Brian Milby wrote:
> > > My suggestion is to just bite the bullet and build LC where 'file'
> > > exports using LF on Mac
> >
> > Oh please yes!
>
> Seconded.
>
> Containing the scope of the remedy to text writes should affect very
> few, and those affected will probably welcome the change.
>
> What needs to be done to move this forward?
>
>
> Bob Sneidar wrote:
> > Upon examining the ascii value of every line terminator I discovered
> > something, perhaps the OS or the software itself, converted the
> > terminators to something else. I also find this practice to be not
> > just confusing, but reprehensible.
>
> LC supports two write modes: text and binary. Perhaps the editor you'd
> used supports the equivalent of LC's text mode, where the data is indeed
> altered to provide greater convenience for cross-platform line-endings,
> replacing NULLs with spaces, etc. This is consistent with how HyperTalk
> established writes, and I've seen some text editor packages do similar
> things.
>
> When you need to preserve data as-is, use binary mode.
>
> Thankfully LC provides both. HyperCard provided only text mode, and
> SuperCard only binary mode. I like being able to use each depending on
> what I'm doing.
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> [hidden email] http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode
I gave the wrong impression. I was saying that other apps and it perhaps the OS X system itself takes liberties with conversion of line endings. For instance, Mocrosoft Word and Excel. I would expect I could open a file to look at it, close it without saving, and absolutely nothing would change. But it does.

I know this because I tested it with one of the aforementioned Address Book Export files. I exported the file, then imported it without opening it in any MacOS app. Worked fine. Opened the file in Word, closed without saving, copier refused to import the file.

That sort of thing is what I meant was reprehensible. Developers should not be taking those liberties.

Bob S


> On Oct 31, 2019, at 09:24 , Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> Bob Sneidar  wrote:
> > Upon examining the ascii value of every line terminator I discovered
> > something, perhaps the OS or the software itself, converted the
> > terminators to something else. I also find this practice to be not
> > just confusing, but reprehensible.
>
> LC supports two write modes: text and binary.  Perhaps the editor you'd used supports the equivalent of LC's text mode, where the data is indeed altered to provide greater convenience for cross-platform line-endings, replacing NULLs with spaces, etc.  This is consistent with how HyperTalk established writes, and I've seen some text editor packages do similar things.
>
> When you need to preserve data as-is, use binary mode.
>
> Thankfully LC provides both.  HyperCard provided only text mode, and SuperCard only binary mode.  I like being able to use each depending on what I'm doing.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
Bob Sneidar wrote:

 > I would expect I could open a file to look at it, close it without
 > saving, and absolutely nothing would change. But it does.
 >
 > I know this because I tested it with one of the aforementioned Address
 > Book Export files. I exported the file, then imported it without
 > opening it in any MacOS app. Worked fine. Opened the file in Word,
 > closed without saving, copier refused to import the file.
 >
 > That sort of thing is what I meant was reprehensible. Developers
 > should not be taking those liberties.

When read-only tasks write, head should roll.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
Or could this be a result of OS Xs decision to save iterative versions of a
file whether you want it to or not?

--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On October 31, 2019 11:46:29 AM Richard Gaskin via use-livecode
<[hidden email]> wrote:

> Bob Sneidar wrote:
>
> > I would expect I could open a file to look at it, close it without
> > saving, and absolutely nothing would change. But it does.
> >
> > I know this because I tested it with one of the aforementioned Address
> > Book Export files. I exported the file, then imported it without
> > opening it in any MacOS app. Worked fine. Opened the file in Word,
> > closed without saving, copier refused to import the file.
> >
> > That sort of thing is what I meant was reprehensible. Developers
> > should not be taking those liberties.
>
> When read-only tasks write, head should roll.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  ____________________________________________________________________
>  [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: cr, lf, and reading in terminals/vim

Richard Gaskin via use-livecode
Possibly, but then where is the original file? And why make a new file when closed without saving?

Bob S


> On Oct 31, 2019, at 09:54 , J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> Or could this be a result of OS Xs decision to save iterative versions of a file whether you want it to or not?
>
> --
> Jacqueline Landman Gay | [hidden email]
> HyperActive Software | http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12