最近的生活

Blog 停水了一陣子,最近都在忙論文的東西,其實寫得差不多了,口試日期也決定了,剩下的就是好好地為學生生活劃下一個完美的句點 (還有把該還的債還一還 XD)。其實來交大這兩年應該算是我活二十幾年來學到最多東西的一段時間吧!在這邊遇到很多高手和貴人,系計中真是臥虎藏龍,真的要感謝很多人,就趁所剩不多的這段時光,再多糟糕一下吧!XD

接下來就要進入職場了,算是進到人生的另一個不同的階段,也請各位前輩們多多照顧了。:)

(0)

值得尊敬的人

工三的垃圾筒都是放在廁所旁的樓梯口角落,經過的時候偶爾會看到一個負責清理這些垃圾筒的阿姨,在我的以往的印象中,看到不少清理垃圾筒的人對待週遭的人不是很友善,不然就是有點冷淡不太想理人;但是這位阿姨對週遭的人態度都很好,我現在經過都會跟她打聲招呼。

不知道為什麼,明明垃圾筒上的紙條寫得很清楚要分類,總是有很多人看也不看就隨便亂丟,每次都看到阿姨整理得很辛苦,雖然總是有分不完的垃圾,但這位阿姨的態度還是很好,我遇過不少邊整理邊罵的人。這些努力付出勞力的人,每天都很盡責地做好自己的事,也許他們的工作不能舒舒服服地坐在冷氣房,也許他們的工作常搞得全身騷臭不堪,但我覺得多歸了他們,這個社會多了一分人情味,在我心中,他們的職業是很值得人尊敬的,這比一大堆高文憑卻連基本的垃圾分類都做不好的人來得更值得敬重。

下次丟垃圾的時候多想想,做好分類花不了你一分鐘,卻可省下他們不少時間。

(1)

VIM: Hack Your Editor!!

在系計中的小分享,這次著重在開發環境和 Plugin,蠻多部份沒有在 Slides 點出來,而是用口頭講述的,也有很多東西來不及準備完所以就沒講了,不過這種東西還是實際去玩學得比較快,也比較容易了解原理。:P

Corrinne May – 難得一見的好聲音

Corrinne May - Safe in a Crazy World

Corrinne May - Safe in a Crazy World

Corrinne May (中文名:符美云) ,新加坡女歌手,發行過四張專輯,在台灣其實沒多少人認識她,畢竟她有在台灣上市的專輯僅僅只有第一張 “Fly Away” 及最近的一張 “Beautiful Seed”,也許她不像時下的流行歌手般令人印象深刻,但聽過一次她的嗓音,會讓人難以忘懷。

第一次聽到她的歌聲是在網路上,忘記是哪了,只聽背景傳來 “Beautiful Seed” 專輯中 “Love Song for #1″ – “In the twinkling starts that dance like fireflies…”,很舒服的聲音,現在唸書都會放她的歌來聽。

四張專輯:

  • Corrinne May (Fly Away)
  • Safe in a Crazy World
  • The Gift
  • Beautiful Seed

我最喜歡的是”Safe in a Crazy World” & “Beautiful Seed”這兩張專輯。:)

P.S. 某人抱怨我都只發表技術性的文章 XD

Tab Completion on Python Shell

Python 本身的 Interactive Mode (Shell) 其實對於測試一些小功能和 debug,都蠻有用的,不過它的功能一直讓我覺得很陽春,尤其是 Tab Completion,我一直以為沒有實作這個功能,後來在 “Python for Unix and Linux System Administration” 這本書看到原來可以手動打開這個功能:

>>> import rlcompleter, readline
>>> readline.parse_and_bind('tab: complete')

這樣便可以使用 Tab Completion 的功能了,結果大致上會是:

>>> import os
>>> os.lis<TAB>
>>> os.listdir
>>> os.li<TAB><TAB>
os.linesep  os.link    os.listdir

