nmap 是好物

今天要連某微型叢集內的某臺機器，不過因為整個不是我組態的，所以哪臺機器 IP 是多少我不太記得。

以前是自己臨場刻個 perl script 來掃，今天想一想還是找找看有啥工具。果然有個好物

nmap -sP 192.168.10.0/24

速度當然是比自己刻的快太多了，一下子就找到我要找的機器。

如何執行 configure 與 make

3. How to run configure and make / 如何執行 configure 與 make

A package constructed using Autoconf will come with a `configure' script. A user who wants to build and install the package must run this script in order to prepare their source tree in order to build it on their particular system. The actual build process is performed using the make program.

一個使用 Autoconf 建構的套件會含有一個 `configure' 指令稿，想要建置與安裝套件的使用者必須先執行這個指令稿，以針對使用者的系統調整所取得的原始碼樹。實際的建置程序，則是利用 make 程式來執行。

The `configure' script tests system features. For example, it might test whether the C library defines the time_t data type for use by the time() C library function. The `configure' script then makes the results of those tests available to the program while it is being built.

`configure' 指令稿會測試系統所支援的功能，舉例來說，他可能會測試 C 函式庫是不是定義了由 time() 這個 C 函式庫使用的 time_t 資料型別。完成測試後 `configure' 指令稿會把結果包裝成建置時期可以存取的型式，以供建置時使用。

This chapter explains how to invoke a `configure' script from the perspective of a user -- someone who just wants to take your package and compile it on their system with a minimum of fuss. It is because Autoconf works as well as it does that it is usually possible to build a package on any kind of machine with a simple configure; make command line. The topics covered in this chapter include how to invoke configure, the files that configure generates and the most useful `Makefile' targets -- actions that you want make to perform -- that will be available when compiling the package (see section 4. Introducing `Makefile's).

在這章，我們會從使用者 -- 也就是想在他自己的系統上取得你的套件並編譯，但不希望碰上大麻煩的那個人 -- 的角度來解釋怎麼執行 `configure' 指令稿。拜 Autoconf 的精良實作，我們通常可以在任何機器上執行簡單的 configure; make 指令來進行套件的建置。我們會在這章討論怎麼執行 configure，哪些檔案會被 configure 產生，以及一些在編譯套件時很有用的 `Makefile' 建置目標 -- 也就是你想要 make 進行的動作 (請參閱 4. 簡介 `Makefile')。

Microsoft Windows

2.6 Microsoft Windows / Microsoft Windows

In 1995, Microsoft released Windows 95, which soon became the most widely-used operating system in the world. Autoconf and Libtool were written to support portability across Unix variants, but they provided a framework to support portability to Windows as well. This made it possible for a program to support both Unix and Windows from a single source code base.

Microsoft 的 Windows 95 在 1995 年上市後，很快的變成世界上被廣泛使用的作業系統。 Autoconf 與 Libtool 除了提供在各種 Unix 分支版本的可攜性支援外，也提供了延伸可攜性支援到 Windows 上的程式設計框架，這使得透過單一份原始碼來同時支援 Unix 與 Windows 成為可能的事情。

The key requirement of both Autoconf and Libtool was the Unix shell. The GNU bash shell was ported to Windows as part of the Cygwin project, which was originally written by Steve Chamberlain. The Cygwin project implements the basic Unix API in Windows, making it possible to port Unix programs directly.

Autoconf 與 Libtool 都需要 Unix shell 程式，而 GNU bash shell 恰被作為 Cygwin 計畫的一部分移植到 Windows 上。 Cygwin 計畫是由 Steve Chamberlain 所發起的，這個計畫在 Windows 上實做了基本的 Unix API ，使得 Unix 程式可以直接的移植到 Windows 上。

Once the shell and the Unix make program (also provided by Cygwin) were available, it was possible to make Autoconf and Libtool support Windows directly, using either the Cygwin interface or the Visual C++ tools from Microsoft. This involved handling details like the different file extensions used by the different systems, as well as yet another set of shared library features. This first version of this work was by Ian Lance Taylor in 1998. Automake has also been ported to Windows. It requires Perl to be installed (see section A.1 Prerequisite tools).

在 shell 與 Unix 的 make 程式都被移植到 Windows 上之後，便可以讓 Autoconf 與 Libtool 透過 Cygwin 或是 Microsoft Visual C++ toolkit 直接的支援 Windows。增加 Windows 支援牽涉到處理一些在不同的作業系統上細節，例如處理不同的檔案延伸名稱以及額外的共享函式庫功能，第一個可以支援 Windows 的版本在 1998 年由 Ian Lance 所開發。除此之外 Automake 也被移植到 Windows 上，他需要 Perl 預先安裝在系統上 (參見 A.1 需預先安裝的工具) 。

處理 Fink 搭配 subclipse 找不到 JavaHL 的設定

Fink 安裝的位置是 /sw 目錄，不是一個非常公認的地方，所以預設的搜尋路徑是找不到要找的東西的。

