\ x1eを表す方法がないという懸念はありますか？ それとも、アーキテクチャの改善について考えていますか？

配列区切り文字は主に、ユニバーサル変数や環境変数など、文字列のみを受け取る場所で配列を永続化するために使用されると思います。

在2012-12-12上午2:09、「ばかげた魚」 [email protected]写道：

\ x1eを表す方法がないという懸念はありますか？ またはあなたは考えていますか
アーキテクチャの改善について？

私は両方の懸念を念頭に置いていると思います。 前者の場合は、
\ x1eが埋め込まれたファイル名。 POSIXは\ 0以外は許可されていると言っています
ファイル名なので、それは完全に可能です。 配列区切り文字として\ 0を使用すると、
少し良い選択ですが、それは2番目の懸念につながります-それは
壊れやすく、明らかに間違っています。

配列区切り文字は、主に場所に配列を永続化するために使用されると思います
ユニバーサル変数や環境変数のように、文字列のみを取ります。

永続化が「シリアル化」を意味する場合、いいえ。 配列は常にに格納されます
\ x1e-区切られた形式。 エクスポートされた環境アレイは「：」で結合されます。 彼ら
ただし、ユニバーサル変数で使用されます-どのIMHOを実装する必要がありますか
代わりに適切なエスケープを行います。

—
このメールに直接返信するか、GitHubで表示してください。

私用領域の文字を区切り文字として使用するのはどうですか？ 魚はすでにそれらのいくつかを使用している場合があります。

@JanKanisそれは良くありません。 ファイル名（utf8以外のネイティブエンコーディングを使用するファイルシステムを考慮）やその他の文字列で完全に可能です。

とりわけ、 "\0"は、UNIXがファイル名で禁止している唯一の文字であるため、とりわけ_やや_良い選択だと思いますが、それでも私には悪臭がします。 また、すでに多くの配列の分割と組み立てを行っています。真の配列を実装すると、アーキテクチャが改善され、コードが少なくなると思います。

Fishは、外部文字列をwcharにエンコードするときに、すでにプライベート使用文字と無効なバイトを処理しています。 これらの特別な値は、バイトごとに特定の私用文字のセットにエンコードされ、fishは出力時に再びデコードするため、原則として、別の私用文字を使用すると機能します。 ただし、真の配列を使用する方がはるかに優れていることに同意します。 fishとfishdの間の通信は、utf8文字列を使用してソケットを介して行われるという複雑な問題があります。そこで、fishは（0x1eバイトではなく）エスケープシーケンス「\ x1e」を使用して配列アイテムを分離します。 しかし、それはおそらく、たとえばプライベートな未使用のエスケープシーケンスを使用することで解決できます。

私はxiaqの懸念を共有していますが、（実際の懸念については）暗黙の分割が\ nはるかに不快であることがわかりました。

a<strong i="6">@raspeball</strong> ~> count (printf 'a\x1eb')
1
a<strong i="7">@raspeball</strong> ~> count (printf 'a\nb')
2

サブプロセス出力の（改行で区切られた）配列解釈は、明示的かつオプションである必要があります。

しかし、それはおそらくアレイの基盤となるストレージとは何の関係もありません…

@xiaq ： \0を使用することの何が問題になっていますか？ xargsは、それを「信頼できる」オプションとして使用しているようです。

環境変数で\0を使用することはできないため、配列を子シェルにエクスポートするのが難しくなります。

私はzshから移行しており、このシーケンスを使用して、「結合された」変数機能を利用して、$ LESSenv変数を適切な方法で定義しています。

typeset -xT LESS less ' '
less=(
    --HILITE-UNREAD
    --LONG-PROMPT
)

簡潔にするために、オプションの完全なリストは省略しました。 zshでは、$ LESS env varは、$ less配列内のオプションのスペースで区切られたリストになります。 魚に相当するものは、要素がレコード区切り文字（\ x1e）文字で区切られる結果になります。 配列の要素はスペースで区切られるとのドキュメントにも関わらず（PATHなどの特別な配列を法として）。 期待される結果を得るには、値を単一の文字列に補間する割り当てを明示的に行う必要があります。

set -x LESS --HILITE-UNREAD \
    --LONG-PROMPT
set LESS "$LESS"

現時点では、\ x00ではなく\ x1eが配列のシリアル化に内部的に使用されているかどうかは気にしません。 エクスポートされた配列の要素が\ x1eで区切られていることに注意してください。 それはただ壊れている、間違っている、fubarです。 形容詞を選んでください。 また、前述の回避策および文書化された動作とも矛盾します。 この問題は、バグIMHOとしてタグ付けする必要があります。

PS、ドキュメントのどこにもレコード区切り文字（\ x1e）の使用については言及されていません。 これは別の問題です。

@ krader1961これを共有していただきありがとうございます。 リストのような環境変数には、標準のUnix規則はありません。コロンで区切られているものもあれば、スペースで区切られているものもあります。 fishは\ x1eを使用するため、自身の配列を区別できます。

間違ったドキュメントを教えていただけますか？

配列はどのようにエクスポートされると思いますか？コロン、スペース、改行、その他。 魚はこのキャラクターの環境変数もトークン化する必要がありますか？

スペースで区切られた引数をあまり期待していないようです。 おそらく最も簡単な回避策はset -x LESS '--HILITE-UNREAD --LONG-PROMPT'などです。

定義上、等号で区切られ、ヌルバイトで終了するキーと値で構成される任意のバイトシーケンスであるため、環境変数のようなリストの標準はありません。 印刷可能な文字である必要はありません。 より高いレベルの抽象化のために広く受け入れられている唯一の規則は、PATH env varのexeclp（）関数によって確立された規則です。

複数の要素を持つ変数をエクスポートするときに、配列の要素を区切るために\ x1E、\ 036、30、または「レコード区切り文字」文字を使用することに言及していない限り、ドキュメントは誤りです。 ドキュメントには次のように記載されています

..., and array variables will be concatenated using the space character.

これは、 http：//fishshell.com/docs/current/index.htmlの「変数の拡張」のセクションからのものです。 同じドキュメントの「配列」セクションと「特殊変数」セクションに記載されているように、特殊なケースに分類されていないエクスポートされた変数にも、このステートメントが適用されると推測するのが妥当です。

魚は、環境変数をPATHなどのコロンで区切られた特殊なケースの変数以外のリストに自動的にトークン化するべきではないと私は感じています。 ただし、ユーザーがvarを任意の文字の配列にトークン化できる堅牢な手段が必要です。

変数ごとに使用される文字を構成するメカニズムがない場合（zsh "typeset -T"コマンド）、配列の要素を連結するときにスペースを使用する必要があります（ここでも、コロンで区切られた特殊な場合の変数を除く）。 ）。 明らかに、これはユニバーサル変数のストレージなどのプライベートデータストアには適用されません。

最後に、env varを使用して、複数の要素を含む配列を別の関数またはスクリプトに渡す標準のfish関数の使用法を見つけることができませんでした。 このようなユースケースは存在する可能性がありますが、文字列にレコード区切り文字が含まれる変数から配列を暗黙的に再構築するためにfishに依存するのではなく、データのシリアル化/逆シリアル化に明示的に協力するスクリプトが必要です。

