Hi,

is there an alternative way to get a line break in the new release? Or is this a bug?

Now leads to

tobi: > test newline
HARRY:  Ok\r\nthis is a newline

It was working in older versions, it this a new bug or has something changed i am missing?

I thought I saw it not work. But when I went to debug backslash n, it was working and now works for me.

But now I can repeat it…. I will figure it out.

Is there an update on this issue yet?
I still have the error in the new release 7.6

What I see when I compile this

topic: ~INTRODUCTIONS keep repeat (~emogoodbye ~emohello ~emohowzit name here )

t: Greetings ^keep()
u: (newline) ok \n this is a newline \n and another.

and then type “newline”, looks correct on windows console and log entry is this:
Respond: user:d bot:harry ip: (~introductions) 1   newline ==> ok this is a newline and another. 

Is your issue with the log line?  Similarly when I do local client and host, the local client windows console correctly shows the new line….  If your issue is with log line, I do not allow log line itself have have newline character in it because that would break :trim tools

Bruce Wilcox - Oct 29, 2017:

Is your issue with the log line?

No, it’s with the windows console

Bruce Wilcox - Oct 29, 2017:

What I see when I compile this

topic: ~INTRODUCTIONS keep repeat (~emogoodbye ~emohello ~emohowzit name here )

t: Greetings ^keep()
u: (newline) ok \n this is a newline \n and another.

and then type “newline”, looks correct on windows console

I redownloaded the Chatscript 7.6 release to start from scratch. I extracted it, replaced the ~introductions topic with yours, compiled Harry and for me the output looks like this:
https://i.imgur.com/SQhPm23.png

Your problem is value of responseControl. If in your bot you explicitly set $cs_response = #RESPONSE_UPPERSTART | #RESPONSE_REMOVESPACEBEFORECOMMA | #RESPONSE_ALTERUNDERSCORES | #RESPONSE_REMOVETILDE
that should solve the issue.
Current accidental default for #ALL_RESPONSES includes suppressing nl conversions (fixing)

It solved the issue, thank you very much Bruce!

I saw this post and if you are using Postgres, I would be careful about adding the special characters / and \
It will likely break your cs database implementation if you are using Postgres.

To defend against this Postgres challenge, I added a filter on the front end, so these characters, and others, cannot be sent to CS.

The Postgres CS database schema definition for your user data field value is bytea and under the latest version of Postgres, the / and \ are special characters that will not be saved in this field without escaping it. So, if you save the data and these special characters are within it, it will not save the data.  You might not notice it, until you realize that your user data is not being saved.  And to fix this, it is a rabbit hole for now. Best to just avoid it altogether, unless you have a solution.

You will need to modify the Postgres cs code and database definition.
In short, I would stay away from using any reference of / and \ in anything that might make it to your user files. Actually, I would scan all of your code and get rid of anything that uses these characters.

If someone has a clever workaround, please let me know.