とてもニッチな話で申し訳ありません。
拙作のUpTeX.appはtlmgrの簡単なGUIを付けてありますが、これはobjective-cのpipeでtlmgrを叩いて動かしてます。その際、ただフルパスで実行すると従属するプロセスにパスが渡せずにコケるので、hoge/TEX/texbinの場所をhogehogeとして取得して
/bin/bash -c export PATH=hogehoge:$PATH ; tlmgr hogehogehoge
のようなかたちでパイプに渡してます（macOSのアプリは個々のユーザーが.bash_profileなどで設定したパスは参照してくれません）。これでずっと問題なく動いていたのですが、一週間ほど前から
TLPDB::_install_package: unsupported container format xz (or lz4)
というエラーが出て、update, install, restoreがコケるようになりました。tlmgr自身が用意しているxz,lz4を探すのに失敗しているようなのです。当たり前ですがターミナルでの実行では問題ないので、UpTeX.appで従属するプロセスに、xz, lz4を探すのに使われている記述に必要なパスを渡すのに失敗しているのだろうと思われます（ダウンロードはできて展開で失敗するのでwgetは探せてる？）。それにまつわるtlmgr側の挙動に何か変更があったのだと思いますが、対応を試行錯誤しているものの、うまくいっておりません。何かヒントになるようなことがありましたら、ご教示いただけると幸いです。
なお、その部分のソースファイルを添付しておきます。
ひとまず回避できましたが、若干問題が残ってます。
macでは
https://texwiki.texjp.org/?TeX%20Live%2FMac
にもあるように、tlmgr実行で不要なXcodeのインストールを要求される問題があるので、tlmgrの冒頭にCC=:を加えて実行させてました。
#!/bin/sh
PATH=$1:$PATH
export PATH
cd ~/
bash -c "CC=: tlmgr $2"
のようなシェルスクリプトをターミナルで$2にinstall hogeなどを与えて実行させてみたら、件のエラーが出ます。単にtlmgr $2だとエラーになりません。UpTeX.app内でも、NSpipeに与えるコマンド文字列からCC=:を削除したら、正常に動作するようになりました。
なお、単純にターミナルで直接実行しても
MagnaPalace:~ danna$ bash -c "CC=: tlmgr install 12many"
tlmgr: package repositories
main = http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet/ (not verified: gpg unavailable)
tlcontrib = http://contrib.texlive.info/current (not verified: gpg unavailable)
[1/1, ??:??/??:??] install: 12many @main [3k]
TLPDB::_install_package: unsupported container format xz
tlmgr: package log updated: /Applications/UpTeX.app/Contents/Resources/TEX/2019/texmf-var/web2c/tlmgr.log
のような結果になりました。
が、Xcode要求問題は解消したんでしたっけ？（Xcodeを入れてない環境が手元にないので、自分ですぐには確認できないです。）もし解消してないんだと、UpTeX.app固有ではなくターミナルでの実行でも双方の回避策が両立しなくなりませんでしょうか。
macでは
https://texwiki.texjp.org/?TeX%20Live%2FMac
にもあるように、tlmgr実行で不要なXcodeのインストールを要求される問題があるので、tlmgrの冒頭にCC=:を加えて実行させてました。
#!/bin/sh
PATH=$1:$PATH
export PATH
cd ~/
bash -c "CC=: tlmgr $2"
のようなシェルスクリプトをターミナルで$2にinstall hogeなどを与えて実行させてみたら、件のエラーが出ます。単にtlmgr $2だとエラーになりません。UpTeX.app内でも、NSpipeに与えるコマンド文字列からCC=:を削除したら、正常に動作するようになりました。
なお、単純にターミナルで直接実行しても
MagnaPalace:~ danna$ bash -c "CC=: tlmgr install 12many"
tlmgr: package repositories
main = http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet/ (not verified: gpg unavailable)
tlcontrib = http://contrib.texlive.info/current (not verified: gpg unavailable)
[1/1, ??:??/??:??] install: 12many @main [3k]
TLPDB::_install_package: unsupported container format xz
tlmgr: package log updated: /Applications/UpTeX.app/Contents/Resources/TEX/2019/texmf-var/web2c/tlmgr.log
のような結果になりました。
が、Xcode要求問題は解消したんでしたっけ？（Xcodeを入れてない環境が手元にないので、自分ですぐには確認できないです。）もし解消してないんだと、UpTeX.app固有ではなくターミナルでの実行でも双方の回避策が両立しなくなりませんでしょうか。
まず、xcode 要求問題は不明ですのでパス。
うまくいったり、いかなかったりと不安定なようなので確認のための質問です。
tlmgr のperl スクリプトをちら見するとダウンロードはwget か curl を、圧縮ファイルの伸張は lz4 か xz を使うように見えるのですが、 curl は /usr/bin にバンドルされたものがあるのでダウンロード自体はうまくゆくのは理解できます。
なので質問です。
ターミナルで which -a wget curl lz4 xz の各コマンドの先頭のパスは /etc/paths や /etc/paths.d/* のファイルに記述されていますか？
UpTeX.app でそれを考慮してあげないと、開発者（ターミナルで実行なども含む）のPATHが異なってxz 関連でエラーになるのでは？
/etc/profile や man path_helper を参考にしてください。
tlpkg/installer/ に置かれているものは texlive インストール時だけだとは思うのですが...texlive 2018 vs 2019 でtlmgr 関連の perlスクリプトを比較検討しています。
T2018=/usr/local/texlive/2018
T2019=/usr/local/texlive/2019
diff -u $T2018/bin/x86_64-darwin/tlmgr $T2019/bin/x86_64-darwin/tlmgr
diff -r -u $T2018/tlpkg/TeXLive/ $T2019/tlpkg/TeXLive/
# tlmgr のシェバンが #!/usr/bin/env perl なのでperl のバージョンの差も考えられるけど今回はその可能性はないかと判断しています。
＃添付する tlmgr のダミーラッパーシェルで一時的に置き換えてみるとUpTex.app で PATH の変数とかの情報が得られます。よろしければどうぞ。chmod +x をお忘れなく。
うまくいったり、いかなかったりと不安定なようなので確認のための質問です。
tlmgr のperl スクリプトをちら見するとダウンロードはwget か curl を、圧縮ファイルの伸張は lz4 か xz を使うように見えるのですが、 curl は /usr/bin にバンドルされたものがあるのでダウンロード自体はうまくゆくのは理解できます。
なので質問です。
ターミナルで which -a wget curl lz4 xz の各コマンドの先頭のパスは /etc/paths や /etc/paths.d/* のファイルに記述されていますか？
UpTeX.app でそれを考慮してあげないと、開発者（ターミナルで実行なども含む）のPATHが異なってxz 関連でエラーになるのでは？
/etc/profile や man path_helper を参考にしてください。
tlpkg/installer/ に置かれているものは texlive インストール時だけだとは思うのですが...texlive 2018 vs 2019 でtlmgr 関連の perlスクリプトを比較検討しています。
T2018=/usr/local/texlive/2018
T2019=/usr/local/texlive/2019
diff -u $T2018/bin/x86_64-darwin/tlmgr $T2019/bin/x86_64-darwin/tlmgr
diff -r -u $T2018/tlpkg/TeXLive/ $T2019/tlpkg/TeXLive/
# tlmgr のシェバンが #!/usr/bin/env perl なのでperl のバージョンの差も考えられるけど今回はその可能性はないかと判断しています。
＃添付する tlmgr のダミーラッパーシェルで一時的に置き換えてみるとUpTex.app で PATH の変数とかの情報が得られます。よろしければどうぞ。chmod +x をお忘れなく。
lz4 という圧縮・伸張プログラムはhomebrew でもインストールしていないのに tlmgr update したときにバックアップされるディレクトリをみたら拡張子は lz4 になっている。
ということは tlpkg/installer/lz4.x86_64-darwin が使われているようですね。
それを踏まえて2018 vs 2019 を比較すると tlpkg/TeXLive/TLConfig.pm で伸長時のオプションを変えていますね。
diff -r -u $T2018/tlpkg/TeXLive/TLConfig.pm $T2019/tlpkg/TeXLive/TLConfig.pm
......
@@ -127,7 +127,7 @@
our %Compressors = (
"lz4" => {
"decompress_args" => ["-dcf"],
- "compress_args" => ["-zfmq", "--rm"],
+ "compress_args" => ["-zfmq"],
"extension" => "lz4",
"priority" => 10,
},
ちなみに
--rm : remove source file(s) after successful de/compression
なのですが、修正されたのは今年3/1 なので、申立のあったここ数日というのとどう関係するかも含め明日調べます。
ということは tlpkg/installer/lz4.x86_64-darwin が使われているようですね。
それを踏まえて2018 vs 2019 を比較すると tlpkg/TeXLive/TLConfig.pm で伸長時のオプションを変えていますね。
diff -r -u $T2018/tlpkg/TeXLive/TLConfig.pm $T2019/tlpkg/TeXLive/TLConfig.pm
......
@@ -127,7 +127,7 @@
our %Compressors = (
"lz4" => {
"decompress_args" => ["-dcf"],
- "compress_args" => ["-zfmq", "--rm"],
+ "compress_args" => ["-zfmq"],
"extension" => "lz4",
"priority" => 10,
},
ちなみに
--rm : remove source file(s) after successful de/compression
なのですが、修正されたのは今年3/1 なので、申立のあったここ数日というのとどう関係するかも含め明日調べます。
中間報告
まずお詫び二点
■お詫び1 ... 添付したダミーラッパーtlmgr で gnused 使っていたのでゴミが出ます。
■お詫び2 ... TLConfig.pm の "--rm" が削除されているのは圧縮時用なので問題なしなので 2019年 07月 15日(月曜日) 00:54 投稿内容は無視してください。
さて、UpTex.app でtlmgr を利用すると（インストールシて起動後アップデート設定し、再起動すると）たしかに報告のあった障害が出ますね。
他にも関連のファイルが更新されているのですが、これから外出しなければならないので、詳しくは調べれません。夕方以降になりますがtlmgr はperl なのでデバッガーで調べれそうです。
まずお詫び二点
■お詫び1 ... 添付したダミーラッパーtlmgr で gnused 使っていたのでゴミが出ます。
■お詫び2 ... TLConfig.pm の "--rm" が削除されているのは圧縮時用なので問題なしなので 2019年 07月 15日(月曜日) 00:54 投稿内容は無視してください。
さて、UpTex.app でtlmgr を利用すると（インストールシて起動後アップデート設定し、再起動すると）たしかに報告のあった障害が出ますね。
他にも関連のファイルが更新されているのですが、これから外出しなければならないので、詳しくは調べれません。夕方以降になりますがtlmgr はperl なのでデバッガーで調べれそうです。
和田様
ありがとうございます。
確認した環境は二つです。
a.macbook 2015：OSのメジャーアップデートをくり返し、かなりグチャグチャな環境
b.iMac 27inch 2019：最近更新されたばかりの研究室資材。クリーンな状態から環境を整えたもの
どちらにもXcode, homebrewが入ってます。
which -a wget curl lz4 xzの結果
どちらも
/usr/bin/curl
/etc/pathsの記述はどちらも
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
/etc/paths.d/*は、bの方は空。aの方は、昔試験的に入れたTeXLiveが作ったと思しき"TeX"が/Library/TeX/texbinに、Xquartzの"40-XQuartz"が/opt/X11/binにパスを通してます。
.bash_profileでは追加で/Applications/UpTeX.app/Contents/Resources/TEX/texbinにパスを通してますが、UpTeX.appのテスト時には、これは消しています。
どうも現象としてはやはり、"CC=:"付で実行するとwget.x86_64-darwinは探せるけどlz4.x86_64-darwinとxz.x86_64-darwinは探せなくなってるようです。
ありがとうございます。
確認した環境は二つです。
a.macbook 2015：OSのメジャーアップデートをくり返し、かなりグチャグチャな環境
b.iMac 27inch 2019：最近更新されたばかりの研究室資材。クリーンな状態から環境を整えたもの
どちらにもXcode, homebrewが入ってます。
which -a wget curl lz4 xzの結果
どちらも
/usr/bin/curl
/etc/pathsの記述はどちらも
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
/etc/paths.d/*は、bの方は空。aの方は、昔試験的に入れたTeXLiveが作ったと思しき"TeX"が/Library/TeX/texbinに、Xquartzの"40-XQuartz"が/opt/X11/binにパスを通してます。
.bash_profileでは追加で/Applications/UpTeX.app/Contents/Resources/TEX/texbinにパスを通してますが、UpTeX.appのテスト時には、これは消しています。
どうも現象としてはやはり、"CC=:"付で実行するとwget.x86_64-darwinは探せるけどlz4.x86_64-darwinとxz.x86_64-darwinは探せなくなってるようです。
BasicTeXを入れて、そちらで追試してみました。
MagnaPalace:~ danna$ which tlmgr
/Library/TeX/texbin/tlmgr
MagnaPalace:~ danna$ sudo bash -c "CC=: tlmgr install 12many"
tlmgr: package repository http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet (not verified: gpg unavailable)
[1/1, ??:??/??:??] install: 12many [3k]
TLPDB::_install_package: unsupported container format xz
tlmgr: package log updated: /usr/local/texlive/2019basic/texmf-var/web2c/tlmgr.log
MagnaPalace:~ danna$ sudo tlmgr install 12many
tlmgr: package repository http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet (not verified: gpg unavailable)
[1/1, ??:??/??:??] install: 12many [3k]
running mktexlsr ...
done running mktexlsr.
tlmgr: package log updated: /usr/local/texlive/2019basic/texmf-var/web2c/tlmgr.log
と、やはり"CC=:"を付けると同じコケ方をしますので、UpTeX.app（に内蔵のTeXLiveサブセット）固有ではなく、TeXLive一般で起こる問題のようです。
MagnaPalace:~ danna$ which tlmgr
/Library/TeX/texbin/tlmgr
MagnaPalace:~ danna$ sudo bash -c "CC=: tlmgr install 12many"
tlmgr: package repository http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet (not verified: gpg unavailable)
[1/1, ??:??/??:??] install: 12many [3k]
TLPDB::_install_package: unsupported container format xz
tlmgr: package log updated: /usr/local/texlive/2019basic/texmf-var/web2c/tlmgr.log
MagnaPalace:~ danna$ sudo tlmgr install 12many
tlmgr: package repository http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet (not verified: gpg unavailable)
[1/1, ??:??/??:??] install: 12many [3k]
running mktexlsr ...
done running mktexlsr.
tlmgr: package log updated: /usr/local/texlive/2019basic/texmf-var/web2c/tlmgr.log
と、やはり"CC=:"を付けると同じコケ方をしますので、UpTeX.app（に内蔵のTeXLiveサブセット）固有ではなく、TeXLive一般で起こる問題のようです。
旧いmacbook airがあるので、アップデート可能な上限のHigh sierraでクリーンな環境をつくって、Xcodeは入れずにBasicTeXでの追試をしてみました。やはりXcodeはBasicTeXのインストーラが動いている段階から要求されました。それを無視してインストールを終えて、tlmgrを動かしてみましたが、この環境では"CC=:"付でも正常動作でした。UpTeX.appも正常動作です。
Mojaveと最近のtlmgrとの間の問題であることまで絞れましたが、MojaveでもXcodeが入ってないと挙動が違うかどうかまでは、にわかに環境が用意できず確かめられません。また、Sierraとかではどうかも未検証です。
Mojaveと最近のtlmgrとの間の問題であることまで絞れましたが、MojaveでもXcodeが入ってないと挙動が違うかどうかまでは、にわかに環境が用意できず確かめられません。また、Sierraとかではどうかも未検証です。
再度中間報告
【イイワケ】大量の複写コピー、差分確認のため git 化、試行錯誤でとても時間を要しています。 :-(
心配なので通常Net や ISOイメージからのインストールする形態環境も併せて調べていますが、今の所通常のほうは問題ないように思えます。
小川さんとは意見が違うようですが、texlibe.infra teexlive.infra.x86_64-darwin パッケージが更新されると UpTeX の場合のみ、それ以降 PATH にxz lz4 が含まれるパスリストがあろうがなかろうがtlmgr update/install は失敗します。バージョン情報は以下の通り。
texlive.infra (51232 -> 51561@main)
texlive.infra.x86_64-darwin (50203 -> 51563@main)
で、どのような変更か差分を調べると懸念されている xcode 関連のコードがtlpkg/installer/config.guess に以下のように追加されていますね。
- UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
- set_cc_for_build
- if test "$UNAME_PROCESSOR" = unknown ; then
- UNAME_PROCESSOR=powerpc
+ UNAME_PROCESSOR=`uname -p`
+ case $UNAME_PROCESSOR in
+ unknown) UNAME_PROCESSOR=powerpc ;;
+ esac
+ if command -v xcode-select > /dev/null 2> /dev/null && \
+ ! xcode-select --print-path > /dev/null 2> /dev/null ; then
+ # Avoid executing cc if there is no toolchain installed as
+ # cc will be a stub that puts up a graphical alert
+ CC_FOR_BUILD=no_compiler_found
+ else
+ set_cc_for_build
fi
なお「CC=:」は set_cc_for_build 内で評価され CC_FOR_BUILD にCC の値が入ります。このCC_FOR_BUILD はコンパイルを通してUNAME_PROCESSOR を決めるために使われます。現在 powerpc なmacOS を使っている人は恐らくいないので「:」でもよいですが 和田の意見としては CC=: は指定しないほうが良いように思います。
なぜUpTeX．app 環境だけがいまのところうまくいかない原因は今のところ不明。なにか構成ファイルが不足してるのかな？
＃とりあえず休憩を兼ねて休みます。
【イイワケ】大量の複写コピー、差分確認のため git 化、試行錯誤でとても時間を要しています。 :-(
心配なので通常Net や ISOイメージからのインストールする形態環境も併せて調べていますが、今の所通常のほうは問題ないように思えます。
小川さんとは意見が違うようですが、texlibe.infra teexlive.infra.x86_64-darwin パッケージが更新されると UpTeX の場合のみ、それ以降 PATH にxz lz4 が含まれるパスリストがあろうがなかろうがtlmgr update/install は失敗します。バージョン情報は以下の通り。
texlive.infra (51232 -> 51561@main)
texlive.infra.x86_64-darwin (50203 -> 51563@main)
で、どのような変更か差分を調べると懸念されている xcode 関連のコードがtlpkg/installer/config.guess に以下のように追加されていますね。
- UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
- set_cc_for_build
- if test "$UNAME_PROCESSOR" = unknown ; then
- UNAME_PROCESSOR=powerpc
+ UNAME_PROCESSOR=`uname -p`
+ case $UNAME_PROCESSOR in
+ unknown) UNAME_PROCESSOR=powerpc ;;
+ esac
+ if command -v xcode-select > /dev/null 2> /dev/null && \
+ ! xcode-select --print-path > /dev/null 2> /dev/null ; then
+ # Avoid executing cc if there is no toolchain installed as
+ # cc will be a stub that puts up a graphical alert
+ CC_FOR_BUILD=no_compiler_found
+ else
+ set_cc_for_build
fi
なお「CC=:」は set_cc_for_build 内で評価され CC_FOR_BUILD にCC の値が入ります。このCC_FOR_BUILD はコンパイルを通してUNAME_PROCESSOR を決めるために使われます。現在 powerpc なmacOS を使っている人は恐らくいないので「:」でもよいですが 和田の意見としては CC=: は指定しないほうが良いように思います。
なぜUpTeX．app 環境だけがいまのところうまくいかない原因は今のところ不明。なにか構成ファイルが不足してるのかな？
＃とりあえず休憩を兼ねて休みます。
お手数をおかけして申し訳ありません。
High SierraでXcodeインストール後の実行結果です。
Air:~ dboy$ which tlmgr
/Library/TeX/texbin/tlmgr
Air:~ dboy$ sudo bash -c "CC=: tlmgr install 12many"
query_ctan_mirror: Programs not set up, trying wget
cannot contact mirror.ctan.org, returning a backbone server!
tlmgr: package repository http://www.ctan.org/tex-archive/systems/texlive/tlnet (not verified: gpg unavailable)
[1/1, ??:??/??:??] install: 12many [3k]
TLPDB::_install_package: unsupported container format xz
tlmgr: package log updated: /usr/local/texlive/2019basic/texmf-var/web2c/tlmgr.log
Air:~ dboy$ sudo tlmgr install 12many
tlmgr: package repository http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet (not verified: gpg unavailable)
[1/1, ??:??/??:??] install: 12many [3k]
running mktexlsr ...
done running mktexlsr.
tlmgr: package log updated: /usr/local/texlive/2019basic/texmf-var/web2c/tlmgr.log
何も追加していない素のBasicTeXですので、何か必要なファイルが欠けているせいだとすると、UpTeX.appとの共通点がそこにあるかもしれません。こちらではひとまず原因追及よりも、UpTeX.appでCC=:の有無を選択できるオプションを環境設定に付け加えて、当座の対処を済ます作業中です。
High SierraでXcodeインストール後の実行結果です。
Air:~ dboy$ which tlmgr
/Library/TeX/texbin/tlmgr
Air:~ dboy$ sudo bash -c "CC=: tlmgr install 12many"
query_ctan_mirror: Programs not set up, trying wget
cannot contact mirror.ctan.org, returning a backbone server!
tlmgr: package repository http://www.ctan.org/tex-archive/systems/texlive/tlnet (not verified: gpg unavailable)
[1/1, ??:??/??:??] install: 12many [3k]
TLPDB::_install_package: unsupported container format xz
tlmgr: package log updated: /usr/local/texlive/2019basic/texmf-var/web2c/tlmgr.log
Air:~ dboy$ sudo tlmgr install 12many
tlmgr: package repository http://ftp.jaist.ac.jp/pub/CTAN/systems/texlive/tlnet (not verified: gpg unavailable)
[1/1, ??:??/??:??] install: 12many [3k]
running mktexlsr ...
done running mktexlsr.
tlmgr: package log updated: /usr/local/texlive/2019basic/texmf-var/web2c/tlmgr.log
何も追加していない素のBasicTeXですので、何か必要なファイルが欠けているせいだとすると、UpTeX.appとの共通点がそこにあるかもしれません。こちらではひとまず原因追及よりも、UpTeX.appでCC=:の有無を選択できるオプションを環境設定に付け加えて、当座の対処を済ます作業中です。
何も試していませんが，コメントです。
「CC=:」を付けるのは，
「Xcode 未インストールの環境で Xcode をインストールするよう要求されるのを避けるため」
ですね。
https://texwiki.texjp.org/?TeX%20Live%2FMac#xcode
このような要求が起こるのは，
https://tug.org/pipermail/tex-live/2013-October/034385.html
のとおり，
「TeX Live が今走っているプラットフォームを自動判定するために cc コマンドを使おうとするから」
です。
UpTeX.app の場合，そもそも macOS 向けアプリケーションなのですから，小川さんの仰る
> UpTeX.appでCC=:の有無を選択できるオプションを環境設定に付け加えて
よりも，自動判定させないようにプラットフォームを外から指定してやればいいような気がします。
（でもオプション名は忘れました…。）
原因について当てずっぽうですが，
「CC=:」の「:」は何もしないという意味の bash の組込コマンドですから，
「bash じゃなかったら動かない」とかが絡んでいないでしょうか？
「CC=:」を付けるのは，
「Xcode 未インストールの環境で Xcode をインストールするよう要求されるのを避けるため」
ですね。
https://texwiki.texjp.org/?TeX%20Live%2FMac#xcode
このような要求が起こるのは，
https://tug.org/pipermail/tex-live/2013-October/034385.html
のとおり，
「TeX Live が今走っているプラットフォームを自動判定するために cc コマンドを使おうとするから」
です。
UpTeX.app の場合，そもそも macOS 向けアプリケーションなのですから，小川さんの仰る
> UpTeX.appでCC=:の有無を選択できるオプションを環境設定に付け加えて
よりも，自動判定させないようにプラットフォームを外から指定してやればいいような気がします。
（でもオプション名は忘れました…。）
原因について当てずっぽうですが，
「CC=:」の「:」は何もしないという意味の bash の組込コマンドですから，
「bash じゃなかったら動かない」とかが絡んでいないでしょうか？
自己解決の方向にいっているようですが理由は完全には究明できていませんが別解です。
tlmgr update --list しても「リポジトリが云々カンヌン」とかその他いわれるので man tlmgr を参考に ftp://ftp.tug.org/texlive/tlnet/ となっていたリポジトリを
tlmgr option repository http://mirror.ctan.org/systems/texlive/tlnet
としたらうまく行くようになったので、可能かどうか試していただけると助かりいます。
＃ソースでリポジトリ設定のところを最近は上記一択で良いと思います。あちこち適当に見繕ってくれるので。
tlmgr update --list しても「リポジトリが云々カンヌン」とかその他いわれるので man tlmgr を参考に ftp://ftp.tug.org/texlive/tlnet/ となっていたリポジトリを
tlmgr option repository http://mirror.ctan.org/systems/texlive/tlnet
としたらうまく行くようになったので、可能かどうか試していただけると助かりいます。
＃ソースでリポジトリ設定のところを最近は上記一択で良いと思います。あちこち適当に見繕ってくれるので。
和田様・aminophen様
Mojaveのクリーンな環境をつくって、BasicTeXとUpTeX.appでの挙動をXcode/ComTools無し→ComTools有で調べてみました。
まず、リポジトリの選択は、挙動には影響がありませんでした。また挙動はBasicTeXとUpTeX.app共通で、Xcode/ComToolsがなければ"CC=:"付でも通り、どちらかを入れると通らなくなりました。
aminophenさんからご提案いただいたプラットフォームの指定（tlmgr platform set x86_64-darwin）ですが、ちょっと意外な結果でした。
残念ですが、これにはXcode/ComToolsのインストール要求抑止効果はありませんでした。一方で、指定しておくとXcode/ComToolsが入っていても"CC=:"付が通ります。
tlmgrのhelpには
Platform detection is needed to select the proper "xz" and "wget" binaries that are shipped with TeX Live.
とあります。Platform detectionの過程でccがどのように使われるのかは具体的に理解できてませんが、現象面からは次のように考えられます。プラットフォームが指定されていてもどうしてか、ccを探してしまうので、要求抑止はできない。一方、ccをみつけてプラットフォーム特定作業に入ってしまったとき、（前は"CC=:"になっていても何故か問題なかったのに）あるはずのccが何もしないことでxz,lz4を呼びだすことに失敗してしまう。けれどもプラットフォームが指定されていれば、特定作業がスキップされてccの出番がないので、このトラブルが起こらない（ccがなければ、そもそもスキップされる）。
なお、このトラブルもXcode要求問題もどちらもcc絡みで、xz,lz4の呼び出しに関わるものですから、どちらかを必要とする場合にのみ起こります。よって再現性が完全に100%ではないようです。
そういうわけで、対症療法的には
tlmgr platform set x86_64-darwinしておいて"CC=:"付を使う
が簡単ですが、あまり筋はよくないと思えます。Xcode/ComToolsとも問題のccは/usr/bin/ccでしょうから、その有無を判定して"CC=:"を使うか否か分岐させる方がマシでしょうか。
Mojaveのクリーンな環境をつくって、BasicTeXとUpTeX.appでの挙動をXcode/ComTools無し→ComTools有で調べてみました。
まず、リポジトリの選択は、挙動には影響がありませんでした。また挙動はBasicTeXとUpTeX.app共通で、Xcode/ComToolsがなければ"CC=:"付でも通り、どちらかを入れると通らなくなりました。
aminophenさんからご提案いただいたプラットフォームの指定（tlmgr platform set x86_64-darwin）ですが、ちょっと意外な結果でした。
残念ですが、これにはXcode/ComToolsのインストール要求抑止効果はありませんでした。一方で、指定しておくとXcode/ComToolsが入っていても"CC=:"付が通ります。
tlmgrのhelpには
Platform detection is needed to select the proper "xz" and "wget" binaries that are shipped with TeX Live.
とあります。Platform detectionの過程でccがどのように使われるのかは具体的に理解できてませんが、現象面からは次のように考えられます。プラットフォームが指定されていてもどうしてか、ccを探してしまうので、要求抑止はできない。一方、ccをみつけてプラットフォーム特定作業に入ってしまったとき、（前は"CC=:"になっていても何故か問題なかったのに）あるはずのccが何もしないことでxz,lz4を呼びだすことに失敗してしまう。けれどもプラットフォームが指定されていれば、特定作業がスキップされてccの出番がないので、このトラブルが起こらない（ccがなければ、そもそもスキップされる）。
なお、このトラブルもXcode要求問題もどちらもcc絡みで、xz,lz4の呼び出しに関わるものですから、どちらかを必要とする場合にのみ起こります。よって再現性が完全に100%ではないようです。
そういうわけで、対症療法的には
tlmgr platform set x86_64-darwinしておいて"CC=:"付を使う
が簡単ですが、あまり筋はよくないと思えます。Xcode/ComToolsとも問題のccは/usr/bin/ccでしょうから、その有無を判定して"CC=:"を使うか否か分岐させる方がマシでしょうか。
> プラットフォームの指定（tlmgr platform set x86_64-darwin）
> 残念ですが、これにはXcode/ComToolsのインストール要求抑止効果はありませんでした。
> 一方で、指定しておくとXcode/ComToolsが入っていても"CC=:"付が通ります。
意外です…。ということは，
> プラットフォームが指定されていてもどうしてか、ccを探してしまうので、要求抑止はできない
という挙動は改善の余地があるかもしれません。
tlmgr のメンテナのお一人であるノルベルトさんに聞いてみます。
> Xcode/ComToolsとも問題のccは/usr/bin/ccでしょうから、
> その有無を判定して"CC=:"を使うか否か分岐させる方がマシでしょうか。
「Xcode/ComTools が入っていない macOS」はよく知らないので，わかる方教えてください。
「Xcode/ComTools がインストールされていない時にインストール要求する」
という仕組みは，Apple はどうやって実現しているのでしょう。
「ダミーの /usr/bin/cc というプログラム」
が入っていて，cc を実行するとそれが起動するとか？
（もしそうなら「有無を判定」でなく「ダミーかどうか判定」にしないといけない？）
> 残念ですが、これにはXcode/ComToolsのインストール要求抑止効果はありませんでした。
> 一方で、指定しておくとXcode/ComToolsが入っていても"CC=:"付が通ります。
意外です…。ということは，
> プラットフォームが指定されていてもどうしてか、ccを探してしまうので、要求抑止はできない
という挙動は改善の余地があるかもしれません。
tlmgr のメンテナのお一人であるノルベルトさんに聞いてみます。
> Xcode/ComToolsとも問題のccは/usr/bin/ccでしょうから、
> その有無を判定して"CC=:"を使うか否か分岐させる方がマシでしょうか。
「Xcode/ComTools が入っていない macOS」はよく知らないので，わかる方教えてください。
「Xcode/ComTools がインストールされていない時にインストール要求する」
という仕組みは，Apple はどうやって実現しているのでしょう。
「ダミーの /usr/bin/cc というプログラム」
が入っていて，cc を実行するとそれが起動するとか？
（もしそうなら「有無を判定」でなく「ダミーかどうか判定」にしないといけない？）
手元でちょっと実験してみた感じでは，次のような挙動をしているようです。
/usr/bin/ccは/usr/bin/clangへのシンボリックリンク。- Command Line Tools をインストールする前から，
/usr/bin/ccや/usr/bin/clangのファイル自体は存在する。 /usr/bin/clangはフロントエンド。/Applications/Xcode.appや/Library/Developers/CommandLineToolsの中に clang の実体が存在するかどうかチェックし，存在すればそれを起動する。- どこにも clang の実体が見つからなければ，Command Line Tools のインストール要求ダイアログを出す。
- Command Line Tools をインストールすると，
/Library/Developers/CommandLineToolsの中に clang の実体がインストールされる。 - Command Line Tools のインストール前後で，
/usr/bin/clangのファイルそのものに変化はない。 /Applications/Xcode.appが存在する環境下では，そちらが呼び出されるため/Library/Developers/CommandLineToolsは存在しなくてよい。その環境下でもxcode-select --installによって/Library/Developers/CommandLineTools以下に clang を重複してインストールできる。
ご教示ありがとうございます。
私も開発環境なしの/usr/bin内に、ccやgccを見つけて面食らってました。/usr以下の各ディレクトリの中身も、ひとまずファイル数を比べると開発環境有とまるで変わっておらず、何がどう違うのか途方に暮れかかっていました。なるほどこの仕組み、Appleは徹底して/usrとかの中身を（localは例外として）いじらせたくなく、自分たちでも原則としてクリーンインストール時から変更しないというわけでしょうかね。
真っ当に開発環境の有無を判定しようとするなら、/Applications/Xcode.appと、/Library/Developers/CommandLineTools/usr/bin/clangあたりとの有無をチェックせねばなりませんね。あまりありそうではないけど、/Library/Developers/CommandLineToolsの判定で済ますと、その中身だけ手動で捨ててしまっているようなケースに対応できないし。
私も開発環境なしの/usr/bin内に、ccやgccを見つけて面食らってました。/usr以下の各ディレクトリの中身も、ひとまずファイル数を比べると開発環境有とまるで変わっておらず、何がどう違うのか途方に暮れかかっていました。なるほどこの仕組み、Appleは徹底して/usrとかの中身を（localは例外として）いじらせたくなく、自分たちでも原則としてクリーンインストール時から変更しないというわけでしょうかね。
真っ当に開発環境の有無を判定しようとするなら、/Applications/Xcode.appと、/Library/Developers/CommandLineTools/usr/bin/clangあたりとの有無をチェックせねばなりませんね。あまりありそうではないけど、/Library/Developers/CommandLineToolsの判定で済ますと、その中身だけ手動で捨ててしまっているようなケースに対応できないし。
あまりありそうではないけど、/Library/Developers/CommandLineToolsの判定で済ますと、その中身だけ手動で捨ててしまっているようなケースに対応できないし。
実際，OSをアップデートした直後には，/Library/Developers/CommandLineTools は存在するが中身の /Library/Developer/CommandLineTools/usr/bin は削除されている（/Library/Developer/CommandLineTools/usr/share/man は残っている），という状態になっているようです。
（ちなみに，Xcode.app 内の clang の実体は /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin 内に見つかります。）
ありがとうございます。xcode-select --print-pathの結果をみてみました。Xcode.appがあればそのなかを、Command Line Toolsだけがあればそれを返しますね。
もともとインストールされてない場合も、Xcode.appやCommand Line Toolsのフォルダを強引にゴミ箱に捨てて削除したような場合も、どちらも返り値はひとまずMojaveでもHigh Sierraでも
error: unable to get active developer directory, use `sudo xcode-select --switch path/to/Xcode.app` to set one (or see `man xcode-select`)
でした。この返り値をerrorという文字列を含むかどうかで判定することにします。
本来ならば、プラットフォームを指定しておけばtlmgrがCCをまったく呼ばないようになってくれて、開発環境があろうがなかろうが"CC=:"なしで処理するのがシンプルでしょうが、当面はこれで凌ぎます。
もともとインストールされてない場合も、Xcode.appやCommand Line Toolsのフォルダを強引にゴミ箱に捨てて削除したような場合も、どちらも返り値はひとまずMojaveでもHigh Sierraでも
error: unable to get active developer directory, use `sudo xcode-select --switch path/to/Xcode.app` to set one (or see `man xcode-select`)
でした。この返り値をerrorという文字列を含むかどうかで判定することにします。
本来ならば、プラットフォームを指定しておけばtlmgrがCCをまったく呼ばないようになってくれて、開発環境があろうがなかろうが"CC=:"なしで処理するのがシンプルでしょうが、当面はこれで凌ぎます。
古い話題の蒸し返しで恐縮です。macOSで開発環境が入ってないとtlmgr実行時にインストールを促される問題ですが、たまたま久しぶりに開発環境を入れない状態のセットアップをしてみたところ、解消したようです。TeXLive 2020になったときになんでしょうか。
逆に、Objective-CのPipeで
bash -c "hogehoge; hogehoge; CC=: tlmgr hoge; hogehoge"
なんてのを与えると、昨年の時点では問題なかったのですが、CC=:があることで？開発環境のインストールを求められてしまい、そこでPipe処理も終わってしまうという副作用が発生しました（CC=:のせいらしきことはtlmgrを含めCC=:の前後を削って確認）。ターミナルで同じことを実行しても（長いのはやってませんが）問題はありませんでした。
（以上はCatalinaとHigh Sierraで確認）
UpTeX.appでは、ひとまず分岐処理を廃止して開発環境があろうがなかろうがCC=:なしで処理するようにしましたが、開発環境なしでの挙動にはいろいろよくわからないところがあって煮詰め切れてません。
もしかしたら処理を細かく切ってやれば回避できるかもしれませんが、UpTeX.appでは付属のコンソールに過程を表示しながら連続して非同期処理をさせているので、一つ一つの処理の終了を確認してから次の処理をさせるのは面倒そうで避けました。
逆に、Objective-CのPipeで
bash -c "hogehoge; hogehoge; CC=: tlmgr hoge; hogehoge"
なんてのを与えると、昨年の時点では問題なかったのですが、CC=:があることで？開発環境のインストールを求められてしまい、そこでPipe処理も終わってしまうという副作用が発生しました（CC=:のせいらしきことはtlmgrを含めCC=:の前後を削って確認）。ターミナルで同じことを実行しても（長いのはやってませんが）問題はありませんでした。
（以上はCatalinaとHigh Sierraで確認）
UpTeX.appでは、ひとまず分岐処理を廃止して開発環境があろうがなかろうがCC=:なしで処理するようにしましたが、開発環境なしでの挙動にはいろいろよくわからないところがあって煮詰め切れてません。
もしかしたら処理を細かく切ってやれば回避できるかもしれませんが、UpTeX.appでは付属のコンソールに過程を表示しながら連続して非同期処理をさせているので、一つ一つの処理の終了を確認してから次の処理をさせるのは面倒そうで避けました。
tlpkg/installer/config.guessの1350行目以降に
if command -v xcode-select > /dev/null 2> /dev/null && \
! xcode-select --print-path > /dev/null 2> /dev/null ; then
# Avoid executing cc if there is no toolchain installed as
# cc will be a stub that puts up a graphical alert
# prompting the user to install developer tools.
CC_FOR_BUILD=no_compiler_found
else
set_cc_for_build
fi
という記述がありました。TXLive2020のtlmgrではxcode-select --print-pathで開発環境の有無を判定して、なければここでCC_FOR_BUILD=no_compiler_foundにしてしまうという処理を、tlmgr内でやってくれるようになっていました。ありがたいことです。
if command -v xcode-select > /dev/null 2> /dev/null && \
! xcode-select --print-path > /dev/null 2> /dev/null ; then
# Avoid executing cc if there is no toolchain installed as
# cc will be a stub that puts up a graphical alert
# prompting the user to install developer tools.
CC_FOR_BUILD=no_compiler_found
else
set_cc_for_build
fi
という記述がありました。TXLive2020のtlmgrではxcode-select --print-pathで開発環境の有無を判定して、なければここでCC_FOR_BUILD=no_compiler_foundにしてしまうという処理を、tlmgr内でやってくれるようになっていました。ありがたいことです。