It's possible I'm not forming the value of command correctly, but the hacky solution I found is to create a shell script that does a rosparam set and generates some stdout to put into a dummy variable.
foo/scripts/timestamp.sh:
#!/bin/sh
rosparam set dst $ROS_WORKSPACE/`date +%d-%m-%Y_%Ih%Mm%S`.mp3
echo "blah"
And the launch file:
<param name="dummy" command="$(find foo)/scripts/timestamp.sh"/>
rosparam get dst
gets a timestamped filename with the mp3 suffix, and no single quotes or carriage return as mentioned in my comments to the other answer.
There will be the dummy variable hanging around:
$ rosparam get dummy
'blah
'
The point is to make sure the script gets run before any nodes are launched that will depend on the param being set, where just running the timestamp.sh from a roslaunch <node>
may or may not create the param first ( http://answers.ros.org/question/33772... ). The documentation in http://wiki.ros.org/roslaunch/XML/param isn't explicit about that but I assume it does always run the command first.
Nested roslaunches with param command?
Could that (somewhat ugly) approach also could generalize to running entire other roslaunches that would have to run then exit before the higher level launch would launch any nodes?
<!-- launch some stuff before doing anything else here -->
<param name="dummy" command="roslaunch bar xyz.launch"/>
If that works it would be an answer to some other questions here.
It produces an error:
run_id on parameter server does not match declared run_id: 9d505b9e-3991-11e7-b59e-
d8fc93bc28de vs 9d224222-3991-11e7-b59e-d8fc93bc28de
Though at the same time I can see parameters set by xyz.launch were actually set.