// 說明
Node API 版本為 v0.10.31。
中文參考:http://nodeapi.ucdok.com/#/api/,http://blog.sina.com.cn/oleoneoy
本段為部落客注解。
目錄
● 程序
○ Event: 'exit'
○ Event: 'uncaughtException'
○ Signal Events
○ process.stdout
○ process.stderr
○ process.stdin
○ process.argv
○ process.execPath
○ process.execArgv
○ process.abort()
○ process.chdir(directory)
○ process.cwd()
○ process.env
○ process.exit([code])
○ process.getgid()
○ process.setgid(id)
○ process.getuid()
○ process.setuid(id)
○ process.getgroups()
○ process.setgroups(groups)
○ process.initgroups(user, extra_group)
○ process.version
○ process.versions
○ process.config
○ process.kill(pid, [signal])
○ process.pid
○ process.title
○ process.arch
○ process.platform
○ process.memoryUsage()
○ process.nextTick(callback)
○ process.maxTickDepth
○ process.umask([mask])
○ process.uptime()
○ process.hrtime()
程序
process 對象是一個全局對象,能在任何地方被通路。它是一個 EventEmitter 執行個體。
當程序将要退出時發射。在這個時候沒有任何途徑來阻止退出事件循環,且當所有的 exit 監聽器運作完之後程序将會退出。是以,在本監聽器内你必須隻使用同步的操作。這是一個很好的執行子產品狀态的檢驗的鈎子(比如用于單元測試上)。回調函數有一個參數,即程序的退出碼。
監聽 exit 的例子:


當一個異常一路冒泡到事件循環時發射。如果為這個異常添加了一個監聽器,那麼預設的動作(列印堆棧資訊并退出)将不會被觸發。
監聽 uncaughtException 的例子:


注意 uncaughtException 是一種非常粗魯的異常捕獲途徑且有可能在将來移除。
不要使用它,使用 domains 取代。如果你使用了它,在每個沒被正常捕獲的異常後重新開機你的應用程式。
不要使用它因為 node.js 相當于出了錯待會恢複重新開始。一個未捕獲的異常意味着你的應用程式——推而廣之 node.js 本身處于未知狀态。盲目地恢複意味着什麼事情都有可發生。
假想當你正在更新系統時拔了電源線,然後恢複了。十次有九次都沒事發生——但在第十次,你的系統就崩了。
你已經被警告過。
當程序受到一個信号時發射。參看 sigaction(2) 列出的标注 POSIX 信号,例如 SIGINT,SIGHUP等。
監聽 SIGINT 的例子:
在大多數的終端程式中一個簡單的發送 SIGINT 信号的方法是使用 Control-C。
注意:
SIGUSR1 被 node.js 保留用以啟動 debugger。可以建立一個監聽器但那不會停止 debugger 的啟動。
SIGTERM 和 SIGINT 在非 Windows 平台下有預設的監聽器,退出并在退出前重置終端 mode 為128加信号數值。如果這兩信号之一建立了監聽器,它們的預設操作将會被移除(node 将永不退出)。
SIGPIPE 預設被忽略,他可以建立監聽器。
SIGHUP 在 Windows 下當控制台視窗被關閉時産生,在其他平台各個類似的條件下,參看 signal(7)。它可以建立監聽器,然而 node 将在大約10秒後被 Windows 無條件終止。在非 Windows 平台下,SIGHUP 的預設行為是終止 node,但一旦建立了監聽器預設的行為将被移除。
SIGTERM 在 Windows 下不支援,可以被監聽。
SIGINT 從終端發送該信号能被所有平台支援,且通常可以用 CTRL+C 産生(即使這是可配置的)。當終端 raw 模式啟動時它不能被産生。
SIGBREAK 在 Windows 下當按下 CTRL+BREAK 時産生,在非 Windows 平台下可以别監聽,但沒有途徑可以發送或産生它。
SIGWINCH 當控制台改變大小時産生。在 Windows 下,這隻會發生在滑鼠正在移動時向控制台輸入,或刻度的 tty 在 raw 模式下使用。
SIGKILL 不可被監聽,在任何平台下 node 都将無條件終止。
SIGSTOP 不可被監聽。
注意 Windows 不支援發送信号,但 node 使用 process.kill() 和 child_process.kill() 提供了一些模拟:——發送信号0可以用來查找程序是否存在——發送SIGINT,SIGTERM 和 SIGKILL 讓目标程序無條件退出。
寫向标準輸出的可寫流。
例子:console.log 的定義
process.stderr 和 process.stdout 和 Node 中的其他流不同,向它們寫入通常是阻塞的。
當它們指向普通檔案或 TTY 檔案描述符時它們是阻塞的。
當它們指向管道:
○ 在 Linux/Unix 下是阻塞的。
○ 在 Windows 下與其他流一樣是非阻塞的。
要檢驗 Node 是否運作在 TTY 上下文中,參看 process.stderr,process.stdout 或 process.stdin 的 isTTY 屬性:


更多資訊參看 tty 文檔。
寫向标準錯誤輸出的可寫流。
process.stderr 和 process.stdout 和 Node 中的其他流不同,向它們寫入通常是阻塞的。
标準輸入的可寫流。
打開标準輸入并監聽兩個事件的例子:


作為一個流,process.stdin 也可以用于“老”模式,那是為了相容使用 v0.10 之前的 node 所寫的代碼。更多資訊參看流相容性。
在“老”模式下标準輸入流預設是暫停的,是以必須調用 process.stdin.resume() 來從從裡面讀取。而且需要注意調用 process.stdin.resume() 本身會将流選擇為“老”模式。
如果你正在啟動一個新項目,你應該選擇更現代的“新”流模式而不是“老”的。
一個包含指令行參數的數組。第一個元素為 'node',第二個元素為 JavaScript 檔案名。剩下的參數為附加的指令行參數。
輸出将會是:
這是啟動程序的可執行程式的絕對路徑。
例子:
這是啟動程序的可執行程式的 node 特殊的指令行參數集。這些選項不會在 process.argv 出現,且不會包括 node 可執行程式,腳本名,或任何在腳本名後的選項。當為了使用父程序同樣的執行環境建立子程序,這些參數是有用的。
例子:
process.execArgv 的結果:
process.argv 的結果:
這會導緻 node 發射一個 abort。這回引起 node 退出并建立一個核心檔案。
改變程序的目前工作目錄或如果失敗則抛出一個異常。


傳回程序的目前工作目錄。
一個包含使用者環境的對象。參看 environ(7)。
使用指定的 code 停止程序。如果省略,使用“成功”碼 0 退出。
使用一個“失敗”碼退出:
執行 node 的 shell 将看到1作為退出碼。
注意:這個函數隻在 POSIX 平台下可用(也就是 Windows 不能使用)
擷取程序的組辨別。(參看 getgid(2)。)這是數字組 id,不是組名。
設定程序的組辨別。(參看 setgid(2)。)接收一個數值 ID 或一個組名字元串。如果組名指定,本函數阻塞直到将它解析為一個數值 ID。


擷取程序的使用者辨別。(參看 getuid(2)。)這是一個數值使用者 id,不是使用者名。
設定程序的使用者辨別。(參看 setuid(2)。)接收一個數值 ID 或一個使用者名字元串。如果使用者名指定,本函數阻塞直到将它解析為一個數值 ID。


傳回一個儲存補充組 ID 的數組。如果有效組 ID 被包含在内 POSIX 不管它讓它未指定,但 node.js 確定它總是。
// 說明:不熟悉 POSIX,真心看不懂。
設定補充組 ID。這是一個特權選項,意味着你需要為 root 使用者或擁有 CAP_SETGID 的能力。
清單可以包含組 ID,組名,或二者都包含。
使用使用者名所在的所有組,讀取/etc/group且初始化組可通路清單。這是一個特權選項,意味着你需要為 root 使用者或擁有 CAP_SETGID 的能力。
user 是一個使用者名或使用者 ID。extra_group 是一個組名或組 ID。
當登出權限時需要注意。例子:
一個表示 NODE_VERSION 的編譯進來的屬性。
一個表示 node 和它的依賴的版本字元串屬性。
将列印如下輸出:


