Feature: an action to store a fact/variable/context from the output of a command

[airtonix]

Description
Describe the idea / feature request in your own words.

actions:
  - action: context.set
    command: echo $env:profile
    context: os.user_profile

or

  - action: cmd.run
    command: echo
    args:
      - "$env:profile"
    stdout:
      context: os.user_profile

🤷🏻

Additional information
Add more context which didn't fit in the fields above.

[airtonix]

Failing that perhaps there's a way to do this in any value?

- action: file.link
  from: profile.ps1
  to: "{{ getEnv('profile') }}"

In powershell, $profile magically points to : C:\Users\zenobius\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

Do we have a way to differentiate between $env:profile and $profile in powershell? ($env:profile is not the same as $profile btw)

[martintc]

Thanks for all the issues. Looks like there is a lot of love the windows platform needs. Unfortunately, I don't think any of us on the maintainer ship team main Windows, however, I set up Windows 11 on my secondary disk to work through some of this. Plan to move through this a little bit at a time.

For the command.run action and calling echo, it looks like we need to prefix the commands with some things in Rust for it to work. Right now, comtrya will literally call echo <whatever you input>. So it causes issues even running echo hello world. Best I have found is that echo needs to be prefixed with cmd /C, at least when we are calling it from rust with std::process:Command. So, we should have rust output cmd /C echo <whatever we want>.

I have a branch here that hopefully at least addresses some of the issues with the command.run action. Could you give this a shot with your files and see how much changes?

[airtonix]

I wouldn't assume people are using cmd.exe, in fact since the default shell on windows 10 and up is now powershell i'd assume they're using powershell.

Additionally, when you run powershell, it dumps to the terminal help text encouraging you to install the latest version of powershell which is then run via pwsh.exe.

So to work with this, it'd be good to leave it up to the user with the following attrs :

  - action: cmd.run
    command: echo
    shell: pwsh
    args:
      - "$env:profile"
    stdout:
      context: os.user_profile

[martintc]

Something to note, using cmd /c is even in the documentation when using std::process::Command, so it may be how the internal implementation occurs, implementation in std, lines 462-468. Will probably need to delve in deeper or see if there are crates better suited for windows rather than using std. One thing that provides difficulties is that Command, according to documentation, will look for executable on PATH. And some common things like echo, I guess are not their own stand alone .exe. So std::process:Command can't find echo and requires it to be prefixed with cmd /C. But yea, this may not work when calling other commands with command.run.

This exerpt

structs a new Command for launching the program at path program, with the following default configuration:

    No arguments to the program
    Inherit the current process’s environment
    Inherit the current process’s working directory
    Inherit stdin/stdout/stderr for [spawn](https://doc.rust-lang.org/std/process/struct.Command.html#method.spawn) or [status](https://doc.rust-lang.org/std/process/struct.Command.html#method.status), but create pipes for [output](https://doc.rust-lang.org/std/process/struct.Command.html#method.output)

Builder methods are provided to change these defaults and otherwise configure the process.

If program is not an absolute path, the PATH will be searched in an OS-defined way.

The search path to be used may be controlled by setting the PATH environment variable on the Command, but this has some implementation limitations on Windows (see issue #37519).

[airtonix]

I guess this is why ansible (used to? still does?) have a separate action for running a command than for running stuff that can run in a shell.

• https://docs.ansible.com/ansible/latest/collections/ansible/builtin/command_module.html
• https://docs.ansible.com/ansible/latest/collections/ansible/builtin/shell_module.html

[martintc]

I guess this is why ansible (used to? still does?) have a separate action for running a command than for running stuff that can run in a shell.

• https://docs.ansible.com/ansible/latest/collections/ansible/builtin/command_module.html

• https://docs.ansible.com/ansible/latest/collections/ansible/builtin/shell_module.html

Will check this out. We may end up having to do something similar, really hoping to avoid it, but it may be the only reasonable solution. The good news is, we can place this probably behind cfg settings so it doesn't interfere elsewhere. I will also be trying to look more into the internals of shells on windows.

[icepuma]

Why not setting an ENV var with the desired value and hand it over to comtrya?