Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/554
-1
I think some shells don't respect `\n` so this could break things all over
the place. The norm in shells is for double-quoted strings to be allowed to
have a new line, so we
Github user neykov commented on the issue:
https://github.com/apache/brooklyn-server/pull/554
Agree @geomacy. Haven't realised it's still treated as a single string
value.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well.
Github user neykov commented on the issue:
https://github.com/apache/brooklyn-server/pull/554
@Graeme-Miller That's one of the scenarios where adding a new line will
lead to unexpected results.
doing
```
export
Github user Graeme-Miller commented on the issue:
https://github.com/apache/brooklyn-server/pull/554
@aledsage has pointed out a way to get around the problem I am having, so I
no longer need this PR. However, I think it might still be useful
@neykov, the use case here is
Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/554
FYI I tried this:
```
tee file1 <<-EOF
line1
line2
EOF
MYVAR=`cat file1`
echo $MYVAR
# shows "line1 line2" - note the special char shown as space
Github user neykov commented on the issue:
https://github.com/apache/brooklyn-server/pull/554
`\n` Doesn't behave as expected in most bash operations. It will just be
treated as the verbatim text.
It could lead to weird errors later one so I'd says it's better to fail
early if
