Just tested the new version of the BSF4ooRexx command line installer and it
works with the official
ooRexx 5 installation. To test:
* download
"https://sourceforge.net/projects/bsf4oorexx/files/beta/20200928/BSF4ooRexx_install_v641-20210715-beta.zip";
* run "xattrs -d com.apple.quarantine
BSF4ooRexx_install_v641-20210715-beta.zip"
* unzip
* change into "bsf4oorexx/install/macosx", issue "sh install.sh"
o BSF4ooRexx gets copied to "/opt/BSF4ooRexx"
o to uninstall use "sh /opt/BSF4ooRexx/install/macosx/uninstall.sh"
---rony
P.S.: The alternative would be to use the GUI-package for MacOSX which includes
ooRexx 5:
* download
"https://sourceforge.net/projects/bsf4oorexx/files/beta/20200928/b4r_641_500_64Bit_macosx-universal-20210627-r12266.zip";
* run "xattrs -d com.apple.quarantine
b4r_641_500_64Bit_macosx-universal-20210627-r12266.zip"
* unzip and open the package for installation
* to uninstall: use the menu by opening "/Applications/ooRexx.app", choose
"Installation -> Uninstall"
On 16.07.2021 15:41, Rony G. Flatscher wrote:
>
> While testing a little bit, here is maybe another helpful insight: after
> downloading the ooRexx
> installation package it is possible without super-user power to remove the
> quarantine attribute
> using Renés example:
>
> xattr -d com.apple.quarantine ooRexx-5.0.0-12280.macOS.x86_64.dmg
>
> Then installing ooRexx by opening the dmg-file and following the installation
> directions yields a
> working installation in /Applications/ooRexx5!
>
> ---rony
>
>
> On 16.07.2021 14:27, René Jansen wrote:
>> Running
>>
>> sudo xattr -r -d com.apple.quarantine $YOUR_DIRECTORY
>>
>> mostly helps.
>>
>> René
>>
>>> On 16 Jul 2021, at 14:10, P.O. Jonsson <oor...@jonases.se
>>> <mailto:oor...@jonases.se>> wrote:
>>>
>>> What version of MacOS are we talking about? In the past extracting the .dmg
>>> caused a warning
>>> that could be overwritten but I never experienced that rexx would not
>>> launch? Is this a M1 thing
>>> only? Or „Fat Binary“ problem? Does it help to install to ~/Applications (a
>>> local install)
>>> rather than to /Applications (Install for all users)?
>>>
>>> I run High Sierra (10.13) and the build machine runs Mojave (10.14). In
>>> view of the age of the
>>> build machine (~ late 2014) I would not go beyond Catalina (10.15) and I
>>> see no gain in
>>> changing, just risk of running into problems with outdated hardware.
>>>
>>> We do not have at our disposal any machine with macOS Big Sur (11.1) that
>>> can run on either
>>> Intel or M1 hardware.
>>>
>>> What I can try to do is to see if I can get some Virtual Machines set up
>>> with Catalina/Big Sur.
>>> But it will not be on M1 hardware.
>>>
>>> Hälsningar/Regards/Grüsse,
>>> P.O. Jonsson
>>> oor...@jonases.se <mailto:oor...@jonases.se>
>>>
>>>
>>>
>>>> Am 16.07.2021 um 13:47 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at
>>>> <mailto:rony.flatsc...@wu.ac.at>>:
>>>>
>>>> Downloaded the latest MacOS version of ooRexx 5.0 from the ooRexx project
>>>> page at sourceforge.
>>>>
>>>> It turns out that Apple inhibits using anything from that dmg as it was
>>>> downloaded from the
>>>> Internet and not from Apple's store! :(
>>>>
>>>> This is due to Apple's "security policy" that they put in effect, which
>>>> simply deprive the
>>>> owners of those Apple computers.
>>>>
>>>> Here are two use cases, each demonstrated with an attached screenshot:
>>>>
>>>> * Scenario 1: installing ooRexx according to the readme will create
>>>> "/Application/ooRexx5"
>>>> with the "bin", "lib" etc directories. Trying to run
>>>> "/Application/ooRexx5/bin/rexx -v"
>>>> causes "Screenshot 2021-07-16 at 12.46.04.png" to pop up. Apple
>>>> suggests to move the
>>>> program to the bin! :-(
>>>>
>>>> * Scenario 2: using Finder to "open" (run)
>>>> "/Application/ooRexx5/bin/rexx" yields at first a
>>>> pop up that seems to indicate, that further opening would allow the
>>>> program to run from now
>>>> on, cf. "Screenshot 2021-07-16 at 12.53.17.png". However when "rexx"
>>>> loads the
>>>> "librexx.4.dylib" the "Move to Bin" popup as above gets displayed!
>>>>
>>>> Probably turning off SIP
>>>> (<https://apple.stackexchange.com/questions/208478/how-do-i-disable-system-integrity-protection-sip-aka-rootless-on-macos-os-x>)
>>>> will allow this to work again, however, asking users to turn off SIP may
>>>> be too much.
>>>>
>>>> The alternative would be to get and use the keys from Apple and use them
>>>> to sign the ooRexx
>>>> executables.
>>>>
>>>> The question then is, who should apply/buy this: RexxLA or some individual
>>>> developer in this
>>>> group who signs the releases? Who is going to pursue this?
>>>>
>>>> ---rony
>>>>
>>>> P.S.: @Enrico: this may be also the reason why on M1 with a stricter
>>>> "security policy" in place
>>>> would not pick the amd64 binaries from the fat distribution! If you look
>>>> at the first screen
>>>> shot you can read "Reason: no suitable image found.", the same error
>>>> message as on M1, but here
>>>> there is additional information pointing ad "Library Validation: ..." that
>>>> fails.
>>>>
>>>> This behavior might not be present if you create ooRexx on the M1 and run
>>>> it from there, as
>>>> then the binaries did not come from "insecure locations" according to
>>>> Apple (which is the
>>>> Internet and locations that are not under the control of Apple software).
>>>>
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
