first of all sorry for the typo
should have been >> #! /usr/bin/env xxxxxx
I use the suggested shebang for all my scripts
rexx, bash - the scripting languages I use normally
but it works for python, perl, lua, ruby,
i even works for sbcl which needs an argument
#! /usr/bin/env sbcl --script
as far as the operating system
I have been using above shebang on
APPLE OSX
FreeBSD
and a few flavors of linux
ubuntu, debian, centos, fedora
so I guess that it should cover most of them
cheers
enrico
> On 24 Feb 2018, at 17:29, Gil Barmwater <gbarmwa...@alum.rpi.edu> wrote:
>
> So my question is "Does the suggested shebang line work for all the *nix
> flavors we support?"
>
> If so, it seems like a minimum amount of editing of the non-Windows-only
> *.rex files to put this issue to bed.
> Gil B.
> On 2/24/2018 7:11 AM, Enrico Sorichetti wrote:
>> IMO the most flexible shebang line is
>>
>> #! /usr/env/bin xxxxxx
>>
>> in this case
>> #! /usr/env/bin rexx
>>
>> it will pick up the executable according to the precedences set by $PATH
>> environment variable
>>
>> most useful to test different version of Rexx
>> I usually have a couple of them installed in different directories
>> ( after having changed CMakeLists.txt ways to a more reasonable behaviour )
>>
>> Too bad that the rexx Developers do not let the user set the INSTALL_PREFIX
>> according to the user standards but force Their poor choices on the user
>>
>> I still wonder why for APPLE OSX They do not follow the usual *nix logic
>>
>> Best regards
>>
>> enrico
>>
>>
>>> On 24 Feb 2018, at 11:16, oor...@jonases.se <mailto:oor...@jonases.se>
>>> wrote:
>>>
>>> Dear Rony,
>>>
>>> many thanks for your insights, it brings me to ask a question:
>>>
>>> I am building a larger project with many smaller „modules“ and I wanted to
>>> be a brave boy and start directly writing test cases for the modules as I
>>> go along.
>>>
>>> When I look at the ooRexx site the latest ooRexxTest I could find was 4.2.
>>> Can I use this version also for ooRexx 5.0.0?
>>>
>>> PS I looked into the .rexx files and saw that the Shebang for Unix/Linux is
>>> no longer correct, maybe you should do a S&R for
>>>
>>> #!/usr/bin/rexx
>>>
>>> and change it to
>>>
>>> #!/usr/local/bin/rexx
>>>
>>> in all places.
>>>
>>> Hälsningar/Regards/Grüsse,
>>> P.O. Jonsson
>>> oor...@jonases.se <mailto:oor...@jonases.se>
>>> Von mein MacBookPro gesendet
>>>
>>>
>>>
>>>> Am 22.02.2018 um 10:46 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at
>>>> <mailto:rony.flatsc...@wu.ac.at>>:
>>>>
>>>> Since the end of last December I have been working on a new "reflection
>>>> core" for BSF4ooRexx on the
>>>> Java side in every free minute (including evenings and weekends). The
>>>> reason being that with Java 9
>>>> some internals in the reflection area got changed and issue warnings, and
>>>> it is announced that with
>>>> future versions of Java these warnings will be changed to errors.
>>>>
>>>> As I would like to support a Java baseline of 1.6/6 the new reflection
>>>> logic has to work also on
>>>> Java 1.6/6, 1.7/7 and 1.8 in addtion to Java 9. So whenever there are
>>>> fundamental changes in the
>>>> experimental code I test them against all these versions on the same
>>>> machine using ooRexx 5.0 beta
>>>> without rebooting. Needless to say there may be bugs that show up after
>>>> such a change. In order to
>>>> be sure that the new functionality is on par with the current
>>>> functionality I regularly employ test
>>>> unit runs taking advantage of the latest ooRexx test unit framework
>>>> ("ooRexxTest").
>>>>
>>>> The observation and reason why I post this on the ooRexx developer list is
>>>> the following: from time
>>>> to time there have been quite surprising problems that have shown up. In a
>>>> couple of instances I
>>>> literally traced down for weeks (!) all kind of execution threads of the
>>>> library and the BSF4ooRexx
>>>> infrastructure to understand what is happening. Well, yesterday, in
>>>> despair, I killed rxapi and
>>>> re-ran the test suit and surprisingly, the unexplainable, erratic
>>>> surfacing errors went away! One
>>>> such error was for instance that turning a Java null into an ooRexx .nil
>>>> by sending an object proxy
>>>> string to Rexx indicating the object named ".NIL" causing a replacement
>>>> with .nil ("The NIL object")
>>>> all of a sudden would assign the string value of the environment symbol
>>>> .NIL instead (if res=".NIL"
>>>> then res=.nil) ! After killing rxapi and re-running the test suit
>>>> everything worked as it should,
>>>> the unexplainable errors went away!
>>>>
>>>> So it seems that there is state in rxapi that can affect a newly created
>>>> Rexx interpreter. In my
>>>> complex test environment it seems that when errors occur over time
>>>> eventually rxapi seems to be
>>>> affected and in turn newly started Rexx interpreters may get affected as
>>>> well!
>>>>
>>>> In case others experience such a phenomenon killing rxapi may save you a
>>>> lot of time!
>>>>
>>>> ---rony
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org <http://slashdot.org/>!
>>>> http://sdm.link/slashdot <http://sdm.link/slashdot>
>>>> _______________________________________________
>>>> Oorexx-devel mailing list
>>>> Oorexx-devel@lists.sourceforge.net
>>>> <mailto:Oorexx-devel@lists.sourceforge.net>
>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org <http://slashdot.org/>!
>>> http://sdm.link/slashdot_______________________________________________
>>> <http://sdm.link/slashdot_______________________________________________>
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> <mailto:Oorexx-devel@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> <http://sdm.link/slashdot>
>>
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> <mailto:Oorexx-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
> --
> Gil Barmwater
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot_______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