修正方法有兩種，我是直接改到 eclipse.ini 裡去，並沒有另外弄個 wrapper script 來處理。

要加入的內容如下

-Djava.library.path=.:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:/sw/lib

前面一大串是預設直，在未作任何變動前應該可以從 About Eclipse Platform 的 Configuration 列表之中找到。

把 eclipse workspace 放在 netatalk AFP volume 上的額外設定

因為 netatalk 還不支援 file locking 所以會造成一點問題，要繞過這個問題就是把 locking mechanism 關掉就好了。

一樣是在 eclipse.ini 動手腳，在檔案末端加上下面這個設定即可。

-Dosgi.locking=none

在 Fedora7 上的 nss-mdns

nss-mdns 是 linux 上的 Zeroconf mDNS 解析器，主要功能是界接 glibc 與 Avahi 的名稱解析模組。

套件可以在 Fedora 的 Koji 中找到，或是很多第三方套件網站也有。

在 Mac OS X 的 Terminal.app 下在遠端 screen 無法使用 backspace

狀況是這樣子，在 Mac OS X 的終端機裡，連線到遠端的主機後，在遠端主機執行的 screen 會不理會 backspace 鍵。

我在 debian 上遇到這個問題，其他的 distribution 可能也會有這個問題，不過我不確定。

基本上原因就是 Terminal.app 送出的終端機識別字串沒有被識別，解決方法有修改終端機識別字串，或是有點掩耳盜鈴似的告訴 screen 應該怎麼識別終端機。

修改終端機識別字串，在 Mac 上執行這個指令:

defaults write com.apple.Terminal TermCapString xterm

覆寫掉遠端的終端機名稱描述，在遠端主機執行這個指令:

export TERM=xterm

或是，我是把下面這個丟到 .bashrc 裡:

alias screen ='TERM=xterm screen'

Libtool 的發展

2.5 Libtool Development / Libtool 的發展

Over time, Unix systems added support for shared libraries.

隨著時間的推移，Unix 系統加入了共享函式庫的支援。

Conventional libraries, or static libraries, are linked into a program image. This means that each program which uses a static library includes some or all of the library in the program binary on disk.

傳統的函式庫，或稱為靜態函式庫，會直接連結到程式檔之中。這表示，每個使用靜態函式庫的程式，會把所使用的函式庫的部份或全部複製到位於磁碟上的程式機械碼檔案之中。

Shared libraries, on the other hand, are a separate file. A program which uses a shared library does not include a copy of the library; it only includes the name of the library. Many programs can use a single shared library.

另一方面，共享函式庫則是分離的檔案。使用了共享函式庫的程式不需把函式庫的內容複製到程式內部；僅需在程式檔案內記錄函式庫的名字。數個程式可以使用一個共享函示庫。

Using a shared library reduces disk space requirements. Since the system can generally share a single executable instance of the shared library among many programs, it also reduces swap space requirements at run time. Another advantage is that it is possible to fix a bug by updating the single shared library file on disk, without requiring all the programs which use the library to be rebuilt.

使用共享函式庫可以減少磁碟空間的使用需求。此外，在執行時系統可以讓多個程式共用一份共享函式庫的執行實體，因此也可以減少執行時期所需的記憶體分頁暫存空間需求。另外一個好處是，修正函式庫的臭蟲只需更新一份共享函式庫的檔案，而不需重新建置所有有用到函式庫的程式。

The first Unix shared library implementation was in System V release 3 from AT&T. The idea was rapidly adopted by other Unix vendors, appearing in SunOS, HP-UX, AIX, and Digital Unix among others. Unfortunately, each implementation differed in the creation and use of shared libraries and in the specific features which were supported.

第一個 Unix 的共享函式庫實作是在 AT&T 的 System V release 3 之中。這個概念很快的被其他 Unix 廠商採用，在 SunOS, HP-UX, AIX, 與 Digital Unix 等等都可以見到。遺憾的是，每個實作在函式庫的建立、使用與所支援的功能上都有些許的不同。

Naturally, packages distributed as source code which included libraries wanted to be able to build their own shared libraries. Several different implementations were written in the Autoconf/Automake framework.

很自然的，含有函式庫的原始碼套件會需要建置他們自己的共享函式庫。在 Autoconf/Automake 程式設計框架下，有好幾個不同的實作被撰寫出來。

In 1996, Gordon Matzigkeit began work on a package known as Libtool. Libtool is a collection of shell scripts which handle the differences between shared library generation and use on different systems. It is closely tied to Automake, although it is possible to use it independently.

在 1996 年，Gordon Matzigkeit 開始製作一個稱為 Libtool 的套件。 Libtool 是一組 shell 指令稿，用來應付在不同系統上產生與使用共享函式庫的差異。 Libtool 是針對 Automake 而製作的，但也可以被獨立的使用。

Over time, Libtool has been enhanced to support more Unix variants and to provide an interface for standardizing shared library features.