思いやりのある対応ありがとうございます。 スペースを使用した連結について引用したセクションは、特に二重引用符で囲まれた文字列用です。 エクスポートされた配列で何が起こるかについての議論を追加する必要があります。

ユーザーは、たとえばset SOMEPATH (string split : $SOMEPATH)を使用して文字列をトークン化できます。

スペースを連結するエクスポートされた変数の欠点は、魚が再帰的に実行されるときに変数が変更されることです。 今日これは機能します：

> set -x list 1 2 3
> count $list
3
> fish -c 'count $list'
3

ただし、スペースを使用してエクスポートした場合、再帰呼び出しの場合は1が表示されます。 あなたが言うように、私たちはこれに依存していませんが、一貫性の観点からは素晴らしいです。

思いやりのある対応ありがとうございます。

私はそれを2番目にする必要があります！ 物事について新鮮な視点を持つことは常に素晴らしいことです。

この議論に不慣れな人のために、私はこれに関連するいくつかのものを持ち込む必要があると思います。

すぐに頭に浮かぶのは、＃2090のような問題に現れるlistifyホワイトリストです。

これは、$ PATH、$ CDPATH、および$ MANPATHの場合、それらはフィッシングのリスト/配列として表示されますが、エクスポートされると、再び「：」で結合されることを意味します。 その後、魚の中の魚はそれらを再び分割します。 これは、\ x1eではなく、コロンで機能します。 コードの私の理解から、それはエスケープする機会がなく、すべてのコロンでそれを行うように見えるので、コロンが中にある$ PATHエントリで壊れるかもしれません-UNIXはファイルパス内で許可しますが、少なくとも$ PATHでは壊れているようです。 このスキームは、たとえばPYTHONPATHやGOPATHにも使用されます。

これは実際には2つの異なるスキームであるため、暗黙のalways-split-on- \ x1e-except-for-these-three-split-them-on-colonよりも、環境変数を分割するための明示的なものが必要です。 1つとリストをエクスポートすると、現在、魚以外のすべてが常に混乱します。

私の好ましい解決策はsplitenv var1 var2 var3のような関数です：

function splitenv --no-scope-shadowing
    set -e IFS # string split doesn't have superpowers, so unset IFS lest we split on both : and \n
    for arg in $argv
        set -q $arg; and set $arg (string split ":" $$arg)
    end
end

（ string splitに超能力がある場合、これは少し簡単になります）

すべてのリストはエクスポート時にコロンで結合されるため、ユーザーはsplitenvで明示的に結合を解除できます（ヘルパー関数に完全に没頭しているわけではありませんが、これを簡単にするのは良いことだと思いますやるべき事）。 下位互換性のために、起動時にsplitenv PATH CDPATH MANPATHが実行されます。 ユーザーが別の方法でエクスポートしたい場合は、 string joinを使用できます。

これはすべて、\ x1eが不要になったことを意味します。少なくとも他のプログラムによって理解される可能性が高いスキームがありますが、（かなりエキゾチックなIMHOの）魚の中の魚はfish -c 'splitenv list; count $list'なります。 。

問題は、もちろん、前述のように、通常のコロンで区切られたリストスキームにはコロンをエスケープする方法がなく、コロンを追加したい場合、 string splitには「-unscaped」がないことです。エスケープされていないセパレーターでのみ分割するオプション。

私は意味がありますか？

@fahoアイデアにはメリットがあると思います。 古いスキームの最悪の部分は、コロンで暗黙的に分割することでした。これは、分割されるべきではない変数をマングルします。 あなたの考えでは、これは（ほとんど）常に明示的であるため、非常に安全だと思います。

エスケープに関しては、PATHでコロンをエスケープしないことは、見つけたリンクごとに意図的に行われます。 PYTHONPATH、CLASSPATHなどがこの点でこれ以上一貫しているとは思えません。 これらのパスではコロンを使用できないため、コロンをエスケープするかどうかを選択できます。 ただし、コロンをエスケープする場合は、バックスラッシュをエスケープする必要があります。PATHにバックスラッシュを含めることができると思います。 「逃げない」ホワイトリストが必要になる場合があります（ugh）。

または、それについて心配する必要はなく、コロンを区切り文字として機能させるだけです。 シンプルさと他のシェルに精通しているため、私はこれに傾倒していると思います。

リストのような変数の中にはスペースで区切られているものと、コロンで区切られているものがあるという問題にまだ直面しています。 1つの可能性は、 splitenvが区切り文字を受け入れ、それを記憶し、それを使用してエクスポート時に値を再構築することです。

splitenv --on ' ' LESS
splitenv --on ':' PYTHONPATH

これらの呼び出しは、既存の変数をインポートすることと、変数がどのようにエクスポートされるかをマークすることの2つの役割を果たします。 どう思いますか？

また、config.fishを編集せずにこれを行う方法はありますか？ 多分普遍的な変数の一部として？

リストのような変数の中にはスペースで区切られているものと、コロンで区切られているものがあるという問題にまだ直面しています。 1つの可能性は、splitenvが区切り文字を受け入れ、それを記憶し、それを使用してエクスポート時に値を再構築することです。

いいですね。 とにかくC ++側からの協力が必要なので、その時点でsplitenvをスクリプトにすることはおそらく役に立たないでしょう。

これらの呼び出しは、既存の変数をインポートすることと、変数がどのようにエクスポートされるかをマークすることの2つの役割を果たします。

「splitenv」はもはや完璧な名前ではない可能性があります（もちろん、私がそれを考えたときでした：笑い：）-私は「listify」も検討しました。

以前に関連する議論がどこにあったのか思い出せないのは私を悩ませていますが、今夜も問題を精査する必要があると思います。

ユーザーは、たとえばset SOMEPATH (string split : $SOMEPATH)を使用して文字列をトークン化できます。

stringコマンドは、私が見つけることができる場所には文書化されていません。 また、 man stringは、BSD（およびMac OS X）での文字列操作関数を文書化したstring（3）のマニュアルページを示しています。

ただし、スペースを使用してエクスポートした場合、再帰呼び出しの場合は1が表示されます。 あなたが言うように、私たちはこれに依存していませんが、一貫性の観点からは素晴らしいです。

ただし、その動作は驚くべきものです。 100人に複数の要素を持つ変数をエクスポートするとどうなるかを尋ねると、そのうちの90人は、値が区切り文字としてスペースと連結されていると言うでしょう。 区切り文字としてコンマまたは他の文字が使用されていると言う人もいるかもしれません。 また、 envを実行した2人は、 cat -evtのようなもので出力をフィルタリングしない限り、レコードの区切り文字が表示されないため、値は区切り文字なしで連結されていると言います。

＃2090のような問題に現れます

申し訳ありませんが、そのユーザーの苦情には何のメリットもありません。 この問題は、MANPATHがすでに設定されているかどうかを明示的にテストすることで簡単に回避できます。 これは、先頭のコロンと末尾のコロンのセマンティクスを考えると、いずれにしてもあなたがしなければならないことのように思えます。

