搜索
Table_bottom

标签云
Table_bottom

分类
Table_bottom

声明
文章若未特別註明,皆採用 知识共享许可协议 請自覺遵守
Table_bottom

存档
Table_bottom

匆匆过客
31944
Table_bottom

功能
Table_bottom

長終端輸出“截屏”

今天偶然想把兩段終端輸出轉化成圖片發給別人(爲了保留顏色)。然而輸出特別長,一屏不足以顯示下來。於是想有沒有什麼方法可以讓我將終端的完整輸出截出來,畢竟手動一幅幅地裁剪太蠢了。

題目是聯想到一些Android設備上的所謂“長截屏”而取的,意義很是相似。

 

概要

由於沒有找到專門的工具,所以打算自己hack一個出來,故而事情分兩步:

  1. 將命令輸出存下來
  2. 將輸出轉化成圖片

然而在進行第二步的時候發現沒有工具可以一步到位,所以就通過HTML進行中轉。於是最終變成了三步:

  1. 將命令輸出存下來
  2. 將之前保存的輸出轉換成HTML
  3. 將HTML轉換成圖片

第一步:保存輸出

第一步可以直接重定向(加上強制彩色輸出),但我這種懶人使用了script命令。

script可以自動把我所有命令的輸出(帶提示行/prompt)都存下來,而且不用我再去一個個強制彩色輸出。而且啓動它以後會進入專門的環境,於是我可以首先在一個臨時目錄執行script,之後cd到我要執行命令的目錄,最後直接Ctrl+D以免弄亂我的正常目錄。

由於這許多優勢,我傾向於使用script,而不是採取輸出重定向的方案。

第二步:輸出轉HTML

第二步用ansi2html(AUR中有)將輸出轉換成HTML。由於是終端輸出,後面加上--bg=dark參數將背景設爲黑色會更合習慣;由於我的終端模擬器用的配色方案是Tango(我覺得比xterm-256color好看),所以還要加上--palette=tango。最終的命令就是這樣:

ansi2html --bg=dark --palette=tango < typescript > typescript.html

(理論上管道直接到ansi2html的輸入是可行的,但需要手動強制彩色輸出,畢竟多數軟件還是會探測輸出是否是終端的。)

然後可以先找你的瀏覽器看一下輸出是否符合你的預期(主要是配色方案這部分),確定後就可以進行下一步了。

第三步:HTML轉圖片

把HTML轉爲圖片的工具很多,我選了CutyCapt(依然是AUR上有)這麼一個傢伙,畢竟它滿足我目前的所有功能需求,而且用QtWebKit所以體積很小(我本來就有幾乎全套的Qt)。

對於我們的需求,其基本用法是:

CutyCapt --url=http://www.example.org/ --out=localfile.png

然而其默認的字號太小,怎麼看怎麼不舒服,所以我加了200%的縮放--zoom-factor=2。由於全都是文字,所以又加上僅縮放文字的開關--zoom-text-only=on(並沒有什麼卯月系列)。所以最終命令就成了:

CutyCapt --url=file://`pwd`/typescript.html --out=output.png --zoom-factor=2 --zoom-text-only=on

 

大功告成。(並沒有)

 

 

 

 

 

 

之後還需要手動使用圖片處理軟件(剪裁就可以了,所以gwenview足矣)將多餘部分去除。這樣就大功告成,可以拿去浪了。(其實還是有點小問題)

 

 

 

 

 

 

 

懸而未解

  • 經對比發現,輸出中的高亮並不正確,而且似乎沒有加粗。
  • powerline的輸出無法正確呈現。

 

遷移到awesome 4

前兩天隨手全局刷了一下更新,結果一不留神awesome提示我的配置文件有問題。檢查之下,發現awesome已經到了4了,所以立即意識到配置文件又改了。然而由於當時較爲忙碌,就又downgrade回了3.5,直到週末纔重新更上4並折騰配置,到今天算是初有所成。

 

由於我的配置沒有魔改,所以遷移起來還是比較簡單的。遷移前毫無疑問地,首要事情就是備份自己原來的配置文件;同時可以去看看官方說明文檔。

官方文檔分爲兩個,一個是“簡明遷移文檔”(然而官方自己都說這個只能保證你的配置能用,新功能就別想了),另一個是新的特性文檔。遷移文檔我看了一下就扔下了,然後對着新特性研究了一大半(然而還是沒看完)。