雖然有了基本的 Tab Completion 功能,但說真的,還是挺不習慣 Python 原本的 Shell,後來都改用 IPython 了,比原本的 Python Shell 強大很多,重點是…它會自動 Indent,我不用再按<TAB>按到死了。

Firefox + VIM = vimperator

最近看到一個 Firefox Extension “vimperator“,我只能說,這個東西真是太棒了,尤其對我這種 VIM 重度使用者來說,真是一大福音啊!

看了一下官網的說明,大部份的常用指令都有實作,而且一裝完介面瞬間感受得到有種 VIM-Style,官網還有 Tips & Tricks 專區,不過目前看來數量沒有很多,google 一下應該可以找到更多人的使用經驗,也有些人直接把設定放出來。

現在正在探索它的設定,畢竟跟原本的 VIM 還是有些許不同,對於網頁瀏覽方面應該會有一些對應的設定和功能以增加方便性。有心得再 post 出來。

Screen + Unicode 補完計畫 (UAO)

這篇其實很早就有草稿了,只是拖到最近才把它完成。

之前有談過如何設定 Gnu Screen 的方法,如果你常掛在 server 上,那應該對 Screen 這個好用的工具並不陌生。這篇主要是談怎麼 patch 它,來讓它支援 Unicode 補完計畫 (UAO)。

Unicode 補完計畫 (UAO) 對廣大的鄉民來說,可以說是再親切不過的了,BBS 電子佈告欄在台灣相當地盛行,但它底層僅僅支援 Big5,對於鄉民來說,看日文是件再正常不過的事了,但 Big5 畢竟是個急就章推出的編碼 (事實上,它也沒有一個既定的標準,唯一勉強可以稱得上標準的是 Big5-2003),在當初的設計中並沒有加入日文假名等使用需求。所幸 Big5 有所謂的”使用者造字區”,提供給使用者自行定義新字,也有了後來的”倚天擴充字集”加入了包括日文假名等使用者特殊需求字。

然而,Windows 對於這塊由倚天自行定義的區域,在轉換成 Unicode 時也對應到了使用者造字區,而非它們各自對應到實際在 Unicode 的字,於是造成了 mapping 上的錯誤。UAO 便是為了解決這個問題而產生的,它做的事情只是將這段使用者造字區對應到 Unicode 正確的字。

上面說到的,是針對 Big5 <-> Unicode 的轉換發生在 Windows 的情況,可以利用安裝 UAO 來解決;但因為我的環境是 UTF-8,已經習慣用 Screen 提供的 Encoding Translation 功能來上 BBS 瀏覽文章了,但 Screen 預設提供的 Mapping Table 並沒有處理 UAO,因此這種轉換是在 Screen 內部的情況便無法靠安裝 UAO 來解決,所以必須 patch。

其實許多前輩們已經針對這個部份提供了 Screen 的 UAO patch 以及修正過的 Mapping Table,但他們提供的 Mapping Table 是以 UAO 2.42 所產生的 Binary 檔,這意味著我不清楚它是支援到 UAO 2.42 哪個程度,即使完整支援了 (這反而不好),Binary 檔也代表它難以再編修和進 Version Control System。

所以我從 Firefox 3 的版本取出了內建的 Mapping Table 文字檔來做處理,Firefox 在 2 的版本已經內建單向處理 UAO 的功能了,所以可以取其 Big5 -> Unicode 單向的 Mapping Table 來做修改。修改後再利用轉換程式編成 Binary 檔便可替代原本 Screen 當中的 “18″ 檔 (也就是 Big5 <-> Unicode Mapping Table)。

