私が従ったチュートリアルの1つはcd .
は役に立たない。 OPで示された問題を シンボリックリンクの再帰-何で「リセット」するのか を再現しようとすると、cd .
、これはOPと同じ効果を示した(成長中$PWD
変数)、cd -P
。
これは私が不思議に思う、誰かが実際にcd .
?
これは問題を考えすぎていると思います。 cd .
は、通常の手順で手動で実行するものではないかもしれませんが、プログラムで実行すると発生する可能性のあるものです(ディレクトリにcd
する可能性がある状況を考えてください)パスがユーザーによって指定されたファイルを含む)。したがって、特定の用途は必要ありません。cd <some-path>
の通常のセマンティクスを満たしている限り、便利です。
最後のコマンドが実行されてからディレクトリのパスが変更されている可能性があり、_cd .
_がないと、bashおよびksh93シェルは質問にリンクされている投稿に記載されている論理作業ディレクトリに依存するため、_cd .
_を呼び出しますこれにより、シェルはgetcwd()
syscallを発行して、現在のパスがまだ有効であることを確認します。
Bashで再現する手順:
mkdir ./dir_no_1; cd ./dir_no_1
_を発行mv dir_no_1 dir_no_2
_echo $PWD
_およびpwd
を発行します。ディレクトリの名前が外部的に変更されていることに注意してください。シェルの環境は更新されていません。cd .; pwd; echo $PWD
_を発行します。値が更新されていることに注意してください。ただし、ksh93は環境情報を更新しないため、ksh93の_cd .
_は実際には役に立たない場合があります。 Ubuntuおよび他のDebianベースのシステムの_/bin/dash
_では、_cd .
_は_dash: 3: cd: can't cd to .
_エラーを返しますが、_cd -P .
_は機能します(ksh93とは異なります)。
cd .
のもう1つの使用例は、現在いるディレクトリが削除されてから再度作成された場合です。以下を試してみてください-
temp
cd temp
、次にls
を実行しますtemp
ls: cannot open directory .: Stale file handle
cd .
そしてlsを実行すると正常に動作します「興味深い」場所を指したくない場合は、クイック$OLDPWD
を使用してcd .
をクリアできます。 cd -
にも影響します。
プログラム的には、ノーオペレーションとして役立ちます。外部入力から提供されるパスを考えます。
read -p "Path to file: " p
dirn=$(dirname "$p")
file=$(basename "$p")
echo "dirn=$dirn, file=$file"
cd "$dirn"
ls -ld "$file"
「fred.txt」などのパスを使用すると、ディレクトリは.
になり、cd .
になります。
これは、不良のUSBケーブルで作業する必要があった場合に一般的です。デバイスが切断されて再び接続され、同じディレクトリに自動マウントされた後、cd .
を使用してデバイスを再び機能させる必要があります。
ご了承ください "。" is任意のプロセス(もちろんシェルプロセスを含む)の現在の作業ディレクトリとして開いているファイルの名前を指定する適切な方法、および "。"は常に、現在の作業ディレクトリを含む、すべてのディレクトリにあるファイルの有効な名前です。名前_.
_は、たとえば、基礎となる現在の作業ディレクトリが削除されている(または、古くなったNFSハンドルなどの "不良"になっている)場合、プロセスの特定のインスタンスのファイルの有効な名前ではない可能性があります。これは、すべての有効なディレクトリに存在することが保証されているファイルの有効な名前です。
したがって、_.
_mustは、ディレクトリの名前を受け入れる任意のコマンドの有効な引数である必要があるため、標準のシェルでは_cd .
_は有効なコマンドでなければなりません。
_cd .
_が役立つかどうかは、シェルの実装によって異なります。前述のように、基礎となるchdir
システムコールを呼び出した後、シェルが現在の作業ディレクトリの完全パス名の内部概念をリセットすると、たとえば、基礎となるディレクトリ(またはその親)が名前が変更されました。
少なくとも私が知っているいくつかのシェル(FreeBSDおよびNetBSDでは_/bin/sh
_)は_cd ""
_を_cd .
_に変換します。これは、変数がシェルスクリプトでプログラム的に使用できるようにする機能と言えるでしょうパラメータとして使用する(つまり、空の変数置換を「何もしない」結果に変換する)。ただし、FreeBSDコミット履歴は、変更がchdir("")
による失敗を防ぐためのPOSIXサポートの追加によるものであると述べています。 POSIX指令は失敗するはずです。
他のいくつかのシェルは、_.
_を現在の作業ディレクトリへの完全修飾パス名として保存したものに置き換えます。したがって、これらのシェルは Sahil Agarwalの回答 で述べた動作を可能にする可能性があります。
このコマンドを使用したのは、Gitで作業していたブランチを、同じブランチで最初に作成されたディレクトリ内からリベースしたときです。リベースはうまくいきましたが、その後、git status
がエラーをスローしました。 cd .
以降、すべて正常でした。
(ちなみに私はWindowsのMobaXtermで作業していました。これを再現しようとしている場合に備えて。他のシステムでは発生しない場合があります。)
また、このコマンドを、古いディレクトリの脇に移動して新しいディレクトリに置き換える自動化されたプロセスによって更新されるディレクトリでも使用しました(そのため、可能な限りアトミックに近くなります)。一般的な状況ではありませんが、cd .
はまさに必要なものです。
ステファンシャゼラスからのこの素晴らしい答えを読んだ後:
上記の使用例が機能するのはbash
を使用しているためです。cd .
はcd "$PWD"
と同等です。リンクされた回答を読むことを強くお勧めします。
私が使う cd .
cd
関数を使用してbash
をオーバーロードしたものを再実行します。
私から ~/.bashrc
:
# from the "xttitle(1)" man page - put info in window title
update_title()
{
[[ $TERM = xterm ]] || [[ $TERM = xterm-color ]] && xttitle "[$$] ${USER}@${HOSTNAME}:$PWD"
}
cd()
{
[[ -z "$*" ]] && builtin cd $HOME
[[ -n "$*" ]] && builtin cd "$*"
update_title
}
EDIT:これはすでに Sahil によって提案されています。
これは、別のプロセスによって削除および再作成されたフォルダー内にいる場合に役立ちます。たとえば、2つの端末セッションを想定すると$1
および$2
:
$1 mkdir d
$1 cd d
$1 touch f
$2 rm -rf /path/to/d # delete the folder where $1 is in ...
$2 mkdir /path/to/d # ... and recreate it
$1 touch g # cannot create file g because current dir doesn't exist anymore
touch: cannot touch ‘g’: Stale file handle
$1 cd . # go to the newly created dir (same path)
$1 touch g # works fine now
この動作の根本的な原因が正確にどこにあるか(OS、シェルなど)はわかりません。