よくある質問¶
さて、だれも実際に誰にも尋ねなかったかもしれません。
1.なぜxonsh？¶
xonshのアイデアは、物理学のEffective ComputationのBashの章（私の共著者Katy Huffによって書かれた）を見直しながら、まず打ちました。この本では、パイピングなどの重要で複雑なアイデアを説明する時間を費やしています。しかし、if文やループなど、Bash言語のより基本的な側面には触れません。たとえ10年以上にわたってBashをよく使用してきたとしても、 2つの数値を一緒に追加する方法や配列を一貫して作成する方法はわかりません。これは正常です。
ツールがとても悪い場合は、新しいツールが必要になるかもしれません。だから、xonshは他のシェルが "あなたの脳に合っていない"という問題を解決することを本当に意味します。プログラミングの状況によっては、コンパイラの最適化、型の安全性、証明可能な正当性、レジスタアクセスなどの理由でOKです。しかし、あなたの脳に合わないシェルは、単なる責任です。
偶然、週内に記事がHacker Newsのトップに浮かん で、Cでシェルを書く方法を教えてくれたので、「それは難しいことではない」と思った。
そして再び、私は危険ゾーンに入った。
なぜ、別のエキゾチックな殻がないのfishですか？¶
他の多くの代替シェルには、従来のオプションのシンタックスが大幅に改善されているだけでなく、機能も豊富ですが、Pythonほど美しくないものはありません。xonshでは、あなたはすべての可能な世界の中で最高のものを手に入れます。あなたの脳とあなたが望む任意の機能に既に適合する構文。
3.なぜIPythonコマンドラインインターフェイスを使用しないのですか？¶
このアプローチには2つの重大な欠点がありますが、私はそれを試しました。
最初!に、すべてのサブプロセスコマンドの前にタイプするのは非常に面倒です。私はこれがプレフィックス演算子であり、それであなたがそれをやろうとするときに、あなたがしようとしていることを妨害しているからです。!後置演算子を作ることでこれのいくつかに対処することができますが、おそらく厄介なことにはなりません。
2番目の理由は、a !
が機能しなかった後のサブプロセスコマンドのタブ補完である。これは日常的な使用のためのディール・ブレーカーです。
4.それでは、これはどのように機能しますか？¶
xonshコードをトークン化して解析するには、PLYを使用します。これはpycparser
がこのPLYをどのように使用したかに大きく影響されます。私たちのパーサから、Python ast標準ライブラリモジュールにあるノードだけを使って、抽象構文木（AST）を構築します。これにより、通常のPythonツールを使用してASTをコンパイルして実行することができます。
もちろん、xonshには特別な組み込み関数があるため、実際にコードを実行する前に適切なコンテキスト（組み込み関数、グローバル、ローカル）を設定する必要があります。しかし、ASTはどんな文脈からも完全に独立して構築することができます...ほとんど。
xonsh言語の文法は文脈自由ですが、実行者を文脈に敏感なやり方で書くのが便利でした。これは、特定の式がPythonモードまたはサブプロセスモードに属しているかどうか不明確であるためです。たとえば、ほとんどの人はリストコマンドを見て、
それを見ます。ただし、およびPythonの変数はあったが、これは同等（パイソン）の表現に変換することができたり。どちらも有効なリストコマンドではありません。ls -llslls - lls-l
このようなあいまいさを解消するためにxonshが行うことは、式（lsおよびl上記）の中の名前が現在のPythonコンテキストに含まれているかどうかを確認することです。そうであれば、書かれているように有効なxonshになります。いずれかの名前が見つからない場合、xonshは一番左の名前が外部コマンドであるとみなします。したがって、未取得のサブプロセス呼び出しでその行をラップした後、その行を解析しようとします![]。ラップされたバージョンが正常に解析された場合、その![]バージョンはそのままです。それ以外の場合は、元の行が保持されます。
状況依存解析はすべて、コードが実行される前にAST変換として行われます。これにより、コードが失敗する前に部分的に実行されることはありません。
文脈依存解析は人間にとって便利なものであることに注意することが重要です。あいまいさが残っているか正確が必要な場合は、単に手動で使用し![]、!()、$[]または$()あなたのコードの演算子を。
5.文脈依存の解析は総体的です¶
はい、状況に応じた解析は大雑把です。しかし、xonshのポイントは、xontext-sensitive構文解析を使用し、最終的にBashのような他のシェル言語よりもはるかに少ないことです。さらに、その使用はここで大きく制限されています。
6.私の枝はタイムアウトしていますか？¶
システム、セットアップ、およびリポジトリのサイズに応じて、ブランチの名前と色を計算する（ブランチが汚れているかどうかなど）、かなり遅い操作になります。これは悪いニュースです。なぜなら、xonshはフォーマットするたびにこれらを計算することができるから$PROMPTです。
xonshをきれいにするために、分岐計算のタイムアウトを実装しました。これは、$VC_BRANCH_TIMEOUT
環境変数を介して公称値（通常は0.1秒）に設定されます。
これを自由に設定してください。したがって、潜在的に遅いプロンプトを気にしない場合は、1,5、20、100秒に設定してください！ただし、遅いプロンプトに対処したり、タイムアウトメッセージが表示されないようにするには{curr_branch}、{branch_color}との{branch_bg_color}
部分を削除することができます$PROMPT。これらの値は決して計算されません。
それは{branch_color}、通常はゆっくりとしたポークであることにも注目する価値があります。ただ色のルックアップを削除するだけで$PROMPT、ブランチ名は十分に速くなります。
7. exec¶
の概念execは、xonshのトリッキーな獣のビットです。Pythonと基本的に他のすべてのシェル言語には、根本的に異なる操作を実行するexecがあります。
- Pythonでは
exec、提供された名前空間内の文字列、AST、またはコードオブジェクトを実行する組み込み関数です。 - sh-langs（と他の場所）では
exec、現在のプロセスで別のコマンドを直接実行するコマンドです。
これらの2つのアイデアは両方の言語にとって中心的なものであり、それがなければほとんどのプログラムを実行できません。幸いにも、名前を共有していても、構文が異なり、名前空間を共有しません。したがって、xonshでは、
# exec() as a function is run as Python's exec
>>> exec('x = 41; x += 1', globals(), locals())
# while exec as a statement is like bash's exec
>>> exec gdb
(gdb)
はい、これは潜在的に混乱します。以前のバージョンのPythonには、構文がsh-langコマンド形式で衝突したexec文があったので、これは特に当てはまります。
はい、申し訳ありません。しかし、代わりに、SSHやgdbのように、execの中でexecを使う重要なプログラムは、xonshがデフォルトのシェルとして設定されているときは使用できません。シェルの最も重要な側面は使いやすさであり、xonshは大きなクラスの重要なコマンドに対して潜在的な混乱を起こします。
execの二重性が問題を引き起こしている場合、混乱を緩和するために実装できる操作はいくつかあります。1つは、execエイリアスを削除してxexec代わりにエイリアスを使用できることです。
>>> del aliases['exec']
>>> xexec ssh
あるいは、常に![]またはサブプロセスモードで明示的にexecコマンドを実行することもできます!()。
>>> ![exec bash]
最後に、exec（）関数の結果をthrow変数に代入することができます（戻り値は常にNoneです）。
>>> _ = exec('x = 42')
うまくいけば、このトレードオフは理にかなっていて、キメラ殺しがあなたのバッグでない限り、それについて心配する必要はありません。
8.ゴッチャ¶
複数のバージョンのPythonでxonshを使用する場合、基本的なPythonの動作が異なる可能性があるため、いくつかの動作が異なる場合があります。
例えば、double star globbing **は、Python 3.5以降では再帰的なglobbingが新しいため、Python 3.5以降でのみ動作します（3.4ではなく）。