隨著時間的推移，Libtool 現在可以支援比剛發表時更多的 Unix 衍伸系統，並且也提供了一個標準化的界面來操作共享函式庫。

Automake 的發展

2.4 Automake Development / Automake 的發展

By 1994, Autoconf was a solid framework for handling the differences between Unix variants. However, program developers still had to write large `Makefile.in' files in order to use it. The `configure' script generated by autoconf would transform the `Makefile.in' file into a `Makefile' used by the make program.

在 1994 年時，對於處理各 Unix 分支版本間的差異，Autoconf 已能提供一個完整並可靠的程式設計框架。然而，為了使用 Autoconf，程式設計師得寫幾個巨大的 `Makefile.in' 檔案。由 autoconf 產生出的 `configure' 指令稿會把 `Makefile.in' 轉換成給 make 程式使用的 `Makefile' 檔案。

A `Makefile.in' file has to describe how to build the program. In the Imake equivalent of a `Makefile.in', known as an `Imakefile', it is only necessary to describe which source files are used to build the program. When Imake generates a `Makefile', it adds the rules for how to build the program itself. Later versions of the BSD make program also include rules for building a program.

程式設計師得在 `Makefile.in' 中描述建置程式的方法。在 Imake 中，類似的工作由 `Imakefile' 擔當，但在 `Imakefile' 中只需要列出建置程式所需要的原始碼檔案。當 Imake 產生 `Makefile' 時，他會自動將所需的程式建置規則加進去。在比較晚近的 BSD make 中，也內含有建置程式用的建置規則。

Since most programs are built in much the same way, there was a great deal of duplication in `Makefile.in' files. Also, the GNU project developed a reasonably complex set of standards for `Makefile's, and it was easy to get some of the details wrong.

由於大部分的程式建置方法都一樣，因此在 `Makefile.in' 中有不少的內容是重複的。此外，GNU 計畫發展出了一組規範撰寫 `Makefile' 應依循的標準，這個標準相當的複雜，很容易把一些細節搞錯。

These factors led to the development of Automake. automake, like autoconf, is a program run by a developer. The developer writes files named `Makefile.am'; these use a simpler syntax than ordinary `Makefile's. automake reads the `Makefile.am' files and produces `Makefile.in' files. The idea is that a script generated by autoconf converts these `Makefile.in' files into `Makefile's.

這些種種不便開啟了 Automake 的發展，如同 autoconf 一樣，automake 也是給程式設計師使用的工具。程式設計師先用一套比一般的 `Makefile' 還精簡的語法撰寫 `Makefile.am' 檔案，接著執行 automake 來讀取 `Makefile.am' 並依據其內容產生 `Makefile.in' 檔。如此一來，所產生出來的 `Makefile.in' 檔便可以交給 autoconf 產生的指令稿來產生出 `Makefile' 檔案。

As with Imake and BSD make, the `Makefile.am' file need only describe the files used to build a program. automake automatically adds the necessary rules when it generates the `Makefile.in' file. automake also adds any rules required by the GNU `Makefile' standards.

就像 Imake 與 BSD make 一樣，在 `Makefile.am' 中只需要描述有哪些原始碼檔案會用來建置程式。在產生 `Makefile.in' 檔時 automake 會自動加入必要的規則，此外，automake 也會加入在 GNU 的 `Makefile' 標準中所要求的規則。

The first version of Automake was written by David MacKenzie in 1994. It was completely rewritten in 1995 by Tom Tromey.

第一版的 Automake 是 David MacKenzie 在 1994 年所撰寫。並在 1995 年，由 Tom Tromey 重新撰寫。

在 debian 上準備給 Mac 用的 AFPd

簡單講就是安裝 netatalk 這個套件，設定一下就一切搞定。

問題在於，在 debian 內附的 netatalk 不支援認證時加密，因為 OpenSSL 的授權跟 GPL 有所衝突的關係。這實在是很無聊的理由... 不過總之就是這樣。

因此，就得自己編譯 netatalk 套件。方法跟這篇講的一樣，基本上就是安裝額外的相依套件，然後照著一般的建置程序做就可以了。

cd /usr/src
apt-get install openssl libssl-dev cracklib2 libpam-cracklib cracklib2-dev
apt-get source netatalk
apt-get build-dep netatalk

然後編輯建置規則檔

cd netatalk-2.0.3
vi debian/rules

在大概第 18 行附近找到 ##FIXME: Other changes are needed, like enabling DHX plugin 的字樣，把 DEB_BUILD_OPTIONS=ssl debuild 加進去。

最後執行 dpkg-buildpackage 就會開始製作套件檔，做完用 dpkg -i 安裝就完成了。

接著再修改 /etc/default/netatalk 設定檔，我改了 UAMLIST 並且關掉 AFPD 跟儲存 meta data 用的 CNID 之外的服務。主要是把 ATALKD 跟 PAPD 關掉，其他沒動應該也是無所謂。

AFPD_UAMLIST="-U uams_dhx.so,uams_randnum.so"

