Actually, I just rechecked, and you had answered me.
https://code.ros.org/trac/ros/ticket/1669

The ability to get parameters using a command is indispensable when you
are trying to automagically determine the correct device to open. I have
seen a case where it would have been nice to do a <rosparam> with a
command because there were potentially a whole bunch of parameters
involved (turns out there were only two, but that was just luck).

The case I saw where a more general $(command ) tag would have been
useful was when I was trying to get pr2.launch so that it could be
optionally be pushed into a namespace. The idea was to do:

ROS_NAMESPACE=prl roslaunch pr2.launch

Some remappings (diagnostics, diagnostic aggregation, TF) needed to get
done to make this work well, and I could really have used a $(command )
tag to allow slashes to be added or removed as appropriate. (In the end
limitations in diagnostic aggregation also prevented me from making it
happen.)

The <command> or <exec> tag would be really useful when you want to run
something that isn't ROS aware and don't want it confused by its __name
and __log arguments.

As for the problem of sequencing commands, would it really be so bad to
say that relying on command order execution will lead to undefined
behavior, and adding an option to roslaunch to run things in a random
order with random startup delays so that it is easy to regression test? 

(I'm talking about whether it is a good feature here, not about whether
you have had the chance to implement.)

Cheers,
Blaise

On Fri, 2010-04-16 at 09:05 -0700, Ken Conley wrote:
> On Fri, Apr 16, 2010 at 8:50 AM, Blaise Gassend
> <blaise@willowgarage.com> wrote:
>         I have asked Ken why there is no $(command ) macro in
>         roslaunch but
>         never got an answer... I have seen cases beyond parameters
>         where it
>         would have been handy... but perhaps hacky.
>         
> 
> Must have slipped my mind because I don't recall a ticket. My only
> issues with command hacks is that it is much easier to put something
> in there that is non-portable, and validation is much, much trickier.
> It has its uses, though.
> 
> I've always wanted to a top-level <exec> or <command> tag to
> complement the <node> tag as many things that are called <node>s in
> roslaunch are not actually ROS nodes (and can have different assumed
> behaviors). We attempted to design this prior to ROS 1.0, but it
> quickly spiraled out of control with respect to scope. Unlike nodes,
> commands are sequence-able because they normally terminate, unlike
> nodes which do not. Once you attempt to add sequencing to roslaunch
> for a particular tag, things the design space gets arbitrarily large
> (especially when considering remote launches). 
> 
> I was hoping to have more time to overhaul the roslaunch syntax this
> iteration, but it looks like that won't happen until D-Turtle.
> 
>  - Ken
> 
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users