Big Sur対応されたcjk-gs-integrate-macosの動作が当方では芳しくありません。
なお、tlmgr updateでは更新されず、またuninstall/installをしても新しいものが落ちてこないので、https://github.com/texjporg/cjk-gs-supportから直にcjk-gs-integrate-macos.plとcjk-gs-integrate.plを貰ってきて差し替えました。他のファイルは更新されていないようなので差し替えてません。
また、こちらではgsがないので--output=test付で、かつUpTeX.appに仕込んだものでの実行です。以上の条件が違えば動作も違うのかもしれません。
芳しくないというのは、旧cjk-gs-integrate-macosと新で明らかにシンボリックリンクは増える（Big Surでもcjkgs-macos-highsierra.datを読み込んだ動作をする）けれども、ヒラギノ和文フォントなどを拾ってくれていないというものです。
ひとまず手元での差分（新で拾ってくれるもの）は
OTF
HiraginoSansCNS.ttc
HiraginoSansGB.ttc
Klee.ttc
Kyokasho.ttc
ToppanBunkyuGothicPr6N.ttc
ToppanBunkyuMidashiGothicStdN-ExtraBold.otf
ToppanBunkyuMidashiMinchoStdN-ExtraBold.otf
ToppanBunkyuMinchoPr6N-Regular.otf
TsukushiAMaruGothic.ttc
TsukushiBMaruGothic.ttc
TTF
Yuanti.ttc
Libian.ttc
Baoli.ttc
Kaiti.ttc
Songti.ttc
Xingkai.ttc
です。試しにHigh Sierraのヒラギノ和文フォント群をコピーしてきてtexmf-dist/fonts/opentype以下にぶっ込んでみたりしても、やはり見つけてくれません。よってcjkgs-macos-highsierra.datに記すべきフォントの定義がBig Surのものでは変わってしまったとかでもなさそうで、ちょっと原因の検討をつけられないでいます。ヒラギノはフォントのファイル名が日本語であることはもしかしたら疑わしいかもしれません。
長くなりますし、自分で入れたフォントも混ざってますが、新・旧cjk-gs-integrate-macosを実行したフルの結果を、opentype/truetypeそれぞれのlsで列挙した結果です。比較すると成否の条件が何か絞り込めないでしょうか。
【旧】
ls /Users/danna/UpTeX.app/Contents/Resources/TEX/texmf-local/fonts/opentype/cjk-gs-integrate
AppleSDGothicNeo.ttc HaranoAjiMincho-Light.otf
Hannotate.ttc HaranoAjiMincho-Medium.otf
Hanzipen.ttc HaranoAjiMincho-Regular.otf
HaranoAjiGothic-Bold.otf HaranoAjiMincho-SemiBold.otf
HaranoAjiGothic-ExtraLight.otf LingWaiSC-Medium.otf
HaranoAjiGothic-Heavy.otf LingWaiTC-Medium.otf
HaranoAjiGothic-Light.otf PingFang.ttc
HaranoAjiGothic-Medium.otf WawaSC-Regular.otf
HaranoAjiGothic-Normal.otf WawaTC-Regular.otf
HaranoAjiGothic-Regular.otf YuGo-Bold.otf
HaranoAjiMincho-Bold.otf YuGo-Medium.otf
HaranoAjiMincho-ExtraLight.otf YuppySC-Regular.otf
HaranoAjiMincho-Heavy.otf YuppyTC-Regular.otf
ls /Users/danna/UpTeX.app/Contents/Resources/TEX/texmf-local/fonts/truetype/cjk-gs-integrate
AppleGothic.ttf LiSungLight.ttf bsmi00lp.ttf
AppleMyungjo.ttf NanumGothic.ttc gbsn00lp.ttf
Baekmuk-Batang.ttf NanumMyeongjo.ttc gkai00mp.ttf
Baekmuk-Dotum.ttf NanumScript.ttc ipaexg.ttf
Baekmuk-Gulim.ttf Osaka.ttf ipaexm.ttf
Baekmuk-Headline.ttf OsakaMono.ttf ipag.ttf
Gungseouche.ttf PCmyoungjo.ttf ipagp.ttf
HeadlineA.ttf Pilgiche.ttf ipam.ttf
Hei.ttf STFangsong.ttf ipamp.ttf
Kai.ttf STHeiti-Light.ttc kaiu.ttf
Lantinghei.ttc STHeiti-Medium.ttc msgothic.ttc
LiGothicMed.ttf STHeiti.ttf msmincho.ttc
LiHeiPro.ttf STXihei.ttf
LiSongPro.ttf bkai00mp.ttf
【新】
ls /Users/danna/UpTeX.app/Contents/Resources/TEX/texmf-local/fonts/opentype/cjk-gs-integrate
AppleSDGothicNeo.ttc
Hannotate.ttc
Hanzipen.ttc
HaranoAjiGothic-Bold.otf
HaranoAjiGothic-ExtraLight.otf
HaranoAjiGothic-Heavy.otf
HaranoAjiGothic-Light.otf
HaranoAjiGothic-Medium.otf
HaranoAjiGothic-Normal.otf
HaranoAjiGothic-Regular.otf
HaranoAjiMincho-Bold.otf
HaranoAjiMincho-ExtraLight.otf
HaranoAjiMincho-Heavy.otf
HaranoAjiMincho-Light.otf
HaranoAjiMincho-Medium.otf
HaranoAjiMincho-Regular.otf
HaranoAjiMincho-SemiBold.otf
HiraginoSansCNS.ttc
HiraginoSansGB.ttc
Klee.ttc
Kyokasho.ttc
LingWaiSC-Medium.otf
LingWaiTC-Medium.otf
PingFang.ttc
ToppanBunkyuGothicPr6N.ttc
ToppanBunkyuMidashiGothicStdN-ExtraBold.otf
ToppanBunkyuMidashiMinchoStdN-ExtraBold.otf
ToppanBunkyuMinchoPr6N-Regular.otf
TsukushiAMaruGothic.ttc
TsukushiBMaruGothic.ttc
WawaSC-Regular.otf
WawaTC-Regular.otf
WeibeiSC-Bold.otf
WeibeiTC-Bold.otf
YuGo-Bold.otf
YuGo-Medium.otf
YuMincho.ttc
YuppySC-Regular.otf
YuppyTC-Regular.otf
ls /Users/danna/UpTeX.app/Contents/Resources/TEX/texmf-local/fonts/truetype/cjk-gs-integrate
AppleGothic.ttf LiSungLight.ttf Yuanti.ttc
AppleMyungjo.ttf Libian.ttc bkai00mp.ttf
Baekmuk-Batang.ttf NanumGothic.ttc bsmi00lp.ttf
Baekmuk-Dotum.ttf NanumMyeongjo.ttc gbsn00lp.ttf
Baekmuk-Gulim.ttf NanumScript.ttc gkai00mp.ttf
Baekmuk-Headline.ttf Osaka.ttf ipaexg.ttf
Baoli.ttc OsakaMono.ttf ipaexm.ttf
Gungseouche.ttf PCmyoungjo.ttf ipag.ttf
HeadlineA.ttf Pilgiche.ttf ipagp.ttf
Hei.ttf STFangsong.ttf ipam.ttf
Kai.ttf STHeiti-Light.ttc ipamp.ttf
Kaiti.ttc STHeiti-Medium.ttc kaiu.ttf
Lantinghei.ttc STHeiti.ttf msgothic.ttc
LiGothicMed.ttf STXihei.ttf msmincho.ttc
LiHeiPro.ttf Songti.ttc
LiSongPro.ttf Xingkai.ttc
【旧】
ls /Users/danna/UpTeX.app/Contents/Resources/TEX/texmf-local/fonts/opentype/cjk-gs-integrate
AppleSDGothicNeo.ttc HaranoAjiMincho-Light.otf
Hannotate.ttc HaranoAjiMincho-Medium.otf
Hanzipen.ttc HaranoAjiMincho-Regular.otf
HaranoAjiGothic-Bold.otf HaranoAjiMincho-SemiBold.otf
HaranoAjiGothic-ExtraLight.otf LingWaiSC-Medium.otf
HaranoAjiGothic-Heavy.otf LingWaiTC-Medium.otf
HaranoAjiGothic-Light.otf PingFang.ttc
HaranoAjiGothic-Medium.otf WawaSC-Regular.otf
HaranoAjiGothic-Normal.otf WawaTC-Regular.otf
HaranoAjiGothic-Regular.otf YuGo-Bold.otf
HaranoAjiMincho-Bold.otf YuGo-Medium.otf
HaranoAjiMincho-ExtraLight.otf YuppySC-Regular.otf
HaranoAjiMincho-Heavy.otf YuppyTC-Regular.otf
ls /Users/danna/UpTeX.app/Contents/Resources/TEX/texmf-local/fonts/truetype/cjk-gs-integrate
AppleGothic.ttf LiSungLight.ttf bsmi00lp.ttf
AppleMyungjo.ttf NanumGothic.ttc gbsn00lp.ttf
Baekmuk-Batang.ttf NanumMyeongjo.ttc gkai00mp.ttf
Baekmuk-Dotum.ttf NanumScript.ttc ipaexg.ttf
Baekmuk-Gulim.ttf Osaka.ttf ipaexm.ttf
Baekmuk-Headline.ttf OsakaMono.ttf ipag.ttf
Gungseouche.ttf PCmyoungjo.ttf ipagp.ttf
HeadlineA.ttf Pilgiche.ttf ipam.ttf
Hei.ttf STFangsong.ttf ipamp.ttf
Kai.ttf STHeiti-Light.ttc kaiu.ttf
Lantinghei.ttc STHeiti-Medium.ttc msgothic.ttc
LiGothicMed.ttf STHeiti.ttf msmincho.ttc
LiHeiPro.ttf STXihei.ttf
LiSongPro.ttf bkai00mp.ttf
【新】
ls /Users/danna/UpTeX.app/Contents/Resources/TEX/texmf-local/fonts/opentype/cjk-gs-integrate
AppleSDGothicNeo.ttc
Hannotate.ttc
Hanzipen.ttc
HaranoAjiGothic-Bold.otf
HaranoAjiGothic-ExtraLight.otf
HaranoAjiGothic-Heavy.otf
HaranoAjiGothic-Light.otf
HaranoAjiGothic-Medium.otf
HaranoAjiGothic-Normal.otf
HaranoAjiGothic-Regular.otf
HaranoAjiMincho-Bold.otf
HaranoAjiMincho-ExtraLight.otf
HaranoAjiMincho-Heavy.otf
HaranoAjiMincho-Light.otf
HaranoAjiMincho-Medium.otf
HaranoAjiMincho-Regular.otf
HaranoAjiMincho-SemiBold.otf
HiraginoSansCNS.ttc
HiraginoSansGB.ttc
Klee.ttc
Kyokasho.ttc
LingWaiSC-Medium.otf
LingWaiTC-Medium.otf
PingFang.ttc
ToppanBunkyuGothicPr6N.ttc
ToppanBunkyuMidashiGothicStdN-ExtraBold.otf
ToppanBunkyuMidashiMinchoStdN-ExtraBold.otf
ToppanBunkyuMinchoPr6N-Regular.otf
TsukushiAMaruGothic.ttc
TsukushiBMaruGothic.ttc
WawaSC-Regular.otf
WawaTC-Regular.otf
WeibeiSC-Bold.otf
WeibeiTC-Bold.otf
YuGo-Bold.otf
YuGo-Medium.otf
YuMincho.ttc
YuppySC-Regular.otf
YuppyTC-Regular.otf
ls /Users/danna/UpTeX.app/Contents/Resources/TEX/texmf-local/fonts/truetype/cjk-gs-integrate
AppleGothic.ttf LiSungLight.ttf Yuanti.ttc
AppleMyungjo.ttf Libian.ttc bkai00mp.ttf
Baekmuk-Batang.ttf NanumGothic.ttc bsmi00lp.ttf
Baekmuk-Dotum.ttf NanumMyeongjo.ttc gbsn00lp.ttf
Baekmuk-Gulim.ttf NanumScript.ttc gkai00mp.ttf
Baekmuk-Headline.ttf Osaka.ttf ipaexg.ttf
Baoli.ttc OsakaMono.ttf ipaexm.ttf
Gungseouche.ttf PCmyoungjo.ttf ipag.ttf
HeadlineA.ttf Pilgiche.ttf ipagp.ttf
Hei.ttf STFangsong.ttf ipam.ttf
Kai.ttf STHeiti-Light.ttc ipamp.ttf
Kaiti.ttc STHeiti-Medium.ttc kaiu.ttf
Lantinghei.ttc STHeiti.ttf msgothic.ttc
LiGothicMed.ttf STXihei.ttf msmincho.ttc
LiHeiPro.ttf Songti.ttc
LiSongPro.ttf Xingkai.ttc
ひとまず回避方法がわかりましたので、大半の方には不要な情報だと思いますが報告しておきます。
objective-c/swiftでコマンドを実行するpipe処理ではコマンドは絶対パス指定／外部からパスを渡せないので
/bin/bash -c "$PATH=hoge; hoge1; hoge2; hoge3"
のような書式でコマンドを渡していました。Catalina以降、システムデフォルトのシェルがbashからzshに変わったのですが、これまで問題なかったので放置してたのがまずかったようです。/bin/zsh -cに変えてやったら問題が解消しました。具体的に何が問題だったのかまでは詰められないのですが、上記のコマンドを実行させている大元はシステムデフォルトのシェルなため、bashとzsh間の何らかの不整合で２バイト文字/半角スペースを含むファイル名の処理をうまくできなくなったようです（これまで処理できてたのは逆に？ですが）。
が、単純にzshに置き換えてしまうとCatalinaより前のシステムで真逆の不整合を起こしそうで。分岐処理にするべきか。
ところで、tlmgr unistall/installしても落ちてこないのは、新しいcjk-gs-integrate-macosはまだリポジトリには上げていないということでしょうか？
objective-c/swiftでコマンドを実行するpipe処理ではコマンドは絶対パス指定／外部からパスを渡せないので
/bin/bash -c "$PATH=hoge; hoge1; hoge2; hoge3"
のような書式でコマンドを渡していました。Catalina以降、システムデフォルトのシェルがbashからzshに変わったのですが、これまで問題なかったので放置してたのがまずかったようです。/bin/zsh -cに変えてやったら問題が解消しました。具体的に何が問題だったのかまでは詰められないのですが、上記のコマンドを実行させている大元はシステムデフォルトのシェルなため、bashとzsh間の何らかの不整合で２バイト文字/半角スペースを含むファイル名の処理をうまくできなくなったようです（これまで処理できてたのは逆に？ですが）。
が、単純にzshに置き換えてしまうとCatalinaより前のシステムで真逆の不整合を起こしそうで。分岐処理にするべきか。
ところで、tlmgr unistall/installしても落ちてこないのは、新しいcjk-gs-integrate-macosはまだリポジトリには上げていないということでしょうか？
> /bin/bash -c "$PATH=hoge; hoge1; hoge2; hoge3"
◆ おそらく
「 /bin/bash -c ”PATH=$PATH:hoge; hoge1; hoge2; hoge3"」
の記述ミスだろうと思いますが
◆ 「"」で囲んでいるので $PATH は展開されてしまいますので
PATH が /usr/local/bin:/usr/bin:/bin に設定されているとしたら
「/bin/bash -c ’/usr/local/bin:/usr/bin:/bin=hoge; ...’」
となり「/usr/local/bin:/usr/bin:/bin=hoge コマンドはないよ」とかのエラーになると思います
◆「２バイト文字/半角スペースを含むファイル名」
日曜から暇な時間がたっぷり取れますので後ほど調べてみますが。。。
このような半角スペースがあるファイル名を渡す場合は要注意です。
特に多段で呼ぶような場合は
cmd 'A B C' とした場合、受けての cmd で引数の評価をする場合に起こりがちです。専門的には "$@" で評価すれば 'A B C' ですが $@ で評価すると'A' と 'B' と 'C' になります。
この辺の解釈は bash も zsh も同じだと思います。
では後ほど。
◆ おそらく
「 /bin/bash -c ”PATH=$PATH:hoge; hoge1; hoge2; hoge3"」
の記述ミスだろうと思いますが
◆ 「"」で囲んでいるので $PATH は展開されてしまいますので
PATH が /usr/local/bin:/usr/bin:/bin に設定されているとしたら
「/bin/bash -c ’/usr/local/bin:/usr/bin:/bin=hoge; ...’」
となり「/usr/local/bin:/usr/bin:/bin=hoge コマンドはないよ」とかのエラーになると思います
◆「２バイト文字/半角スペースを含むファイル名」
日曜から暇な時間がたっぷり取れますので後ほど調べてみますが。。。
このような半角スペースがあるファイル名を渡す場合は要注意です。
特に多段で呼ぶような場合は
cmd 'A B C' とした場合、受けての cmd で引数の評価をする場合に起こりがちです。専門的には "$@" で評価すれば 'A B C' ですが $@ で評価すると'A' と 'B' と 'C' になります。
この辺の解釈は bash も zsh も同じだと思います。
では後ほど。
和田様
ご指摘の通りの記述ミスです。
実際には、ラウンチすべきフルパスのコマンドと、渡されるオプションとは
_task.launchPath = @"/bin/bash";
_task.arguments = @[@"-c",_arg];
のように別々に渡されるようになっていて、引き数_argは
NSString* binPath;
binPath = [myPath stringByAppendingString:@"/Contents/Resources/TEX/texbin"];
NSString* _arg;
_arg = [@"export PATH=\"" stringByAppendingString:binPath];
_arg = [_arg stringByAppendingString:@":$PATH\"; "];
_arg = [_arg stringByAppendingString:argString];
*argStringに"hoge1; hoge2..."が代入済み
という感じで_argは
export PATH="hoge:$PATH" ; hoge1 ; hoge2...
実行されるコマンドは
/bin/bash(or zsh) -c export PATH="hoge:$PATH" ; hoge1 ; hoge2...
のようになります。
コードのなかでは以上はメソッドに切り出してあって、argStringを外から与えることで、様々なコマンドを実行させています。このケースの場合は
NSFileManager *tmpFile = [ NSFileManager defaultManager];
[tmpFile changeCurrentDirectoryPath:[myPath stringByAppendingString:@"/Contents/Resources/PREF"]];
NSString* _arg;
_arg = @"echo \"フォントをスキャンしてシンボリックリンクを作成しています。\n\";cjk-gs-integrate --output=test --link-texmf --cleanup;cjk-gs-integrate-macos --output=test --link-texmf; rm -rf ";
_arg = [_arg stringByAppendingString:myPath];
_arg = [_arg stringByAppendingString:@"/Contents/Resources/PREF/test; echo \"\nシンボリックリンクの作成が完了しました。\""];
で生成した文字列になります。仮にUpTeX.appがアプリケーション・フォルダ内だとターミナルから以下を実行するのにほぼ相当します。
/bin/bash(or zsh) -c 'export PATH="/Applications/UpTeX.app/Contents/Resources/TEX/texbin:$PATH"; cjk-gs-integrate --output=test --link-texmf --cleanup; cjk-gs-integrate-macos --output=test --link-texmf'
でも、シェルがzshのBig Surでこれをターミナルで実行しても、zsh -c、bash -cともに正常でした。どうもCocoaのpipe処理固有の問題（仕様？制約？）があるようです。
ご指摘の通りの記述ミスです。
実際には、ラウンチすべきフルパスのコマンドと、渡されるオプションとは
_task.launchPath = @"/bin/bash";
_task.arguments = @[@"-c",_arg];
のように別々に渡されるようになっていて、引き数_argは
NSString* binPath;
binPath = [myPath stringByAppendingString:@"/Contents/Resources/TEX/texbin"];
NSString* _arg;
_arg = [@"export PATH=\"" stringByAppendingString:binPath];
_arg = [_arg stringByAppendingString:@":$PATH\"; "];
_arg = [_arg stringByAppendingString:argString];
*argStringに"hoge1; hoge2..."が代入済み
という感じで_argは
export PATH="hoge:$PATH" ; hoge1 ; hoge2...
実行されるコマンドは
/bin/bash(or zsh) -c export PATH="hoge:$PATH" ; hoge1 ; hoge2...
のようになります。
コードのなかでは以上はメソッドに切り出してあって、argStringを外から与えることで、様々なコマンドを実行させています。このケースの場合は
NSFileManager *tmpFile = [ NSFileManager defaultManager];
[tmpFile changeCurrentDirectoryPath:[myPath stringByAppendingString:@"/Contents/Resources/PREF"]];
NSString* _arg;
_arg = @"echo \"フォントをスキャンしてシンボリックリンクを作成しています。\n\";cjk-gs-integrate --output=test --link-texmf --cleanup;cjk-gs-integrate-macos --output=test --link-texmf; rm -rf ";
_arg = [_arg stringByAppendingString:myPath];
_arg = [_arg stringByAppendingString:@"/Contents/Resources/PREF/test; echo \"\nシンボリックリンクの作成が完了しました。\""];
で生成した文字列になります。仮にUpTeX.appがアプリケーション・フォルダ内だとターミナルから以下を実行するのにほぼ相当します。
/bin/bash(or zsh) -c 'export PATH="/Applications/UpTeX.app/Contents/Resources/TEX/texbin:$PATH"; cjk-gs-integrate --output=test --link-texmf --cleanup; cjk-gs-integrate-macos --output=test --link-texmf'
でも、シェルがzshのBig Surでこれをターミナルで実行しても、zsh -c、bash -cともに正常でした。どうもCocoaのpipe処理固有の問題（仕様？制約？）があるようです。
訂正です。
>実行されるコマンドは
>
>/bin/bash(or zsh) -c export PATH="hoge:$PATH" ; hoge1 ; hoge2...
>のようになります。
元の表記だと/bin/bash(or zsh) -c export PATH="hoge:$PATH"と、hoge1, hoge2はそれぞれ別のコマンドになってしまいますね。
pipe処理で/bin/bash(or zsh)に引き数としてそれぞれ、"-c"と_argの文字列が渡されて処理されるので、
/bin/bash(or zsh) -c 'export PATH="hoge:$PATH" ; hoge1 ; hoge2...'
相当になってくれます。
>実行されるコマンドは
>
>/bin/bash(or zsh) -c export PATH="hoge:$PATH" ; hoge1 ; hoge2...
>のようになります。
元の表記だと/bin/bash(or zsh) -c export PATH="hoge:$PATH"と、hoge1, hoge2はそれぞれ別のコマンドになってしまいますね。
pipe処理で/bin/bash(or zsh)に引き数としてそれぞれ、"-c"と_argの文字列が渡されて処理されるので、
/bin/bash(or zsh) -c 'export PATH="hoge:$PATH" ; hoge1 ; hoge2...'
相当になってくれます。
これに返信します。
objective-c は経験はないのですが、UpTex.app のダウンロード
イメージに含まれていたソースを眺めながら雰囲気でよんでみました。
今回の小川さんの件は、ターミナルで動かすとかファインダーで
ダブルクリックできどうするとか、OS 環境の変化とか ...
環境がちがうと動かなくなる
いわゆる環境変数の汚染の影響だとおもいます。
お話を聞いた限りでは UpTex.app のパスが入っていれば良さそう
とのことなので shell scruipt だったら $0 に相当しそうな
myPath = [ NSBundle mainBundle ].bundlePath ;
を利用して
Contents/Resources/TEX/2020/bin/x86_64-darwin
あるいは
Contents/Resources/TEX/2020/bin/x86_64-darwinlegacy
を連結させて PATH を生成すればようさそうですね。
$PATH を使うと環境変数汚染をもろにうけやすいので、
軽減するために $PATH を使わず macOS が標準でよういしている
/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin を利用する
方法を提案します。
つまり
【UpTeX.AppのPATH】/Contents/Resources/TEX/2020/bin/x86_64-darwin
と /usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin
を 連結されると良いと思います。
もちろん x86_64-darwinlegacy もケアしてあげてくださいね。
こうすればターミナルで実行しても、ファインダーから
ダブルクリックしても同じPATH になりますので。
objective-c は経験はないのですが、UpTex.app のダウンロード
イメージに含まれていたソースを眺めながら雰囲気でよんでみました。
今回の小川さんの件は、ターミナルで動かすとかファインダーで
ダブルクリックできどうするとか、OS 環境の変化とか ...
環境がちがうと動かなくなる
いわゆる環境変数の汚染の影響だとおもいます。
お話を聞いた限りでは UpTex.app のパスが入っていれば良さそう
とのことなので shell scruipt だったら $0 に相当しそうな
myPath = [ NSBundle mainBundle ].bundlePath ;
を利用して
Contents/Resources/TEX/2020/bin/x86_64-darwin
あるいは
Contents/Resources/TEX/2020/bin/x86_64-darwinlegacy
を連結させて PATH を生成すればようさそうですね。
$PATH を使うと環境変数汚染をもろにうけやすいので、
軽減するために $PATH を使わず macOS が標準でよういしている
/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin を利用する
方法を提案します。
つまり
【UpTeX.AppのPATH】/Contents/Resources/TEX/2020/bin/x86_64-darwin
と /usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin
を 連結されると良いと思います。
もちろん x86_64-darwinlegacy もケアしてあげてくださいね。
こうすればターミナルで実行しても、ファインダーから
ダブルクリックしても同じPATH になりますので。
和田様
ご指摘ありがとうございます。また、わざわざソースコードまで見ていただき、お手数をおかけしました。
このご指摘によって原因が見えてきました。
従来、NSTask（pipe処理と書いてたのは不正確でした）ではユーザーの設定したPATHを参照してくれてなかったので、ここでの$PATHは/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/binと同義でした。なのでこれとContents/Resources/TEX/texbinとを連結させたものをexportで与えていたのです。
ところがBig SurではNSTaskでもユーザーの$PATHを読むように挙動が変化したみたいです。先程、TeXLiveを組み込んでないUpTeX.appを実験用にBuildして動作させたら、当然そのなかのコマンドは動かない筈なのに、コマンドが動く挙動をしてビックリしました。確認したところ、自分でパスを通してあるアプリケーション・フォルダ内のUpTeX.appのコマンドが動いたようで、そちらの中のシンボリックリンクが更新されてました。
結論から言うとご指摘のように「 $PATH を使わず macOS が標準で用意している/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin を利用する」記述に変更するのが今後の正解ということになりそうです。TeXとは話題がズレますが、この挙動の変更はコマンドを叩くフロントエンドの類いのアプリの多くに影響を与えかねない、大きいものですね。
ご指摘ありがとうございます。また、わざわざソースコードまで見ていただき、お手数をおかけしました。
このご指摘によって原因が見えてきました。
従来、NSTask（pipe処理と書いてたのは不正確でした）ではユーザーの設定したPATHを参照してくれてなかったので、ここでの$PATHは/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/binと同義でした。なのでこれとContents/Resources/TEX/texbinとを連結させたものをexportで与えていたのです。
ところがBig SurではNSTaskでもユーザーの$PATHを読むように挙動が変化したみたいです。先程、TeXLiveを組み込んでないUpTeX.appを実験用にBuildして動作させたら、当然そのなかのコマンドは動かない筈なのに、コマンドが動く挙動をしてビックリしました。確認したところ、自分でパスを通してあるアプリケーション・フォルダ内のUpTeX.appのコマンドが動いたようで、そちらの中のシンボリックリンクが更新されてました。
結論から言うとご指摘のように「 $PATH を使わず macOS が標準で用意している/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin を利用する」記述に変更するのが今後の正解ということになりそうです。TeXとは話題がズレますが、この挙動の変更はコマンドを叩くフロントエンドの類いのアプリの多くに影響を与えかねない、大きいものですね。
TeX自体の話題ではなくなってしまって恐縮ですが…。Big Sur、さすがはメジャーアップデートなのかこれまでとの変化は半端でないようです。
$PATHを使わないように変更して、Catalina前後でbash/zshを使い分ける分岐にしたものをBuildしたところBig Surではうまくいったのですが、手元にたまたまあったHigh Sierraの環境では、最初に起きたのと同じ和文ファイル名フォントのシンボリックリンクが作成されない問題が発生しました。
まさかと思って、High Sierraで正常動作している20200908版（MojaveでBuild）と全く同じソースをBig SurのXcodeでBuildして、これをHigh Sierraで動かしてみたところ、同じ問題発生です。もしやBuildした環境のデフォルトシェルと同じでないといけないのかとか考えてzshのものの動作を試してみたりしたけど、問題を回避できてません。NSTaskの後方互換性が乏しいというか、仕様変更が大きいというか。Mojave辺りの環境をキープしておかないと今後、旧環境の手当てはできないし、それだとarm版のBuildはできないしで、Big Sur前・後でアプリを分けないといけないかもしれません。ともかく問題は絞れてきました。もはやMacの開発固有の問題になりますので、暫く試行錯誤してみます。
$PATHを使わないように変更して、Catalina前後でbash/zshを使い分ける分岐にしたものをBuildしたところBig Surではうまくいったのですが、手元にたまたまあったHigh Sierraの環境では、最初に起きたのと同じ和文ファイル名フォントのシンボリックリンクが作成されない問題が発生しました。
まさかと思って、High Sierraで正常動作している20200908版（MojaveでBuild）と全く同じソースをBig SurのXcodeでBuildして、これをHigh Sierraで動かしてみたところ、同じ問題発生です。もしやBuildした環境のデフォルトシェルと同じでないといけないのかとか考えてzshのものの動作を試してみたりしたけど、問題を回避できてません。NSTaskの後方互換性が乏しいというか、仕様変更が大きいというか。Mojave辺りの環境をキープしておかないと今後、旧環境の手当てはできないし、それだとarm版のBuildはできないしで、Big Sur前・後でアプリを分けないといけないかもしれません。ともかく問題は絞れてきました。もはやMacの開発固有の問題になりますので、暫く試行錯誤してみます。
現象的にはエンコーディングの問題だからと思って
export LANG=ja_JP.UTF-8; export LESSCHARSET=UTF-8;
も明示的に加えてやったら、Big Sur/High Sierra, zsh/bashどれでも通るようになりました。具体的に何が起こってるのかはわからないままなのですがNSTaskでの/bin/bash(or zsh) -c "......"において
$PATHは
Big Surでの実行：どの環境でBuildしたものでもユーザーが設定したものが参照される。
Mojave以前での実行：どの環境でBuildしたものでもシステムルートのものが参照される。
エンコーディングは
Big SurでBuildしたもの
Big Surでの実行：zsh（デフォルトシェル）は指定せずともUTF-8。bashは明示的に指定しないとUTF-8ではない何か（ASCII?）
Mojave以前での実行：zsh,bashとも明示的に指定しないとUTF-8ではない何か（ASCII?）
Mojave以前でBuildしたもの
Big Surでの実行：bashは明示的に指定しないとUTF-8ではない何か（ASCII?）。
Mojave以前での実行：bashは指定せずともUTF-8。
＊zshについては手元にいまMojave以前の開発環境がないので未検証
というのが、私が遭遇した現象上のパターンです。エンコーディングを指定せずとも動くケースは、もしかしたらOS自体が日本語Lang環境だからという可能性もあります。すると旧環境の場合も、エンコーディングは明示的に指定しておく方が安全でしょう。
いずれにせよmacOSアプリからコマンドを叩かせる場合に、Big Surの前後での変化は要注意のようです。
export LANG=ja_JP.UTF-8; export LESSCHARSET=UTF-8;
も明示的に加えてやったら、Big Sur/High Sierra, zsh/bashどれでも通るようになりました。具体的に何が起こってるのかはわからないままなのですがNSTaskでの/bin/bash(or zsh) -c "......"において
$PATHは
Big Surでの実行：どの環境でBuildしたものでもユーザーが設定したものが参照される。
Mojave以前での実行：どの環境でBuildしたものでもシステムルートのものが参照される。
エンコーディングは
Big SurでBuildしたもの
Big Surでの実行：zsh（デフォルトシェル）は指定せずともUTF-8。bashは明示的に指定しないとUTF-8ではない何か（ASCII?）
Mojave以前での実行：zsh,bashとも明示的に指定しないとUTF-8ではない何か（ASCII?）
Mojave以前でBuildしたもの
Big Surでの実行：bashは明示的に指定しないとUTF-8ではない何か（ASCII?）。
Mojave以前での実行：bashは指定せずともUTF-8。
＊zshについては手元にいまMojave以前の開発環境がないので未検証
というのが、私が遭遇した現象上のパターンです。エンコーディングを指定せずとも動くケースは、もしかしたらOS自体が日本語Lang環境だからという可能性もあります。すると旧環境の場合も、エンコーディングは明示的に指定しておく方が安全でしょう。
いずれにせよmacOSアプリからコマンドを叩かせる場合に、Big Surの前後での変化は要注意のようです。
>従来、NSTask（pipe処理と書いてたのは不正確でした）ではユーザーの設定したPATHを参照してくれてなかったので、ここでの$PATHは/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/binと同義でした。
これは恥ずかしながら、完全に勘違いでした。
Big Sur, High Sierraとも-c "..."の中で$PATHなどを参照した場合、zshは.zshenvがあれば、環境変数はそこで設定されたものを読み、なければシステムルートのものを読みました。bashでは.bash_profileの有無に関わらず、システムルートの環境変数を読む挙動でした。Sierra以前の環境をもう持っていないので確かめられませんが、bashがデフォルトシェルだったときは、.bash_profileを読んでいたのかもしれません。
なのでBig Surで.zshenvのLang設定なし、コード内でのLang設定なしだと、zshでも例の問題は起こりました。
ただし、MojaveでBuildしたbashの版（コード内でのLang設定なし）では、.bash_profileも.zshenvもなくても、やはり件の問題は起こりません。NSTask回りのLangに関する挙動は、.zshenvのLang設定の有無とは別のところで、Big Surで変わった（実行環境としてもBuild環境としても？）のは確かで、この挙動変化が今回の問題の要点のようです。
つまりは、ご指摘頂いたPATHだけでなくLang回りも、環境変数を読ませず実行コマンドのなかで独自に明示的に設定すべきであったということになります。不明を曝してしまい申し訳ありません。
これは恥ずかしながら、完全に勘違いでした。
Big Sur, High Sierraとも-c "..."の中で$PATHなどを参照した場合、zshは.zshenvがあれば、環境変数はそこで設定されたものを読み、なければシステムルートのものを読みました。bashでは.bash_profileの有無に関わらず、システムルートの環境変数を読む挙動でした。Sierra以前の環境をもう持っていないので確かめられませんが、bashがデフォルトシェルだったときは、.bash_profileを読んでいたのかもしれません。
なのでBig Surで.zshenvのLang設定なし、コード内でのLang設定なしだと、zshでも例の問題は起こりました。
ただし、MojaveでBuildしたbashの版（コード内でのLang設定なし）では、.bash_profileも.zshenvもなくても、やはり件の問題は起こりません。NSTask回りのLangに関する挙動は、.zshenvのLang設定の有無とは別のところで、Big Surで変わった（実行環境としてもBuild環境としても？）のは確かで、この挙動変化が今回の問題の要点のようです。
つまりは、ご指摘頂いたPATHだけでなくLang回りも、環境変数を読ませず実行コマンドのなかで独自に明示的に設定すべきであったということになります。不明を曝してしまい申し訳ありません。
くどくで申し訳ありませんが再度の訂正です。
>MojaveでBuildしたbashの版（コード内でのLang設定なし）
CatalinaでのBuildです。
High Sierraのデフォルトシェルはbash（zshになるのはCatalinaから）ですので、NSTask中でのbashとzshの.bash_profile/.zshenvを読むかどうかの違いはデフォルトシェルであるかどうかに依るのではなく、bashかzshそれ自体であることに依るようです。
また、bashがデフォルトシェルであった間はNSTask中でも/bin/bash -cで書くのが素直（わざわざ/bin/zsh -cとはしない）でしょうから、その間は事実上ほぼ「NSTask中ではユーザーの設定した環境変数は読んでくれない」で誤ってなかったようです。
そして怪我の功名ですが、zshがデフォルトになったCatalinaでもbashのままにしてあったので、ユーザーの環境変数は読まない振る舞いをしてくれていた。またCatalinaまではキャラセットを明示的にUTF-8としなくても、そうである振る舞いをしてくれていた。つまりCatalinaまでは問題が顕在化しない動作をしてくれていた。でもBig SurではUTF-8を明示指定しないと駄目に変わった、と解せそうです。
>MojaveでBuildしたbashの版（コード内でのLang設定なし）
CatalinaでのBuildです。
High Sierraのデフォルトシェルはbash（zshになるのはCatalinaから）ですので、NSTask中でのbashとzshの.bash_profile/.zshenvを読むかどうかの違いはデフォルトシェルであるかどうかに依るのではなく、bashかzshそれ自体であることに依るようです。
また、bashがデフォルトシェルであった間はNSTask中でも/bin/bash -cで書くのが素直（わざわざ/bin/zsh -cとはしない）でしょうから、その間は事実上ほぼ「NSTask中ではユーザーの設定した環境変数は読んでくれない」で誤ってなかったようです。
そして怪我の功名ですが、zshがデフォルトになったCatalinaでもbashのままにしてあったので、ユーザーの環境変数は読まない振る舞いをしてくれていた。またCatalinaまではキャラセットを明示的にUTF-8としなくても、そうである振る舞いをしてくれていた。つまりCatalinaまでは問題が顕在化しない動作をしてくれていた。でもBig SurではUTF-8を明示指定しないと駄目に変わった、と解せそうです。
◆ /bin/bash と /bin/zsh
/bin/bash -c "....." は "...." の中を /bin/bash の文法で記述するという 宣言にすぎません。今回の範囲では /bin/zsh や話はそれちゃいますが /bin/sh やもしかしたら /bin/dash でも動くと思います。
挙動がおかしくなる原因の一つは 環境変数 PATH です。 前回意識的に/usr/local/bin を除きましたが、ここには HOMEBREW や macports などで独自インストールしたものがインストールされる場合 があります。ですので開発者の /usr/local/bin を前提としたツールを 作成すると、他の人は利用できなくなってしまうからです。 もちろん、その旨を宣言しておけば良いのですが 。。。
それと報告のあった locale 云々と表現することもありますが LANG も 思わぬ動きをしますので要注意です。 先日実際に経験したのは、ssh ログイン時に debian からログインすると ja_jp.UTF-8 でしたが Windows からだと POSIX（だったと思う）に なってしまう。実際のアプリで strftime というので LANG の値によって 月名や曜日名が日本語になったり英語になったりして暫し悩みました。
◆$HOME/.bash_profile はどう言う状況で読み込まれるか
詳しくは https://techracho.bpsinc.jp/hachi8833/2019_06_06/66396 「Linux: .bashrcと.bash_profileの違いを今度こそ理解する」 を参考にしてください。
結論 「/bin/bash -c "...."」では$HOME/.bash_profileは読み込みません.
じゃどういう状況で読み込むかというと
1. ターミナルを起動した時
2. ターミナルで 「/bin/bash --login ...」とした時
ということで以下を $HOME/.bashrc の先頭に書き込んで実験してみました。
echo DEBUG @ .bash_profile
locale
echo PATH=$PATH | sed 's/:/\n /g'
echo debug @ .bash_profile
- 用意したテストプログラム
% #!/bin/bash echo YAHHO $0
- 実行権を付与
％
- 実験
% / YAHHO ./TEST.sh
- ログイン実験
%
DEBUG @ .bash_profile
LANG="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_CTYPE="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_ALL=
PATH=/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
/opt/X11/bin
/Library/Apple/usr/bin
PS 小川さんが修正されているであろうイメージを想像してもうちょっと実験しています。結果は後ほど。
和田様
お教え頂いた解説で、おおよそは理解できました。「NSTaskはユーザーの環境変数を引き継がない」云々とかつて目にしたのは、「/bin/bash -c "...."ではbash_profileは読み込まれない」ことにもかかわっていたのですね。だとすると、するまでもない実験をしてました。またもや私の無知で恥ずかしい限りですが、この種の設定の話はwebを見ててもいろんな流儀？があって、やはりウッカリ変な設定ファイルが読み込まれないようなコード記述にしておかなければならないことが得心できました。
ところでNSTaskそれそのものが
_task.launchPath = @"/bin/ls";
のような記述でコマンドを実行させる際のシェルは何なのか気にはなっているのですが
_task.launchPath = @"ls";
と書くと動かない。絶対パスしか効かないんですよね。この段階では、システムのものも含め、環境変数の類いは何一つ参照されてないということでしょうかね。その意味ではNSTaskそれ自体はユーザー設定に限らず如何なる環境変数も引き継がないということか。NSTaskそのもののシェルにOSヴァージョンごとのデフォルトシェルが反映して挙動が変わったりするのかと思ったのですが、そうではないようです。思い起こせば、tlmgrのフロントエンド機能を実装しようとしたときに、はじめはアプリ自身の位置から絶対パスを生成してみたけど、tlmgrがあれこれやる際に、TeXLiveの諸コマンドを呼ぶのにtexbinにパスが通ってないからコケる、というのが、/bin/bash -c "...."のなかで環境変数のexportも含めコマンドを与えるようにした出発点でした（(u)platexやdvipdfmxだけなら他のコマンドを呼んだりしないので絶対パスでの実行だけで済んでた）。
>挙動がおかしくなる原因の一つは 環境変数 PATH です。 前回意識的に/usr/local/bin を除きましたが、
これは仰る通りです。$PATHを参照してたのは（.bash_profileは読まれないから）それをシステムデフォルトの値と（誤って）解していたからで、ここではUpTeX.appのtexbin＋標準的なパスの他は、入り込むべきでないというのは私も意図するところでした。
お教え頂いた解説で、おおよそは理解できました。「NSTaskはユーザーの環境変数を引き継がない」云々とかつて目にしたのは、「/bin/bash -c "...."ではbash_profileは読み込まれない」ことにもかかわっていたのですね。だとすると、するまでもない実験をしてました。またもや私の無知で恥ずかしい限りですが、この種の設定の話はwebを見ててもいろんな流儀？があって、やはりウッカリ変な設定ファイルが読み込まれないようなコード記述にしておかなければならないことが得心できました。
ところでNSTaskそれそのものが
_task.launchPath = @"/bin/ls";
のような記述でコマンドを実行させる際のシェルは何なのか気にはなっているのですが
_task.launchPath = @"ls";
と書くと動かない。絶対パスしか効かないんですよね。この段階では、システムのものも含め、環境変数の類いは何一つ参照されてないということでしょうかね。その意味ではNSTaskそれ自体はユーザー設定に限らず如何なる環境変数も引き継がないということか。NSTaskそのもののシェルにOSヴァージョンごとのデフォルトシェルが反映して挙動が変わったりするのかと思ったのですが、そうではないようです。思い起こせば、tlmgrのフロントエンド機能を実装しようとしたときに、はじめはアプリ自身の位置から絶対パスを生成してみたけど、tlmgrがあれこれやる際に、TeXLiveの諸コマンドを呼ぶのにtexbinにパスが通ってないからコケる、というのが、/bin/bash -c "...."のなかで環境変数のexportも含めコマンドを与えるようにした出発点でした（(u)platexやdvipdfmxだけなら他のコマンドを呼んだりしないので絶対パスでの実行だけで済んでた）。
>挙動がおかしくなる原因の一つは 環境変数 PATH です。 前回意識的に/usr/local/bin を除きましたが、
これは仰る通りです。$PATHを参照してたのは（.bash_profileは読まれないから）それをシステムデフォルトの値と（誤って）解していたからで、ここではUpTeX.appのtexbin＋標準的なパスの他は、入り込むべきでないというのは私も意図するところでした。
◆_task.launchPath = @"/bin/ls"; の際のシェルは?
シェルではないです
コマンドを起動する際、そのコマンドファイルの先頭の一部を読みこみ
「#!」で始まっていたら、続く文字列のファイルを読み込みます。
そうでなければ続けてそのファイルをこの場合「/bin/ls」を読み込み、
制御を渡します。
キーワード：シバンまたはシェバン(shebang)
シェルとは OS の機能を操作するユーザとOS の間に介在するサービスプログラム
◆_task.launchPath = @"ls"; と書くと動かない。絶対パスだけ
Objective-C は使ったことがないのですが launch を使っているからではないですか？
以下のような記述もできるようですので試されたら？
NSString* output = [@"echo hello" runAsCommand];
◆ ... TeXLiveの諸コマンドを呼ぶのにtexbinにパスが通ってないからコケる ...
いろいろやり方はあると思うけど https://texwiki.texjp.org/?ヒラギノフォント#macos-hiragino-setup のようなことをやりたいのであれば、
僕だったら添付した shell script を同梱させそのファイルを objective-c のプログラムから読み込むのかな
シェルではないです
コマンドを起動する際、そのコマンドファイルの先頭の一部を読みこみ
「#!」で始まっていたら、続く文字列のファイルを読み込みます。
そうでなければ続けてそのファイルをこの場合「/bin/ls」を読み込み、
制御を渡します。
キーワード：シバンまたはシェバン(shebang)
シェルとは OS の機能を操作するユーザとOS の間に介在するサービスプログラム
◆_task.launchPath = @"ls"; と書くと動かない。絶対パスだけ
Objective-C は使ったことがないのですが launch を使っているからではないですか？
以下のような記述もできるようですので試されたら？
NSString* output = [@"echo hello" runAsCommand];
◆ ... TeXLiveの諸コマンドを呼ぶのにtexbinにパスが通ってないからコケる ...
いろいろやり方はあると思うけど https://texwiki.texjp.org/?ヒラギノフォント#macos-hiragino-setup のようなことをやりたいのであれば、
僕だったら添付した shell script を同梱させそのファイルを objective-c のプログラムから読み込むのかな
種々不勉強をご指摘頂き痛み入ります。またshell scriptのサンプルまでありがとうございます。shell scriptにしてResourceに入れておくのが本来だと思いますが、書き方をちゃんと勉強できていないのと、比較的短いコマンド記述だからと、ソース内に直接書き込んでしまってます。
（不勉強の言い訳になってしまいますが、もとはAppleScriptのアプリバンドルでやっていたのが、OSのセキュリティ強化でそれが出来なくなったので、真っ当なプログラム経験もないのにobjective-cに泥縄・見様見まねで手を出したのです。）
なお
NSString* output = [@"echo hello" runAsCommand];
は調べてみたところ、そういう記述ができるのではなく（objective-cにrunAsCommandという命令があるのではなく）、別に- (NSString*)runAsCommand というメソッドを定義し、そのなかで
[task setLaunchPath: @"/bin/sh"];
[task setArguments:@[@"-c", [NSString stringWithFormat:@"%@", self]]];
と/bin/shをlaunch、引き数を -c, runAsCommandとして与えられたNSStringにするものですから、私がやっていることと基本的に同じでした。launch以外にコマンドを実行させる方法はなさそうです（これまた不勉強なだけかもしれませんが）。
https://stackoverflow.com/questions/412562/execute-a-terminal-command-from-a-cocoa-app/32240064
（不勉強の言い訳になってしまいますが、もとはAppleScriptのアプリバンドルでやっていたのが、OSのセキュリティ強化でそれが出来なくなったので、真っ当なプログラム経験もないのにobjective-cに泥縄・見様見まねで手を出したのです。）
なお
NSString* output = [@"echo hello" runAsCommand];
は調べてみたところ、そういう記述ができるのではなく（objective-cにrunAsCommandという命令があるのではなく）、別に- (NSString*)runAsCommand というメソッドを定義し、そのなかで
[task setLaunchPath: @"/bin/sh"];
[task setArguments:@[@"-c", [NSString stringWithFormat:@"%@", self]]];
と/bin/shをlaunch、引き数を -c, runAsCommandとして与えられたNSStringにするものですから、私がやっていることと基本的に同じでした。launch以外にコマンドを実行させる方法はなさそうです（これまた不勉強なだけかもしれませんが）。
https://stackoverflow.com/questions/412562/execute-a-terminal-command-from-a-cocoa-app/32240064