ATALKD_RUN=no
PAPD_RUN=no
CNID_METAD_RUN=yes
AFPD_RUN=yes
TIMELORD_RUN=no
A2BOOT_RUN=no

再來就是參考這邊，修改 /etc/netatalk/afpd.conf 設定，主要是把 AppleTalk 關掉，走 TCP 就好了。

- -noddp -uamlist uams_randnum.so,uams_dhx.so

然後新增 Avahi 的服務描述檔，這樣就可以直接用 Bonjor 找到機器。

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">

<service-group>

  <name replace-wildcards="yes">AFP on %h</name>

  <service>
    <type>_afpovertcp._tcp</type>
    <port>548</port>
  </service>

</service-group>

該重啟動的重啟動之後，應該就可以用了。

另外還可以在 /etc/netatalk/AppleVolumes.default 加上 option:usedots,noadouble 讓一些 netatalk 用來儲存 Mac 特殊檔案狀態用的檔案名稱不會被編碼，而可以藏起來。

Configure 的發展

2.3 Configure Development / Configure 的發展

The Cygnus `configure' script and the original GCC `configure' script both had to be updated for each new Unix variant they supported. This meant that packages which used them were continually out of date as new Unix variants appeared. It was not hard for the developer to add support for a new system variant; however, it was not something which package users could easily do themselves.

Cygnus 的 `configure' 指令稿與 GCC 原始的 `configure' 指令稿都必須針對所支援的 Unix 衍生作業系統做出修改，這代表當新的 Unix 衍生作業系統出現時，使用了這兩樣工具的軟體套件必須修改才能用在新的作業系統上。對於軟體的發展者而言，修改軟體套件以支援新的作業系統可能並非難事；但是對於軟體套件的使用者而言，這就不是件容易自己搞定的事情。

The same was true of Imake as it was commonly used. While it was possible for a user to build and configure Imake for a particular system, it was not commonly done. In practice, packages such as the X window system which use Imake are shipped with configuration information detailed for specific Unix variants.

被漸漸廣泛使用的 Imake 也面臨一樣的問題，雖然使用者自己針對特定系統建置並設定 Imake 不是難到不可能的事，但其實很少使用者這麼做。在實務上，像 X window 這類使用 Imake 的軟體套件，會帶有針對各個不同的 Unix 衍生作業系統所撰寫的配置檔。

Because Metaconfig and Autoconf used feature tests, the scripts they generated were often able to work correctly on new Unix variants without modification. This made them more flexible and easier to work with over time, and led to the wide adoption of Autoconf.

因為 Metaconfig 與 Autoconf 是利用一序列的測試來決定系統提供的功能，因此所產生的組態指令稿通常不用修改就能在新的 Unix 衍生作業系統上正確執行。這樣的特性讓這兩項工具被視為具彈性且不用頻繁維護的方案，並使 Autoconf 被大量採用。

In 1994, David MacKenzie extended Autoconf to incorporate the features of the Cygnus `configure' script and the original GCC `configure' script. This included support for using system specified header file and makefile fragments, and support for cross-compilation.

在 1994 年 David MacKenzie 將 Autoconf 加以擴充，納入了 Cygnus 的 `configure' 指令稿與原始的 GCC `configure' 指令稿的功能。這次擴充使 Autoconf 支援針對不同系統使用不同的標頭檔或 makefile 檔案片段，另外也支援了跨平臺編譯。

GCC has since been converted to use Autoconf, eliminating the GCC `configure' script. Most programs which use the Cygnus `configure' script have also been converted, and no new programs are being written to use the Cygnus `configure' script.

從此之後，GCC 便轉而使用 Autoconf 並揚棄了原本的 GCC `configure' 指令稿。大多數使用 Cygnus `configure' 指令稿的程式也改用 Autoconf，新的程式也不再使用 Cygnus `configure' 指令稿。

The metaconfig program is still used today to configure Perl and a few other programs. imake is still used to configure the X window system. However, these tools are not generally used for new packages.

Metaconfig 在今日仍被用在 Perl 與幾個其他程式的建置中進行組態工作，Imake 也仍被用來組態 X window 系統。但是，在新的軟體套件中就很少會去使用這些工具了。

twitter

鈍鈍的，大概是 AJAX 用太兇了。

實在是沒想到有什麼用，以後 imbot 有什麼動作的話，就丟上去好了，性質似乎蠻合的。

在 OS X 上裝 CPAN module

沒有想像中可怕，不過 HFS+ 的不分辨大小寫功能的確是會造成問題。

找到這篇文章提到，重點在於設定 cpan 的時候，要讓他把 "INSTALLBIN=/usr/local/bin INSTALLSCRIPT=/usr/local/bin" 設為 perl Makefile.PL 的參數。

從 which 來看，用的應該還是原本 OS X 的 perl 程式，不過 fink 會把 library 的目錄讓他先去搜尋 fink 的 lib 目錄，這是比較稍微有點讓人擔心的地方，其他都蠻正常的。

裝電腦或修電腦這件事

