Cygwin + MinGW + GCC 相談室 Part 8

**デフォルトの名無しさん** · 2014/09/23(火) 00:20:11.40

Windows上で動作するフリーの開発環境 CygwinとMinGWに関する相談スレッドです。

過去スレ:
Cygwin + MinGW + GCC 相談室 Part 7
http://peace.2ch.net/test/read.cgi/tech/1357019230/
Cygwin + MinGW + GCC 相談室 Part 6
http://toro.2ch.net/test/read.cgi/tech/1304609116/
Cygwin + MinGW + GCC 相談室 Part 5
http://hibari.2ch.net/test/read.cgi/tech/1269400706/
Cygwin + MinGW + GCC 相談室 Part 4
http://pc12.2ch.net/test/read.cgi/tech/1221233882/
cygwin + mingwn + gcc 相談室 Part3
http://pc11.2ch.net/test/read.cgi/tech/1177944767/
cygwin + mingwn + gcc 相談室 Part2
http://pc11.2ch.net/test/read.cgi/tech/1126103347/
cygwin + mingwn + gcc 相談室
http://pc8.2ch.net/test/read.cgi/tech/1058134693/

関連サイト:
Cygwin http://www.cygwin.com/
MinGW http://www.mingw.org/

関連スレッド:
GCCについて part10
http://toro.2ch.net/test/read.cgi/tech/1315026784/

**デフォルトの名無しさん** · 2019/06/15(土) 00:44:39.57

>>516
https://ja.forvo.com/word/cygnus/#la

こうか

**デフォルトの名無しさん** · 2019/06/15(土) 11:12:22.87

Cognac
Tough
Lamborghini
を思い出す

**デフォルトの名無しさん** · 2019/06/20(木) 22:49:09.67

クンタッシ

**デフォルトの名無しさん** · 2019/06/22(土) 19:12:03.45

>>523
ぶぁーか

**デフォルトの名無しさん** · 2019/06/23(日) 05:49:44.99

MinGW更新が滞っています

**デフォルトの名無しさん** · 2019/06/24(月) 05:27:39.62

>>526
MinGW-W64 project のやつは滞ってるけど、
MSYS2 project のやつ(pacmanで入れるやつ)は滞ってないよ(9.1.0)。

**デフォルトの名無しさん** · 2019/06/24(月) 12:32:30.26

msys2もWSL2で役目終了かな

**デフォルトの名無しさん** · 2019/06/24(月) 16:47:30.43

そして焼け野原

**デフォルトの名無しさん** · 2019/06/25(火) 20:17:15.80

>>529
一言余計なんだよカス

**デフォルトの名無しさん** · 2019/06/25(火) 20:43:23.33

効いてるw

**デフォルトの名無しさん** · 2019/06/25(火) 21:35:27.64

https://gcc-mcf.lhmouse.com/?C=M&;O=D

ここちゃんとチェックしてるか？9.1.1まで出てるぞ

**デフォルトの名無しさん** · 2019/06/26(水) 01:21:30.62

>>532
普通チェックしないし使わない

**デフォルトの名無しさん** · 2019/07/02(火) 16:03:24.73

>>533
効いてるw

**デフォルトの名無しさん** · 2019/08/05(月) 11:53:08.29

clang で良いんじゃないの？ Google もGCC からclang に切り替えたし。

**デフォルトの名無しさん** · 2019/08/13(火) 11:23:23.39

gcc-9.2

**デフォルトの名無しさん** · 2019/08/14(水) 15:59:31.43

> warning: hoge.hpp.gch/fuga.gch: had text segment at different address
9.2でこんなエラーが出るようになってPCHが効かない。ビルド時間が３倍に。
> cc1plus.exe: warning: '-Werror=' argument '-Werror=hoge-fuga' is not valid for C++
あとこんな警告が大量に出るようになって邪魔。

**デフォルトの名無しさん** · 2019/08/20(火) 15:18:40.97

MinGWで作ったバイナリ、コマンドプロンプトで実行するとすごい遅い
一回実行するとキャッシュでもされるのかそれ以降の実行はわりと速い
ひどいときはプロセス間通信を使ってるバイナリで実行から終了まで7秒とかかかったりする

