export var=$(...)

[knutov]

tasks:
  - name: uptime
    commands:
      - name: uptime_get
        script: |
          export random_var=$(/usr/bin/uptime)
      - name: uptime_debug
        echo: $random_var

spot -t s2 --task uptime -v

spot v1.6.3-004d58f-2023-05-29T05:28:37Z
[s2 some.server:22] run task "uptime", commands: 2
[s2 some.server:22]  > sh -c /tmp/.spot/spot-script1294900175
[s2 some.server:22]  ! /tmp/.spot/spot-script1294900175: 3: export: 02:16:43: bad variable name
[s2 some.server:22]  ! failed command "uptime_get" on host some.server:22 (s2): can't run script on some.server:22: failed to run command on remote server: Process exited with status 2

code looks correct. What "bad variable name" means in this case? Does everything parsed correctly?

[knutov]

Is it possible in some other way to register output of the script to some local variable, like ansible do?

[umputun]

What is "some.server:22" supposed to represent? To me, it looks like your target is pointing to some non-existing server.

This is what running your playbook with a valid target looks like:

I don't understand the part about "some other way" as the proper way seems to work just fine. As long as you export anything, this is "registered"

pls, use discussion to ask similar types of questions, I'll move it

[knutov]

Interesting thing - it is valid for bash, but not for sh

root@s2:~# bash test.sh
setvar random_var= 10:10:48 up 8 days, 10:25, 3 users, load average: 0.03, 0.07, 0.08

root@s2:~# sh test.sh
del.sh: 3: export: 10:12:00: bad variable name

So the question goes to how to use bash instead of sh

[knutov]

valid sh version is: export random_var="$(/usr/bin/uptime)" (quotes added) but I definitely prefer use bash for scripting.

[umputun]

sh is most likely a symlink on your host; not sure what it's pointing to. However, adding the ability to enforce a particular shell runner can be handy in cases like this. To me, it still sounds like an edge case, and I don't get how this is even supposed to work. If my targets include some debian, some rhel, and some alpine boxes, sh is a safe "common denominator". If you set bash on a global level (i.e. command line param or env) this won't work on a system without bash.

Theoretically, it is possible to set shell as a part of the inventory record, but I'm not sure if this even makes sense.

[umputun]

I think the most straightforward approach is to allow the user to set any shebang (if not set will work with the current /bin/sh default), see #119

[knutov]

You are right. Ubuntu (and Debian) uses dash as sh by default. And there is history for that - https://askubuntu.com/questions/976485/what-is-the-point-of-sh-being-linked-to-dash

Using shebang will make a lot of small pieces of code multiline. It just looks not beautiful to me. Is it possible to have global switch/parameter with default shell to use?

The other option is to switch global on all servers sh from dash to bash (which I'll use for now), but in this case a lot of small scripts will work a little bit slower.

[umputun]

v1.6.4 just released. I don't think it will address your error, but it addresses the potential (and very real) conflict with setting variables