簡而言之呢,在我修改的時候,涉及到的新特性有這麼幾個:

  1. 增加了快捷鍵功能顯示界面(modekey+s)
    • 這個功能實際上是爲每個快捷鍵定義增加了一個可選參數,在其中寫上說明以及分組
    • 正確使用需要手動在快捷鍵設置的函數定義後增加這個參數,比葫蘆畫瓢即可
  2. 又重新增加了declarative layout(聲明式佈局?),同時默認配置中的頂部面板(panel)佈局改爲使用declarative layout
  3. 對象的屬性可以直接賦值(想來是有了鉤子/監聽器),而不必再使用set_xxx()
  4. screen現在是動態的(以前不是?)而且是個對象,並且遍歷所有屏幕建議使用awful.screen.connect_for_each_screen(function(s)
  5. 許多舊的api列爲deprecated,並將在日後逐步刪除
  6. 默認爲每個normal(通常?)和dialog(對話框)窗口加上標題欄

由於我之前也沒用什麼奇怪的庫(僅用了awesome-freedesktop和vicious),所以整個過程其實不難:將原來的配置文件($HOME/.config/awesome/rc.lua)備份一下,將新的配置文件/etc/xdg/awesome/rc.lua複製過去,然後開始vimdiff。

  • 一部分設置的位置變了,但內容沒變,所以保留原始狀態不變
  • menu的項目改成原來的
  • tasklist右鍵的默認動作單獨提了出來,不知道具體爲了什麼,但我將它留在原地
  • widget配置方式改成declarative的
    • 糅合panel配置,都放到專門的panels.lua中(因爲我搞了倆panel,上面一個、左邊一個)
  • 爲自己的快捷鍵增加說明
  • 調整窗口默認規則
  • 把normal窗口的默認標題欄去掉

嗯,基本就是這些了吧。剩下的那些邊邊角角的情況都是比葫蘆畫瓢即可。

 

讓我感到比較奇妙的是awesome 4增加的這倆東西:

  1. 新的widget
    • 尤其是其中的piechart和arcchart,感覺可以用來更好地顯示資源佔用了(我原來是用的vicious的文本)
  2. shape api
    • 其中有圓角的支持

然而由於我功力不夠,沒能摸索出來如何更好地使用這些東西……而直接搜索也沒搜到有用的信息(因爲太新了?)。所以接下來一段時間就要摸索這個咯(當然,有時間的話)……

Arch下XPS 13 9343的触摸板多指动作

昨天偶然意識到需要經常“後退”和“前進”,而又懶得用兩隻手去按鍵盤快捷鍵,於是想到觸摸板多指動作。

我的鼠標是羅技的M345,滾輪可以向左右傾斜而觸發後退和前進動作,而且不需要額外設置就可以用,於是感覺應該是有專門的通用事件來處理它,故而試圖尋找觸摸板觸發該事件的方法。

 

由於觸摸板雙指滾動已被佔用,而且知道自己觸摸板可以識別三指(點按),於是鎖定目標在三指滑動。然而synaptics驅動中似乎並沒有該功能,故而前去尋找,終於找到mtrack

該倉庫原本由BlueDragonX維護,後來擱置,於是p2rkw接手並且在持續維護。

 

AUR中有該包(xf86-input-mtrack-git指向的是p2rkw維護的),直接裝之(和xf86-input-synaptics衝突,pacman會提示卸載)。安裝後會自己放置配置文件到/usr/share/X11/xorg.conf.d/10-mtrack.conf,理論上應該可以自動切換觸摸板所用“驅動”(InputClass配置的Driver項)到其上。

然而我之前手動設置了觸摸板的一些配置(在/etc/X11/xorg.conf.d/下),所以還需要改該文件。不過在修改配置之前,首先要確認mtrack到底啓用了沒有,所以我就把我的配置文件中Driver項從synaptics改成了mtrack。

xf86-input-mtrack-git的安裝腳本會提示“可能需要把自己加到input組中”——貌似由於X不再以root運行,所以需要讓自己在input組中以便mtrack可以正確配置觸摸板。

由於X只有在啓動時會讀取配置文件,所以只好忍痛將所有程序都關掉然後重啓X。然而啓動後發現無論用xev怎麼測,三指的動作死活無法觸發(默認配置中,三指上下左右分別對應按鍵8、9、10、11)。於是懷疑是不是mtrack根本沒有啓用。而由於xf86-input-libinput現在被xorg-server依賴,所以沒辦法從源頭上排除(刪掉所有其他和觸摸板相關的東西,如果觸摸板還能工作,說明mtrack在處理它)。故而前去查詢X的日誌(用DM來管理的話在/var/log/Xorg.0.log,startx的話在$HOME/.local/share/xorg/Xorg.0.log),發現mtrack被載入了,然而有這麼幾句:

[     4.741] (EE) mtrack: cannot configure device
[     4.741] (EE) Couldn't init device "我的觸摸板名稱"
[     4.741] (II) UnloadModule: "mtrack"
搜索了很久,然而始終沒有找到對我有用的信息(都是macbook云云)。而網上一些人說道即使有cannot configure device這句,mtrack的配置依然會生效(然而他們及其後的人也說過只要把用戶加到input組中就不會再有這個消息了,可是我這還是有)。後來偶然重新去看日誌,發現上面還有
[     4.741] (WW) Touchpad has minimal capabilities. Some features will be unavailable.
然而也沒有什麼有效信息,只是讓我確認了我的觸摸板功能不夠全……於是繼續搜索了一大圈,最後意識到好像是閾值設置得太高了(SwipeDistance默認是700)……另外,所有有效的“Option”都會打出到日誌中。
 
最後在把閾值設置低一些(我設置的220)以後,通過xev成功監聽到了三指動作的觸發……(然而四指的無論如何都無法觸發,不知是硬件問題還是什麼)
它的配置文件中Scroll*代表雙指划動動作,Swipe*代表三指划動動作,Swipe4*代表四指划動動作;另外還有似乎並沒有通用行爲只是觸發按鍵的:Scale*代表的雙指縮放、Rotate*代表的雙指旋轉。
 
再然後就是配置它以使得符合我的需求。我需要的是左右划動觸發後退和前進,而上下暫時沒有需求。於是通過xev監聽我鼠標滾輪左右的事件,發現是按鈕8和9,而mtrack默認配置和我的需求不同,於是在配置文件中修改之。爲了保留原有的並不知道有什麼用的按鍵10和11,故而選擇交換上下和左右的動作。最終這部分是這樣的:
        Option "SwipeDistance" "220"
        Option "SwipeClickTime" "120"
        Option "SwipeSensitivity" "0"
        Option "SwipeUpButton" "10"
        Option "SwipeDownButton" "11"
        Option "SwipeLeftButton" "8"
        Option "SwipeRightButton" "9"

 

然而在改完了之後,忽然發現xf86-input-mtrack倉庫中的example有(且僅有)XPS 9333的配置文件……雖然是前代,但很多地方還是很有參考借鑑意義的……於是最終將它的配置文件抄過來稍加修改……

 

不過話說回來,example中有許多我是看不懂的(畢竟對X的配置理解不深刻),尤其是那堆重複寫Swipe和Swipe4動作的部分。哪位理解的話希望可以指點一下。

 

另外還見到了兩個其他相關軟件,然而我都沒有試:一個叫touchegg的似乎是截獲觸摸板動作然後改轉發其他動作的軟件;另一個叫easystroke的似乎是手勢識別軟件。

不知疾與無疾

我們先來說說這麼兩種人:第一種人,他們不願意去醫院看病,因爲他們可能本來覺得自己身體還不錯,如果去醫院檢查出來有病會讓他們很不舒服;第二種人,他們感到不舒服時對去醫院檢查並不排斥,並且遵守醫囑,更是還有一部分會定期去醫院做體檢。

第一種人,他們在去醫院檢查之後如果發現沒有病,就會反過來埋怨叫他檢查的人,因爲他覺得耽誤自己時間和浪費錢了;如果檢查出來有病(但並非不可醫治),同樣會去怪罪叫他去檢查的人,因爲他覺得自己本來好好的,如果不去檢查就不會發現有問題;如果檢查出來的病不可醫治,那麼他一般會一蹶不振,並且(雖然不說)在內心中怪罪叫他檢查的人,因爲他覺得自己現在要注意這個注意那個的很討厭。

第二種人,他們在去醫院檢查之後如果發現沒有病,則會感覺更加舒適,且並不會對叫他檢查的人有什麼怨言;如果檢查出來有病(但並非不可醫治),那麼會感謝叫他檢查的人,因爲他知道雖然現在需要有一些限制,但這樣自己可以好得更快,最終是對自己有益的;如果檢查出來的病不可醫治,那麼他依然會積極面對,因爲儘早發現纔能更好地對待自己的身體,遵循建議的話或許可以獲得更長的生命以及平均來講更高的生命質量。

 

這麼兩種人,在生活中應該能找到相應例子,想來諸位應該感觸頗深。一般而言,如果一個人有正常的取向,那麼他會努力去當第二種人而不是第一種人。

然而在計算機領域,這種認知似乎是顛倒的:人們普遍認爲,閉源軟件更“安全”——只因爲它的漏洞相對而言更難以發現。

 

好了我們來看看這些事情:

1. “閉源軟件的漏洞相對而言更難以發現”這句話是正確且毫無疑問的。但“更難”究竟是難多少,卻是一個難以考量的問題。至少我們可以確認一點:閉源並不是不可能被發現漏洞,否則Windows、IE等的漏洞不會被發現那麼多。

2. 人們對軟件的認知不同,於是決定了當發現某軟件的一個漏洞以後不同人會有不同的反應。一部分人認爲,軟件和硬件類似,只要獲得(安裝)了就不再變了,於是在他們的概念中,軟件的漏洞被發現得越少越好,軟件升級也只是讓他們厭煩的事情;另一部分人認爲,軟件和知識類似,擁有(安裝)了以後如果發現有問題是可以改進(升級)的,於是在他們的觀念中,軟件的漏洞發現與否並不是特別重要(或者說他們知道軟件漏洞的發現是必然的),而發現了一個漏洞以後自己的是否能及時得到升級(修復漏洞)纔是最重要的。

3. 發現軟件漏洞的人/團體在發現漏洞之後的做法也不盡相同,大致也可分爲兩類。第一類發現之後會去報告,然後軟件的“生產”方“可能”會花一些時間去修正這個問題,再花一些時候之後將問題的補丁放出;第二類發現之後自己利用漏洞而不去報告,於是漏洞直到有第一類人報告纔有可能會得到修復。

 

由如上諸點,加上開源閉源本身的特性,我們可以得到下面的推論:

1. 一般而言閉源軟件比開源軟件的漏洞更難被發現。

2. 被發現漏洞後,開源軟件有更大的可能性會更快得到修復。原因有三:

1. 會爲閉源軟件找漏洞的一般有兩類人,分別是開發者僱用的人和想找漏洞的人——其中第一種會上報且有希望修復最終(希望)不會造成危害,第二種有一部分不會上報從而可能造成危害;而開源軟件也會有這兩種人——只不過一般而言第一種會少一些,而第二種好人會更多一些,其原因一是開源軟件可以享有下面一條的好處,二是開源軟件“製造”者大多不是公司(公司的本質是追逐利益)。

2. 有一點是開源軟件所有而閉源軟件沒有的:充沛的同儕審查。同儕這裏指任何有興趣的開發者——由於我們可以相信世界上好人多,開發者也是好人多,所以這一部分人會有較高機率會去上報。而且由於源代碼公開,他們很有希望可以直接提出解決方案,而不用等待原始開發者自己再去還原產生環境、查找、修復。在這種睽睽衆目之下,軟件漏洞難以遁形,於是我們可以假設有1個惡意的想找漏洞的人,而有9個善意的想找漏洞的人,有極大的概率使得9個人中有人找到漏洞且修復,而那1個還沒有找到。

3. 開源軟件開發一般都是逐步增長的,即所謂“集市”模式(顯然閉源軟件無法採取這種模式)。這樣,在一個軟件還沒有特別多用戶羣的時候,它的許多基礎問題已經被解決。而且在用戶羣逐步增長的過程中,其新版本加入的內容也在不斷地被驗證確認,本身引入問題的可能性就低;而即使引入問題,由於有許多其他人可以檢查,遇到的問題也會較快地被解決,不用等到像閉源軟件普遍的已經產生大量用戶羣以後再發現、解決。

3. 閉源會給軟件編寫者一種虛假的支配安全感:軟件有錯誤也無所謂,反正除了我們沒人知道。於是在這種心理下,開發者更容易寫出質量較差的代碼,其中產生問題的可能性也更高。反觀開源這邊,因爲一切都是公開進行的,所以開發者一般都會對自己代碼質量有較高要求(不論是出於面子還是什麼),而且即使出現了質量不大高的代碼,其他有空的人也可以對它進行改進,避免小問題最終釀成大禍。

4. 除了被“入侵”這點以外,安全還有兩個層面:

1. 保證用戶的數據安全。閉源軟件由除了其開發者以外沒人能接觸到源代碼,所以如果其中有哪一部分可能會工作不正常而導致數據損壞,開發者只有兩個途徑知道:一是自我審查或者測試的時候發現;二是事情出現以後有用戶報告。如果等到用戶報告,那麼就太晚了。而開源軟件由於代碼公開,所以在審查代碼(無論是自己還是任一一個人)時被發現的可能性要高很多,而且更由於可以有大量的人參與討論,這類問題的修復速度也會比閉源軟件高。

2. 保證用戶本身的安全,尤其是保護用戶隱私。在這一點上,閉源軟件絲毫沒有可信度——看不到源代碼,你說你沒做手腳誰信啊;而開源軟件由於源代碼公開,所以用戶可以放心使用。(嚴格說來,如果一個公司想要在軟件上做些什麼不可告人的事,即使將源代碼公開也可以耍些手段,例如寫得極其晦澀難懂。然而即使真的晦澀難懂也不怕,開源保證了總有人可以依照其原理寫出清晰易懂的,而且用戶們可以不怎麼費勁地切換到新的上面。)

 

這裏還有一些人會有迷思,會認爲如果一個軟件本身就和安全相關,那麼就不應該開源。爲什麼呢?他們的理由是:不公開的東西看起來似乎更不容易被攻破。然而這實際上是對安全的誤解以及對權力的服從而產生的結論。

首先我們必須明確一件事:無論一個系統(加密方法)是否公開,它的安全性是固定的。公開與否改變的是它的問題/漏洞被發現的概率,而不是漏洞是否存在——就類似上面關於去醫院檢查的例子,去檢查能改變的只是你是否知道自己有病,而不能改變你是否病。

然後一種加密技術在被大規模使用以前,是需要有一個檢驗階段的。如果在檢驗階段發現較大漏洞,那麼該技術是顯然不可採用的。如果公開,則全世界有興趣的人都可以對它進行檢驗——甚至是原理上的檢驗——如果存在問題則很快會被發現,可以免造成更嚴重的影響。而如果不公開,則只有開發者(或許還有其委託的少量幾個人)知道其原理,而其他人無法知道,從而在檢驗階段少了很多被尋找到漏洞的可能性。我們知道所有加密方式都有破解方案的——不然怎麼解密——只是被發現的難度不同而已。於是當一個有漏洞的加密方案被大規模應用(例如軍事),而後有人發現其有漏洞於是自己使用,這時候造成的危害實在是不堪設想。

口說無憑,不過現代密碼學就是我的憑證。現代密碼學的基礎原理決定了:其上的加密算公開並不會導致加密效果減弱,反而因爲有大量的同儕評審,不好的算法可以儘早被發現被廢棄。例如多數人都見過卻不一定知道是什麼的AES、RSA算法等就都是現代密碼學產物,而它們(還有相關的其他東西)在計算機世界尤其是網絡世界幾乎是作爲基礎存在的。

 

所以最後一個迷思也被攻破了,那麼作爲正常人作爲用戶,我們是不是應該很明確答案了?

閉源不會爲自己帶來任何好處,而開源至少可以保證個人隱私。所以,爲什麼不從內心中選擇開源?

 

附:

從心中選擇開源不是說要立即把所有的東西都換成類似的開源軟件——當然這樣做很好,但總會遇到各種各樣問題——而是要有意識地去考慮:“某個軟件有沒有相同質量的開源代替物?某個軟件有沒有可能開源,至少讓它開放API以讓人們可以開發開源客戶端?某個開源軟件的設計爲什麼和我用的相同功能的另一個軟件差別那麼大,排除習慣因素,究竟哪個設計更好?”