slack
slack copied to clipboard
newline character not passing through to slack
sending a chat message payload with \n
in it should convert it to a newline within slack. Instead, the \n
is coming across in the message as literal characters.
passing "\n"
within the message does properly insert the newline within the message, so it may be a problem with the slack documentation saying differently.
@Zxurian Sorry for the late reply, did you find out if this is an issue on our end? I'm happy to contact the Slack staff and ask them about it.
If it's just a matter of wrapping every \n
with double quotes ("\n"
), we could make some regex that automatically does this for our users.
yes, it was a case of wrapping it within double quotes. Not sure if you want to put a regex is your own message parser, or just make it clear in the documentation that if you want to add a new line to a message, needs to be wrapped in double quotes. Personally, I just wrap it in double quotes as it's more clear at the time your sending the message.
Ok thanks will have a look at it asap
did this actually get fixed? When using slack module on Ansible my code looks like
- name: Send header message via Slack
slack:
token: 1234/1234/1234
msg: '"\n"Connections reporting problems in network fabric'
channel: #autoatuo
username: "Sean's Auto-BGP Ansible Bot"
delegate_to: localhost
tags:
- slack
with_items: "{{ipv6check}}"
when: '"fe80" not in ipv6check[item][0]'
tags:
and the output does this "\n"Connections reporting problems in network fabric
This issue is still not fixed. Very frustrating when we are trying to automate messages.
How can we push to get this bug fixed?
Same here.
Im using "\n" and PHP_EOL to insert the newline but seems like only 1 or 2 newlines is parsed !?!
Passing 5 newlines, get a message with 2 (middle 2)
I was using single-quotes to wrap my message. When switching to double-quotes, the new line worked properly. Hope this helps.
Still doesn't work 👎
i got it working on PowerShell by adding the 0x0A
character:
# adds a line feed...
$message += (0x0A -as [char])
...terrible and probably not cross-platform, but it works ! I guess this technique could be extended to other languages easily. hope this helps.
doesnt work for me either. any updates here?
I'm also experiencing this issue. I have my message as follows and still get a literal output via slack:
msg: 'This is the first line."\n" This is the second line."\n" This is the third line'
The output still comes back as
This is the first line."\n" This is the second line."\n" This is the third line
as i said, just cast the value 10
(or 0x0A
in hexadecimal) as a character instead of \n
and it should work
@ramlongcat can you provide an example of how you are doing this in the playbook? This isn't working for me
Just found this thread after experiencing something similar. Although I'm not actually using this library, this thread helped me solve my Slack formatting issue when posting with their API... Thought I'd pay it forward in case this is your issue too!
It appears that Slack is precious about whether you use single or double quotes:
Example 1: single quotes, no newline quotes
$string = 'Line 1\nLine 2';
Line 1\nLine 2
Example 2: single quotes with double for the newline
$string = 'Line 1"\n"Line 2';
Line 1"\n"Line 2
Example 3: double quotes with single for the newline
$string = "Line 1'\n'Line 2";
Line 1' 'Line 2
Example 4: double quotes, no newline quotes
$string = "Line 1\nLine 2";
Line 1 Line 2
@unix4linux See @jasontrask message that is well explained. If you outer wrap in double quotes and exclude quotes where you have the new line char (\n), you should be good to go.
@jasontrask - that helped! Thank you!
I specifically used Example 4
Which provides the following output in my slack room:
A new computer is online with IP 192.168.1.100. SSH as the user test and run the command below
ansible-playbook -i "localhost," -c local ~/dothis.yml
The issue here does not seem to be a problem with the API, but a confusion between single and double quoted strings in PHP. A single quoted string will not interpret any special characters. '\n' will be printed out literally. A double quoted string on the other hand will interpret a number of special characters and also expand variables.
/n/r worked for me.
'test1 /n/r test2'
result: test1 test2
Thanks @lauriconeves, that worked for me after trying what others mentioned (I'm trying to use a plain old Slack agent). However, be advised you've got your forward slashes backwards: it's \n\r
, and not /n/r
, which will print literally in your message. For some reason in this context my eyeballs are awful at telling the difference at-a-glance without close examination.
Also note that when saving your event options JSON, Huginn will take care of escaping characters, so when you look at the options on the Agent Summary screen, it will actually appear as \\n\r
.
Here's an example of my JSON:
{
"webhook_url": "https://hooks.slack.com/services/{{my_token}}",
"channel": "{{channel_name}}",
"username": "{{bot_name}}",
"message": "New alert: \\n\r *{{card.name}}* \\n {{card.link}}",
"icon": "{{bot_icon}}"
}
Output in Slack:
New alert:
Card name
https://link-to-card.com
In case this helps others: I couldn't get this to work until I realized I needed to be toggling into the direct JSON editor mode in Huginn, as opposed to using the UI json tree UX. Then \n\r
worked like a charm.
For what it's worth after a few hours of pulling my hair out, I gave PHP_EOL
a shot in a web app I'm working on, and it worked great. Assume there are equivalents in other languages.
$message = '*Error:* ' . $errorMessage . PHP_EOL . '*Name:* ' . $detailArray['toname'] . PHP_EOL . '*Email:* ' . $detailArray['to'] . PHP_EOL . '*Asset:* ' . $assetName . PHP_EOL . '*Asset URL:* ' . $assetURL;
Hi,
I've got the same issue with curl :
curl -X POST -d channel=#chan -d 'text=test1 "\n" test2
' -d token=key -d icon_emoji=:slack: https://slack.com/api/chat.postMessage
the ouput looks like :
test1 "\n" test2
any idea ?
same he :( PostMessage="Line 1\nLine 2" resolved as
"message": {
"text": "Line 1\\nLine 2"
"There’s no bug anywhere, this is how newline char interpretation works in Bash + Slack API." more info: https://discuss.bitrise.io/t/slack-step-does-not-treat-n-as-a-newline-when-message-generated-by-a-bash-script-step/1776/5