carriage return

[UKenGB]

I'm sorry this is so basic, but it's got me foxed.

I'm actually setting up LiveCode Server, but first testing it on the command line with a simple test script:-

Code: Select all

<?lc

 	put "Hello World!" && the date && the time

?>

This works, but I want to output a carriage return at the end and I've not been able to figure out how to do that. Seems to me that simply adding '& return' to the above line ought to do the trick, but it doesn't. In fact it prevents any output at all. Various other combinations produce equally inexplicable results.

So I'm simply not understanding how to tell LiveCode to output a return at the end of the string and could do with some advice on this.

Thanks.

[Klaus]

Hi Ken,

the server outputs HTML, so this should do:

Code: Select all

<?lc
  put "Hello World!" & "</br>" & the date && the time
?>

Best

Klaus

[bogs]

Makes sense, I haven't yet had time to play with the server versions (it is on my list ), but I guess cr, lf, and crlf don't work for that, Klaus? If not, I believe the break tag doesn't have a slash. Unless you are closing something, <p> </p> for instance.

Code: Select all

This text contains<br>a line break.

[Klaus]

Yes, sorry, I meant <br /> which is also compatible with XHTML. (So they say )

[UKenGB]

HTML markup would only work if running this script in a browser. Running it from the command line is different. It just outputs the text as specified (-: except for a carriage return). If I use any HTML tags, it simply outputs those exact strings, so if I include a <br> or even <br />, that's what I see rather than it starting a new line.

[Klaus]

Hi Ken,

ah, sorry, my fault.
Using a CR does not work, too?

Code: Select all

<?lc
  put "Hello World!" & CR & the date && the time
?>

Best

Klaus

[UKenGB]

No. I tried CR and simply return, which is the same thing, but if at the end of that line, when run there's no output at all which doesn't make any sense. I tried putting it in the middle (I forget exactly where) and it output "urn", so it really does look like it's messing up.

Since this seems so much like a basic bug, it occurred to me that I'm using Server v9.0.0 DP11 which may indeed have a bug. I'm setting up an alternative 8.1.9 so I can try both/either as I want. Then I'll try it in 8.1.9 and see if there's the same problem.

[[-hh]]

This is not a problem of LC Server but a general bug of LC 8/9 with putting something into the message box. That is: "put <string>" has in many scenarios NO effect.

Try putting into a variable or into a field. That works.

[FourthWorld]

Outputting line endings to stdout is a a common necessity, one which has worked reliably here in all versions of LC I've ever used up through v9dp11.

If the script Klaus posts isn't working, we'll have to figure out why it doesn't work there but works here and for Klaus.

Which OS version are you using?

[UKenGB]

Whoah, that's a bit worrying that something so simple is a problem like this. Not a good intro to LiveCode.

Certainly the problem exists with both 8.1.9 and 9.0.0.

I'll try with a variable.

Code: Select all

<?lc
        put "Hello World!" && the date && the time & return into myVariable
        put myVariable         
?>

Same problem, no output at all. Works fine if I remove the '& return', but if I add the return to the end of what I put into the variable, or instead after, so 2nd line is 'put myVariable & return', always same problem. No output.

[UKenGB]

Outputting line endings to stdout is a a common necessity, one which has worked reliably here in all versions of LC I've ever used up through v9dp11.

If the script Klaus posts isn't working, we'll have to figure out why it doesn't work there but works here and for Klaus.

Which OS version are you using?

I agree, a common necessity, but right now I cannot get it to work.

I have posted 2 methods, one just 'put'ting the computed string with a return concatenated onto the end (or in the middle) or put'ting it all into a variable first and in both cases it doesn't work at all. Not occasionally - never. I have repeatedly tried this throughout today, in all configurations and variations I can think of and it simply fails.

I may be new to LiveCode, but not to programming and concatenation of text is one of the simplest and most straightforward task and I can do the same in multiple other languages and scripts, but apparently not in LiveCode. Maybe there's a flaw in my method, but I can't see it, so would be happy to have that explained.

Sorry, forgot. I'm trying this on MacOS High Sierra.

[UKenGB]

Ok, I tried piping the output to less and I can now see that it IS outputting all the text, but there's a ^M showing where I try to put return or CR or LF. If the output is sent to the terminal, it simply doesn't display anything before that character.

So the problem appears to be that any of the above constants are not actually being replaced by the correct character.

[UKenGB]

I think I can see what's going on.

As this is the Mac version of LiveCode Server it is translating all lineend/feeds into the ASCII 13 character which is normally used by the Mac. But Terminal and less are unix environments and expect ASCII 10. This mucks up Terminal display and I just get to see the ASCII 13 (control M) in less where it is again not used to indicate a new line.

Whatever I use, whether that is return, CR, LF or even numToChar(10), they all get translated into ASCII 13. Not sure what the solution is, but for sure, I should be able to make it use whatever character I actually specify, so numToChar(10) absolutely should NOT be translated. As for those constants, well again, seems like LF really ought to stay as ASCII 10, and CR ought to stay as ASCII 13. Really, only 'return' should be translated so it's easy to use, but can be avoided if it's a problem by specifying exactly what is required, i.e. CR or LF (or any other synonyms they want to make use of). The important point being that they should never be translated.

Or am I way off beam here and the problem is something else entirely?

[bogs]

I don't know, but it certainly sounds like a weird one you found. I certainly would think numToChar(10) wouldn't be changed. Just weird.

[bwmilby]

Unfortunately there is probably way too much inertia to make CR and LF actually mean what they say... internally everything is LF and converted upon output to the local standard except for MacOS X (where it still uses CR).

I’ve asked about changing that for Mac but there is a concern about things breaking. The code change to do so is trivial (I’ve compiled with the change successfully).

Server does allow:

Code: Select all

set the outputLineEndings to “lf”