Hm, exploiting the idea that the shell will not care about anything after exec, I can even get the following to work in LISP: =========== #!/usr/bin/env sh exec /usr/bin/env rosrun roslisp_support run-lisp-script.sh "$0" "$@" (print "Hello world") =========== That works because I write my own lisp script interpreter (wrapper), and that one can just discard the first two lines of any file it is given. And it works with roslaunch/rostest as well. It is so clean and simple that it is almost embarassing I did not think of it before. So I guess that should solve my problem without any rosbang, thanks. On 08/21/2011 07:50 PM, Ken Conley wrote: > Hi Thibault, > > I just saw this recipe on ActiveState [1] which may get around the > previous csh vs. sh issues. Works in roslaunch/rosh. Is this > sufficient for your roslisp loading needs? > > --------- > > #!/bin/sh > LOADER=''''; exec rosrun rosh rosh "$0" "$@" #''' > > print packages > > > [1]: http://code.activestate.com/recipes/577851-teach-the-hashbang-header-new-tricks-using-a-dual-/ > > On Mon, Aug 15, 2011 at 9:58 AM, Ken Conley wrote: >> Hi Thibault, >> >> Thanks for clarifying. >> >> I think at this point we need to basically decide between: >> >> 1) Modifying rosrun to have the separate command-line syntax (meant >> for scripts, not users). >> 2) Create a new ros/bin/ros-shebang (name TBD) to support this script >> use case instead. >> >> Given that this relates to a major command-line tool like rosrun, I'd >> rather not decide by fiat -- any opinions out there as to which is >> preferred? (+1/-1 votes welcome) >> >> - Ken >> >> >> >> On Fri, Aug 12, 2011 at 2:17 PM, Thibault Kruse wrote: >>>> Why is the "rosrun ABSOLUTE_FILENAME [ARGS]" necessary for some >>>> scripts? >>> Because if I put >>> #! /usr/bin/env rosrun >>> >>> in a script file named foobar.xyz, make foobar.xyz executable, and call >>> >>> $ ./foobar.xyz arg1 arg2 arg3 >>> >>> then bash will effectively call >>> >>> rosrun ./foobar.xyz arg1 arg2 arg3 >>> >>> (So actually the syntax is just rosrun FILENAME [ARGS], not necessarily >>> the absolute path ) >>> >>> So the syntax is merely for shebang, NOT for anyone ever putting >>> rosrun /path/to/filename >>> into any script or the command line. >>> >>>> From the perspective of command-line usage, it doesn't add >>>> much value as it is equivalent to the user typing: >>>> >>>> ./ABSOLUTE_FILENAME [ARGS] >>> Absolutely, yes. That's my working assumption, the reason why I think >>> rosrun could be used instead of rosbang. That's what rosbang would also >>> do. So a rosbang command would be totally useless for command line usage. >>> >>> The syntax of rosbang would equally be >>> rosbang FILENAME [ARGS] >>> and its effect would be the same as >>> ./FILENAME [ARGS] >>> There is no reason why any user would ever type rosbang into the command >>> line. It would exclusively be used in >>> #! /usr/bin/env rosbang >>> >>>> If there is a special need for a script, I would suggest a special >>>> option, e.g. '-f', to flag the different usage and make it >>>> unambiguous. >>> No, not only is that not necessary, but it would make it impossible to >>> use rosrun that way, as >>> #! /usr/bin/env rosrun -f >>> is not possible. >>> >>> I was not aware of the rosexec thread. Went through it now. Introducing >>> rosexec PACKAGE/KEY as syntax would overlap with rosexec >>> directory/filename syntax, as far as i can see those could never be >>> merged into one command without the possibility of surprising the user >>> with unexpected actions in rare cases. So if that is still a >>> perspective, a separate command like rosbang might be wiser. >>> >>> _______________________________________________ >>> ros-users mailing list >>> ros-users@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >>> > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users