そのため、コロンが含まれている$ PATHエントリで破損する可能性があります

それを修正するには少なくとも30年は遅すぎます。 非標準の動作になるため、コロンのエスケープ（および拡張してエスケープ文字）を実装しないでください。 最近まで、私はUNIXサポートスペシャリストとして20年以上を過ごしました。 $ PATHまたは同様の変数に埋め込まれたディレクトリにコロンが存在することが問題であると誰かが不満を言うのを聞いたことがありません。

私の好ましい解決策は、splitenv var1 var2var3のような関数です。

（文書化されていない） string splitが十分でない理由は明らかではありませんが、それは問題ありません。 新しい関数が必要かどうかに関係なく、新しい自動分割env変数を追加しないでください。 動作を保証するのに十分に一般的なのは、PATHとCDPATH（およびすでに特殊なケースであるためMANPATH）の2つだけです。 PYTHONPATHのような他の変数は、有用であると判断した場合、ユーザーが明示的に分割できます。

ただし、特定の変数（PYTHONPATHなど）をエクスポートするときに、その要素を特定の区切り文字と連結する必要があることを登録する方法は確かにあるはずです。 これを行う最も自然な方法は、 setコマンドの新しいオプションを使用することです。 例えば、

set -x -S ':' PYTHONPATH dir1 dir2 dir3

これは、レコード区切り文字charが引き続き使用されるユニバーサルvarデータストアでのvarの格納方法には影響せず、そのデータストアからロードされると自動分割されます。 決定されるのは、エクスポート用に登録された区切り文字が文字列補間にも影響を与えるかどうかです。 私の気持ちはそうあるべきだということです。 つまり、上記の「set」コマンドが実行された場合、後続の

echo "PYTHONPATH is $PYTHONPATH"

PYTHONPATHの値を連結するには、スペースではなくコロンを使用する必要があります。 デフォルトの区切り文字は、既存のセマンティクスを保持し、ユーザーの驚きを最小限に抑えるためのスペースです。 PATHのような特殊なケースの変数も、この例ではコロンを使用することに注意してください。 これは現在の動作と互換性がありませんが、新しいセマンティクスと一致しており、それほど驚くことではありません。 言い換えると、エクスポートされた環境では$ PATHの要素がコロンで区切られているのに、

echo "PATH is $PATH"

文字列コマンドは、私が見つけることができる場所には文書化されていません。 また、man stringは、BSD（およびMac OS X）での文字列操作機能を文書化したstring（3）のmanページを示しています。

簡単、虎。 開発バージョンにあります-https：//github.com/fish-shell/fish-shell/blob/master/doc_src/string.txtを参照してください

（文書化されていない）文字列分割が十分でない理由は明らかではありませんが、それは問題ありません。

私の当初の考えは、これは便利な関数なので、この操作は完全に簡単になるというものでした。 @ridiculousfishの提案により、それはさらに何かになり、ある種のストアを調整して、エクスポート時に変数もその文字に結合されるようにします。 string splitは、文字列を分割する単なるコマンドです。基本的には、 cutのバージョンです。

これを行う最も自然な方法は、setコマンドの新しいオプションを使用することです。

私はセマンティクスで完全に売られているわけではありませんが、それは別のオプションです。 例： set -S ':' PYTHONPATH 。 それはPYTHONPATHを空のリストに設定しますか、それとも既存のPYTHONPATHを分割するだけですか？ これまでのところ、すべての設定オプションは前者を実行しているため、 set -S ':' PYTHONPATH $PYTHONPATHを実行する必要があります。 または、それを行わないようにし、同じツール内で一貫性を持たないようにします。

つまり、エクスポートされた環境では$ PATHの要素がコロンで区切られているのに、 echo "PATH is $PATH"の出力ではスペースで区切られているのはなぜですか。

それは実際には良い質問です。 もちろん、区切り文字がfor p in $PATH; echo $p; endのように表示されることは期待できませんが、変数ごとの区切り文字と結合するのが正しい方法かもしれません。 もちろん、手動で行うにはstring joinがあります。

ただし、その動作は驚くべきものです。 100人に複数の要素を持つ変数をエクスポートするとどうなるかを尋ねると、そのうちの90人は、値が区切り文字としてスペースと連結されていると言うでしょう。

調査による設計と魚の作成には一般的な問題があります。 調査対象の人々は頻繁にbash（および程度は低いが他のPOSIXyシェル）の知識を持っているのに対し、魚のアイデアそのものは、POSIXの少なくとも一部を放棄することによって_より良い_何かをすることです。

それが完全に無価値であると言っているわけではありません、それは覚えておくべきことです-私たちがこれらの種類のアイデアに固執するならば、私たちはbashの言葉を分割する振る舞いとif-fiを持っているでしょう。

set -S ':' PYTHONPATHはPYTHONPATHを空のリストに設定しますか、それとも既存のPYTHONPATHを分割するだけですか？

空のリストに設定されます。 ユーザーが既存の値を保持したい場合は、明示的に含める必要があります（以下を参照）。

エクスポートまたは補間のために特定の変数の配列要素を連結するときに使用される文字（または空の文字列）を構成する手段を除いて、必要なすべての機能がすでにあります。 誰かがPYTHONPATHのような変数を操作したい場合は、それを単純な文字列として扱うことができます。

set PYTHONPATH "/a/new/dir:$PYTHONPATH"

または、配列として扱うこともできます。

set -S ":" PYTHONPATH /a/new/dir (string split ":" $PYTHONPATH)

文字列に補間するときにスペースではなく分割/連結文字を使用するという私の提案は、ユーザーが変数を配列に分割するかどうかに関係なく、一貫した動作を提供することに注意してください。

委員会による設計を提案しているわけではありません。 そのように、zshのような狂気とボゴシティがあります。 私は単に、2つ以上のオプションが与えられ、他の理由がない場合は、シェルのユーザーを最も驚かせないオプションを選択することが最良の選択であることを指摘しています。 また、（今のところ）自動分割変数（もちろん、PATHとCDPATH以外）などの新しいコマンドや動作を導入することに反対しているのもそのためです。 これは、まれにしか実行されない種類のことであり、通常はconfig.fishと、Anacondaの「アクティブ化」スクリプトなどのいくつかの特殊な関数でのみ実行されます。 また、ユーザーがconfig.fishでvarを配列に既に分割しているかどうかに関係なく、後者を正しく動作させる方法は、常に分割する必要のある文字列として扱うことです。 たとえば、PYTHONPATHを修正する必要がある場合は、次のようになります。

# Hypothetical snippet from the Anaconda activate script.
if test (count PYTHONPATH) -gt 1
    set -S ':' PYTHONPATH /activated/python/tree $PYTHONPATH
else
    set PYTHONPATH "/activated/python/tree:$PYTHONPATH"
end

または、もっと簡単に言えば、

# Hypothetical snippet from the Anaconda activate script.
set -S ':' PYTHONPATH /activated/python/tree (string split ':' $PYTHONPATH)