最近又開始有人找我幫忙電腦的問題，不知道是不是天氣冷了，於是大家與電腦接觸的時間長了，就開始有一些怨言。

基本上就是不幫忙，我處理這幾件事的重點是:

裝電腦

原則上，我是不會特地幫忙裝電腦或買電腦，除非我自己剛好也有要買，或是周遭剛好有要出採購團。

列零件配備的話，也是抱歉，不過這裡有張我之前列的表，可以參考看看。這個表有一段時間了就是，大概只能參考牌子吧！

要買電腦，然後自己沒有辦法組裝或挑零件的話，其實我是比較建議買品牌電腦。因為或多或少會有需要維修的時候，有的品牌有提供到府收送，這樣會方便很多，不用自己累得半死搬到店家去。

至於建議的牌子，桌上型的話: ASUS, Dell 。要注意的是，如果是 ASUS 的話，不是所有代理商都有提供到府收送，這是要注意的地方。 Dell 的話，到府收送是一個搭配不同的處理時間保證的選購項目，要弄清楚。

筆記型電腦的話: ASUS 。主要是東西相較之下不是太貴，國內維修點也多。如果要出國的話，可能要看各廠牌對你去的國家維修支援的狀況，問問當地人會比較好。

很多人會問日系品牌到底好不好，就我看，日系機器不見得品質有多好到哪去，尤其有些中低價位的型號根本是委託臺灣廠設計，考量到使用壽命與價格不見得會比較值得。

修電腦

基本上，我並不幫忙修電腦，除非是我的程式的問題，否則我不處理也不檢視。

這種事情我是覺得，女人自己不會修可以去找自己的男人，基本上是男人就應該會修電腦，找不到會修電腦的男人的話，也還是可以上店家花點錢處理。把這種成本轉嫁到無關的人身上，並且沒有相對的報酬，實在蠻過分的。

灌電腦

這個，同上，請自行想辦法處理。

說實在的啦！找認識的人處理電腦問題，十之八九也只是為了免費而已，甚至有的人還會多方徵詢意見，弄了半天結果一點也沒派上用場，感覺實在是挺差的。

「時代已經不同了，這年頭癡情的只有被發卡的份而已。」這是在一篇頗無聊的文章內看到的話，從某種角度而言，這句話道盡了人際關係間的現實啊！

說到修電腦這檔事，主要牽涉到的就是時間與金錢。處理要時間，如果有硬體壞了差不多就得要錢。

雖然時間耗的是出手修的人的時間，不過還是得看找人來修的那位的心態如何。有個朋友，姑且稱之為宅宅好了，去幫一位認識的女生修電腦，好像有個系統檔被置換掉了，總之就是弄很久才解決，花了一整個下午吧！

後來聽熟悉內部情報人士透露，這個下午那個女生的男朋友來找她，總之女生怕宅宅不高興，於是這個男生就被支在外面。後來，女生這邊抱怨說電腦弄的太久了，本來那整個下午她要跟她男友好好翻雲覆雨一翻，結果卻得陪這個宅宅。

比較麻煩的是，通常大家都有很多活動，所以一些要花長時間找的問題就比較尷尬。看到問題，處理好也不是，不處理好又是一個疙瘩。

金錢方面相對是小事，只是算起來還是不太好看，通常我會告訴他們可能是哪個東西壞了，叫他們整台抱去檢修看看。當然，也是有人請我代購，不過有過一次經驗，千里迢迢從號稱實際售價最便宜的光華商場買回來，然後被嫌貴。比較誇張的是，買回來換上去兩三個月後，跟我抱怨現在買比較便宜... 碼的，明年買的話同樣價格功能還更棒咧！

簡言之，不論是就金錢，還是時間而論，修電腦都是件吃力不討好的蠢事。

裝電腦大概比修電腦好一點，至少比較不會遇到那種很怪異難解的問題，不過一樣是浪費時間。一開始可能至少會對搞定系統有點成就感，久了就會對插插拔拔膩了，雖然其實都是小事。

所以，現在我就不太幫修電腦、裝電腦、重裝諸如 Windows, Office 之類的軟體... 花時間，花下去看到的都是負面的，沒什麼實際的好處。

要說對人際關係有什麼好處，我是沒看到啦！會找的那些人，難得有事來找就是修電腦，要玩要幹嘛並是不會來找。

當然，也是因為玩樂的事情來找也玩不起來就是，講白了，根本就不熟啊！熟的，平常出去吃飯打混，電腦有問題問個兩句就解決了，有什麼重要的情報也直接交換，反而感覺上並不太會有需要處理電腦相關事務的時候。

Bonjour on Windows

這東西在標準的名稱是 Zeroconf ，不過各家廠商有各家的叫法。 Apple 算是最誇張的吧！完全抹掉 Zeroconf 這個名字。

總之，對於小型的區域網路來講，的確蠻方便的。主機安裝時都會設有名稱，裝了之後，就可以利用這個名稱轉換成 Zeroconf 的 .local 網域名稱。

在 Windows 上 Apple 有提供 Bonjour for Windows 給 Windows 使用，試了一下，的確可以順利的使用 .local 來完成名稱正解。

關閉光碟自動安插通知

從 Windows98 之後，似乎就不太能輕鬆的完全關掉這項有點麻煩的功能。

要關掉 AutoRun 似乎是修改 HKLM\SYSTEM\CurrentControlSet\Services\Cdrom\ 下的 Autorun 設為 0 值。

要關掉 AutoPlay 的話，可能就得靠 TweakUI 了。除了 TweakUI 本身提供的設定界面，還可以從 TweakUI 進入 Group Policy Editor 編輯 Computer Configuration / Administrative Templates / System 下的 Turn autoplay off 這個選項，把他 Enable 起來。

參考資料: AutoPlay - Wikipedia

最初的 configure 程式

2.2 The First Configure Programs / 最初的 configure 程式

By 1992, four different systems had been developed to help with source code portability:

為了增進原始碼的可攜性，在 1992 年有四個不同的解決方案被開發出來:

• The Metaconfig program, by Larry Wall, Harlan Stenn, and Raphael Manfredi.

  Metaconfig ，由 Larry Wall 、 Harlan Stenn 以及 Raphael Manfredi 所發展。

• The Cygnus `configure' script, by K. Richard Pixley, and the original GCC `configure' script, by Richard Stallman. These are quite similar, and the developers communicated regularly. GCC is the GNU Compiler Collection, formerly the GNU C compiler.

  K. Richard Pixley 為 Cygnus 發展的 `configure' 指令稿；以及由 Richard Stallman 當初為 GCC 撰寫的 `configure' 指令稿， GCC 是 GNU Compiler Collection 的縮寫，其前身為 GNU C compiler 。這兩個指令稿非常相似，兩位發展者也經常交換意見。

• The GNU Autoconf package, by David MacKenzie.

  GNU Autoconf ， David MacKenzie 所發展。

• Imake, part of the X Window system.

  Imake ，屬於 X Window 的一部份。

These systems all split building a program into two steps: a configuration step, and a build step. For all the systems, the build step used the standard Unix make program. The make program reads a set of rules in a `Makefile', and uses them to build a program. The configuration step would generate `Makefile's, and perhaps other files, which would then be used during the build step.

這些解決方案都把建置程式的過程分為兩個步驟: 組態，以及建置。在所有系統上，建置的程序會由 make 這個標準的 Unix 程式進行。 make 程式會由一個稱為 `Makefile' 的描述檔中讀取建置規則，並依據這些規則編譯程式。在建置作業前的組態階段，則會產生建置所需的 `Makefile' 以及其他建置時所需的檔案。

Metaconfig and Autoconf both use feature tests to determine the capabilities of the system. They use Bourne shell scripts (all variants of Unix support the Bourne shell in one form or another) to run various tests to see what the system can support.

Metaconfig 與 Autoconf 都透過執行一序列的測試程式來決定系統的功能與能提供的工具，這兩個工具的測試程式都是用 Bourne shell 指令稿所撰寫的。 (幾乎所有由 Unix 所衍生的作業系統都某種程度的支援 Bourne shell)

The Cygnus `configure' script and the original GCC `configure' script are also Bourne shell scripts. They rely on little configuration files for each system variant, both header files and `Makefile' fragments. In early versions, the user compiling the program had to tell the script which type of system the program should be built for; they were later enhanced with a shell script written by Per Bothner which determines the system type based on the standard Unix uname program and other information.

Cygnus 的 `configure' 指令稿以及 GCC 原始的 `configure' 指令稿也是使用 Bourne shell 指令稿所撰寫的， Cygnus 與 GCC 針對不同的系統平台分別提供了一組特定的系統組態檔、標頭檔、以及指引編譯流程的 `Makefile' 描述檔。在早期的版本，要建置軟體的使用者必須告訴 `configure' 指令稿建置出來的程式的目標執行平台是什麼；後來 Per Bothner 修改了 `configure' 指令稿，讓 `configure' 可以自己利用 uname 這個標準的 Unix 程式以及其他系統環境的資訊來決定目標執行平台。

Imake is a portable C program. Imake can be customized for a particular system, and run as part of building a package. However, it is more normally distributed with a package, including all the configuration information needed for supported systems.

Imake 是一個用 C 語言所撰寫的程式，他具有高度的可攜性。 Imake 可以針對特定作業系統客制化，並在爾後建置軟體套件時使用。不過，通常 Imake 會與軟體套件一起被散佈，套件檔案中會附上在套件所支援的系統上建置軟體所需的組態資訊。

Metaconfig and Autoconf are programs used by program authors. They produce a shell script which is distributed with the program's source code. A user who wants to build the program runs the shell script in order to configure the source code for the particular system on which it is to be built.

Metaconfig 與 Autoconf 是給程式設計師使用的工具，兩者都會產生出隨著軟體原始碼散佈用的 shell 指令稿。要建置軟體的使用者可以執行由 Metaconfig 或是 Autoconf 產生的 shell 指令稿，以將程式原始碼針對執行建置作業的系統環境作調整。

The Cygnus and GCC `configure' scripts, and imake, do not have this clear distinction between use by the developer and use by the user.

Cygnus 與 GCC 的 `configure' 指令稿，以及 Imake ，就比較沒有如此的清楚區分說哪部份要由程式設計師使用，哪個部份是給建置套件的使用者使用。

The Cygnus and GCC `configure' scripts included features to support cross development, both to support building a cross-compiler which compiles code to be run on another system, and to support building a program using a cross-compiler.

Cygnus 與 GCC 的 `configure' 指令稿支援了跨平台程式發展的功能，兩者都支援建置 cross-compiler ，或是利用 cross-compiler 建置程式。利用 cross-compiler ，可以編譯出執行在與編譯器執行平台相異的作業平台的機械碼。

Autoconf, Metaconfig and Imake did not have these features (they were later added to Autoconf); they only worked for building a program on the system on which it was to run.

Autoconf 、 Metaconfig 與 Imake 都不支援這些跨平台程式發展功能 (不過後來 Autoconf 有加入了這些功能) ；這些工具只能用來建置在建置環境中執行的程式。

The scripts generated by Metaconfig are interactive by default: they ask questions of the user as they go along. This permits them to determine certain characteristics of the system which it is difficult or impossible to test, such as the behavior of setuid programs.

由 Metaconfig 所產生出來的指令稿，在預設下是需要與使用者互動的: 在建置過程中，指令稿會問使用者一些問題。這個設計是為了取得一些比較難以自動偵測的系統組態與特性，比如說 setuid 程式的行為模式。

The Cygnus and GCC `configure' scripts, and the scripts generated by autoconf, and the imake program, are not interactive: they determine everything themselves. When using Autoconf, the package developer normally writes the script to accept command line options for features which can not be tested for, or sometimes requires the user to edit a header file after the `configure' script has run.

Cygnus 與 GCC 的 `configure' 指令稿、由 Autoconf 所產生的指令稿、以及 Imake 等這三者則相反，他們執行時不與使用者互動: 這些工具會自己做出所有關於環境特性的決定。如果要取得無法利用測試偵測出來的系統組態或特性，一般而言，套件發展者會撰寫額外的指令稿讓使用者可以利用指令列參數告知系統組態，或是，有時候可能會要求使用者在執行完 `configure' 指令稿後編輯一個特定的標頭檔，好指出系統的組態。

Unix 系統間的歧異

2.1 The Diversity of Unix Systems / Unix 系統間的歧異

Of the programs discussed in this book, the first to be developed was Autoconf. Its development was determined by the history of the Unix operating system.

在本書所討論的工具程式中，第一個被發展出來的工具是 Autoconf ，這個工具的發展與 Unix 作業系統的歷史習習相關。

The first version of Unix was written by Dennis Ritchie and Ken Thompson at Bell Labs in 1969. During the 1970s, Bell Labs was not permitted to sell Unix commercially, but did distribute Unix to universities at relatively low cost. The University of California at Berkeley added their own improvements to the Unix sources; the result was known as the BSD version of Unix.

第一版的 Unix 是在 1969 年由 Dennis Ritchie 與 Ken Thompson 在 Bell Labs 所寫出來的。在 1970 年代，雖然 Bell Labs 的母公司並未將 Unix 商業化販售，但是 Bell Labs 還是有將 Unix 以相對低廉的價格散佈到大學校園內。加州大學柏克萊分校的研究人員將他們的研究成果加入了 Unix 的原始碼中，這個增強後的版本就是後來為眾人所知的 BSD 版 Unix 系統。

In the early 1980s, AT&T signed an agreement permitting them to sell Unix commercially. The first AT&T version of Unix was known as System III.

在 1980 年前期 AT&T 開始商業販售 Unix 作業系統，第一個 AT&T 的 Unix 版本稱為 System III 。

As the popularity of Unix increased during the 1980s, several other companies modified the Unix sources to create their own variants. Examples include SunOS from Sun Microsystems, Ultrix from Digital Equipment Corporation, and HP-UX from Hewlett Packard.

Unix 在 1980 年代開始普及，許多其他的公司也修改了 Unix 的原始碼並衍伸出自己的作業系統。比如，昇陽電腦的 SunOS ，迪吉多電腦的 Ultrix，以及惠普電腦的 HP-UX 。

Although all of the Unix variants were fundamentally similar, there were various differences between them. They had slightly different sets of header files and slightly different lists of functions in the system libraries, as well as more significant differences in areas such as terminal handling and job control.

雖然所有由 Unix 衍伸出的作業系統在設計上的出發點是相似的，但仍有相當的相異。他們有不同的標頭檔，系統函式庫所提供的函式呼叫也不太一樣，在終端機的控制以及工作的管理上也有可觀的差異。

