Octopus Variable Replace Filter not working as expected

Octopus Server
1

The bug

I have a requirement to replace a path’s single backslash (\) with double backslash(\\). Since \ is an escape character, I used .Net Framework format convention like this

‘#{Octopus.Tentacle.Agent.ApplicationDirectoryPath | Replace “\\” “\\\\” }\#{Environment}\frontier-nginx-includes’;

My Application directory is D:\Data\Octopus\Applications

What is happening

The output is ‘D:\\\\Data\\\\Octopus\\\\Applications\\Dev\\frontier-nginx-includes’

(Notice 4 slash in place of 2 slashes where replacement happened)

.Net does it correctly using the same inputs.

Capture
Capture866×403 51.9 KB

What I expect to happen

I expect the output to be ‘D:\\Data\\Octopus\\Applications\\Dev\\frontier-nginx-includes’;

Steps to Reproduce

  1. Write-Host #{Octopus.Tentacle.Agent.ApplicationDirectoryPath | Replace “\\” “\\\\” }
  2. Deploy against a target.
  3. Notice extra black slash(es)

Affected Versions

Tested on Octo server v2019.12.0 LTS with Tentacle v5.0.9 & v5.012

Links

Additional Information

.Net supports verbatim string

originalPath.Replace(@“\”, @“\\”);

In octopus, this fails and the variable remains as-it-is & is never replaced.

3

Hi Nikhil,
Thanks for reaching out with this issue.

I went ahead and did a reproduction of the issue and was definitely able to see the issue as you described. Reading our docs and the .NET docs it would appear that escaping the “\” would be the way to go, but this seems to only apply to the item to be replaced (source as opposed to destination).

So I tested instead by doing the following:

$directorybefore =  write-host #{Octopus.Tentacle.Agent.ApplicationDirectoryPath}
Write-Host $directorybefore

$directoryafter =  write-host #{Octopus.Tentacle.Agent.ApplicationDirectoryPath | Replace "\\" "\\" }

Write-Host $directoryafter

So the destination doesn’t appear to need the escaping as its being written to the new variable directly. This, to be honest isn’t as intuitive as it could be for sure.

Can you try this and see if it works for you?

Kind Regards,
Paraic

4

Hi @paraic.oceallaigh,

Thanks for replying.

This worked as expected and yes it doesn’t look intuitive to replace with ‘itself’. :slight_smile:

Could you raise a GitHub issue to hear from a developer’s perspective if it’s a bug or there’s a concrete reason behind this?

Cheers,
Nikhil

5

Hi Nikhil,
In chatting with out engineers, how its processed is that the first parameter is a regex while the second parameter is a direct substitution. So pretty much what we were discussing.

So this is a feature, not a bug but clearly does not reflect typical Powershell or other language substitutions. We will take a look at the docs to clarify this to make it clearer.

Hope that resolves it for you.

Let us know if you need anything else.

Kind Regards,
Paraic

6

Hi @paraic.oceallaigh,

Thanks for the behind-the-scenes info. :slight_smile:

Now it’s clear what is causing this behaviour -

And yes updating docs will help. I will wait for it.

Pls, treat this issue resolved.

Thanks,
Nikhil

8

Hi Nikhil,
I added a short note to the docs page explaining with an example how escaping special characters works.

Kind Regards,
Paraic