<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Wed, 13 Apr 2022 at 15:19, Siep Kroonenberg <<a href="mailto:siepo@bitmuis.nl">siepo@bitmuis.nl</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Apr 13, 2022 at 05:19:19PM +0200, Bruno Voisin wrote:<br>
> Reinhard Kotucha wrote:<br>
> <br>
> > Is it difficult to install Bash on the systems you mentioned?  Are<br>
> > there package managers available which allow installation of free<br>
> > software as easily as on Linux?<br>
> <br>
> bash is still part of macOS, and at the expected location. Here on<br>
> the very latest beta (macOS Monterey 12.4 Beta):<br>
> <br>
>       % which bash /bin/bash<br>
> <br>
> But it is no longer the default shell (zsh is). I have read that<br>
> bash might be removed at some point, but could not found any<br>
> official Apple statement about this.<br>
> <br>
> Apparently, it all comes down to a license issue.<br>
> <<a href="https://dev.to/bphogan/use-modern-bash-shell-on-macos-22a6" rel="noreferrer" target="_blank">https://dev.to/bphogan/use-modern-bash-shell-on-macos-22a6</a>><br>
> writes<br>
> <br>
> "macOS ships with an older version of the Bash shell, because<br>
> newer versions use a license that makes it more difficult for<br>
> Apple to integrate into their OS. In macOS Catalina, Apple changed<br>
> the default shell to ZSH for this reason."<br>
> <br>
> and mention the older version as 3.2.57(1)-release. Indeed, on<br>
> macOS 12.4 Beta,<br>
> <br>
>       % bash --version GNU bash, version 3.2.57(1)-release<br>
>       (arm64-apple-darwin21) Copyright (C) 2007 Free Software<br>
>       Foundation, Inc.<br></blockquote><div><br></div><div>Around 2014, IT required my group to replace Apple bash with a </div><div>version that had current security patches for the shellshock bug.  </div><div>I think many organizations replace Apple's bash with a current </div><div>version.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> More worrying for the future is the planned removal of scripting<br>
> languages. Python was removed in macOS 12.3, which forced TeX Live<br>
> Utility (the Mac GUI to tlmgr, and more), largely written in<br>
> Python, to embed a Python framework.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> <br>
> Next in line are Perl and Tcl. Right now you get:<br>
> <br>
>       % tclsh > <br>
>       WARNING: This version of tcl is included in macOS for<br>
>       compatibility with legacy software.  In future versions of macOS<br>
>       the tcl runtime will not be available by default, and may require<br>
>       you to install an additional package.<br>
> <br>
> and<br>
> <br>
>       % perl -de1<br>
> <br>
>       WARNING: This version of perl is included in macOS for<br>
>       compatibility with legacy software.  In future versions of macOS<br>
>       the perl runtime will not be available by default, and may<br>
>       require you to install an additional package.<br>
> <br>
> So the countdown has started already for those two!<br>
> <br>
> There is a nice pre-built macOS Python package at<br>
> <<a href="https://www.python.org" rel="noreferrer" target="_blank">https://www.python.org</a>>, but no such thing for Tcl at<br>
> <<a href="https://www.tcl.tk" rel="noreferrer" target="_blank">https://www.tcl.tk</a>> nor Perl at <<a href="https://www.perl.org" rel="noreferrer" target="_blank">https://www.perl.org</a>>.<br>
></blockquote><div><div><br></div><div>I think Apple wants to keep ordinary users away from the command</div><div>line altogether.  They had a nice Developer document for </div><div>command-line usage, but last time I looked it was marked </div><div>"deprecated".   In it. Apple says 3rd party python should be invoked </div><div>using the full pathname to avoid issues with the PATH setting and </div><div>potential conflicts with system scripts that use Python.  </div><div><br></div><div>Should TeX Live install Python with a locked-down configuration or </div><div>allow users to add packages (some TeX uses may require packages</div><div>beyond what you get with a basic install).?</div><div><br></div><div>With 3rd party tools there will be issues with users who</div><div>have some failed or corrupt installation, so you you need </div><div>some basic tests to ensure that the required tools are</div><div>available and in working order.</div><div><br></div><div>Linux has the unique advantage that widely used tools</div><div>(Python, ghostscript, Perl, tcl, fontconfig, etc. are available </div><div>as distro packages, can generally be assumed to work and</div><div>have lots of optional extras).   For the other OS's you need</div><div>to figure out where to get tools and how to verify that they</div><div>actually work.  You don't have conventions on where things</div><div>get installed and how to deal with multiple installations.</div><div>Windows systems often end up with multiple Python </div><div>programs.   On my work laptop Python.org's Python is</div><div>installed using Software Center and AppStore is disabled.</div><div>Python is added to the System PATH so has priority over the</div><div>User PATH setting.</div><div><br></div><div>Users outside enterprise environments get the same Python </div><div>from the AppStore configured with an amazing web of links, </div><div>most of which can't be used to run python scripts from a command-line.</div><div>Maybe you are supposed to use the 'py -N.N' mechanism.</div><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> The approach used in TeX Live for Windows<br>
> <<a href="https://tug.org/texlive/windows.html" rel="noreferrer" target="_blank">https://tug.org/texlive/windows.html</a>>, namely provide minimal<br>
> Perl and Tcl setups inside TeX Live, in a way that does not affect<br>
> PATH, seems promising.<br>
></blockquote><div><br></div><div>These minimal packages cause confusion when a TL user needs</div><div>more than the minimal configuration.   There can also be issues on </div><div>corporate/enterprise systems where IT requires removal of tool versions</div><div>with known security problems.   I think it better for TL to focus on</div><div>sanity check for the available tools at install time, and a list of recommended</div><div>sources for packages that get timely security updates.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
> Being part of the MacTeX team, I looked rapidly through the TeX<br>
> Live source, to find info on how these setups are created (ie<br>
> which perl and tcl packages are selected -- for example are<br>
> LWP::UserAgent and Mozilla::CA included for Perl --, how they are<br>
> built, how they are installed), to prepare for the future, see<br>
> whether/how the approach could be adapted to macOS. But I couldn't<br>
> find anything. Does anybody here know about this?<br>
<br>
Windows versions of perl, of required perl modules and of Tcl/Tk are<br>
built separately. This is explained in<br>
<TLroot>/source/tlperl/tlperl.README and<br>
<TLroot>/source/tlgui/tltcl/tltcl.README.<br></blockquote><div><br></div><div>Anaconda.org provides python in miniconda3 for macOS, Windows, and linux</div><div><a href="https://anaconda.org/intel/tcl">Tcl :: Anaconda.org</a> supports macOS, Windows, and linux.  A drawback to </div><div>Anaconda is that it requires the user to activate the environment, but this </div><div>does get around the problem of a Python directory in the System PATH, so</div><div>may be the best option to minimize confusion for users who have other versions </div><div>of the tools installed.</div><div><br></div><div>For windows, Msys64 provides a fairly robust set of tools (including Python, tcl, and</div><div>perl) managed using pacman.  The R-Project is using a customized version of </div><div><a href="https://mxe.cc/">MXE (M cross environment)</a>, and also provides Windows "packages" Rtools40 and </div><div>RTools42).</div><div><br></div><div><br></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>George N. White III<br><br></div></div></div></div></div></div></div></div></div>