The emerging POSIX standards helped to eliminate some of these differences. However, in some areas POSIX introduced new features, leading to more variants. Also, different systems adopted the POSIX standard at different times, leading to further disparities.

雖然 POSIX 標準的推出協助消弭了一些歧異，但是，因為 POSIX 也提出了一些新的功能，所以 POSIX 也引出了更多歧異。此外，隨著 POSIX 的改版，新舊版本的標準間也存在著差異，連帶使得不同時期推出的作業系統也因為採用了不同版本的標準而有歧異。

All of these variations caused problems for programs distributed as source code. Even a function as straightforward as memcpy was not available everywhere; the BSD system library provided the similar function bcopy instead, but the order of arguments was reversed.

當以原始碼形式散佈程式時，這些作業系統間的歧異會造成困擾。就算是 memcpy 這類基本的函式也不見得在所有平台上都支援；比如說，在 BSD 的系統函式庫中，提供這項功能的是叫做 bcopy 的函式，不過他的參數順序與 memcpy 是正好顛倒的。

Program authors who wanted their programs to run on a wide variety of Unix variants had to be familiar with the detailed differences between the variants. They also had to worry about the ways in which the variants changed from one version to another, as variants on the one hand converged on the POSIX standard and on the other continued to introduce new and different features.

如果程式設計師想讓程式能在各種由 Unix 衍伸出的系統上運作，他就得對各家衍伸系統間的差異非常了解。另外，作業系統可能為了符合 POSIX 標準或是引入新的功能而改版，進而造成版本間的歧異，這也是程式設計師得面對的問題。

While it was generally possible to use #ifdef to identify particular systems and versions, it became increasingly difficult to know which versions had which features. It became clear that some more organized approach was needed to handle the differences between Unix variants.

一般來講可以用 #ifdef 來辨認出平台所採用的作業系統與版本，但是，，要知道哪個版本有什麼功能則是越來越不容易。因此，程式設計師們漸漸明確的知道，需要一個系統化的方法來處理不同 Unix 衍伸系統間的差異。

發展歷史

2. History / 發展歷史

In this chapter we provide a brief history of the tools described in this book. You don't need to know this history in order to use the tools. However, the history of how the tools developed over time helps explain why the tools act the way that they do today. Also, in a book like this, it's only fair for us to credit the original authors and sources of inspiration, and to explain what they did.

在這一章，我們會簡單的描述一下本書主角 Autotools 的發展歷史。你不需要知道這些歷史就可以將這些工具上手，但是，了解這些工具程式的發展歷史可以幫助你理解為什麼這些工具的行為是今日你所見的這樣。此外，本書也要藉此機會向這些工具程式的創造者與貢獻者致敬，並解釋他們當初作下的設計決策背後的原因。

本書的組織方式

1.4 How this book is organized / 本書的組織方式

Like any good tutorial, this book starts with an explanation of simple concepts and builds on these fundamentals to progress to advanced topics.

如同所有優秀的入門文件一樣，這本書從簡單的概念開始，然後以這些簡單的概念為基礎，擴充到較複雜的主題上。

Part I of the book provides a history of the development of these tools and why they exist.

這本書的第一部份描述這些工具軟體的發展歷史，以及他們被發展出來的原因。

Part II contains most of the book's content, starting with an introduction to concepts such as `Makefile's and configuration triplets. Later chapters introduce each tool and how to manage projects of varying sizes using the tools in concert. Programs written in C and C++ can be non-portable if written carelessly. Chapters 14 and 15 offer guidelines for writing portable programs in C and C++, respectively.

本書的第二部份包含了大部分的內容，首先從介紹概念開始，如 `Makefile' 以及 configuration triplet 等等。接下來的章節會分別介紹如何使用 Autotools 的工具，以及如何利用這些工具管理不同規模的專案。最後，在 14 與 15 章中將會介紹使用 C/C++ 撰寫程式時需要注意的可攜性議題，撰寫 C/C++ 程式時若不特別注意的話，很容易會寫出無法移植的程式。

Part III provides information that you are unlikely to find in any other documentation, that is based on extensive experience with the tools. It embodies chapters that treat some advanced, yet essential, concepts such as the m4 macro processor and how to write portable Bourne shell scripts. Chapter 23 outlines how to migrate an existing package to the GNU Autotools framework and will be of interest to many developers. One of the most mystifying aspects of using the GNU Autotools for building packages in a cross-compilation environment. This is de-mystified in Chapter 25.

一些在其他文件中比較難找到的資訊被放在第三部份中，這些內容是以大量的實務經驗為基礎而撰寫的。首先，一些較進階並且重要的主題會在這部份討論，比如 m4 巨集處理器以及撰寫具可攜性的 Bourne shell 指令稿的注意事項。在第 23 章會提到如何將現有的專案移到 GNU Autotools 框架中，這部份會是很多發展者有興趣的地方。在第 25 章會解釋如何在 cross-compilation 環境中使用 GNU Autotools 來管理專案。