[ros-users] [Ros-developers] suggest new ros shebang command

Thibault Kruse 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:

===========
#!/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<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
>>>> 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 at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users




More information about the ros-users mailing list