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

[Richard Gaskin via use-livecode]

Brian Milby wrote:

> https://github.com/livecode/livecode/pull/7214
>
> We'll see where it goes this time...

Thank you, Brian.  This is a good step forward for the usability of the 
language.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Brian Milby via use-livecode]

https://github.com/livecode/livecode/pull/7214

We'll see where it goes this time...

On Thu, Oct 31, 2019 at 12:27 PM Brian Milby  wrote:

> I’ll submit a PR tonight.
>
> Thanks,
> Brian
> On Oct 31, 2019, 12:26 PM -0400, Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com>, 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
> 
> ambassa...@fourthworld.com http://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Bob Sneidar 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 
>  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 | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[J. Landman Gay 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 | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 31, 2019 11:46:29 AM Richard Gaskin via use-livecode 
 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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Bob Sneidar 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 
>  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Brian Milby via use-livecode]

I’ll submit a PR tonight.

Thanks,
Brian
On Oct 31, 2019, 12:26 PM -0400, Richard Gaskin via use-livecode 
, 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
> 
> ambassa...@fourthworld.com http://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Klaus major-k via use-livecode]

Hi Ben,

> Am 31.10.2019 um 16:16 schrieb Ben Rubinstein 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.)

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

> ...
> 
> Ben

Best

Klaus

--
Klaus Major
https://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Ben Rubinstein 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 <
use-livecode@lists.runrev.com> 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
   
   ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Bob Sneidar 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 
>  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Bob Sneidar 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 
>  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Brian Milby 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 <
use-livecode@lists.runrev.com> 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
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Brian Milby 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 <
use-livecode@lists.runrev.com> 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
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[hh 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Dr. Hawkins via use-livecode]

On Oct 30, 2019, at 2:57 PM, Klaus major-k via use-livecode 
 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Klaus major-k via use-livecode]

Hi Richard,

> Am 30.10.2019 um 22:55 schrieb Dr. Hawkins 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?

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

> — 
> Richard E. Hawkins, Esq.

Best

Klaus
--
Klaus Major
https://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Dr. Hawkins 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Klaus major-k via use-livecode]

Hi Richard,

> Am 30.10.2019 um 22:28 schrieb Dr. Hawkins 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.

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
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Matthias Rebbe 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 
WinSignMaker Mac 

> Am 30.10.2019 um 22:28 schrieb Dr. Hawkins via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> 
> 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
> use-livecode@lists.runrev.com 
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode