Uploaded image for project: 'Puppet Agent'
  1. Puppet Agent
  2. PA-2156

Environment.bat causes PATH issues when a folder name contains an ampersand



    • Type: Bug
    • Status: Resolved
    • Priority: Normal
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Template:
    • Team:
      Night's Watch
    • Story Points:
    • Sprint:
      PR - 2019-06-25, PR - 2019-07-10
    • Method Found:
      Needs Assessment
    • CS Priority:
    • Release Notes:
      Not Needed
    • QA Risk Assessment:
      Needs Assessment


      This ticket has arisen from a support ticket where a customer has a Windows 2012R2 agent that was failing every run due to the following error. It appeared to have been occurring since the agent was first installed: 


      status: failure 
      resource_type: Service 
      resource_title: pxp-agent 
      message: Could not find init script for 'pxp-agent'


      In the console, the "service_provider" fact for this node showed "init" (this should be "windows")

      We've seen this before and usual cause of the service failing to start and complaining about an init script (which should only pertain to Linux systems) is that the windows provider for Service resources expects that net.exe will be in a directory specified by the system path. If it isn't, it considers the windows provider unsuitable.

      The reason why the customer didn't have net.exe in their path was that one of the directories in their current path contained an ampersand and when the following line of the environment.bat was run, it hit the ampersand and it interpreted all the text that folowed as a new command.



      As the ampersand is a valid character in a Windows folder name, is there a way that the current environment.bat can be revised to work with any directories that contain these special characters?


      I have replicated this in my test environment, as you can see I had a directory named C:\Users\s-tfs_e&test\test\test in my PATH and when I then checked the path in a Command Prompt with Puppet, you can see it has stopped at the position of the &

      The customer was able to work around this by hardcoding their directories and I have also suggested escaping this by using ^& which should be adequate for now but going forward I do think this needs to be properly addressed.






          Issue Links



              oana.tanasoiu Oana Tanasoiu
              patrick.grant Patrick Grant
              0 Vote for this issue
              6 Start watching this issue



                  Zendesk Support