저는 개발할 때 윈도를 쓰지만, POSIX compliant한 Cygwin 환경에서 대부분의 작업을 합니다. 주로 하는 일이라는 게 ./configure 스크립트를 돌리고 make를 치고 소스 코드를 vim으로 보는 것이기 때문입니다.

최근에는 조금 복잡한 소스 코드를 가져다가 Visual C++(커맨드 라인의 cl.exe와 link.exe)와 Cygwin을 섞어서 컴파일할 일이 있는데, 이렇게 되니깐 상당히 헷갈리는군요. 윈도 쪽에서 set으로 환경 변수준 것도 있고 Cygwin에서 export한 것도 있고, 특히나 파일 패스명이 다르다 보니 어디에서는 /cygdrive/c/ 와 같이 시작하고 어디에서는 C:\로 시작하니 정신이 없습니다. 특히 Subversion, Python, Ruby 등은 윈도 버전도 깔려 있고 Cygwin 버전도 깔려 있어서 내가 지금 어느 윈도용을 쓰는건지 Cygwin용을 쓰는 건지도 헷갈리게 되네요.

그래서 제가 다시 부활시킨 게 MinGW입니다. MinGW는 Win32를 위한 미니멀한 툴 체인을 주는 것을 목표로 하고 있는데, 원래는 Cygwin에서 fork된 프로젝트입니다. 다만 철학이 달라서 Cygwin이 POSIX를 거의 다 에뮬레이션해서 대부분의 프로그램을 컴파일하는 데 비해서, MinGW는 미니멀한 툴 체인만 주고, 보다 Win32에 특화된 네이티브한 어플리케이션을 작성할 수 있게 합니다.

여러분은 어떤 환경에서 작업하세요?


추가: MinSYS의 경우 rxvt 터미널에서 pty emulation 관련 문제로 네이티브 윈도 프로그램들이 제대로 동작 안 하네요. python.exe이나 irb.bat 등을 실행시키면 멈춰 버립니다 ㅠ.ㅠ

추가: 이 문제로 메일링 리스트에 포스팅을 했더니, MinSYS에 rxvt를 디폴트 터미널로 해야할지 말아야 할지로 꽤 많은 의견이 오가고 있군요. rxvt가 일으키는 문제의 원인은 다음과 같았습니다.

Keith MARSHALL <keith.marshall@total.com>

RXVT owns the `stdin', `stdout' and `stderr' file descriptors bound to your console, and uses pipes to connect these to your shell, and to any process you invoke from that shell. A pipe is not a tty, so `isatty()' returns `false', for these `stdio' streams in the application; thus, the standard runtime init routines enable block buffering for these streams, rather than the expected line buffered or unbuffered modes. This causes at least two serious problems for interactive console applications, run within an RXVT:

1) Expected output is delayed in the block buffer, instead of appearing on the screen; users are left waiting for prompts that never appear on the screen, yet the application has moved on, and is waiting for their input, (unless the application has been sprinkled with `flush()' calls, to explicitly work around this abnormal behaviour).

2) Special characters, such as ^D or ^Z, which users expect to be able to use to signal EOF on input are swallowed by RXVT; applications which loop until EOF on `stdin' are locked into a perpetual interminable state.

The above is a consequence of Win32's lack of *nix's `pty' feature; trying to emulate it with pipes just isn't at all satisfactory. I do know that Earnie has put considerable effort into seeking a solution to this `pty' emulation problem, with frustrating lack of success.