Gitとかはコマンドプロンプトで実行してもすぐに実行されるんだけど、何が違うんだろう
ウィルスソフトのリアルタイムスキャンに時間がかかってるのかと思って、問題のバイナリの除外設定とかしてみたけど、効果なかった

問題のバイナリはプロセス間通信を使ってるから、このプロセス間通信がボトルネックになってるのかなぁ
WindowsのCreateProcessはLinuxのforkに比べるとめちゃくちゃ遅いらしいし

**デフォルトの名無しさん** · 2019/08/20(火) 15:20:15.93

cmd からじゃなくて mintty から実行しても遅いか？

**デフォルトの名無しさん** · 2019/08/20(火) 15:35:04.29

>>539
試してないけど試してみます

**デフォルトの名無しさん** · 2019/08/20(火) 15:50:21.30

mkpasswdとかmkgroupとかやっとかないとあかんのじゃなかったっけ

**デフォルトの名無しさん** · 2019/08/20(火) 17:27:25.95

>>539
mintty, MSYSでは動作が速かったです
cmd特有の「初回起動だけ遅い」というのはありませんでした
powershellでも試してみます

>>541
cmdでも実行は出来てるんですが、なんか初回実行だけ遅いんです
初回以降は速くて、しばらく放置してまた実行すると遅くなってます

**デフォルトの名無しさん** · 2019/08/20(火) 17:37:17.04

キャッシュしてるとしたら socks の dll かな

**デフォルトの名無しさん** · 2019/08/20(火) 17:51:30.05

ログ吐かせてどこにネックがあるのかみてみないと

**デフォルトの名無しさん** · 2019/08/21(水) 17:19:04.83

雑な事いえばminttyやMSYSを起動すると、起動した時点でMinGWのdllが
読み込まれるのでコマンド起動遅くならないのでは

**デフォルトの名無しさん** · 2019/08/21(水) 17:33:03.25

それならそれで解決とするか

**デフォルトの名無しさん** · 2019/08/21(水) 23:34:12.77

dllの読み込みに時間かかってるってことですか
なるほど
ということはMinGWでコンパイルしたバイナリ全般に現れる問題っぽいですね

**デフォルトの名無しさん** · 2019/08/22(木) 04:38:34.97

コマンドプロンプトで実行するようなプログラムは
Windowsネイティブアプリにしろよw

**デフォルトの名無しさん** · 2019/08/22(木) 05:37:28.68

MinGWで作ったら余程変態技を使わない限りWindowsネイティブアプリ

**デフォルトの名無しさん** · 2019/08/22(木) 06:10:29.02

>>548
最初はLinuxで開発してて、それからWindows用に移植したんですよ
で、MinGWが手軽だったからMinGW使ってたんだけど

**デフォルトの名無しさん** · 2019/08/22(木) 10:15:45.06

そんな用途には tdmgcc64 おすすめ

**デフォルトの名無しさん** · 2019/08/23(金) 03:35:27.20

ググっても一件しか出なかった
gccなのはわかる

**デフォルトの名無しさん** · 2019/08/23(金) 15:09:01.75

これやろ
https://ja.wikipedia.org/wiki/TDM-GCC
http://tdm-gcc.tdragon.net/download

**デフォルトの名無しさん** · 2019/08/23(金) 18:17:23.56

>>553
おお、ありがとう
ダウンロードしてみる

**デフォルトの名無しさん** · 2019/08/23(金) 18:24:15.33

今はこっちが良くね
https://text.baldanders.info/remark/2018/03/mingw-w64/

**デフォルトの名無しさん** · 2019/08/24(土) 06:55:34.51

TDM-GCCでビルドしたら遅いの無くなったかもしれない(*´Д｀)！！！
>>551
>>553
もう少し様子見るけど、まじでありがとう

>>555
これはMinGWとは違うの？

**デフォルトの名無しさん** · 2019/08/24(土) 09:36:31.35

staticになってるだけというオチだったらわろす

**デフォルトの名無しさん** · 2019/08/24(土) 14:59:08.43

ただ単に -static -O3 -mtune=skylake を指定していないだけ
じゃねえだろうな？

**デフォルトの名無しさん** · 2019/08/24(土) 17:29:38.98

staticオプションは特に指定しませんが……
dllの読み込みが原因だとしたらstaticにすれば解決という話ですか
そういう発想はなかった

>>558
--mtune=skylakeってなんですか？

**デフォルトの名無しさん** · 2019/08/24(土) 17:48:35.57

DLLよりstaticが速いとか都市伝説

**デフォルトの名無しさん** · 2019/08/25(日) 16:54:37.16

>>559
-O3はコードの最適化を3レベル(あるいはタイプ3)で行う
実際に何を行っているかはコンパイランの説明を読まないと分からない
-mtune=skylakeはコードをIntel CPUのSkyLakeアーキテクチャで最適な形にする
どちらも記述したコードを実行形式にするときに最適化を行うオプションなので、
非常に大きなコードを書いた際や似たような処理を繰り返すコードを書いている際に
指定すると早くなる事もある(ライブラリに含まれるコードは最適化されない)

>>560
都市伝説ってこともない

関数A、B、C、Dが含まれるライブラリlibhogeが存在する場合、自分のプログラムで
関数BとDだけを使っていると、ダイナミックリンクの場合自分のプログラムの実行
コードに加えてすべての関数が含まれるlibhoge.dll全体を読み込む必要がある
スタックリンクの場合には自分のプログラムの実行コードに加えてlibhoge.aから抽出した
関数BとDのコードを読み込むだけなので関数AとCのコードを読み込まない分ロードが
早くなる可能性は高くなる

ただし、実際問題としてはdllを一回読み込めばキャッシュからなくならない限り読み込む
必要がない+Windowsのプログラミングで使用するライブラリで基本的なものは通常
システムを起動した時点でキャッシュされていることに加えて、Windowsでプログラムを
動かすために必要な関数郡はかなりの量になる事が多いのでスタティックにリンクすると
すでにキャッシュされている関数郡を使わずに、必要な関数郡を含んだ大きなコードを
読み込む必要があるのでスタティックリンクの方が起動が遅くなるって本末転倒な事態が
発生することもある

MinGWの場合にはWindows一般では使わないライブラリを使用するので1回目の
起動時には必要なdllを読み込むよりは、必要な関数のみをリンクしたスタティックな
状態の方が早い場合があるかもってこと

**デフォルトの名無しさん** · 2019/08/25(日) 19:02:38.36

もっと短く

**デフォルトの名無しさん** · 2019/08/25(日) 23:51:01.48

>>561
ということは--static -O3 -mtune=skylakeでビルドすれば起動が早くなるかもということですか
時間があるときに試したいと思いますm(_ _)m

**デフォルトの名無しさん** · 2019/08/26(月) 01:28:47.93

やっぱり名前解決の問題が大きいんすよ
ライブラリの読み込みだけでは説明できない

**デフォルトの名無しさん** · 2019/08/26(月) 14:11:24.03

>スタックリンクの場合には自分のプログラムの実行コードに加えてlibhoge.aから抽出した
>関数BとDのコードを読み込むだけなので関数AとCのコードを読み込まない分ロードが

これ関数単位でソース分けてあって
一関数が一objになってる場合だけだよな

**デフォルトの名無しさん** · 2019/08/26(月) 14:11:24.09

>スタックリンクの場合には自分のプログラムの実行コードに加えてlibhoge.aから抽出した
>関数BとDのコードを読み込むだけなので関数AとCのコードを読み込まない分ロードが

これ関数単位でソース分けてあって
一関数が一objになってる場合だけだよな

**デフォルトの名無しさん** · 2019/08/26(月) 17:43:39.53

dll読み込みってそんなに重いかな？
なんか別のところで時間がかかっていそうな感じ。

**デフォルトの名無しさん** · 2019/08/26(月) 21:44:29.54

>>565-566
MinGWの場合はそうかな。確かMinGWでは--gc-sectionsが効かなかったかと。
LTOで未使用関数が除去されるかもしれないけどバグが多いので試してない。

**デフォルトの名無しさん** · 2019/08/27(火) 05:30:30.81

>>563
でビルドしてみました
様子見します
-O3は、前にビルドしたときにプログラムがうまく動作しないことがあったんですよね
-O0にすると正常に動作したんですけど

**デフォルトの名無しさん** · 2019/08/27(火) 09:41:49.02

-O3に完璧を求める方が可笑しい

**デフォルトの名無しさん** · 2019/08/27(火) 11:08:45.95

そこで-Ofastですよ

**デフォルトの名無しさん** · 2019/08/27(火) 12:32:02.21

-O3と-O0で挙動が違うのは、不定の値を使っているとか、
未規定の動作に依存しているとか、そういう系だぞ

まれにコンパイラのバグということもあるが大抵てめーが悪い

**デフォルトの名無しさん** · 2019/08/28(水) 17:10:08.53

VCで造られたdllをmingwのgccで使いたいです
hoge.dll と hoge.lib は有るのですが
libhoge.a がありません
あと hoge.c とかのソースファイルもありません
hoge.def は hoge.dll から作れるのですが
hoge.lib から libhoge.a を作るのはどうすればよかったか思い出せません

**デフォルトの名無しさん** · 2019/08/28(水) 17:25:07.66

https://stackoverflow.com/questions/8683046/compatibility-of-dll-a-lib-def-between-visualstudio-and-gcc

dlltool.exe -m i386:x86-64 -d libhoge.def -D hoge.dll -l libhoge.a
dlltool.exe -m i386 -d libhoge.def -D hoge.dll -l libhoge.a

しらんけど

**デフォルトの名無しさん** · 2019/08/28(水) 17:45:16.06

実際parallelstlをコンパイルするのはVCの方が楽だしな
これを.aに変換したいと思っていたのでありがたいです

**デフォルトの名無しさん** · 2019/09/03(火) 16:24:26.27

9.2.0 Rev2 でPCHのエラーが出なくなった。

**デフォルトの名無しさん** · 2019/09/13(金) 12:46:20.65

本物のWInネイティブアプリの起動はもっと速いのかもしれません。
MinGW+MSYS2がCygwinより速い理由が釈然としませんが、
forkがCygwinのものまんまよりは多少軽量だったりするんだろうか
https://twitter.com/nullpo_head/status/905032098506915840
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2019/09/13(金) 12:48:07.35

ビルド環境のまとめ
http://i.loveruby.net/ja/rhg/cd/buildenv.png
http://i.loveruby.net/ja/rhg/cd/win.html

**デフォルトの名無しさん** · 2019/09/13(金) 13:01:11.82

mingwはその本物のネイティブとちゃうか

**デフォルトの名無しさん** · 2019/09/13(金) 15:13:51.93

cygwin の fork = native じゃなくて emu
mingw の fork = あるんか？

**デフォルトの名無しさん** · 2019/09/13(金) 16:40:00.05

MinGW+MSYS2がCygwinより速い理由は
Cygwinはたとえ遅くなろうとも完璧なエミュレートを目指してるのに対して
MinGW+MSYS2は目指してないから

**デフォルトの名無しさん** · 2019/09/13(金) 18:56:41.57

MSYS2は、Windowsネイティブアプリを作るための環境です。
Windowsネイティブアプリを作りましょう。

**デフォルトの名無しさん** · 2019/09/13(金) 19:47:41.41

>>581
どういうことなの…

**デフォルトの名無しさん** · 2019/09/14(土) 10:05:32.62

fork の歴史 (windows の fork 含む)
https://www.eelsgo.com/cs-CZ/article/fork%20windows
https://support.microsoft.com/ja-jp/help/190351/how-to-spawn-console-processes-with-redirected-standard-handles

**デフォルトの名無しさん** · 2019/09/14(土) 10:32:34.60

なぜ今 fork が熱いのか
https://mao.5ch.net/test/read.cgi/linux/1560665525/

**デフォルトの名無しさん** · 2019/09/14(土) 11:49:59.95

http://www.kobore.net/diary_techno/?date=20180221
http://www.kobore.net/diary_techno/?date=0214
https://books.google.co.jp/books?id=NdmjDwAAQBAJ&;pg=PT819&dq=NTDLL+RtlCloneUserProcess

**デフォルトの名無しさん** · 2019/09/15(日) 06:58:43.73

>>584
むりぽ
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/afdf1b68-1f3e-47f5-94cf-51e397afe073/cygwin-fork-and-rtlcloneuserprocess?forum=windowsgeneraldevelopmentissues

**デフォルトの名無しさん** · 2019/10/02(水) 07:41:31.63

GMPって真面目にソースtarからビルドするしかないの？ビルド済みのバイナリですぐ使えるのがあれば欲しいんだけどcygwinのインストーラでチェック入れてもダメで、なんじゃこりゃってなってるんだけど。

**デフォルトの名無しさん** · 2019/10/02(水) 11:20:07.41

https://stackoverflow.com/questions/19192963/are-there-any-recent-gmp-windows-binary-distributions
http://7shi.hateblo.jp/entry/2012/05/07/034105
https://cs.nyu.edu/~exact/core/gmp/index.html

**デフォルトの名無しさん** · 2019/10/02(水) 11:46:15.82

4.1.2 は解決

**デフォルトの名無しさん** · 2019/10/02(水) 12:47:35.09

>>589
どうでもいいことだが Stack Overflow のURLは削れる。

build - Are there any recent GMP Windows binary distributions? - Stack Overflow
https://stackoverflow.com/questions/19192963

**デフォルトの名無しさん** · 2019/10/02(水) 12:53:13.99

どうでもいいことだが thx

https://stackoverflow.com/questions/19192963/are-there-any-recent-gmp-windows-binary-distributions
と
build - Are there any recent GMP Windows binary distributions? - Stack Overflow
https://stackoverflow.com/questions/19192963/
では前者の方がバイト数は少ない

**デフォルトの名無しさん** · 2019/10/19(土) 01:49:14.48

msys2のpacmanでfdupesがないんですけど、どっからか手に入りますか？

**593** · 2019/10/19(土) 15:58:06.55

arch linuxので解決

**デフォルトの名無しさん** · 2019/11/10(日) 23:46:15.76

長期間更新がありませんが何か支障があるのでしょうか・・

**デフォルトの名無しさん** · 2019/11/14(木) 16:18:35.97

>>595
あるよ

**デフォルトの名無しさん** · 2019/11/15(金) 14:11:12.27

>>595
ないない

**デフォルトの名無しさん** · 2019/11/15(金) 20:34:54.04

ないあるよ

**デフォルトの名無しさん** · 2019/11/15(金) 23:50:32.38

WSL使ったら？

**デフォルトの名無しさん** · 2019/12/23(月) 02:13:46.99

Cygwin って /cygdrive上ではディレクトリまたげないんだけど、これってそんなもんだったっけ？

かなり久しぶりにCygwinを使おうとしているのだが困っている。
ディレクトリ構成 D:\DEV\debug で
下のディレクトリから上のディレクトリのファイルをコピーする、以下のコマンドが通らない。

MyMachine@MyName /cygdrive/d/dev/debug
$ cp ../some_file .

ディレクトリまたげないんだけど、こんなんだったっけ？
なお / をバックスラッシュにしても駄目。
なお/home以下のディレクトリならこれらのコマンドは通る。あまり試していないが、おそらく、/cygdrive以下だけ駄目。

何か設定がおかしい？それともこんなものだったっけ？
なお今のところディレクトリをまたげないだけでカレントについてはコマンドは通る。

**デフォルトの名無しさん** · 2019/12/23(月) 02:30:38.75

>>600
すまぬ自己解決した。
debugがシンボリックリンクだったorz

**デフォルトの名無しさん** · 2019/12/23(月) 12:40:57.34

もちつけ
他人のせいにする前に自分を疑え

**デフォルトの名無しさん** · 2019/12/23(月) 12:45:36.48

自分を疑う自分を疑え

**デフォルトの名無しさん** · 2019/12/23(月) 13:59:53.49

>>602
それはそうだが普段シンボリックリンクである事なんて意識しないからな。
いまだにcygwinではNTFSのシンボリックリンクを辿れないのはしょぼいと思うが。
なお32bit版。bashはversion4.4.12(3)、cygwin1.dll はversion 3001.2.0.0
（昨日の時点でsetup.exeを使いBestに更新）

64bit版なら行けるのかも？誰か動作報告よろしく。

**デフォルトの名無しさん** · 2019/12/23(月) 14:06:09.78

NTFSのリンクはシンボリックリンクではないでしょ

**デフォルトの名無しさん** · 2019/12/23(月) 14:48:39.41

シンボリックリンクあるよ、ジャンクションじゃないやつ

**デフォルトの名無しさん** · 2019/12/23(月) 15:26:21.18

>>605
シンボリックリンクはSever2008/Vistaから導入された。もう10年以上前になる。
https://www.atmarkit.co.jp/fwin2k/win2ktips/988symlink/symlink.html
つかお前、このレベルの話を知らないでその言い草は完全に老害化してるぞ。

**デフォルトの名無しさん** · 2019/12/23(月) 15:39:18.43

mklink /? で普通に表示されるのに
それすらやったことないのか？

**デフォルトの名無しさん** · 2019/12/23(月) 15:40:22.34

共有フォルダ作るときなんか
シンボリックリンクとジャンクションの違いを知らないと困るだろうが

**デフォルトの名無しさん** · 2019/12/23(月) 15:41:13.85

みなさん思いのほか親切ですね

**デフォルトの名無しさん** · 2019/12/23(月) 15:47:56.41

>>604
シンボリックリンクもジャンクションも辿れるし、環境変数の設定(CYGWIN=winsymlinks:nativestrict)によってはln -sやtarの展開でNTFSのシンボリックリンクができる
NTFS側でD:とかをリンク先にしても、勝手に/cygdrive/d以下に読み替えてくれる
cygdrive以下だけ動かないなら、/etc/fstabの設定がおかしいとか?

**デフォルトの名無しさん** · 2019/12/23(月) 15:48:24.03

だけどシンボリックリンクωを名乗ってるだけでシンボリックリンクではないですねこれ

**デフォルトの名無しさん** · 2019/12/23(月) 15:52:08.05

難癖つけたいんなら、具体的に問題を指摘しろや

**デフォルトの名無しさん** · 2019/12/23(月) 15:54:08.35

Windowsには
1.ハードリンク
2.ジャンクション
3.あほなシンボリックリンク
4.だるいシンボリックリンク
がある

**デフォルトの名無しさん** · 2019/12/23(月) 16:12:25.30

>>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 と使い勝手は同じ。

**デフォルトの名無しさん** · 2019/12/23(月) 16:26:38.22

cygwinはもう永眠させてやれ
WSLに乗っ取られた

**デフォルトの名無しさん** · 2019/12/23(月) 18:46:28.73

>>612
黙れ！

**デフォルトの名無しさん** · 2019/12/23(月) 22:27:33.69

>>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に合わせていると考えられる。

**デフォルトの名無しさん** · 2019/12/23(月) 23:39:27.27

>>618
こちらの状況は正しく伝わっており、君の言っていることも正しい。
こちらも615を書いた後、遠い昔にシンボリックリンク周りでトラブった記憶があり、
あれはなんだったかな？と思っていたところだった。

つまりbashで上手く誤魔化していてくれているわけだ。
ではtcshは？と確認したが、こちらもsymlinks変数で誤魔化し方を調整出来るようになっている。
https://linuxjm.osdn.jp/html/tcsh/man1/tcsh.1.html
結果、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 ".."
> ..
分かれば出来れば解説よろしく。

**デフォルトの名無しさん** · 2019/12/23(月) 23:43:56.19

WindowsがーではなくCygwinの問題でしょ
WindowsはWindowsの仕様でやってる。それがなんであれ正しい仕様

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

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

**デフォルトの名無しさん** · 2019/12/23(月) 23:58:57.35

>>620
それは違う。
Cygwinはエミュレーションレイヤーを提供しており、つまりUnixのシステムコールを受け付けているだけ。
だから仕様としてUnixと同じ動作になる。
詳しくはWikiなり本家なり読めばいい。

問題はUnixの糞仕様が今も修正されずそのままbash等で誤魔化され続け、
windowsでは修正された？為に動作が異なっている事による。
ただこれをCygwinで修正することは出来ないし、するべき事柄でもない。