一個包含我們用來編譯目前 node 可執行檔案的配置選項的 JavaScript representation 的對象(//注:這裡看不懂啥是 representation ,看英文吧)。這和運作 ./configure 腳本生成的“config.gypi"是一樣的。
可能的輸出例子如下:


發送一個信号給程序 pid。pid 為程序 id,signal 為描述發送的信号的字元串。信号名為形如 'SIGINT 或 'SIGHUP' 的字元串。如果省略,信号預設為 'SIGTERM'。更多資訊參看 Signal Events 和 kill(2)。
如果目标程序不存在将抛出一個異常,且作為特例,信号 0 可以用來測試程序是否存在。
注意隻是因為這個函數的名字是 process.kill,它實際上隻是一個信号發送者,如同系統調用 kill。信号發送後可以做其它事情而不僅僅殺死目标程序。
發送信号給自己的例子:


注意:當 Node.js 接收到 SIGUSR1 它會啟動調試器,參看 Signal Events。
程序的 PID。
用來設定在 ’ps' 中的顯示什麼的 getter/setter。
當作為 getter 使用時,最大長度由系統指定,有可能是很短的。
在 Linux 和 OS X 下,它受限于名字二進制大小加上指令行參數長度,因為它覆寫了參數記憶體。
v0.8 通過也覆寫環境記憶體允許更長的程序标題字元串,但那有潛在的不安全性/在某些情況下會混亂(不僅是模糊不清)。
你運作在什麼處理器架構上:'arm','ia32',或 'x64'。
你運作在什麼平台上:'darwin','freebsd','linux','sunos',或 'win32'。
傳回一個描述 Node 程序記憶體使用的對象,機關是位元組。
這将列印:
heapTotal 和 heapUsed 表示 V8 的記憶體使用。
在事件循環的下一次調用這個回調函數。這不僅是 setTimeout(fn, 0) 的别名,它更有效率。典型地它在任何其他的 I/O 事件之前運作,但有一些例外。參看下面的 process.maxTickDepth。
在開發 API 時若你想給使用者機會去在對象被建立之後但在任何 I/O 發生之前配置設定事件監聽器,這個函數是很重要的。


保證 API 是100%同步的或100%異步的是非常重要的。考慮下面的例子:


這個 API 是冒險的。如果你執行下面:
那麼不清楚到底 foo() 還是 bar() 先被執行。
這個方法會更好:


● 數字類型 預設值 = 1000
傳遞給 process.nextTick 的回調函數通常會在目前的執行結束後才被調用,是以近似于盡快地同步調用一個函數。不進行任何檢驗,這将有可能餓死時間循環,阻止任何的 I/O 調用發起。
考慮這樣的代碼:
為了避免 Node 被一系列遞歸 nextTick 無限循環鎖阻塞,它會延遲來讓一些 I/O 每隔一段時間被執行。
process.maxTickDepth 的值是 nextTick 調用 nextTick 回調函數的最大深度,以在允許其他形式的 I/O 發起前進行評估。
設定或讀取程序的檔案模式的建立掩碼。子程序從父程序繼承掩碼。如果 mask 參數給出則傳回就是掩碼,否則傳回目前的掩碼。
Node 已經運作的秒數。
傳回 [秒,納秒] 的元組數組形式的目前高精度真實時間。它相對于過去的任意時間。它不是跟一天中的某個時間有關,是以不會受制于時鐘偏移。主要的用途是測量某間隔間的程式執行。
你可以傳遞之前的調用結果給 process.hrtime() 來獲得一個差異值,對基準和測量間隔很有用:

