Re: Anyone running X11 apps on Mojave? [Solved]
Hi,
Effectively, the problem was the risk of loop.
My preference would be toward the second solution but with a mechanism like the
« alternatives » Debian. So, my solution could be:
# File to replace with alternative
File="/bin/bash"
OptFile="/opt/local/bin/bash"
AlternDir="/etc/alternatives"
# Creation of a directory to be use with alternative mechanism.
[ -d "${AlternDir}" ] || mkdir -p "${AlternDir}"
# If it’s a symbolic?
if [ -h "${File}" ] ; then
mv "${File}" "${File}.traditional"
ln -s "${File}.traditional" "${File}"
fi
# Creation of the alternative
[ -f "${File}" ] && /bin/rm "${File}"
ln -s "${OptFile}" "${File}"
As is, if an OS upgrade arrive, if this one change something about /bin/bash, I
can reactive it simply.
Best wishes.
> Le 22 janv. 2019 à 07:23, Bill Cole
> a écrit :
>
> On 21 Jan 2019, at 5:41, Pierre Malard wrote:
>
>> It’s a great new for me but I have a subsidiary question:
>> « How can I use the MacPort BASH in place of Apple one? »
>>
>> If you have a solution…
>
> I have options for that specific task...
>
>
> 1. Switch to the MacPorts bash without looping
>
> Put these 4 lines at the top of ~/.bash_profile:
>
> if [ -z "$MACPORTS_BASH" ] && [ -x /opt/local/bin/bash ]
> then
> MACPORTS_BASH=DONE PATH=/opt/local/bin:$PATH exec -l bash -l
> fi
>
> You could probably put those in /etc/profile with equivalent safety and make
> it happen for all login shells. This approach WILL NOT fix older versions of
> MacOS X, where /bin/sh (the POSIX default shell) is a version of bash which
> is vulnerable to serious security flaws. There is a risk in this because the
> MacPorts bash depends on MacPorts dynamic libraries. Adding precautionary
> checks inside the conditional might be able to mitigate those risks.
>
> OR:
>
> 2. Replace /bin/sh
>
> The following patch will add a "static" variant to the bash port and
> includes a message describing how to replace /bin/sh with that build. If you
> use it, you MUST re-patch the Portfile every time the bash port is updated.
> It SHOULD NOT be in the MacPorts core because it is a horrifically
> unsupportable hack that no one should ever use because it violates the core
> of the OS.
>
> HOWEVER: it has worked for me for a few years on a Snow Leopard machine where
> the last Apple bash cannot be allowed to exist...
>
> BEGIN PATCH
> ---
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/shells/bash/Portfile.orig
> 2018-06-02 09:27:05.0 -0400
> +++
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/shells/bash/Portfile
>2018-06-09 21:24:27.0 -0400
> @@ -123,6 +123,29 @@
> # Always source .bashrc when connecting remotely with ssh, #40603
> configure.cflags-append -DSSH_SOURCE_BASHRC
>
> +variant static description "Links all MacPorts library dependencies
> statically to allow the binary to replace the system shell" {
> + system "mkdir -p ${prefix}/lib/statics"
> + system "ln -f ${prefix}/lib/*.a ${prefix}/lib/statics/"
> + system "ln -f ${prefix}/lib/*.o ${prefix}/lib/statics/"
> + configure.args-append "--with-included-gettext
> --libdir=/opt/local/lib/statics "
> + configure.ldflags-delete "-L${prefix}/lib"
> + configure.ldflags-append "-L${prefix}/lib/statics"
> +}
> +
> +post-install {
> + if {[variant_isset static]} {
> + ui_msg
> "***"
> + ui_msg "If you want to replace the system shell with this build of
> bash,"
> + ui_msg "you must do so manually by copying or hardlinking it into /bin
> !"
> + ui_msg " ln -f /opt/local/bin/bash /bin/bash"
> + ui_msg " ln -f /opt/local/bin/bash /bin/sh"
> + ui_msg "OR:"
> + ui_msg " cp /opt/local/bin/bash /bin/bash"
> + ui_msg " cp /opt/local/bin/bash /bin/sh"
> + ui_msg
> "***"
> + }
> +}
> +
> livecheck.type regex
> livecheck.url
> http://ftp.gnu.org/gnu/${name}/${name}-${bash_version}-patches/?C=M=D
> livecheck.version [format %03d ${bash_patchlevel}]
> END PATCH
>
> The goal here is to build a shell that can replace /bin/sh and be independent
> of every dynamic shared library for which a linkable static library exists.
> The result on the Snow Leopard machine where I hacked this up is a /bin/sh
> which depends only on /usr/lib/libSystem.B.dylib, so in an emergency
> single-user boot where /opt/local is unmounted or mangled, the shell still
> can work.
>
>
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Available For Hire: https://linkedin.com/in/billcole
--
Pierre Malard
« Ce qui tombe sous le sens
Re: Anyone running X11 apps on Mojave? [Solved]
On 21 Jan 2019, at 5:41, Pierre Malard wrote:
It’s a great new for me but I have a subsidiary question:
« How can I use the MacPort BASH in place of Apple one? »
If you have a solution…
I have options for that specific task...
1. Switch to the MacPorts bash without looping
Put these 4 lines at the top of ~/.bash_profile:
if [ -z "$MACPORTS_BASH" ] && [ -x /opt/local/bin/bash ]
then
MACPORTS_BASH=DONE PATH=/opt/local/bin:$PATH exec -l bash -l
fi
You could probably put those in /etc/profile with equivalent safety and
make it happen for all login shells. This approach WILL NOT fix older
versions of MacOS X, where /bin/sh (the POSIX default shell) is a
version of bash which is vulnerable to serious security flaws. There is
a risk in this because the MacPorts bash depends on MacPorts dynamic
libraries. Adding precautionary checks inside the conditional might be
able to mitigate those risks.
OR:
2. Replace /bin/sh
The following patch will add a "static" variant to the bash port and
includes a message describing how to replace /bin/sh with that build. If
you use it, you MUST re-patch the Portfile every time the bash port is
updated. It SHOULD NOT be in the MacPorts core because it is a
horrifically unsupportable hack that no one should ever use because it
violates the core of the OS.
HOWEVER: it has worked for me for a few years on a Snow Leopard machine
where the last Apple bash cannot be allowed to exist...
BEGIN PATCH
---
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/shells/bash/Portfile.orig 2018-06-02
09:27:05.0 -0400
+++
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/shells/bash/Portfile 2018-06-09
21:24:27.0 -0400
@@ -123,6 +123,29 @@
# Always source .bashrc when connecting remotely with ssh, #40603
configure.cflags-append -DSSH_SOURCE_BASHRC
+variant static description "Links all MacPorts library dependencies
statically to allow the binary to replace the system shell" {
+ system "mkdir -p ${prefix}/lib/statics"
+ system "ln -f ${prefix}/lib/*.a ${prefix}/lib/statics/"
+ system "ln -f ${prefix}/lib/*.o ${prefix}/lib/statics/"
+ configure.args-append "--with-included-gettext
--libdir=/opt/local/lib/statics "
+ configure.ldflags-delete "-L${prefix}/lib"
+ configure.ldflags-append "-L${prefix}/lib/statics"
+}
+
+post-install {
+ if {[variant_isset static]} {
+ ui_msg
"***"
+ ui_msg "If you want to replace the system shell with this build
of bash,"
+ ui_msg "you must do so manually by copying or hardlinking it into
/bin !"
+ ui_msg " ln -f /opt/local/bin/bash /bin/bash"
+ ui_msg " ln -f /opt/local/bin/bash /bin/sh"
+ ui_msg "OR:"
+ ui_msg " cp /opt/local/bin/bash /bin/bash"
+ ui_msg " cp /opt/local/bin/bash /bin/sh"
+ ui_msg
"***"
+ }
+}
+
livecheck.type regex
livecheck.url
http://ftp.gnu.org/gnu/${name}/${name}-${bash_version}-patches/?C=M=D
livecheck.version [format %03d ${bash_patchlevel}]
END PATCH
The goal here is to build a shell that can replace /bin/sh and be
independent of every dynamic shared library for which a linkable static
library exists. The result on the Snow Leopard machine where I hacked
this up is a /bin/sh which depends only on /usr/lib/libSystem.B.dylib,
so in an emergency single-user boot where /opt/local is unmounted or
mangled, the shell still can work.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
Re: Anyone running X11 apps on Mojave? [Solved]
I’m a stupid guy! Effectively, the easiest way is to configure the Terminal to use /opt/local/bin/bash! I prefer this solution because of OS upgrades which erase any local configuration. However your suggestion to use exec -a -bash /opt/local/bin/bash —noprofile work. Thanks a lot > Le 21 janv. 2019 à 12:36, Richard L. Hamilton a écrit : > > Instead of that line in .bash_profile, as long as all the systems you use > your login (if you're using OpenDirectory) on have /opt/local/bin/bash > installed, > the Unix way would be to add /opt/local/bin/bash to the list of shells in > /etc/shells (if that file doesn't exist, it's as if it existed with just > /bin/sh and /bin/csh, > one per line), and edit your account so that your login shell was > /opt/local/bin/bash. > > The one gotcha when reinstalling MacPorts after an OS upgrade, (actually, > just before the OS upgrade) you'd have to edit your account again to use an > OS supplied shell that will be there throughout the MacPorts reinstall, and > change it back when done. > > If your account info is just in local files, you can probably use the chsh > command rather than the Directory Editor app to change your shell, but it > still needs to be in /etc/shells. > > FYI, my /etc/shells contains > /bin/bash > /bin/csh > /bin/ksh > /bin/sh > /bin/tcsh > /bin/zsh > > You cannot add --login to your line in .bash_profile, because that would loop > (you're already reading .bash_profile, so you exec a login shell which reads > it again, exec's again, etc). Maybe there's some other tricky thing you > could do with your own files that might work; perhaps if it were the last > line in .bash_profile, and looked like > > [ -x /opt/local/bin/bash ] && exec -a -bash /opt/local/bin/bash --noprofile > > that _might_ work (it would look like a login shell with $0 set to -bash, but > not actually run the profile files again), but I'm not going to make all those > changes (I use /bin/ksh as my login shell), log out, log back in to test, and > then reverse all that, just to find out if it works. > > If the only way you run interactive shells where you really want > /opt/local/bin/bash is with Terminal, you can change its settings to use that > as your shell, only for what's run under Terminal (won't affect xterm, ssh, > etc). > > Those are the only sorts of ways I can see around whatever problem that line > is causing you, while still running the shell of your choice. > > >> On Jan 21, 2019, at 05:41, Pierre Malard wrote: >> >> Hi, a great thanks! >> >> You were right, it was my specific configuration which was in cause, even if >> it was not a DISPLAY error. >> >> After a long wile and successives tests I found why it doesn’t work :-) >> >> First, I found that was the « —login » parameter of X11 script which was in >> cause. If I launch X11 without it, it works. In piratical: >> 1- the « exec -l /bin/bash --login -c 'exec >> /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin' - >> /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin » of X11 script won’t >> work. >> 2- An « exec -l /bin/bash -c 'exec >> /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin' - >> /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin » world fine. >> It’s the same thing with XQuartz. >> >> The explanation now: >> As I have a BASH v4.3 installed with MacPort, I would use it in my « >> Terminal.app » sessions and I just add this line in my « ~/.bash_profile » >> file: >> [ -x /opt/local/bin/bash ] && exec /opt/local/bin/bash >> to launch BASH v4.3. I remove it and everything work with X11… >> >> As it is evident now, this « exec » line trouble opening X11 with the other >> « exec —login ». As explain in the « man bash »: >> When bash is invoked as an interactive login shell, or as a >> non-interactive shell with >> the --login option, it first reads and executes commands from the file >> /etc/profile, if >> that file exists. After reading that file, it looks for >> ~/.bash_profile, >> ~/.bash_login, and ~/.profile, in that order, and reads and executes >> commands from the >> first one that exists and is readable. >> So, my « ~/.bash_profile » were read with the first call, not with the >> second one. >> >> It’s a great new for me but I have a subsidiary question: >> « How can I use the MacPort BASH in place of Apple one? » >> >> If you have a solution… >> >> >> Le 19 janv. 2019 à 12:03, Christopher Jones a >> écrit : >>> >>> The logs below indicate problems with DISPLAY. They also suggest you have >>> some residual parts of the non-macports Xquartz installed. >>> >>> Do you set DISPLAY at all in any of your shell login scripts. If so remove >>> this. Try creating a new test user on your system, log in as that and see >>> if it works from there. If so it would indicate something in your user >>> environment. >>> >>> Make sure you have all parts of the other Xquartz removed. In
Re: Anyone running X11 apps on Mojave? [Solved]
Instead of that line in .bash_profile, as long as all the systems you use your login (if you're using OpenDirectory) on have /opt/local/bin/bash installed, the Unix way would be to add /opt/local/bin/bash to the list of shells in /etc/shells (if that file doesn't exist, it's as if it existed with just /bin/sh and /bin/csh, one per line), and edit your account so that your login shell was /opt/local/bin/bash. The one gotcha when reinstalling MacPorts after an OS upgrade, (actually, just before the OS upgrade) you'd have to edit your account again to use an OS supplied shell that will be there throughout the MacPorts reinstall, and change it back when done. If your account info is just in local files, you can probably use the chsh command rather than the Directory Editor app to change your shell, but it still needs to be in /etc/shells. FYI, my /etc/shells contains /bin/bash /bin/csh /bin/ksh /bin/sh /bin/tcsh /bin/zsh You cannot add --login to your line in .bash_profile, because that would loop (you're already reading .bash_profile, so you exec a login shell which reads it again, exec's again, etc). Maybe there's some other tricky thing you could do with your own files that might work; perhaps if it were the last line in .bash_profile, and looked like [ -x /opt/local/bin/bash ] && exec -a -bash /opt/local/bin/bash --noprofile that _might_ work (it would look like a login shell with $0 set to -bash, but not actually run the profile files again), but I'm not going to make all those changes (I use /bin/ksh as my login shell), log out, log back in to test, and then reverse all that, just to find out if it works. If the only way you run interactive shells where you really want /opt/local/bin/bash is with Terminal, you can change its settings to use that as your shell, only for what's run under Terminal (won't affect xterm, ssh, etc). Those are the only sorts of ways I can see around whatever problem that line is causing you, while still running the shell of your choice. > On Jan 21, 2019, at 05:41, Pierre Malard wrote: > > Hi, a great thanks! > > You were right, it was my specific configuration which was in cause, even if > it was not a DISPLAY error. > > After a long wile and successives tests I found why it doesn’t work :-) > > First, I found that was the « —login » parameter of X11 script which was in > cause. If I launch X11 without it, it works. In piratical: > 1- the « exec -l /bin/bash --login -c 'exec > /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin' - > /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin » of X11 script won’t > work. > 2- An « exec -l /bin/bash -c 'exec > /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin' - > /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin » world fine. > It’s the same thing with XQuartz. > > The explanation now: > As I have a BASH v4.3 installed with MacPort, I would use it in my « > Terminal.app » sessions and I just add this line in my « ~/.bash_profile » > file: > [ -x /opt/local/bin/bash ] && exec /opt/local/bin/bash > to launch BASH v4.3. I remove it and everything work with X11… > > As it is evident now, this « exec » line trouble opening X11 with the other « > exec —login ». As explain in the « man bash »: > When bash is invoked as an interactive login shell, or as a > non-interactive shell with > the --login option, it first reads and executes commands from the file > /etc/profile, if > that file exists. After reading that file, it looks for > ~/.bash_profile, > ~/.bash_login, and ~/.profile, in that order, and reads and executes > commands from the > first one that exists and is readable. > So, my « ~/.bash_profile » were read with the first call, not with the second > one. > > It’s a great new for me but I have a subsidiary question: > « How can I use the MacPort BASH in place of Apple one? » > > If you have a solution… > > > Le 19 janv. 2019 à 12:03, Christopher Jones a > écrit : >> >> The logs below indicate problems with DISPLAY. They also suggest you have >> some residual parts of the non-macports Xquartz installed. >> >> Do you set DISPLAY at all in any of your shell login scripts. If so remove >> this. Try creating a new test user on your system, log in as that and see if >> it works from there. If so it would indicate something in your user >> environment. >> >> Make sure you have all parts of the other Xquartz removed. In particlar make >> sure all the plist entries under Library are removed. >> >> cheers Chris >> >>> On 19 Jan 2019, at 10:58 am, Pierre Malard wrote: >>> >>> Thanks again, >>> >>> There is no crash but here are the only logs I found. I don’t understand >>> why it doesn’t work. The log file « ~/Library/Logs/X11/org.macports.log » >>> is generate when I launch X11.bin directly on a Terminal. When I try to >>> open App, there is nothing neither logs. >>> However, I have the same trouble on
Re: Anyone running X11 apps on Mojave? [Solved]
Hi, a great thanks!
You were right, it was my specific configuration which was in cause, even if it
was not a DISPLAY error.
After a long wile and successives tests I found why it doesn’t work :-)
First, I found that was the « —login » parameter of X11 script which was in
cause. If I launch X11 without it, it works. In piratical:
1- the « exec -l /bin/bash --login -c 'exec
/Applications/MacPorts/X11.app/Contents/MacOS/X11.bin' -
/Applications/MacPorts/X11.app/Contents/MacOS/X11.bin » of X11 script won’t
work.
2- An « exec -l /bin/bash -c 'exec
/Applications/MacPorts/X11.app/Contents/MacOS/X11.bin' -
/Applications/MacPorts/X11.app/Contents/MacOS/X11.bin » world fine.
It’s the same thing with XQuartz.
The explanation now:
As I have a BASH v4.3 installed with MacPort, I would use it in my «
Terminal.app » sessions and I just add this line in my « ~/.bash_profile » file:
[ -x /opt/local/bin/bash ] && exec /opt/local/bin/bash
to launch BASH v4.3. I remove it and everything work with X11…
As it is evident now, this « exec » line trouble opening X11 with the other «
exec —login ». As explain in the « man bash »:
When bash is invoked as an interactive login shell, or as a
non-interactive shell with
the --login option, it first reads and executes commands from the file
/etc/profile, if
that file exists. After reading that file, it looks for
~/.bash_profile,
~/.bash_login, and ~/.profile, in that order, and reads and executes
commands from the
first one that exists and is readable.
So, my « ~/.bash_profile » were read with the first call, not with the second
one.
It’s a great new for me but I have a subsidiary question:
« How can I use the MacPort BASH in place of Apple one? »
If you have a solution…
Le 19 janv. 2019 à 12:03, Christopher Jones a écrit :
>
> The logs below indicate problems with DISPLAY. They also suggest you have
> some residual parts of the non-macports Xquartz installed.
>
> Do you set DISPLAY at all in any of your shell login scripts. If so remove
> this. Try creating a new test user on your system, log in as that and see if
> it works from there. If so it would indicate something in your user
> environment.
>
> Make sure you have all parts of the other Xquartz removed. In particlar make
> sure all the plist entries under Library are removed.
>
> cheers Chris
>
>> On 19 Jan 2019, at 10:58 am, Pierre Malard wrote:
>>
>> Thanks again,
>>
>> There is no crash but here are the only logs I found. I don’t understand why
>> it doesn’t work. The log file « ~/Library/Logs/X11/org.macports.log » is
>> generate when I launch X11.bin directly on a Terminal. When I try to open
>> App, there is nothing neither logs.
>> However, I have the same trouble on all my Mac on Mojave. Is it a new «
>> security » mesure from Apple?
>>
>> piotr@Rascasse:~/Library/Logs/X11$ cat org.macosforge.xquartz.log
>> X11.app: DISPLAY does not look like a launchd set variable, unsetting.
>> X11.app: main(): argc=1
>> argv[0] = /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin
>> Waiting for startup parameters via Mach IPC.
>> X11.app: No launchd socket handed off, unsetting DISPLAY
>> X11.app: do_start_x11_server(): argc=7
>> argv[0] = /opt/X11/bin/X
>> argv[1] = :0
>> argv[2] = -listen
>> argv[3] = tcp
>> argv[4] = -iglx
>> argv[5] = -auth
>> argv[6] = /Users/piotr/.serverauth.38793
>> [1706135.851] Xquartz starting:
>> [1706135.851] X.Org X Server 1.18.4
>> [1706135.851] Build Date: 20161025
>> [1706135.870] x: 0, y: 0, w: 2560, h: 1418
>> [1706135.883] (II) GLX: Initialized Core OpenGL GL provider for screen 0
>> [1706135.965] X11.app: DarwinProcessFDAdditionQueue_thread: Sleeping to
>> allow xinitrc to catchup.
>> [1706135.982] (EE) Error loading keymap /tmp/server-0.xkm
>> [1706135.982] (EE) XKB: Failed to load keymap. Loading default keymap
>> instead.
>> [1706137.861] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
>> [1706160.556] (II) Server terminated successfully (0). Closing log file.
>>
>>
>>
>> piotr@Rascasse:~/Library/Logs/X11$ cat org.macports.log
>> X11.app: DISPLAY
>> ("/private/tmp/com.apple.launchd.SKs4xIJJVq/org.macosforge.xquartz:0") does
>> not match our id ("org.macports"), unsetting.
>> X11.app: main(): argc=2
>> argv[0] = /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin
>> argv[1] = -psn_0_340051
>> Waiting for startup parameters via Mach IPC.
>> X11.app: No launchd socket handed off, unsetting DISPLAY
>> X11.app: do_start_x11_server(): argc=7
>> argv[0] = /opt/local/bin/Xquartz
>> argv[1] = :0
>> argv[2] = -nolisten
>> argv[3] = tcp
>> argv[4] = -iglx
>> argv[5] = -auth
>> argv[6] = /Users/piotr/.serverauth.1026
>> [ 227.231] Xquartz starting:
>> [ 227.231] X.Org X Server 1.18.4
>> [ 227.231] Build Date: 20180831
>> [ 227.238] x: 0, y: 0, w: 2560, h: 1418
>> [ 227.303] (II) GLX:
