It may be true that one can individually change the ooRexx location and version
by changing PATH such that the operating system can find the desired ooRexx in
that particular session that changed the PATH to point to a different ooRexx..
(This ability will not be lost if supporting update-atlernatives on Linux,
rather new possibilities of installation combinations that do not break
alternate installations becomes possible on Linux.)
However, this is not matching what update-alternatives defines and allows for:
- parallel installations of the same software in different versions,
- parallel installations of the equivalent software by different groups and
vendors,
- listing of all of the alternative installations,
- making one of the alternatives the system default, such that no one has to
fiddle with PATH settings in any session,
- maintaining the alternative packages.
This is not a service that developers of a certain package need like the ones
on this list, rather it is a service for deploying and for the „customers“ of
such packages that may be provided by different sources.
Personally, I have come to respect and admire this feature (as a huge time
saver) on Linux regarding my work on BSF4ooRexx for which I need different
versions of Java present in order to become able to test BSF4ooRexx on them.
One reason being that BSF4ooRexx needs to work on Java 1.6/6 (current Java
baseline) which is still deployed in companies, where the latest Java carries
the version 14 since a few weeks! With the open-sourced Java OpenJDK there have
been many, many new sources for Java installations that have become available
in addition to Oracle, IBM et.al., e.g. adoptOpenJdk.net, in all versions, 8,
9, 10, 11, 12, 13, 14, with hotspot or with an alternative JVM, etc.
All these many and different Java packages adhere to update-alternatives,
making it possible to have all these versions installed in parallel. If I need
to test against a certain version of Oracle Java I just pick that from
update-alternatives, if I have a need for and adoptOpenJDK in a certain
configuration and version I just pick that. As a result of using
update-alternatives to set a default Java from the list of alternative Javas
installed, no matter from which session I start a BSF4ooRexx application it
will use exactly that default version of Java set with update-alternatives. No
need to fiddle around with any environment variables in any of these sessions!
In the case of ooRexx supporting update-alternatives on Linux adds these
additional services and makes it easy on non-developers to maintain the version
of ooRexx to use by default (but also on developers who may have a need to test
their apps with different versions of ooRexx they know get used at customer
installations).
If a Rexx application runs into a problem with a certain version of ooRexx the
user can install an older or a newer version of ooRexx to test whether the Rexx
application would work in that environment. If not switching back is a breeze
with update-alternatives, because no fiddling of the environment is incurred on
the user, no need to reboot or open a new session that the change can take
effect etc.
It also would allow e.g. Regina users to install ooRexx, switch termporarily to
it to test their Rexx programs and applications from this moment on with a
specific version of ooRexx and allows them to switch back to Regina. Or the
other way around.
So there are IMHO quite important features in update-alternatives for Linux
that Rexx users can benefit over time. Therefore if it is possible to support
it for ooRexx, please do so!
Mark has offered his help to make sure that it works on ooRexx and with
Enrico‘s expertise on CMake (among other fields) it should be possible to come
up quickly with a stable, working, And tested version to the benefit of the
Rexx community as a whole!
—-rony
Rony G. Flatscher (mobil/e)
> Am 07.04.2020 um 08:33 schrieb P.O. Jonsson <oor...@jonases.se>:
>
>
>>> Am 07.04.2020 um 01:40 schrieb Mark Hessling <m...@rexx.org>:
>>>
>>> The only "configuration" is when you want to switch between alternate Rexx
>>> interpreters. Just as you have to run a script to switch between different
>>> versions of ooRexx.
>>>
>>> With the relocatable executables that ooRexx has, how do man pages get
>>> swapped?
>>>
>> I just tried this out on my Mac with an installation to ~/Applications. man
>> rexx works and give the expected information. I then removed
>> ~/Applications/ooRexx5/bin from the path and man rexx stated that there was
>> no information on rexx. I then copy and pasted the entire ooRexx
>> Installation (a single icon on macOS) to /Applications (where ALL Apps
>> reside), amended /Applications/ooRexx5/bin to the path and pop! man rexx
>> give the information again, this time from another location.
>>
>> My take on it is that at least on macOS there is no need to move the
>> manpages to /usr/local/share/man or /usr/share/man, the OS will find them
>> inside the installation.
>>
>> And uninstall is a single drag to the bin :-)
>> eg. I have a version of ooRexx installed in say /opt/ooRexx-v5.0.0 which has
>> a rexx.1 man page with certain contents, and I have another version of
>> ooRexx installed in /opt/ooRexx-v5.1.0 which has introduced a new switch to
>> the rexx binary and is documented in the new rexx.1 man page. When I switch
>> executables, how are the equivalent man pages switched so I get the correct
>> man page contents for the correct binary?
>>
>> While the concept of relocatable executables is a great idea for switching
>> between different versions of ooRexx, how does it work when I want to switch
>> between ooRexx and Regina?
>>
>> Cheers, Mark
>>
>> On 7/4/20 9:27 am, Enrico Sorichetti wrote:
>>> I just looked at the man pages both for Ubuntu and Fedora, and it looks like
>>> The update alternatives have to be configured
>>>
>>> IMO it is much more simple to
>>> Cd <path to the rexx executable directory>
>>> Export PATH=`pwd`:$PATH
>>> Or better use the attached snippets
>>>
>>> It works for me on Darwin Fedora, CentOS
>>> Enrico
>>>
>>> Here are two bash snippets to add/remove a directory to/from the PATH
>>> ( I have also the same for zsh )
>>>
>>> Cd somewhere and …
>>>
>>> The snippets should be sourced, not executed
>>>
>>> source path.here
>>> . path.here
>>>
>>> source path.remove
>>> . path.remove
>>>
>>>
>>> # path.here
>>> # remove the current path from the PATH and add it to the front
>>>
>>> # add in front of PATH
>>> prepen_path()
>>> {
>>> if ! eval test -z "\"\${$1##*:$2:*}\"" -o -z "\"\${$1%%*:$2}\"" -o -z
>>> "\"\${$1##$2:*}\"" -o -z "\"\${$1##$2}\"" ; then
>>> eval "$1=$2:\$$1"
>>> fi
>>> }
>>>
>>> # remove path
>>> remove_path()
>>> {
>>> # front/middle
>>> if eval test -z "\"\${$1##$2:*}\"" -o -z "\"\${$1##*:$2:*}\"" ; then
>>> eval "$1=${!1/$2:/}"
>>> return
>>> fi
>>> # tail
>>> if eval test -z "\"\${$1%%*:$2}\"" ; then
>>> eval "$1=${!1/:$2/}"
>>> return
>>> fi
>>> # only
>>> if eval test -z "\"\${$1##$2}\"" ; then
>>> eval "$1=${!1/$2/}"
>>> return
>>> fi
>>> }
>>>
>>> # the works
>>> here="$(pwd)"
>>> if ! test -d "${here}" ; then
>>> echo "strange ... path not found '${here}'"
>>> else
>>> remove_path PATH "${here}"
>>> export PATH
>>> prepen_path PATH "${here}"
>>> export PATH
>>> fi
>>>
>>> # cleanup
>>> unset prepen_path
>>> unset remove_path
>>>
>>>
>>>
>>>
>>> # path.remove
>>> # remove the current path from the PATH
>>>
>>> # remove path
>>> remove_path()
>>> {
>>> # front/middle
>>> if eval test -z "\"\${$1##$2:*}\"" -o -z "\"\${$1##*:$2:*}\"" ; then
>>> eval "$1=${!1/$2:/}"
>>> return
>>> fi
>>> # tail
>>> if eval test -z "\"\${$1%%*:$2}\"" ; then
>>> eval "$1=${!1/:$2/}"
>>> return
>>> fi
>>> # only
>>> if eval test -z "\"\${$1##$2}\"" ; then
>>> eval "$1=${!1/$2/}"
>>> return
>>> fi
>>> }
>>>
>>> #the works
>>> here="$(pwd)"
>>> if ! test -d "${here}" ; then
>>> echo "strange ... path not found '${here}'"
>>> else
>>> remove_path PATH "${here}"
>>> export PATH
>>> fi
>>>
>>> # cleanup
>>> unset remove_path
>>>
>>>
>>>
>>>> On 7 Apr 2020, at 01:05, Mark Hessling <m...@rexx.org> wrote:
>>>>
>>>> Hi P.O.,
>>>>
>>>> I apologise for problems my changes caused you; it was not intentional and
>>>> if I had known about your problems at the time I would have fixed them.
>>>>
>>>
>> --
>> ------------------------------------------------------------------------
>> * Mark Hessling, m...@rexx.org http://www.rexx.org/
>> * Author of THE, a Free XEDIT/KEDIT editor and, Rexx/SQL, Rexx/CURL, etc.
>> * Maintainer of Regina Rexx interpreter
>> * Use Rexx? join the Rexx Language Association: http://www.rexxla.org/
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
