+1<div><br></div><div>I wonder if this could also be used to control which version of Python you are using without changing the paths and such. I have been working on making ros, ros_comm, and common_msgs more Python 2/3 portable because of MORSE, which uses Blender, which requires Python3. I had considered setting something like env['ROS_PYTHON'] and replacing the #!/usr/bin/env python lines with something like ros-shebang that would select python executables and paths based on the environment variable. This isn't something I see people doing often, but it might be a use case to consider when designing this tool. There might also be a better/existing way of doing what I am talking about, but I am just not aware of it.</div>
<div><br></div><div>Looks good,</div><div><br clear="all">~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>William Woodall<br>Graduate Software Engineering<br>Auburn University<br><a href="mailto:w@auburn.edu" target="_blank">w@auburn.edu</a><br>
<a href="mailto:wjwwood@gmail.com" target="_blank">wjwwood@gmail.com</a><div><a href="http://williamjwoodall.com" target="_blank">williamjwoodall.com</a><br>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</div><br>
<br><br><div class="gmail_quote">On Wed, Aug 10, 2011 at 11:21 AM, Ken Conley <span dir="ltr"><<a href="mailto:kwc@willowgarage.com">kwc@willowgarage.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
+1<br>
<br>
If shorter names are being debated, I offer 'rosbang'. The placement<br>
of the hyphen in ros-shebang doesn't quite feel like a ros command<br>
name.<br>
<br>
I should also note that part of this discussion also includes what<br>
distributions ros-shebang should be included in, i.e. should it be<br>
backported to diamondback, sneak in through the electric freeze,<br>
etc...<br>
<br>
The hashbang spec has definitely been an impediment for having a good<br>
ease-of-use with rosh, so I support at least having this in ROS<br>
Electric. I'm indifferent to ROS Diamondback as my development is<br>
always focused on the latest-and-greatest release.<br>
<font color="#888888"><br>
- Ken<br>
</font><div><div></div><div class="h5"><br>
On Tue, Aug 9, 2011 at 2:40 PM, Thibault Kruse <<a href="mailto:kruset@in.tum.de">kruset@in.tum.de</a>> wrote:<br>
> Hi,<br>
><br>
> I would like to make a suggestion.<br>
><br>
> I want to add a command (called ros-shebang for now) to ros/bin that runs<br>
> script files by invoking a second shebang line.<br>
><br>
> This allows invoking script interpreters with #! and passing additional<br>
> arguments, as well as invoking interpreters that live in ROS packages.<br>
><br>
> My stake is calling an interpreter for roslisp scripting. However a<br>
> similar concern is invoking of rosh plugins, see<br>
> <a href="http://www.ros.org/wiki/rosh/Overview/Roshlets" target="_blank">http://www.ros.org/wiki/rosh/Overview/Roshlets</a><br>
><br>
> Example for rosh:<br>
> #! /usr/bin/env ros-shebang<br>
> #! /usr/bin/env rosrun rosh rosh rosh/echolet.py<br>
> --plugins=rosh_common,rosh_geometry<br>
><br>
> Example for roslisp:<br>
><br>
> #! /usr/bin/env ros-shebang<br>
> ;; /usr/bin/env rosrun sbcl run-sbcl.sh --script<br>
><br>
> One less known alternative is to use other directives to declare the<br>
> script interpreter than #!, (in case you wonder, for lisp, #| and ":";<br>
> work) however this does not work with python subprocess.Popen, which means<br>
> roslaunch and rostest would fail to run scripts like that (except using<br>
> shell=True, but this is strongly discouraged for security and portability<br>
> reasons).<br>
><br>
> Alternatives:<br>
> - A modification to roslaunch syntax to allow forcing shell=true<br>
><br>
> - an executable in ros/bin that executes roslisp scripts, such that we<br>
> could write:<br>
> #! /usr/bin/env ros-run-roslisp-script<br>
><br>
> - A required fixed installation of our lisp implementation, or some custom<br>
> made variant of /usr/bin/env<br>
><br>
><br>
> I wrote a ros-shebang script in python that works, which is no more magic<br>
> than reading the second line and calling python execvp on it (minus the<br>
> first two symbols).<br>
><br>
> If a new command were introduced to ros/bin, this would affect more people<br>
> than those working with roslisp, so opinions should be heard. There is no<br>
> urgency to this, roslisp works fine as it is without offering comfortable<br>
> scripting, just as rosh works fine by loading plugins after the shebang<br>
> line.<br>
><br>
> Not sure if there are other scripting interpreter usages with similar<br>
> issues in ROS (Java, Lua, Javascript, ...).<br>
><br>
> Thoughts?<br>
><br>
> Thibault<br>
><br>
> _______________________________________________<br>
> ros-developers mailing list<br>
> <a href="mailto:ros-developers@code.ros.org">ros-developers@code.ros.org</a><br>
> <a href="https://code.ros.org/mailman/listinfo/ros-developers" target="_blank">https://code.ros.org/mailman/listinfo/ros-developers</a><br>
> _______________________________________________<br>
> ros-users mailing list<br>
> <a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
> <a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
><br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br></div>