はい、それは潜在的に単純な文字列であったかもしれないものを配列に変える可能性があります。 しかし、 -Sスイッチで指定された文字は、その変換を配列にエクスポートおよび補間するときに使用されるという私のルールでは、実際には重要ではありません。 ただし、1つのコーナーケースがあります。 ユーザーがconfig.fishで変数を配列に明示的に変換しておらず、上記の架空のスクリプトのようなものを実行した場合はどうなりますか。 varは潜在的に複数要素の配列になります。つまり、後で

for elem in $PYTHONPATH
   echo $elem
end

これは、仮想の「アクティブ化」スクリプトによって行われる分割に気づかなかったため、ユーザーが期待するように、コロンで区切られたディレクトリの形式の値でforループの本体を1回だけ実行することはありません。 ユーザーがそのようなことをするのは厄介なので、私たちはそれで生きることができると思います。

tl; drリストは区切り文字を「記憶」する必要があると思いますが、以下がその理由です。

私は上記のほとんどの多くに同意します。 ただし、まだ面倒に思えるのは、上記のコマンドがまだ過度に冗長に見えることです。 つまり、これらのコマンドの一部を平易な英語で説明する方が簡単な場合があります。

例として（そして私は繰り返されるものの数ほど長さに焦点を合わせていません）：

