Avoid %% escape in xtrigger func args (7.8.x).

[hjoliver]

These changes close #3256

Requirements check-list

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).

• Appropriate tests are included (unit and/or functional).

• Includes an appropriate entry in the release change log CHANGES.md.

• (7.8.x branch) I have updated the documentation in this PR branch.

[hjoliver]

Test using the built-in echo xtrigger, which just echoes its function args (run in debug mode to see the result in the server log):

# workflow "test3256"

[scheduling]
  [[xtriggers]]
     a = echo(%(point)s, '%%(asdf)s')
  [[dependencies]]
     graph = "@a => foo"
[runtime]
  [[foo]]
     script = sleep 10

In the function args, %(point)s is a valid string template for cycle point; %%(asdf)s is not a template because % is escaped, so it should be passed in as a string literal.

On current 7.8.x and master branches (reproduces the bug):

[oliverh@niwa-1007885 cylc-flow]$ cylc val test3256
Illegal template in xtrigger a: asdf

On this branch, validation and run:

[oliverh@niwa-1007885 cylc-flow]$ cylc val test3256
Valid for cylc-7.8.3-13-g32f85

[oliverh@niwa-1007885 cylc-flow]$ cylc run --no-detach --debug test3256
            ._.                                                       
            | |            The Cylc Suite Engine [7.8.3-13-g32f85]    
._____._. ._| |_____.           Copyright (C) 2008-2019 NIWA          
| .___| | | | | .___|   & British Crown (Met Office) & Contributors.  
| !___| !_! | | !___.  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
!_____!___. |_!_____!  This program comes with ABSOLUTELY NO WARRANTY;
      .___! |          see `cylc warranty`.  It is free software, you 
      !_____!           are welcome to redistribute it under certain  
2019-07-30T13:51:23+12:00 DEBUG - creating suite run directory: /home/oliverh/cylc-run/test3256
...(SNIP)...
2019-07-30T13:51:24+12:00 DEBUG - [xtrigger-func cmd] cylc-function-run echo '["1", "%(asdf)s"]' '{}' /home/oliverh/suites/foo
        [xtrigger-func ret_code] 0
        [xtrigger-func out] [false, {}]
        [xtrigger-func err]
        echo: ARGS: (u'1', u'%(asdf)s')  <-----------------------BINGO!
        echo: KWARGS: {}
2019-07-30T13:51:24+12:00 DEBUG - echo(1, %(asdf)s): returned {}

[hjoliver]

Zero-width negative look behind assertion, innit 😁

[trwhitcomb]

You beat me to it! I used an exclusion class (i.e. r[^%]%\() instead of any fancy lookbehinds though.

[hjoliver]

You beat me to it! I used an exclusion class (i.e. r[^%]%\() instead of any fancy lookbehinds though.

Sorry about that! However, I don't think the exclusion class works because it is not zero width. i.e. it would match x%(blah)s but not plain old %(blah)s. (And adding a "zero or one of" qualifier doesn't fix the problem because the other % gets in the way then?)

[trwhitcomb]

I think you're right, but because the exclusion isn't part of the capturing group, even if it did match x%(blah)s it should still only pick up blah which is what this code is looking for.

I don't have an issue with the zero width lookaround, but I will confess that I didn't recognize it immediately. I think the lookaround will also permit two of these format strings to be concatenated, which would fail to match using the exclusive character class.

[kinow]

Maybe we should include a few unit tests covering the cases discussed above so far ☝️ ? 😬

[hjoliver]

Maybe we should include a few unit tests covering the tests above point_up ? grimacing

Yes, I've left this as a WIP/Draft pending time to think about tests.

[kinow]

Oh, sorry, didn't look at the checklist.

[trwhitcomb]

Now I'm very glad my fix got scooped by @hjoliver!

[hjoliver]

God damn it. Style fail.

[hjoliver]

@trwhitcomb - I've added you as a "collaborator" on this repository so I can assign you to review this PR. You should get an invite from GitHub.

[matthewrmshin]

Test failures are related to #3244 - Travis CI hostname issue.