利用修正過後的 Screen 便可看到在日文假名以及某些特殊字框的顯示正常很多了;但是實際使用後會發現一個問題,就是對於某些 Double Mapping 的字會優先轉換到 0×8140-0xA0FE 這段擴充區 (這裡所謂的 Double Mapping 是指多個 Big5 的字對應到同一個 Unicode 的字,例如 0xB86D 和 0×82AA 都是對應到 0×7F6E,一個是正常區的,另一個是擴充區的),而在當初的 Mapping Table 文字檔便是依造 Big5 的字碼來排序,很不巧的 0×8140-0xA0FE 這段擴充區會放置在最前面;而又剛好 Screen 的 Mapping Table 是同時做雙向轉換的,針對這種 Double Mapping 的情況,它會以第一個找到的為優先,這便造成了某些不需 UAO 便可閱讀的字,變成需要 UAO 才能閱讀了,而這篇文章是你打的。解決方式便是將這段擴充區移到 Mapping Table 的最後面,讓正常區的字優先權較高。於是最後的 Mapping Table 表便誕生了,我在每行最後都有加上 UTF-8 所對應到的字。

最後的比較圖如下:
Screen_with_different_mapping_table

參考資料:

P.S. 其實 UAO 在本意上是良好的,但是作法我不太推崇,畢竟它不是一個標準,只是為了配合 BBS 所產生的過渡產物,所以讓 Screen 支援 UAO 僅是為了讓瀏覽 BBS 文章更方便而已,在其他環境下,我還是建議以 Unicode 為主,畢竟它是一個標準,支援度又高,Big5 就讓它慢慢走向歷史吧!

The Tips of Setting Workstation Environment

這份投影片是之前在系計中內部分享的,整理了一下 share 出來,裡面有些嘴砲請自動略過 XD。有錯也請指正 :)

Colorize A 256-Color Mutt

Mutt 是一個我很愛用的 Mail Client,除了平常在用的 GMail 外,其他幾乎都是由它包辦,其實之前就知道 Mutt 支援 256-Color,只是一直沒有時間好好調校,昨天趁著颱風天的下午,在 FreeBSD 上把 Mutt 的 256-Color 設定好了。

在預設的 Mutt color setting 中,單純使用常用的 16-Color 就是用 black, green, red, blue, …, etc 這類的顏色詞來設定;但是在 256-Color 的環境下,必須使用 color0, color1, …, color254, color255 來做設定,關於顏色的對照表,可以參考這邊

這邊提供一下我的設定 (看是要放到 $HOME/.muttrc 或是另放一個檔案,再從 $HOME/.muttrc include 進去):

color normal            default         default         # normal text
color indicator         color214        color237        # actual message
color tree              color99         default         # thread arrows
color status            color118        color237        # status line
color error             color196        default         # errors
color message           color196        default         # info messages
color signature         brightblack     default         # signature
color attachment        brightblack     default         # MIME attachments
color search            brightyellow    red             # search matches
color tilde             brightmagenta   default         # ~ at bottom of msg
color markers           red             default         # + at beginning of wrapped lines

color hdrdefault        color33         default         # default header lines
color bold              red             default         # hiliting bold patterns in body
color underline         green           default         # hiliting underlined patterns in body

color quoted            color107        default         # quoted text
color quoted1           color66         default
color quoted2           color32         default
color quoted3           color30         default
color quoted4           color99         default
color quoted5           color36         default
color quoted6           color114        default
color quoted7           color109        default
color quoted8           color41         default
color quoted9           color138        default
# header
color header            color205        default         "^(From|Subject|To|Cc|Bcc):"

# body
color body              color214        default         "(http|https|ftp|news|telnet|finger)://[^ ]+"
color body              color81         default         "[-a-z_0-9.+]+@[-a-z_0-9.]+"
color body              red             default         "(^| )\\*[-a-z0-9*]+\\*[,.?]?[ \n]"
color body              green           default         "(^| )_[-a-z0-9_]+_[,.?]?[ \n]"

# index
uncolor index *         # unset all color index entries
color index             brightgreen     default         ~F      # Flagged
color index             color74         default         ~N      # New
color index             color169        default         ~T      # Tagged
color index             brightblack     default         ~D      # Deleted