• 魚： set -S ':' PYTHONPATH /activated/python/tree (string split ':' $PYTHONPATH)
• 英語：「 /activated/python/treeをPYTHONPATHに追加（ : -delimited`）」

ここには、 PYTHONPATHと区切り文字:の2つの繰り返しがあります。 PYTHONPATHを繰り返す必要があるということは、2つの理由でほぼ間違いなく問題ありません。また、これら2つの理由のどちらも区切り文字には当てはまりません。

1. 誰かがset PYTHONPATH /activated/python/tree $PYTHONPATHと言ったときに何が起こっているのかを直感的に理解するのは難しくありません。これは、非常によく知られている概念/イディオムであるi = 2 + iのようなものと非常に似ているからです。 （ただし、 +=のようなショートカットはまだあります。そのため、以下に--appendフラグを提案します。）一方、リストへの追加について考えるとき、分割については考えません。区切り文字で参加します。 彼らは、リスト全体を他の形式に変換し、実際の操作を実行して、元に戻すことを考えていません。 彼らの心の中では、彼らは当然、区切り文字を「内部」または「優先」区切り文字に変更するのではなく、区切り文字として読みます。
2. 追加にプレーンなsetコマンドを使用すると、2つの異なるリストを結合するための別のコマンドを追加する手間が省けます。 一方、ある区切り文字から別の区切り文字への変換は、主に上記の理由により、理想的にはユーザーに手動で行わせたくないものです。

対照的に、リストで区切り文字を指定する別の方法を提案します。それをリストに無期限に関連付けます。 したがって、上記の例は次のように実行できます。

# Changes the delimiter for this list. This might be done in some global config file for common lists as this one.
set -S ':' --no-modify PYTHONPATH
# or, workaround if you don't want to add extra options to set:
set -S ':' PYTHONPATH $PYTHONPATH

# The actual append operation
set --prepend PYTHONPATH /activated/python/tree
# or, workaround if you don't want to add extra options to set:
set PYTHONPATH /activated/python/tree $PYTHONPATH

含意/フォローアップ質問/など：

1. これは、現在の提案とかなり互換性があります。 必要な変更は次のとおりです。
   
   
   
   • 区切り文字をスティックにします（おそらく__fish_sep_PYTHONPATHとして別の変数を使用します）
   
   
   • （オプション）現在--no-modifyと呼んでいるフラグを追加します。これは、リストの内容を変更せずにリストの区切り文字を変更するように魚に指示します。 上記の理由（1）のために、 --append ＃$フラグと--prependフラグも追加する可能性があります。 とにかく、これは必須ではありません。上記の回避策が示すように、今日の魚で追加と追加がどのように行われるかを示しています。
   
   
2. 魚では、リストは少なくとも一級市民のように_扱われる_必要があります。 これは、区切り文字を変更すると、リスト表現ではなく文字列表現が変更される必要があることを意味します（区切り文字が要素の1つに存在する場合を除き、その場合、分割は避けられません）。 たとえば、区切り文字を,から:に変更する場合、 ["0:1", "2"]は["0", "1,2"] ["0", "1", "2"]になるはずです（これがリストの裏にある文字列を変更せずに区切り文字を変更するだけで発生します）。 この動作は、現在の動作との互換性と、現在デフォルトの不変の区切り文字があるという事実を最大化する必要があります。

結論は次のとおりです。

• これにはトークンがはるかに少なく、ほとんど何も繰り返されません。
• これは、多くのユーザーが持っているメンタルモデルに似ています。 ユーザーは、「追加」、「区切り文字の設定」、「変更しない」という用語で考えます。
• これは、このタスクを実行する唯一の正しい方法のように見えます（古い方法は今では非常に不器用に見えます）。したがって、これらの追加は直交性を破壊しません。

set --no-modify -S : PYTHONPATH
set --prepend PYTHONPATH /activated/python/tree

@szhu 、私の提案に関する詳細なコメントをありがとう。 ただし、提案されたソリューションには多くの問題があります。 たとえば、 -no-modifyオプションを追加すると、実際には変数がリストに変換されて変更され、変数が変更されます。 私はあなたの提案のほとんどすべての要素を拒否しますが、それは私にあなたのポイントのすべてではないにしてもほとんどに対処するより簡単な解決策について考えさせました。 おそらく、特定のenv varが常に自動的に分割され、特定のトークン（たとえば、「：」または「」）で再構成される必要があることを魚に伝えるメカニズムが必要です。 これは自動配列指定と呼ばれる場合があり、実行されると、既存の値がまだ配列でない場合はすぐに分割されます。

この動作をアクティブにするために、新しいオプションをsetコマンドに追加できます。 ただし、そうすることはあいまいであり、値のない変数を定義するものとして解釈される可能性があることを懸念しています。 setコマンドに-Aトークンオプションを追加することは明確ですか？ 例えば：

set -x -A ':' PYTHONPATH

おそらく、コロンで分割された後、既存のPYTHONPATH envvarをすぐに配列に変換します。 逆に、文字列にエクスポートまたは補間されると、値がコロンに連結されます。 同様に、コマンドの実行時にPYTHONPATHが存在しなかった場合でも、自動配列の指定が記憶され、その後の使用に影響します。 たとえば、これは明らかに配列を作成します。

set PYTHONPATH /a/path /b/path /c:/d/path

しかし、その最後の議論はどうですか？ 自動的に2つのトークンに分割する必要がありますか？

この動作はエクスポートされた変数にのみ適用される必要があり、そうでない場合はエラーが発生することに注意してください。 綴りが必要ないくつかのコーナーケースもあります。 たとえば、元の自動分割宣言に次の例のような値が含まれている場合はどうなりますか。

set -x -A ':' PYTHONPATH 'hello:goodbye' $PYTHONPATH

これらの値は自動分割トークンで分割する必要がありますか？ または、エラーが発生し、値の変更を別のステートメントで行う必要がありますか？ また、どちらの構文を選択しても、自動分割トークンを含む値をどうするかという問題があります。 悪魔は細部に宿っています。 つまり、私が考えていなかったこの提案の他の影響があるかもしれないということです。 より冗長な構文を使用した私の元の提案は、私が知る限り、これらの問題を回避します。

@ krader1961 、ご回答ありがとうございます。 しかし、あなたは私が変数を文字列からリストに変換していると思っているようです。 あなたは魚の重要な概念の1つを誤解していると思います。すべての変数は文字列のリストです。 文字列のように見える変数は、実際には長さ1のリストです。魚はそれらを長さ0または2またはその他の長さのリストと同じように扱います。

また、区切り文字を変更すると、環境変数の受け渡しに使用される基になる文字列が変わる可能性がありますが、魚の強みの1つは、ユーザーが通常、区切り文字についてまったく考える必要がないことです。 これが、 -Sオプションで、このリストを魚の外にエクスポートするときに文字列に変換する方法を指定することをお勧めする理由です。 -Sは、魚内リストの表現を変更しないでください（ターゲット区切り文字を使用してそのリストを表現できない場合を除く）。

ちなみに、これが私の提案がどれほどきれいかを示す一例です。 変数$Lをデフォルトの区切り文字\x1eに戻すためのコードを次に示します。 今日の魚で作成できる変数（スコープ、アイテム数）にはまったく影響しません。

set -S \x1e L $L

もう1つ、引数の--no-modifyファミリーは単なるショートカットです。 同等のものは次のとおりです。

| ショートカット| 同等|
| --- | --- |
| set [other args] --no-modify L | set [other args] L $L |
| set [other args] --prepend L $TOADD... | set [other args] L $TOADD... $L |
| set [other args] --append L $TOADD... | set [other args] L $L $TOADD... |

（前に次のように述べましたが、今はもっとうまく説明できると思います。）これらの3つの議論がいかに「馬鹿げている」かを強調することで、それらが必要かどうか疑問に思う人もいるかもしれません。 魚には直交性の設計原理があると言う人もいるかもしれません。 すべてが直交している場合、これは、実行したい大きなタスクについて、そのタスクを実行するために選択する機能のセットが明確である必要があることを意味します。それを実行する正しい方法は1つだけである必要があります。 ここで、リストに変更を追加/追加/防止する別の方法を実際に追加しますが、これは、置き換えられる同等のものが不必要に冗長であると思うからです。 変更リストを追加する正しい方法ではありません。 これを自分に納得させる1つの方法は、リストへの追加についてどのように考えるかを考えることです。 「 $Lを$L $TOADDに設定する」ではなく、「 $TOADDを$Lに追加する」と思うかもしれません。

あなたの考えを教えてください、そしてこれが私の提案に対してより説得力のあるケースになるかどうか。 （また、私が物事を誤解することはかなり一般的ですので、遠慮なく私を訂正してください。）

@szhu私は、魚のすべての変数が0、1、またはそれ以上の値のリストであることをよく知っています。 また、関連する区切り文字が内部表現や、値がユニバーサルデータストアに保持される方法（区切り文字の保存以外）に影響を与えてはならないことを明確に述べている以前のコメントも読んでいないようです。 あなたは私の前のポイントにも言及しませんでした。 最後の例を考えてみましょう。

set -S \x1e L $L

Lにすでに2つ以上の値が含まれている場合は、どうすればよいですか？ おそらく、関連する区切り文字を変更する以外に何もありません。 その場合、 $ L引数はオプションでしょうか？ または、最初に既存の配列を単純な文字列に変換し（おそらく、既存の区切り文字を使用して連結します）、次にその文字列を新しい区切り文字で分割する必要がありますか？ 前にも言ったように、悪魔は細部に宿っています。

最終的に、確立された設計者と保守担当者は、 --no-modifyファミリーの関数を追加するかどうかを決定しますが、コストに比べて十分な価値がないため、私は反対票を投じます。

申し訳ありませんが、このスレッドは長いです。上記の承認を逃したに違いありません。 同じページにいることを知っておくとよいでしょう。 上記の懸念事項のほとんどにも対処したと思いますが、すべてではありません。 以下では、それぞれの懸念事項について具体的に説明します。

1. set -S \x1e L $Lの$Lオプションですか？

setの既存の動作は変更されません。 現在の動作では、 set L $LはLを変更せず、 set LはLを空のリストにします。 set -S \x1e L $Lおよびset -S \x1e Lと同じです。

1.1 set -S \x1e L $Lは、区切り文字を変更するだけでは冗長に見えませんか？

少し。 そのため、このショートカットとして--no-modifyオプションを提案します。

しかし、このショートカットが存在しなくても、私の計画は崩壊しません。 リストを追加するとき、私たちはすでにこの問題に毎日対処しています： set PATH ~/.bin $PATH 。 そのため、同じ理由で、 --prependと--appendも提案します。

2.変換プロセスはどのように行われますか？

古い区切り文字が\x1eで、新しい区切り文字が$ :であり、魚のリスト["hello", "world"] （ hello\x1eworldとしてエクスポート）があるとします。 変換を行うための2つの基本的な方法があります（「変換オプション」）：

1. ["hello", "world"]を使用して、 ["hello", "world"]に変換します（ hello,worldとしてエクスポートされます）
   利点：リストの表現は変わりません。
2. hello\x1eworldを使用して、 ["hello\x1eworld"]に変換します（ hello\x1eworldとしてエクスポートされます）
   利点：エクスポートされた値の表現は変更されません。

これは、実装の観点ではなく、UIの観点からのものであることに注意してください。 私たちはそれがユーザーにどのように見えるかについて話している。 次の質問で実装について説明します。 _注：この回答の残りの部分は、あなたの質問に促されて、私が上で取り上げていない新しいものです。 ありがとう！_

魚の中。 まず、私たちが完全に魚で作業している場合、リストは一流であり、区切り文字について心配する必要はないので、どちらも必要ありません。 （繰り返しますが、「すべき」はユーザーの観点からです。開発者として、これを実現するのは私たちの責任です。）

変数のエクスポート形式を変更します。 したがって、ユーザーが区切り文字を変更する必要がある唯一の理由は、環境変数を読み取るプログラムのエクスポートされた文字列を変更することです。 魚で作成されたリストの場合、リストとしての変数の意味が重要で明確に定義されているため、変換オプション1を必ず使用します。したがって、リスト表現を保持する必要があります。

varsのインポート形式を変更します。 ただし、最初に魚の外部で作成されたPATHのような環境変数の場合、既に区切り文字が含まれているリストの場合、その区切り文字が何であるかを魚に伝える必要があります。 このために、変換オプション2を使用できます。

2.1これはどのように実装されますか？

Fishは、ユーザーがこれを知る必要はありませんが、実際にはリストを文字列として格納します。 変数xはhello\x1eworldとして格納されます。 私の提案では、変数xの区切り文字を指定する別の変数__fish_delimiter_xがあります。 現在は存在しないため、デフォルトの区切り文字\x1eを使用します。

変換オプション1の場合：

1. 古い区切り文字で変数を分割すると、実装言語（C ++）で真のリストが作成されます。
2. 新しい区切り文字を使用してリストに参加すると、新しい文字列が生成されます。
3. 新しい区切り文字を__fish_delimiter_xに保存します。

変換オプション1の場合、同等の実装：

1. 変数で、古い区切り文字のすべての出現箇所を新しい区切り文字に置き換えます。
2. 新しい区切り文字を__fish_delimiter_xに保存します。

変換オプション2の場合：

1. 新しい区切り文字を__fish_delimiter_xに保存します。

2.2両方の変換オプションが必要な場合、ユーザーはどちらを使用するかをどのように指定しますか？

おそらく、2つのオプションがあります。オプション1の場合-Dまたは--convert-delimiter 、オプション2の場合-dまたは--set-delimiterです。

2.3本当に両方のオプションが必要ですか？

現在の魚の下では、魚の外の野生では\x1eは見られないと仮定することを選択します。 これをデフォルトの区切り文字として保持し、この仮定を維持する場合、変換オプション1は区切り文字の変換と設定の両方に十分であり、変換オプション2は必要ありません。 （これを確信する簡単な方法は、仮定が真の場合、外部で作成されたリストを変換するときに、変換オプション1のステップ「古い区切り文字のすべての出現箇所を新しい区切り文字に置き換える」は何も行わず、変換全体が減少することを理解することです。変換オプション2へ。）

@ridiculousfish 、特にUIと実装の詳細に関して、これについてもフィードバックをいただければ幸いです。 ありがとう！

ここには2つの問題があるようです。 最初のものについて話しましょう。

真の配列の場合は+1

そのセパレータートリックは本当に魚に必要ですか？ Ping＃627

変数値の文字列表現を配列に変換するための互換性のない2つの方法があることに気付いた、問題＃2106の修正に照らしてこれを再検討します。 そのうちの1つは、空の要素を誤って削除しました。 中心的な問題は、 class env_var_tがwcstringのベクトルではなく、 wcstringに基づいていることです。 それを変える価値があるかどうかは議論の余地があります。

この問題をフォローしている場合は、PR＃4082を確認し、おそらくテストすることをお勧めします。 これに対処する最善の方法は、zshの同じ名前の機能に似た「結び付けられた」変数であると判断しました。

これらのコロンでエクスポートされたリストを取り巻く質問と、このホワイトリストに含めるべきenvvarsは、まだ決定されていないようです。 この件の現状はどうなっていますか？ このトピックの最終的な解決策を期待できますか？ ちょうど今日、LD_LIBRARY_PATHがホワイトリストにないという罠に再び遭遇しました...

要約すると、Unix環境変数は文字列であるため、配列のようなenv変数は区切り文字を使用する必要があります。 ほとんどの場合、コロン（$ PATH）を使用します。 すべてがそうするわけではありませんが（$ LESS）。 インポート/エクスポートのすべての配列を区切るためにコロンを使用したいと思います（実際、魚はこのように機能していました）。 問題は、一部のフラット変数にコロン（$ DISPLAY、$ SSH_CONNECTION）が含まれていることです。

目標は、区切られた変数を魚の配列サポートで自然に機能させることです。 @szhuは、区切り文字を追跡するためにsetを拡張することを提案しましたが、$＃$ set $＃$を拡張するIMOは、これを添付するのに間違った場所です。

• 変数の設定とその区切り文字の設定の間の煩わしい相互作用（ --no-modifyの動機付け）。
• 区切り文字が変数スコープとどのように相互作用するかについてのトリッキーな質問。
• ユニバーサル変数に関する問題。 uvarsで変数を現在の値に設定する方法がないため、区切り文字を覚えておくようにuvarsに教える必要があります。また、 --no-modifyについても教える必要があります。

レビューでは、 @ fahoのsplitenvのアイデアを支持します。 splitenv nameは、既存の変数をコロンで分割します。それだけです。 素晴らしくシンプルです。 コロンを使用しない変数は非常にまれであるため、特別なサポートは必要ありません。

欠点は、魚がエクスポートした配列がコロンで区切られた文字列として再インポートされることです。 実際には、これはまれだと思います。

回避できるのであれば、このsplitenvの複雑さをユーザーに負わせるべきではありません。 したがって、さらに一歩進んで、コロンのホワイトリストを、名前がPATHで終わるすべての環境変数（ LD_LIBRARY_PATH、PYTHONPATHなど）に展開します。実際には、これはほぼ常に正しいことを行うはずです。 噛まれた人は誰でもstring joinを使って値を修正できます。

だから私が提案するもの（本当にfahoの提案）：

• コロンを使用してすべての配列をエクスポートします。 ASCIIレコード区切り文字はもう必要ありません。
• コロンで変数を分割するsplitenv関数を実装します。 これは魚のスクリプトで書くことができます。
• コロンで区切られたホワイトリストを、PATHで終わるすべての変数に拡張します。

これにより、コロンで区切られた配列に関連するほとんどの問題に、最小限の互換性のある方法で対処できると思います。

splitenvのアイデアに関して：

たとえば、 ["item1", "item:2"]のように、アイテムにコロンが含まれているリストを魚にエクスポートしたいとします。 （特に配列を使用してユーザー入力を格納する場合、これはまれなことではないと思います。）

リストはitem1:item:2としてエクスポートされますか？ その場合、エクスポート後に元のリストを再作成することはできません。

また、変数の不変のホワイトリストを持つことは間違っていると感じますが、ホワイトリストを*?PATHにすることはそれほど間違っているとは感じません。 （これが、区切り文字を変数として格納するという私の提案のもう1つの理由でした。ホワイトリストは、変数を設定することで変更できます。）

@szhuその通りです。 Exported-lists-can't-contain-colonsは、Unixがすでに苦しんでいる問題です。

以来 \

だから私は魚に同じ制限を導入することについてそれほど悪くは感じません（エクスポートされた変数のみ）。

また、この問題は、配列を再帰的に呼び出されたfishインスタンスにエクスポートする場合にのみ発生しますが、これはまれだと思います。 これが一般的であることが判明した場合は、サイドカーデータを別の変数にアタッチするか、魚を再帰的に呼び出すときに別の配列区切り文字を使用することができます。 私の推測では、それほど遠くまで行く必要はないでしょう。

提案がうまくいかないというエッジケースはあまり一般的ではないことに同意しますが、人々がそれに遭遇した場合、それは本当に悪いことになるのではないかと心配しています。

部分的にしか作成されていない例を次に示します。

set -x TEST color:red 
set -x TEST2 color:red font:serif
set -x TEST_PATH color:red 
set -x TEST2_PATH color:red font:serif
exec fish
echo $TEST #=> color:red
echo $TEST2 #=> color:red:font:serif
echo $TEST_PATH #=> color red 
echo $TEST2_PATH #=> color red font serif

上記を見て、多くの新規ユーザーが混乱していることが想像できます。

次の動作の方がはるかに快適だと思います。

set -x TEST color:red 
set -x TEST2 color:red font:serif
set -x TEST_PATH color:red 
set -x TEST2_PATH color:red font:serif
exec fish
echo $TEST # color:red
echo $TEST2 # color:red font:serif
echo $TEST_PATH #=> color:red 
echo $TEST2_PATH #=> color:red font:serif

これについてあなたとコミュニティの考えをお願いします。

既存のコロンを脱出してみませんか？ それは区別を維持するでしょう。

エスケープは私には理にかなっています。

変数が配列であるかどうかが記憶されないことは、まだ混乱する可能性がありますか？

set -x TEST2 color:red font:serif
set -x TEST2_PATH color:red font:serif
exec fish
echo $TEST2 # color\:red:font\:serif
echo $TEST2_PATH #=> color:red font:serif

はい。 私の仮説は、パスリストの外では、配列のエクスポートは一般的ではないということです。

MANPATHは、二重コロン（：:）に対して特別な意味を持っています-＃2090を参照してください-これは、作品にスパナを投げますか？

また、サイドカー変数FISH_ARRAY_VARIABLES=FOO\t:\nBAR\t;\nBAZ\t-\nを使用することは、他のプロセスを妨害することなく、また「私たちは今魚を巻き込む」チェッカー。

再： https ：//github.com/fish-shell/fish-shell/issues/436#issuecomment -392409659 @zanchey
＃2090の詳細は読んでいませんが、コロンで区切られた文字列形式と配列形式の間の変換は完全にシームレスであると思います（コロンが配列項目に表示されない場合を除く）。

MANPATHにダブルコロンを含めるには、ダブルコロンが表示される場所に空の文字列を追加するだけです。

$ set -x MANPATH 1 2 '' 3
# Check if it's set
$ bash -c 'echo $MANPATH'
1:2::3

MANPATHをコロンで開始するには、先頭に空の文字列項目を追加するだけです。

$ set -x MANPATH '' 1 2 3
# Check if it's set
$ bash -c 'echo $MANPATH'
:1:2:3

ここではすべてをフォローしているわけではありませんが、ユーザーとして「構成なし」を提唱したいと思います。
set -Sとsplitenvは構成の形式だと思います。 一部のユーザーは、fish.configでそれらを実行し、PYTHONPATHを配列として処理します。 他の人は、PYTHONPATHを単一のコロンで区切られた単語として処理しません。 スタックオーバーフローのアドバイスをコピーして貼り付けたり、あるユーザーから別のユーザーにPYTHONPATHを操作するスクリプトを実行したりすると、常に機能するとは限りません...

修正された「 PATHで終わる場合」のルールは構成が不要で、：+ 1：を取得できる限り完璧に聞こえます。
（後方互換性の価値があるかどうかについては意見がありません）
はい、 set -x TEST2_PATH color:red font:serifはcolor red font serif配列としてインポートされますが、これは変数のエクスポートに関する処理です。 エクスポートされた変数を実際に配列に設定するには、その動作を理解する必要があります。

はい。 私の仮説は、パスリストの外では、配列のエクスポートは一般的ではないということです。

@ridiculousfishは現在の貝殻に当てはまるかもしれませんが、魚の牽引力が増すにつれて、ユーザーは魚の能力を利用して子魚の貝殻にリストを送信したいと思うかもしれません。 魚のセッションの状態を管理するプログラム/プラグインが最終的に存在する可能性があり（これが本当かどうかを確認するために数年後にこのコメントをチェックします）、リストを普遍的に自動デコード/シリアル化できるようになると想像できますそのコードをよりクリーンにし、回避策を減らします-y。

似ているが少し異なる考えのようなものです。 PATHを特殊なケースとして扱うことは、ユーザーがシェルの典型的なユースケースの履歴を持っている場合にのみ理解できる時代錯誤的なエッジケースです。 これにより、一般的なスクリプト言語として使用される魚の能力が制限され、将来の潜在的なユースケースが制限されます。

@ridiculousfish考えられる解決策の1つは、各環境変数/配列を独自のセパレーターに関連付けることだと思います（そして、デフォルトとして'\x1e'または' 'または':'を保持できます）。また、環境変数を作成するユーザーは、競合を回避するために適切なセパレーターを選択する責任があります。 コマンドは次のようになります： set --separator ':' TMP 1 2 3 。 したがって、これらのよく知られた環境変数の場合、ユーザーは対応するよく知られたセパレーターを選択するだけで、他のプログラムでも認識でき、魚をより多くのプログラム（Pythonなど）との互換性を高めることができます。

最近のコメントだけを読んでいる人のために、 @ thuzhfのset --separator推奨は、このスレッド全体で繰り返し言及されているset -S推奨と同じであることに注意してください。 そのディスカッションのコンテキストをさらに把握するには、このページをset -Sでgrepできます。

@szhu前のset -Sに気づかずにすみません。 それは基本的に私も欲しいものです。 また、この新しいオプションについて他の人が懸念していることにも気づきました。 これらの懸念について以下に考えてみましょう（魚のセットではオプションとして-sを使用していないため、以降は-sを使用して--separatorを参照します）。

1. --no-modifyは何かを変更します。 はい。名前を明示的に変更する必要があります（例： --change-separator 。
2. いくつかのコーナー/トリッキーなケースがあります。 これは基本的に構文が明確に定義されていないためであり、構文を厳密に定義すれば自然に回避できます。 例えば：
   
   
   
   1. 基本的な考え方：すべての変数（リスト）は、定義時に独自のセパレーターに関連付けられます（デフォルトは' 'です）。 このセパレータは、この変数が文字列から作成されるとき、および文字列に変換されるときに使用されます（これは、Pythonのjoin()関数などの一部の言語では一般的な考え方です）。 varは、エクスポートされるとき、またはユーザーがこれを実行したいときに文字列に変換されます。
   
   
   2. 環境変数を作成する方法
      
      
      
      
      
      1. set ENV_VAR a b c 。 -sがない場合、デフォルトの区切り文字として' 'を選択します。
      
      
      
      2. set -s ':' ENV_VAR 。 この場合、ENV_VARは空のリストに設定されます。
      
      
      
      3. set -s ':' ENV_VAR a b:c d e:f 。 この場合、このコードを作成するユーザーは、 ':'が区切り文字であり、ENV_VARが['a b', 'c d e', 'f']のような配列になり、 'a b:c d e:f'としてエクスポートされることを明確に理解する必要があります。 エクスポートされたENV_VARがスペースで始まり、スペースで終わるようにしたい場合はどうなりますか？ set -s ':' ENV_VAR \ a b:c d e:f\のようなエスケープを使用する必要があります。 その場合、ENV_VARは[' a b', 'c d e', 'f ']になり、 ' a b:c d e:f 'としてエクスポートされます。
      
      
      
      4. set -s ':' ENV_VAR a b:c d e:f $ENV_VAR 。 この場合、 $がどのように機能するかによって異なります。 リストではなくENV_VARの文字列値を抽出するように定義されている場合、このコマンドは、$ ENV_VARを下のリストから変換された文字列値に置き換えるのと同じになります。この場合、 set -s ':' ENV_VAR a b:c d e:f:$ENV_VARは次のようになります。おそらくあなたが本当に欲しいもの（ f $の後の$ :に注意してください）; ENV_VAR（文字列ではなくリスト）の変数を抽出するように定義されている場合、これはPythonの場合と同様にリスト拡張操作になるはずです。 たとえば、後者の場合、 ENV_VARが前に['x', 'y']であった場合、この操作の後、 ENV_VARは['a b', 'c d e', 'f', 'x', 'y']になります。 ENV_VARの前の区切り文字が':'でない場合はどうなりますか？ 前者の場合、正しいことを行っていることを確認するのはあなたの責任です。たとえば、元の区切り文字を':'に変更するか、現在の区切り文字を元の区切り文字に変更して、一貫した区切り文字を使用する必要があります。 後者の場合、これにより、この配列のセパレーターが元の配列から（それが何であれ） ':'に設定されます。
      
      
      
   
   
   3. 区切り文字の変更方法
      
      
      
      
      
      1. set --change-separator ':' ENV_VAR 。 ENV_VARが存在しない場合、プログラムは0以外のエラーコードで終了する必要があります。簡単で明示的です。
      
      
      
   
   
   4. セパレータの見方
      
      
      
      
      
      1. set --view-separator ENV_VAR 。
      
      
      
   
   

その上、この問題は明白で緊急であり、ユーザーにとって大きな問題であると私は本当に思います。これはユーザーエクスペリエンスに大きな影響を与えるため、この問題をできるだけ早く解決できることを願っています。 実は、これほど大きな魚を除いて、今のところ魚を使っている他の（非常に小さな）問題に遭遇したことはありません。

この問題は明白で緊急だと思います

@thuzhf ：あなたはそれを過大評価していると思います。

理由の1つは、＃5169の問題が$ LD_LIBRARY_PATHにあったことですが、それは実際には魚のリストではありません。 他のシェルと同じように、 set LD_LIBRARY_PATH "$LD_LIBRARY_PATH:/some/path"のように設定する必要があります。

Fishは、正確に3つの継承/エクスポートされた変数を自動的にリストに変換します。

$ PATH、$ MANPATH、および$ CDPATH。 そして、まさにこのリストには、エクスポート時に「：」区切り文字があります。

$ LD_LIBRARY_PATHのような他の「標準化された」変数は、fishscriptのリストとして処理されるべきではないため、この問題は発生しません。 標準化されていない変数は、他のプログラムがとにかくそれらを処理しないため、好きなように処理できます。したがって、セパレーターは重要ではありません。

@faho明確な説明をありがとう。 それは私にとって本当に理にかなっています。 OK、この問題は私にとって解決されたと言えます。

＃2090で説明されているMANPATHの問題を調べました。 シナリオは、システムパスを引き続き使用するようにmanpathに追加することです。

bashでは、これをexport MANPATH="$MANPATH:/new/path"と記述します。 MANPATHが設定されている場合、これが追加されます。 設定されていない場合、これはコロンを付加します。これは、システムディレクトリを使用するための男性固有の指示です。 この構文は魚では機能しません。 問題は、MANPATHが配列であるため、「$ MANPATH」にはコロンではなくスペースが含まれることです。

「変数を結び付ける」アプローチでは、たとえばfish_manpathを、コロンで区切られた文字列としてMANPATHをミラーリングする配列として使用できます。 これは完全に魚のスクリプトで構築できます。 ただし、MANPATHだけでなく、すべてのパスのような変数に対してこれを実行する必要があります。これは、管理方法が明確ではない重大な互換性の低下になります。 また、同じ問題があります。たとえば、zshのmanpath配列変数は追加するのが面倒なので、なぜ存在するのかは明確ではありません。

ここでの私の提案は、MANPATHの状況を良くも悪くもしません。 やるべきことはパントであり、MANPATHに追加するための簡単なストーリーがあると思います。これは次のとおりです。

set -q MANPATH || set MANPATH ''
set -x MANPATH $MANPATH /new/path

config.fishに貼り付けるのはそれほど苦痛ではありません。

ここでの私の提案は、MANPATHの状況を良くも悪くもしません。 やるべきことはパントであり、MANPATHに追加するための簡単なストーリーがあると思います。これは次のとおりです。

@ridiculousfish ：私はさらに一歩進むことを考えていました。実際には、これらの特別な変数を割り当て時に「：」で分割し、引用符で囲まれた展開でスペースの代わりに「：」で結合します。

つまり、 set -gx MANPATH "$MANPATH:/new/path"を実行すると、魚が自動的に分割を実行し、結果としてset -gx MANPATH "" /new/pathに相当します。

これは、「：」が$ MANPATH（および$ PATH、および$ CDPATH）のパスに表示されないことを意味しますが、魚以外のユーティリティが破損するため、とにかく表示できません。

それはまた、それを処理する相互互換性のある方法を追加するので、おそらくいつか特別な処理を削除することを可能にします-あなたは:で割り当て、 (string split : -- $MANPATH)でそれを使用する必要があります

@faho私はその考えに熱心です-ユーザーはどのようにして変数をこの特別な扱いを受けているとマークしますか？ splitenvはそれをしますか？

ユーザーは、変数をこの特別な扱いを受けるものとしてどのようにマークしますか？

私の考えは、実際にはマーキングをまったく許可しないことでした。$ PATHなどの特別な動作としてそのままにしておいてください。 これにより、将来のある時点でリスト化から逃れることができます。

ただし、他の変数でこれを許可すると、他の変数でも役立つことがわかりました。たとえば、外部との互換性のために、$ EDITORが1つの要素（ set EDITOR "emacs -nw" ）として設定されていることを前に説明しました。ツールですが、魚はそれがリストであればもっと良いと思います。

したがって、PATHに似ている場合を除いて、区切り文字としてデフォルトで_space_を使用することになります（名前がPATHで終わる場合はおそらく問題ないと仮定します）。

splitenvはそれをしますか？

私はこれのために別のビルトインを導入するのが本当に好きではないので、おそらく引数から設定へのオプションを使用するでしょう。

「特別な場合のPATH / MANPATH / CDPATHは奇妙です。より一般的な解決策が必要です」と私は同意します。

特殊ケーシングのPATH / MANPATH / CDPATHを停止することを提案します。 それらは（魚のエンドユーザーによって）他の殻と同じように扱われます。 $ PATH（およびその他）は、コロンを含む単一の文字列（または、魚の専門用語では長さが1のリスト）になります。 これらが内部でどのように処理されるかではなく、魚のユーザーエクスペリエンスに言及していることに注意してください。 魚の内部での実装がどのようになるかはわかりません。他の人に問題を指摘してもらいます。

確かに、後方互換性がないというデメリットもありますが、シンプルさとエレガンスを大幅に向上させる価値があると思います。 ＃2090にも対応すると思います。

みんなどう思いますか？

5245がマージされたため、これは解決されたようです。