620(2): デフォルトの名無しさん [sage] 2019/12/23(月) 23:43:56.19 ID:gENEPh5i(1) AAS
WindowsがーではなくCygwinの問題でしょ
WindowsはWindowsの仕様でやってる。それがなんであれ正しい仕様

Cygwinがエミュレート機能をすべて行ってる
問題があるならそれはCygwinの問題

WSLならその問題も解決してるだろうさ

619(1): デフォルトの名無しさん [sage] 2019/12/23(月) 23:39:27.27 ID:IO6RyZUn(6/7) AAS
>>618
こちらの状況は正しく伝わっており、君の言っていることも正しい。
こちらも615を書いた後、遠い昔にシンボリックリンク周りでトラブった記憶があり、
あれはなんだったかな？と思っていたところだった。

つまりbashで上手く誤魔化していてくれているわけだ。
ではtcshは？と確認したが、こちらもsymlinks変数で誤魔化し方を調整出来るようになっている。
外部ﾘﾝｸ[html]:linuxjm.osdn.jp
結果、Cygwinとしては仕様通り、UNIXは糞仕様（≒仕様バグ）だな。

突っ込む必要はないと思うが、
> (引数の..が親ディレクトリの意味になるかはコマンドに依存するから、シェルが勝手に置き換えられない)
これはよく分からない。
bashがコマンドに引数を渡すときにあらかじめシンボリックリンク周りを解決していたら、どういう問題が発生する？
というかtcshだとsymlinks=expandに設定したらそうなるらしい。
今回で言えば、
MyMachine@MyName /cygdrive/d/dev/debug
$ cp ../some_file .
を cp /cygdrive/d/dev/somefile /cygdrive/d/dev/debug として実行すれば問題ないはず。
(.を展開する必要はないかもだが）
既存シェルスクリプトの互換性が無くなるだけなら仕様バグでした、残念でした、でしかなく、
後発のwindowsでは修正されているということになる。
シンボリックリンクを辿って、その上の「論理的ではない、物理的上位ディレクトリ」を辿る必要がある使い方なんて無いはず。

なお上記man of tcshのsymlinksの最後の
> > cd ".."; echo $cwd
> /tmp/from
> > /bin/echo ..
> /tmp/to ←これがよく分からん、/tmpではなくて？あるいはコマンドが .. ではなく /bin/echo . なら納得だが
> > /bin/echo ".."
> ..
分かれば出来れば解説よろしく。