Unexpected $(dirname) behaviour when value assigned to arg.

[mikepurvis]

The existing test is here, added as part of the overall feature in #1103:

https://github.com/ros/ros_comm/blob/e96c407c64e1c17b0dd2bb85b67f388380527097/tools/roslaunch/test/xml/test-dirname.xml

If the test is augmented to be:

<launch>
  <param name="foo" value="$(dirname)/bar" />
  <include file="$(dirname)/test-dirname/included.xml">
    <arg name="baz" value="$(dirname)/baz" />
  </include>
</launch>

And then the included.xml file is changed to:

<launch>
  <arg name="baz" />

  <param name="bar" value="$(dirname)/baz" />
  <param name="baz" value="$(arg baz)" />
</launch>

You'd expect the baz parameter to have tools/roslaunch/test/xml/baz as its path, but instead it's tools/roslaunch/test/xml/test-dirname/baz. That is, dirname is being lazily resolved at the point where the value is assigned to the parameter, rather than when the arg value is assigned. Historically this hasn't mattered, as no other substitutions have this kind of context sensitivity.

I'm not sure how much effort this will be to fix, but I had an instance recently where it would have been nice to be able to pass a "back path" into an included file, and wasn't able to do so due to this problem.

[danielwangksu]

this indeed is a issue

[v4hn]

This is entirely unintuitive behavior demoting the use of the (in ROS terms) relatively new $(dirname).
Sad to see this unresolved three years after Mike went through the trouble to document it...

[mikepurvis]

@v4hn In fairness to the maintainers of this repo, I am in fact the author of the original $(dirname) patch, so this ticket was as much about self-disclosure as it was anything else. :) We ended up reworking our launchfiles to not require this fixed, but I left the ticket up in case someone else was interested in tackling it.

[v4hn]

I am in fact the author of the original `$(dirname)` patch,

Thanks! Without this bug, it would be an even more useful command, though it already helps with relative includes. 😎

We ended up reworking our launchfiles to not require this fixed, but I left the ticket up in case someone else was interested in tackling it.

Yeah, the usual lot of bugs that are relatively easy to work around... They just never disappear unless some good soul has the interest and time to fix it.