いくつかのディレクトリがあるとします:
/Users/user1/ApplicationThing/
/Users/user1/Documents/
/Users/user1/other/directory/it/doesnt/matter/
main.shにファイルがあり.../ApplicationThing/、それが別のファイル に依存しているとしますdependancy.sh。
main.sh他のどのディレクトリにも移動して、をその WD を CWD として実行できるようにし、コンテンツ.../ApplicationThing/ディレクトリがシステム上の他のすべてのディレクトリにあるかのようにします。 の場合のようにではなく$PATH、コンテンツが実際にディレクトリ内にあるが、オートコンプリートや にもポップアップ表示されないかのようにしますls -l。
答え1
これは、別の作業ディレクトリで呼び出された場合でも、特定の場所から依存関係を見つけるように ApplicationThing を修正する必要があるように思われます。
環境変数を設定することでこれを実行できます:
export ApplicationThingHome=/Users/user1/ApplicantionThing
main.shそして、その変数の値を使用して、その変数のすべての依存関係を参照します（変数が設定されていない場合は、必要に応じて適切なデフォルト値を使用します）。例：
${ApplicationThingHome:-/usr/local/ApplicationThingDefaultDir}/dependancy.sh
の代わりに
./dependancy.sh
次に、main.shのディレクトリを に配置して$PATH、任意のディレクトリから使用できるようになります。
提案された解決策には問題があります。他のディレクトリにいて、たとえば または という名前のファイルを作成したい場合main.sh、dependency.sh代わりに ApplicationThing のそれぞれのファイルを上書きすることになります。文字通り、ApplicationThing に属するファイル以外は所有/使用できなくなりますmain.sh... ディレクトリはまさにそのような問題を回避するために発明されたのです。
もちろん、最初に実行されたときにのみ「疑似ファイル」が存在するという条件にすることもできます...ただし、その場合、期待どおりに動作しない場合にトラブルシューティングを行うために、何が表示されるかをmain.sh確認するための別のツール セットが必要になります。main.sh
ApplicationThingを修正できない場合は、システム上のどこからでもApplicationThingを呼び出すラッパースクリプトを作成し、それ$PATH に含まれるディレクトリ内のスクリプト:
#!/bin/sh
# set the correct working directory for silly ApplicationThing
cd /Users/user1/ApplicationThing
# if ApplicationThing has any other environment requirements,
# this would be a great place to ensure they're satisfied too.
# Now execute the main.sh of ApplicationThing, giving it any
# command line arguments that were given to this script, exactly as-is.
exec ./main.sh "$@"
このスクリプトは別のプロセスとして実行されるため、cdスクリプト内のコマンドはスクリプトを呼び出すセッションにはまったく影響しません。execを実行する際のキーワードにより、main.sh呼び出しシェルと の間に余分なプロセスが残されることがなくなりますmain.sh。
このアプローチでは、main.shファイル名をパラメータとして受け取る場合、相対パス名は呼び出しセッションの CWD に対する相対パス名ではなく、ApplicationThing のディレクトリに対する相対パス名として解釈されるため、絶対パス名としてファイル名を指定main.shする必要があります。
それが問題になる場合は、コマンドラインパラメータを に渡す前に、より複雑な前処理を記述する必要があるかもしれませんmain.sh。このStackExchangeの質問適用できると思われるアイデアがいくつかあります。