[GitHub] brooklyn-server issue #554: Ensured the \n character is escaped when escapin...
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 should _not_ escape it as `\n`. If the issue is to ensure that a string fits on a single line I think you have to look at a different escaping mechanism. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] brooklyn-server issue #554: Ensured the \n character is escaped when escapin...
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. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] brooklyn-server issue #554: Ensured the \n character is escaped when escapin...
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 BROOKLYN_CFG_ADDITIONS="brooklyn.location.jclouds.aws-ec2.identity = test_ident\nbrooklyn.location.jclouds.aws-ec2.credential = test_key" echo $BROOKLYN_CFG_ADDITIONS ``` results in ``` brooklyn.location.jclouds.aws-ec2.identity = test_ident\nbrooklyn.location.jclouds.aws-ec2.credential = test_key ``` So same thing repeated verbatim. It's possible to get a new line out of it by using `printf "BROOKLYN_CFG_ADDITIONS"`. Wonder which one is better - failing early (when trying to serialise) or escaping the new line. Current behaviour is worst - could easily be exploited. Given this I'm inclined to merge the PR and then discuss improvements. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] brooklyn-server issue #554: Ensured the \n character is escaped when escapin...
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 that I have brooklyn.config like this: ``` brooklyn.config: brooklyn.cfg.additions: | brooklyn.location.jclouds.aws-ec2.identity = test_ident brooklyn.location.jclouds.aws-ec2.credential = test_key ``` Brooklyn sets the config to be ``` brooklyn.location.jclouds.aws-ec2.identity = test_ident\nbrooklyn.location.jclouds.aws-ec2.credential = test_key ``` (please note '\n' is a character, not a '\\' followed by an 'n'. If you use a '\\' followed by an 'n' this works) I later pump this config into a bash env variable like this: ``` shell.env: BROOKLYN_CFG_ADDITIONS: $brooklyn:config("brooklyn.cfg.additions") ``` However, when the string is bash encoded, the '\n' is not encoded. My script then ends up looking like this: ``` BROOKLYN_CFG_ADDITIONS="brooklyn.location.jclouds.aws-ec2.identity = test_ident brooklyn.location.jclouds.aws-ec2.credential = test_key" ``` Which means the \n is used to create a line break in the script (which does nothing) rather than keeping the \n in the variable. Changing this bash encoding means my script ends up looking like this: ``` BROOKLYN_CFG_ADDITIONS="brooklyn.location.jclouds.aws-ec2.identity = test_ident\nbrooklyn.location.jclouds.aws-ec2.credential = test_key" ``` Whilst Aleds suggestion will work, I worry others might try to use multi line bash config in the same way that I did. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] brooklyn-server issue #554: Ensured the \n character is escaped when escapin...
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 echo $MYVAR > file2 echo "$MYVAR" > file3 ``` End result is that file3 is right (contains new line), but file2 does not. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] brooklyn-server issue #554: Ensured the \n character is escaped when escapin...
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 there's a new line. What's your use case, how did you come upon this problem? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---