這樣設定完成後,如果你跟我一樣使用 $TERM=xterm,沒意外的話會噴出這樣子的訊息:

Error in /home/yzlin/.mutt/color/color256, line 9: 214: color not supported by term
Error in /home/yzlin/.mutt/color/color256, line 10: 99: color not supported by term
Error in /home/yzlin/.mutt/color/color256, line 11: 118: color not supported by term
Error in /home/yzlin/.mutt/color/color256, line 12: 196: color not supported by term
Error in /home/yzlin/.mutt/color/color256, line 13: 196: color not supported by term
Error in /home/yzlin/.mutt/color/color256, line 20: 33: color not supported by term
Error in /home/yzlin/.mutt/color/color256, line 24: 107: color not supported by term
...

會出現這樣的問題,是因為 Mutt 使用到 ncurses,會判斷 termcap 中,你所使用的 TERM (在此是 xterm) 是否支援 256-Color,如果不支援那麼高,就會噴出這樣子的訊息,這時候有人就會把 TERM 設成 xterm-256color,如此一來,就會成功!?很遺憾的,照樣噴 XD,在 Linux 下,可以單純只設成 xterm-256color,但是在 FreeBSD 下,卻不行!

為何會有如此的差異?其實這個問題帶有一點點歷史的包袱,FreeBSD 預設使用的是 termcap,而 Linux 多半使用的是 terminfo,也因為如此,FreeBSD termcap 會受限於單一 entry 字元數必須小於 1024 個的限制,如此一來,沒辦法將全部的 feature 都包含進去,xterm-256color 就是一個例子,在 /usr/share/misc/termcap 中有一段說明:

# These aliases are for compatibility with the terminfo; termcap cannot provide
# the extra features, but termcap applications still want the names.
xterm-16color|xterm alias 1:tc=xterm-xfree86:
xterm-88color|xterm alias 2:tc=xterm-256color:
xterm-256color|xterm alias 3:tc=xterm-xfree86:

從說明可以看到 xterm-256color 其實引入的是 xterm-xfree86,再詳細去看,xterm-xfree86 當中並沒有 Co 的設定 (Co 指的是 “Maximum number of colors on screen”,相當於 terminfo 中的 colors),而是引入 xterm-basic 的設定,當中只支援 Co#8,這也是為什麼 xterm-256color 在 FreeBSD 中並不是真的支援 256 色。

若要知道目前使用的 TERM 所支援的 colors,可以使用:

tput Co

注意不是 co 而是 Co,co 是 columns 的意思。

既然無法針對 termcap 下手,那究竟該如何設定使用 Co#256 呢?好在我們可以自行設定一個環境變數 TERMCAP,來強制指定,在 $HOME/.cshrc 設定:

setenv TERMCAP 'xterm|xterm-color:Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm:tc=xterm-xfree86:'

由上面的設定,可以看到我們覆寫了 Co、AB、AF,這樣的設定跟 .screenrc 當中的設定很像,AF 指的是 foreground color 的表示方式;AB 則是 backgound color 的表示方式。設定完成如果要確定是否成功,可以利用 tput 去檢查 Co,出現 256 便是表示成功了,接著在這樣的環境下執行 Mutt,沒意外會看到這樣子的畫面:
mutt-256color

Zsh – autocomplete error

最近開始在嘗試一套蠻強大的 shell – zsh,我用過的 shell 沒有很多,最常用的還是 tcsh & sh,bash 以前有用過一陣子。試用了一陣子,覺得它真的蠻強的,可以把 prompt 的介面和 auto-complete 的功能弄得很炫。改天再發篇文寫一下自己的設定心得。

這篇主要是講一下之前遇到的一個問題,在 auto-complete 的設定下,會出現:

_alternative:69: command not found: _canonical_paths

雖然好像可以正常運作,但就是覺得怪怪的,後來 google 了一下,發現了別人的解法,原來是 $HOME/.zcompdump 爛掉,把它砍掉,讓 zsh 自動重建就行了。