[ros-users] [Ros-developers] suggest new ros shebang command
kruset at in.tum.de
Mon Aug 22 15:48:23 UTC 2011
Hm, exploiting the idea that the shell will not care about anything
after exec, I can even get the following to work in LISP:
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  which may get around the
> previous csh vs. sh issues. Works in roslaunch/rosh. Is this
> sufficient for your roslisp loading needs?
> LOADER=''''; exec rosrun rosh rosh "$0" "$@" #'''
> print packages
> : 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<kwc at willowgarage.com> 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<kruset at in.tum.de> wrote:
>>>> Why is the "rosrun ABSOLUTE_FILENAME [ARGS]" necessary for some
>>> 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
>>> 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 at code.ros.org
> ros-users mailing list
> ros-users at code.ros.org
More information about the ros-users