Error when calling cmd-file that reads input from text file (SET /P var=<file.txt)

I have a situation where I have to call an existing cmd-file on a Win 2008 R2 enterprise server.
I have a tentacle on this server, the tentacle service is set up with an admin user.
I have a powershell step that calls the cmd-file. See step-script.ps1 for content.
The simpleScript.cmd is just an extract of a much larger script, but is enough to recreate the error.

The error (I think) is that the standard out is changed somehow when running through Octopus deploy. As soon as the execution hits the line “set /P LOGFOLDER=<version1.txt” every line in the command script is written to the output in the octopus task log.
This has the unfortunate side effect that the next time I use "[some command] > someFile.txt " every following command is written as text to this someFile.txt-file. The file is not possible to delete, and further commands will not execute as expected (I have not looked into further errors as I guess a fix of the output routing will be enough,)

I have tested the script by logging on the server with the same user as the one on the tentacle service. I have copied the “step-script.ps1”-file into the folder C:\Users<user>\AppData\Local\Tentacle\Temp and have executed it from there using a powershell 2.0 console. This runs as expected.

Note; I am not able to affect powershell version on servers, nor the real content of what I have called “simpleScript”. Also; the real script does not use “ECHO 1.2.3 > version1.txt” it uses FINDSTR and SED, result is the same.

I am using version;

Best regards
-Gard Ellefsen

simpleScript.cmd (931 Bytes)

step-script.ps1 (60 Bytes)

Hi Gard,

Thanks for getting in touch. This is a bit of a strange issue. I initially tried to reproduce it using a general purpose Windows 2012 VM but it worked perfectly using Octopus 2.6.x and Octopus 3.1. Both files were deleted. Unfortunately, there isn’t a lot we can do when you’re executing an external script/batch file as it’s largely environmental. If it was happening within a powershell script, there are things we can do to help remove the locks.

I’d suggest trying a few variations of executing the script from Powershell. I’ve used the following article previously when executing external commands.

Let me know how you go.


Hi, thanks for the link
Unfortunately it did not help. I have tried all I can think of now. I have also upgraded to octopus 3.1.
You say it is environmental, but how can it be that running the ps1-file I attached runs as it should when running in ISE, or directly in a powershell, on the very box where it does not work when running through a tentacle?
I do not have a 2012 server available but have tested using different Win 2008 R2 enterprise servers and Win 7 enterprise machines, also tested using powershell v2 and v3. It always works as it should, except when running through the tentacle.
Also, as you can see, the script I am testing with has no input params and the commands inside are really simple. I am at a loss here having spent days on this, are you 100% certain that this has nothing to do with octopus?


Hi Gard,

Thanks for following-up. I’m not 100% sure this isn’t Octopus related. I think it’s probably a combination of Windows Server environment as well as the way Octopus executes the PowerShell script that executes your batch/command file.

The code that executes powershell is opensource and you can have a look at it here.

You can see that we do redirect standard output and error so we capture as much detail as possible when executing PowerShell scripts. This is likely causing some sort of conflict on Windows Server 2008. Unfortunately, your scenario is a bit of an edge case that we don’t really support. I understand the script is out of your control however I’d suggest rewriting the actions it performs in powershell as this shouldn’t have any conflicts and is better supported.

Hope this helps!


Thank you for the time spent on this, Rob!
I know this is not quite “the Octopus way” of doing things, so I have recommended that we start rewriting the deployment process. It is much better to have it all in Octopus and have control of everything there.
Thanks again!