Cygwin + MinGW + GCC 相談室 Part 8 (987ﾚｽ)
上下前次1-新
608: デフォルトの名無しさん [sage] 2019/12/23(月) 15:39:18.43 ID:Losi+wwQ(2/4) AAS
mklink /? で普通に表示されるのに
それすらやったことないのか？
609: デフォルトの名無しさん [sage] 2019/12/23(月) 15:40:22.34 ID:Losi+wwQ(3/4) AAS
共有フォルダ作るときなんか
シンボリックリンクとジャンクションの違いを知らないと困るだろうが
610: デフォルトの名無しさん [] 2019/12/23(月) 15:41:13.85 ID:sEnpgkKc(3/4) AAS
みなさん思いのほか親切ですね
611(1): デフォルトの名無しさん [sage] 2019/12/23(月) 15:47:56.41 ID:nbY+qllN(1) AAS
>>604604(1): デフォルトの名無しさん [sage] 2019/12/23(月) 13:59:53.49 ID:IO6RyZUn(3/7) AAS
>>602
それはそうだが普段シンボリックリンクである事なんて意識しないからな。
いまだにcygwinではNTFSのシンボリックリンクを辿れないのはしょぼいと思うが。
なお32bit版。bashはversion4.4.12(3)、cygwin1.dll はversion 3001.2.0.0
（昨日の時点でsetup.exeを使いBestに更新）
64bit版なら行けるのかも？誰か動作報告よろしく。
シンボリックリンクもジャンクションも辿れるし、環境変数の設定(CYGWIN=winsymlinks:nativestrict)によってはln -sやtarの展開でNTFSのシンボリックリンクができる
NTFS側でD:とかをリンク先にしても、勝手に/cygdrive/d以下に読み替えてくれる
cygdrive以下だけ動かないなら、/etc/fstabの設定がおかしいとか?
612(2): デフォルトの名無しさん [] 2019/12/23(月) 15:48:24.03 ID:sEnpgkKc(4/4) AAS
だけどシンボリックリンクωを名乗ってるだけでシンボリックリンクではないですねこれ
613: デフォルトの名無しさん [sage] 2019/12/23(月) 15:52:08.05 ID:Losi+wwQ(4/4) AAS
難癖つけたいんなら、具体的に問題を指摘しろや
614: デフォルトの名無しさん [sage] 2019/12/23(月) 15:54:08.35 ID:qAO2lZtX(1) AAS
Windowsには
1.ハードリンク
2.ジャンクション
3.あほなシンボリックリンク
4.だるいシンボリックリンク
がある
615(1): デフォルトの名無しさん [sage] 2019/12/23(月) 16:12:25.30 ID:IO6RyZUn(5/7) AAS
>>611
すまんが、/cygdrive以下だけ動かない、というのは間違いだった。
動作としては、シンボリックリンクを辿ることは出来るが、戻れない、というものだ。
本来はシンボリックリンクはカレントと共に使用される。
つまりD:/dev/debugがシンボリックリンクでそこにD:/devからcdして入ったら、 cd .. だとD:/devに戻って来れないといけない。
（シンボリックリンク先に入った時の元に戻る。他から入ったらそこに当然戻る）
これが出来ておらず、debugしかないディレクトリ（というものを作って渡しているのだと思う）に戻ってしまう。
だから下から上が参照出来ない。上から下は参照出来るし、
下から上でも自分に戻ってくるのなら参照出来る。（言葉だと分かりにくいが要するに以下が通る）
MyMachine@MyName /cygdrive/d/dev/debug
$ less ../debug/some_file
下から上でもファイル名の補完は出来るのでbash自体は動作してる。
なお cd ../.. とシンボリックリンクを跨いで2つ上がることは可能。
cdってbashのコマンドだっけ？だとして、やはりbash自体は動作してる。
bashから各アプリに渡す時に失敗しているか、cygwin1.dll自体が対応してないか、だと思う。
バグ報告してもいいけど、それ以前に64bit環境の動作を確かめてからでないとウザがられる。
というわけで普段から64bit環境で使っている人がいたら試してみてくれ。
>>612
いや完全にシンボリックリンクだよ。
ln -s と使い勝手は同じ。
616: デフォルトの名無しさん [sage] 2019/12/23(月) 16:26:38.22 ID:CGg4xw4r(2/2) AAS
cygwinはもう永眠させてやれ
WSLに乗っ取られた
617: デフォルトの名無しさん [sage] 2019/12/23(月) 18:46:28.73 ID:wtBUbgEZ(1) AAS
>>612
黙れ！
618(1): デフォルトの名無しさん [sage] 2019/12/23(月) 22:27:33.69 ID:nMe23UdH(1) AAS
>>615
何をしようとしているか大体分かった。
・/cygdrive/d/dev/debug はシンボリックリンクで /cygdrive/d/test/debug を指すと仮定
・/cygdrive/d/dev/some_file があると仮定
このとき
・まずcd /cygdrive/d/dev/debugする
・次にcp ../some_file .するとファイルが無いと言われる
ということだと思う。もしそうならそれがUNIX系では普通。LinuxやMacでもそうなる。
これは、cdした時点で既にカレントディレクトリが/cygdrive/d/test/debugに移っているからで、cpは/cygdrive/d/test/some_fileを読もうとしているために起こる。つまり
>本来はシンボリックリンクはカレントと共に使用される。
がUNIX的には正しくない。
実際の挙動としては、
・UNIXの場合、カーネル的にはカレントディレクトリはあくまでもディレクトリで、シンボリックリンクをパスの途中に含むことはできない
・cd ..でもといたディレクトリに戻るのはbashがシンボリックリンクを本当のデイレクトリのようにエミュレーションしているから(set -Pで切れる)
・これは基本的には内部コマンドのcdやpwdに対してのみできることで、外部コマンドのcpやlessに対してはできない(引数の..が親ディレクトリの意味になるかはコマンドに依存するから、シェルが勝手に置き換えられない)
・シェルはPWD環境変数にシンボリックリンクを含むロジカルなカレントディレクトリを出力するので、これを見るようにすれば原理的には外部コマンドもエミユレーションに対応できる(危なっかしいので普通はしない)
WindowsのシンボリックリンクはUNIXと違ってOS自体がシンボリックリンクを含むカレントディレクトリを扱っているようだが、CYGWINはUNIXに合わせていると考えられる。
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 ".."
> ..
分かれば出来れば解説よろしく。
620(2): デフォルトの名無しさん [sage] 2019/12/23(月) 23:43:56.19 ID:gENEPh5i(1) AAS
WindowsがーではなくCygwinの問題でしょ
WindowsはWindowsの仕様でやってる。それがなんであれ正しい仕様
Cygwinがエミュレート機能をすべて行ってる
問題があるならそれはCygwinの問題
WSLならその問題も解決してるだろうさ
621: デフォルトの名無しさん [sage] 2019/12/23(月) 23:58:57.35 ID:IO6RyZUn(7/7) AAS
>>620
それは違う。
Cygwinはエミュレーションレイヤーを提供しており、つまりUnixのシステムコールを受け付けているだけ。
だから仕様としてUnixと同じ動作になる。
詳しくはWikiなり本家なり読めばいい。
問題はUnixの糞仕様が今も修正されずそのままbash等で誤魔化され続け、
windowsでは修正された？為に動作が異なっている事による。
ただこれをCygwinで修正することは出来ないし、するべき事柄でもない。
622: デフォルトの名無しさん [sage] 2019/12/24(火) 00:05:26.55 ID:8h2rOUkn(1/2) AAS
> Cygwinはエミュレーションレイヤーを提供しており、つまりUnixのシステムコールを受け付けているだけ。
ただしい
? だから仕様としてUnixと同じ動作になる。
○ 仕様としてUnixと同じ動作になるように目指すべきだが、できてない
623(2): デフォルトの名無しさん [sage] 2019/12/24(火) 00:06:45.59 ID:8h2rOUkn(2/2) AAS
なんか文字化けする方法のバツを記録してるな。これでいいか？
× だから仕様としてUnixと同じ動作になる。
○ 仕様としてUnixと同じ動作になるように目指すべきだが、できてない
624: デフォルトの名無しさん [sage] 2019/12/24(火) 00:22:04.30 ID:6GYTbaHl(1/4) AAS
>>620
なおWSLは理屈上はUnixの動作になるはず。
ただしbash等を見る限り既知の問題だから対策出来そうではあるが、
バイナリ互換なので現実的に無理だと思う。
(もちろんwindows専用bashを用意すればいいが、それだと既存のシェルスクリプトが動かなくなる。
といってもそれで問題が発生するような奴はWSLなんて使わずDockerだと思うが）
が、まあ、俺に関して言えば、
問題の詳細は判明し、特段問題ないから当面はCygwinを使う。
(すまんがNGに当たっているようなのでバラバラにして投稿する）
625: デフォルトの名無しさん [sage] 2019/12/24(火) 00:23:19.80 ID:6GYTbaHl(2/4) AAS
(すまんがNGに当たっているようなのでバラバラにして投稿する）
>>623
> ○ 仕様としてUnixと同じ動作になるように目指すべきだが、できてない
違う。そこを目指してない。
CygwinはUnixのシステムコールをcygwin1.dllが受け付けることにより、
GNU等が書き溜めた膨大なUnix向けCソースをそのまま動作させることを目標としている。
結果、ありとあらゆるUnixのツールがcygwin上では動くので、大成功している。
626: デフォルトの名無しさん [sage] 2019/12/24(火) 00:24:32.17 ID:6GYTbaHl(3/4) AAS
>>623続き
windowsのＣＭＤ。ＥＸＥのエミュレーションなんて必要ないし、目指してもいない。
本家でも読め。
そして認識も間違っている。CygwinはUnixと同じ動作になってる。つまり、「できてる」
627(3): デフォルトの名無しさん [sage] 2019/12/24(火) 00:29:23.48 ID:d/S5Qnsu(1) AAS
>>619
・tcshのmanは間違っているだけだと思う。実際試したら想定通り/tmpになった。
・シェルが勝手に置き換えるべきではないというのは、単にgrep ..とかの動作が今までと変わって直感的でなくなるあたりの問題。.や..の置き換えの仕様とエスケープやクォートの仕様を十分理解すればまあそんなに困らないとは感じる。
628: デフォルトの名無しさん [sage] 2019/12/24(火) 00:49:31.91 ID:6GYTbaHl(4/4) AAS
>>627
おおサンクス、手元にこなれた環境がないので助かる。
しかし今更このレベルの誤字ってあるかね？
まあtcshなんて今時誰も使ってないが、他のマニュアルもそうなってるし。
外部ﾘﾝｸ:linux.die.net
とはいえ実行結果がそうなのならそれが一番信憑性があるが。
Unixは今更直せないで行くのだろうけど、WSLの際にMS内部ではどうするか検討してるだろうね。
WSL推しの人はどうぞ動作報告よろしく。
629: デフォルトの名無しさん [] 2019/12/24(火) 15:52:35.51 ID:IBUEMR4t(1) AAS
WSLの話題はこちらへどうぞ 2chｽﾚ:linux
cygwinの話題は引き続きこのスレでどうぞ
630(1): デフォルトの名無しさん [sage] 2020/01/05(日) 00:06:31.37 ID:RxmL5T69(1) AAS
>>627
ばーーーか
631: 627 [sage] 2020/02/21(金) 14:13:26.80 ID:3bMJAyBr(1) AAS
>>630
ごめんなさい。
632: デフォルトの名無しさん [sage] 2020/03/07(土) 09:24:50.59 ID:6t68C04E(1) AAS
このところ、MSYS2 の pacman を実行するとエラーが出るな
サーバー不調なん？それとも pacman がバグった？
一度アンインストールして最初から入れなおしてもダメやった・・・
上下前次1-新書関写板覧索設栞歴
あと 355 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.026s