sed源碼編譯

㈠ 如何在Windows下構建ARM linux QT開發環境

在PC上，需要得到兩個版本的Qt，分別是：Qt－4.5.2和QtEmbedded-4.5.2-arm。前者包括了QtDesigner等基本工具，用於在PC上對程序的開發調試，使能確保程序放到板子上之前就符合設計的要求；然後用後者的庫將調試好的程序編譯成能在arm-linux平台上運行的程序。

Qt-4.5.2用從網上下載到的qt-x11-opensource-src-4.5.2.tar.gz編譯後安裝得到；QtEmbedded-4.5.2-arm用qt-embedded-linux-opensource-src-4.5.2.tar.gz編譯後安裝得到，Qt-embedded-linux-opensource-src-4.5.2.tar.gz還可以編譯成QtEmbedded-4.5.2-X86，但不需要。在編譯qt-embedded-linux-opensource-src-4.5.2.tar.gz之前，必須准備好arm-linux-gcc交叉編譯工具，用的是arm-linux-gcc-3.4.1。

所以先要准備好的軟體包有：

Pc的操作系統是：LINUX-ubuntu8.04。

下面是具體編譯安裝過程：

1、Qt－4.5.2的獲得將qt-x11-opensource-src-4.5.2.tar.gz復制到目錄：/home/chh/Project/qt,

2、然後解壓：

#tarzxvfqt-x11-opensource-src-4.5.2.tar.gz

得到一個新目錄：qt-x11-opensource-src-4.5.2

cd進入這個目錄，准備開始編譯。

3、在終端中這樣操作：

#./configure–qvfb//編譯配置，此過程大概歷時幾分鍾；#make//正式編譯，過程漫長，大概2個多小時；#cdtools/qvfb//進入此目錄，准備對它進行編譯#make//編譯，幾分鍾#cd../..//回到qt-x11-opensource-src-4.5.2主目錄，准備安裝#makeinstall//安裝，十幾分鍾吧；

4、此步必須以root身份完成，否則無法建立目錄

5、可以在/usr/local/下看到一個Trolltech目錄，進入該目錄發現Qt-4.5.2目錄已經出現，進入裡面的bin目錄，Designer等工具已經可以使用了。

6、編譯過程相當費時，所以可以直接拷貝已經編譯過的源碼，直接makeinstall。

7、至此，Qt-4.5.2的安裝已經順利完成。

QtEmbedded-4.5.2-arm的獲得

在編譯安裝qt-embedded-linux-opensource-src-4.5.2之前，必須先配置好arm-linux-gcc，將arm-linux-gcc-3.4.1.tar.bz2解壓到目錄：/usr/local下，此時local下出現一個名為arm的目錄，然後配置好環境變數：在/etc/profile添加一句：exportPATH=$PATH:/usr/local/arm/3.4.1/bin，保存後＃source/etc/profile一下，讓它即時生效。否則下面的編譯過程會提示找不到arm-linux-gcc命令。現在可以開始編譯了：

將qt-embedded-linux-opensource-src-4.5.2.tar.gz復制到目錄：/home/chh/Project/qt,然後解壓：#tarzxvfqt-embedded-linux-opensource-src.tar.gz，得到新目錄qt-embedded-linux-opensource-src-4.5.2。

進入qt-embedded-linux-opensource-src-4.5.2目錄，首先進行configure。這里的參數很重要，必不可少的是-embeddedarm，所以最簡單的配置信息可以這樣：

./configure-embeddedarm

然後回車，就開始configure了，參數設置和參考文章一樣，裁減了很多，減少了編譯時間：

./configure-release-shared-fast-no-largefile-qt-sql-sqlite-no-qt3support-no-xmlpatterns-no-mmx-no-3dnow-no-sse-no-sse2-no-svg-no-webkit-qt-zlib-qt-gif-qt-libtiff-qt-libpng-qt-libmng-qt-libjpeg-makelibs-xplatformqws/linux-arm-g++-nomaketools-nomakeexamples-nomakedocs-nomakedemo-no-nis-no-cups-no-iconv-no-dbus-no-openssl-embeddedarm-little-endian-qt-freetype-depths16,18-qt-gfx-linuxfb-no-gfx-transformed-no-gfx-multiscreen-no-gfx-vnc-no-gfx-qvfb-qt-kbd-usb-no-glib

之後就可以編譯了，＃make，漫長等待後再＃makeinstall。Makeinstall還是需要root許可權。

完成後，在/usr/local/Trolltech下多了一個目錄：QtEmbedded-4.5.2-arm。

㈡ 批處理中sed如何使用

他是 Gentoo Technologies, Inc. 的總裁兼 CEO，Gentoo Linux（用於 PC 的高級 Linux）和 Portage 系統（Linux 的下一代埠系統）的創始人。他還是 Macmillan 書籍Caldera OpenLinux Unleashed、SuSE Linux Unleashed 和Samba Unleashed 的作者。Daniel 自小學二年級起就與計算機結下不解之緣，那時他首先接觸的是 Logo 程序語言，並沉溺於 Pac-Man 游戲中。這也許就是他至今仍擔任 SONY Electronic Publishing/Psygnosis 的首席圖形設計師的原因所在。Daniel 喜歡與妻子 Mary 和新出生的女兒 Hadassah 一起共度時光。可通過[email protected] 與 Daniel 聯系。
挑選編輯器在UNIX 世界中有很多文本編輯器可供我們選擇。思考一下 -- vi、emacs 和 jed 以及很多其它工具都會浮現在腦海中。我們都有自己已逐漸了解並且喜愛的編輯器（以及我們喜愛的組合鍵）。有了可信賴的編輯器，我們可以輕松處理任何數量與 UNIX 有關的管理或編程任務。
雖然互動式編輯器很棒，但卻有其限制。盡管其互動式特性可以成為強項，但也有其不足之處。考慮一下需要對一組文件執行類似更改的情形。您可能會本能地運行自己所喜愛的編輯器，然後手工執行一組煩瑣、重復和耗時的編輯任務。然而，有一種更好的方法。
進入sed如果可以使編輯文件的過程自動化，以便用「批處理」方式編輯文件，甚至編寫可以對現有文件進行復雜更改的腳本，那將太好了。幸運的是，對於這種情況，有一種更好的方法 -- 這種更好的方法稱為 "sed"。
sed 是一種幾乎包括在所有 UNIX 平台（包括 Linux）的輕量級流編輯器。sed 有許多很好的特性。首先，它相當小巧，通常要比您所喜愛的腳本語言小很多倍。其次，因為 sed 是一種流編輯器，所以，它可以對從如管道這樣的標准輸入接收的數據進行編輯。因此，無需將要編輯的數據存儲在磁碟上的文件中。因為可以輕易將數據管道輸出到 sed，所以，將 sed 用作強大的 shell 腳本中長而復雜的管道很容易。試一下用您所喜愛的編輯器去那樣做。
GNU sed對Linux 用戶來說幸運的是，最好的 sed 版本之一恰好是 GNU sed，其當前版本是 3.02。每一個 Linux 發行版都有（或至少應該有）GNU sed。GNU sed 之所以流行不僅因為可以自由分發其源代碼，還因為它恰巧有許多對 POSIX sed 標准便利、省時的擴展。另外，GNU 沒有 sed 早期專門版本的很多限制，如行長度限制 -- GNU 可以輕松處理任意長度的行。
最新的 GNU sed
在研究這篇文章之時我注意到：幾個在線 sed 愛好者提到 GNU sed 3.02a。奇怪的是，在ftp.gnu.org（有關這些鏈接，請參閱參考資料）上找不到 sed 3.02a，所以，我只得在別處尋找。我在alpha.gnu.org 的 /pub/sed 中找到了它。於是我高興地將其下載、編譯然後安裝，而幾分鍾後我發現最新的 sed 版本卻是 3.02.80 -- 可在alpha.gnu.org 上 3.02a 源代碼旁邊找到其源代碼。安裝完 GNU sed 3.02.80 之後，我就完全准備好了。
正確的 sed在本系列中，將使用 GNU sed 3.02.80。在即將出現的本系列後續文章中，某些（但非常少）最高級的示例將不能在 GNU sed 3.02 或 3.02a 中使用。如果您使用的不是 GNU sed，那麼結果可能會不同。現在為什麼不花些時間安裝 GNU sed 3.02.80 呢？那樣，不僅可以為本系列的餘下部分作好准備，而且還可以使用可能是目前最好的 sed。
sed 示例sed 通過對輸入數據執行任意數量用戶指定的編輯操作（「命令」）來工作。sed 是基於行的，因此按順序對每一行執行命令。然後，sed 將其結果寫入標准輸出 (stdout)，它不修改任何輸入文件。
$ sed -e 'd' /etc/services
如果輸入該命令，將得不到任何輸出。那麼，發生了什麼？在該例中，用一個編輯命令 'd' 調用 sed。sed 打開 /etc/services 文件，將一行讀入其模式緩沖區，執行編輯命令（「刪除行」），然後列印模式緩沖區（緩沖區已為空）。然後，它對後面的每一行重復這些步驟。這不會產生輸出，因為 "d" 命令除去了模式緩沖區中的每一行！
在該例中，還有幾件事要注意。首先，根本沒有修改 /etc/services。這還是因為 sed 只讀取在命令行指定的文件，將其用作輸入 -- 它不試圖修改該文件。第二件要注意的事是 sed 是面向行的。'd' 命令不是簡單地告訴 sed 一下子刪除所有輸入數據。相反，sed 逐行將 /etc/services 的每一行讀入其稱為模式緩沖區的內部緩沖區。一旦將一行讀入模式緩沖區，它就執行 'd' 命令，然後列印模式緩沖區的內容（在本例中沒有內容）。我將在後面為您演示如何使用地址范圍來控制將命令應用到哪些行 -- 但是，如果不使用地址，命令將應用到所有行。
第三件要注意的事是括起 'd' 命令的單引號的用法。養成使用單引號來括起 sed 命令的習慣是個好注意，這樣可以禁用 shell 擴展。
另一個 sed 示例
下面是使用 sed 從輸出流除去 /etc/services 文件第一行的示例：
$ sed -e '1d' /etc/services | more
如您所見，除了前面有 '1' 之外，該命令與第一個 'd' 命令十分類似。如果您猜到 '1' 指的是第一行，那您就猜對了。與第一個示例中只使用 'd' 不同的是，這一次使用的 'd' 前面有一個可選的數字地址。通過使用地址，可以告訴 sed 只對某一或某些特定行進行編輯。
$ sed -e '1,10d' /etc/services | more
當用逗號將兩個地址分開時，sed 將把後面的命令應用到從第一個地址開始、到第二個地址結束的范圍。在本例中，將 'd' 命令應用到第 1 到 10 行（包括這兩行）。所有其它行都被忽略。
帶規則表達式的地址
現在演示一個更有用的示例。假設要查看 /etc/services 文件的內容，但是對查看其中包括的注釋部分不感興趣。為了

㈢ 吉林網路運維學習都需要會什麼沒基礎可以嗎

網路基礎+操作系統（核心學Linux）+資料庫（待遇高便於提升深造）；系統運維的工作越來越有經驗，軟體工程師就是吃青春飯。做系統運維，以後可以轉向管理，職業很有前景。建議你先學一個基礎，然後工作1年再深化培訓。 可以學RHCE+CCNP+OCP,WINDOWS的我想你每天自學也沒問題可以不學，系統運維就是比較細 雜 廣 系統運維要求什麼都懂一點，主要是基於Linux、UNIX有前途，shell 網路 資料庫都需要懂一些。越老越吃香 知識不需要太多創造性的東西 了解基本規律 然後去部署排錯 以後轉管理。
深入了解Linux/Unix操作系統
深入了解分布式系統、計算機網路、硬體體系結構
精通Linux/Unix環境下腳本語言（Shell、Perl、PHP、JSP、Python）的編程
熟練使用grep、awk、sed、vi等系統工具
可以學 RHCE+CCNP+OCP
RHCE是紅帽Linux認證 目前最普及的企業版LINUX發行版的認證 學了通吃LINUX 再學一下AIX 就UNIX搞定；可以朝RHCA發展
CCNP 基本是思科網路工程師比較成熟基礎的技能培訓認證 ，將來有錢了可以朝CCIE發展
OCP Oracle資料庫DBA認證專家 也是成熟的基礎認證 ，可以發展為OCM
吉林北大青鳥計算機學校還不錯，好多大企業都認他們的學員。

㈣ linux中運行一個腳本，用戶不需要什麼樣的許可權

linux中運行一個腳本，用戶不需要W許可權。

執行：1。

寫入：2。

讀取：4。

其他許可權分別是

－rw－－－－－－－ （600） －－ 只有讀寫許可權。

－rw－r－－r－－ （644） －－ 只有有讀寫許可權；而屬組用戶和其他用戶只有讀許可權。

－rwx－－－－－－ （700） －－ 只有有讀、寫、執行許可權。

－rwxr－xr－x （755） －－ 有讀、寫、執行許可權；而屬組用戶和其他用戶只有讀、執行許可權。

－rwx－－x－－x （711） －－ 有讀、寫、執行許可權；而屬組用戶和其他用戶只有執行許可權。

(4)sed源碼編譯擴展閱讀：

sed ＝ filename ｜ sed ＇N；s／＼n／＼t／＇

＃ 對文件中的所有行編號（行號在左，文字右端對齊）。

sed ＝ filename ｜ sed ＇N； s／＾／ ／； s／ ＊＼（．＼｛6，＼｝＼）＼n／＼1 ／＇

＃ 對文件中的所有行編號，但只顯示非空白行的行號。

sed ＇／．／＝＇ filename ｜ sed ＇／．／N； s／＼n／ ／＇

＃ 計算行數 （模擬 ＂wc －l＂）

㈤ 如何編譯SQLite-How To Compile SQLite

SQLite是ANSI-C的源代碼。在使用之前必須要編譯成機器碼。這篇文章是用於各種編譯SQLite方法的指南。

這篇文章不包含編譯SQLite的每個步驟的反饋，那樣可能會困難因為每種開發場景都不同。所以這篇文章描述和闡述了編譯Sqlite的原則。典型的編譯命令已經作為例子提供了，以期望應用開發者能夠使用這些例子作為完成他們自己定製的編譯過程的的一個指南。換句話說，這篇文章提供了想法和見解，而不是交鑰匙的解決方法。

融合VS單獨源文件

Sqlite是由超過一百個c源碼文件以及眾多的目錄下的腳本構建的。Sqlite的實現是純粹的ANSI-C，但是許多c語言源代碼文件是由輔助的C程序生成或者轉換來的，並且AWK，SED和TCL腳本會融合到完成的sqlite庫中。對Sqlite構建需要的C程序和轉換和創建C語言源碼是一個復雜的過程。

為了簡化這些，sqlite也通過一個預打包的合並後的源碼文件：sqlite3.c。這個合並文件是一個ANSI-C源碼實現整個SQLite庫的唯一文件。合並後的文件更容易處理。所有的東西都包含在這一個文件里，所以很容易進入一個更大的C或者C++程序的源碼樹。所有的代碼生成和轉換步驟都已經實現了，因此沒有輔助的C程序需要去配置和變異，也沒有腳本需要去運行。並且，因此所有哭都包含在一個翻譯單元，編譯器可以做更多高級的優化從而提升5%到10%的性能。因為這些原因，融合後的源碼文件sqlite3.c對所有程序來講都是值得推薦的。

推薦所有的應用程序使用融合文件。

直接從單獨的源碼文件中構建sqlite當然可以，但是並不推薦。對一些特殊的應用程序，可能需要修改構建程序去處理使用那些從網站上下載的預構建的源碼文件不能完成的情況。對於這些情況，推薦構建和使用一個定製過的合並文件。換句話說，即使一個工程需要以單獨的源碼文件構建sqlite，仍然推薦使用一個融合後的源碼文件作為一個中間步驟。

編譯命令行介面（CLI）

構建命令行介面需要三個源碼文件：

sqlite3.c:Sqlite融合的源碼文件

sqlite3.h:匹配sqlite3.c以及定義sqlite的c語言介面的頭文件

shell.c:命令行介面程序本身。這個c源碼文件包含一個main()的常式和每輪循環的用戶輸入的提示符並將輸入傳給sqlite資料庫引擎用於處理。

所有的上述源碼的三個文件都被包含在下載頁面的amalgamation tarball中。

為了構建CLI，簡單的將這三個文件放置在相同的目錄下然後一起編譯他們。用MSVC：
cl shell.c sqlite3.c -Fesqlite3.exe

在unix系統上（或者在windows上用cygwin或者mingw+msys）典型的命令會有些像這樣：
gcc shell.c sqlite3.c -lpthread -ldl

為了SQLite線程安全，需要pthreads庫。但是因為CLI是一個單線程的，我們可以指示SQLite構建一個非線程安全的庫並因此護綠pthreads庫：
gcc -DSQLITE_THREADSAFE=0 shell.c sqlite3.c -ldl

-ldl庫是在支持動態裝載時需要，例如sqlite3_load_extension() 介面和load_extension()
SQL function。如果這些特性都不要求，那麼我們也可以使用SQLITE_OMIT_LOAD_EXTENSION編譯時間選項忽略他們。
gcc -DSQLITE_THREADSAFE=0 -DSQLITE_OMIT_LOAD_EXTENSION shell.c sqlite3.c

有人可能想要提供其他的編譯時間選項(compile-time options)，例如SQLITE_ENABLE_FTS3去全文本搜索或者SQLITE_ENABLE_RTREE用於R*樹搜索引擎擴展。而有人將正常指定一些編譯優化開關。（預編譯的CLI可以從選擇sqlite網站上使用「-Os」下載下來）有無數種可能的變數在這里。

關鍵點在這里：構建CLI需要編譯一起兩個C語言文件。shell.c文件包含入口的定義和用戶輸入的loop，而sqlite融合文件sqlite3.c包含完整的sqlite庫的實現。

編譯TCL介面

sqlite的tcl介面是一個小的模塊被添加到一般的融合文件中。結果是一個新的融合後的源碼文件，稱之為「tclsqlite3.c」。這個源碼文件是生成一個可以使用TCL

load命令去載入到一個標準的tclsh或者wish中，或者隨著sqlite構建成功生成一個單獨唯一的tclsh的共享庫所需要的。一個tcl的融合的副本被包含在下載頁的TEA
tarball中作為一個文件。

為了生成一個linux上的sqlite的TCL-loadable庫,下面的命令需要滿足：
gcc -o libtclsqlite3.so -shared tclsqlite3.c -lpthread -ldl -ltcl

不幸的是構建Mac OS X 和 Windows的共享庫並不是如此簡單。對於這些平台最好使用包含在TEA tarball中的configure腳本和makefile.

為了生成一個單獨的tclsh，可以用於sqlite靜態鏈接，使用如下的編譯器調用：
gcc -DTCLSH=1 tclsqlite3.c -ltcl -lpthread -ldl -lz -lm

這里的技巧是-DTCLSH=1選項。sqlite的TCL介面模塊包含一個main的過程，用於初始化一個TCL解釋器並在以-DTCLSH=1編譯後進入到一個命令行loop。上述命令可以工作在Linux和Mac
OS X,雖然有時可能需要依賴於平台調整庫選項以及編譯的TCL的哪一個版本。

構建融合文件

下載頁提供的sqlite融合文件的版本對大多數用戶來說是足夠的。然而，一些工程可能想要或者需要構建他們自己的融合文件。一個常見的構建一個定製的融合文件的理由是為了使用特定的compile-time options來定製sqlite庫。回想sqlite融合文件中包含了許多C代碼由輔助程序和腳本生成。許多的編譯時間選項影響這一成聖代碼而且必須在融合文件組裝前提供給代碼生成器。這一系列必須傳給代碼生成器的編譯時間相關的選項會使得sqlite的發布版本各不相同，但是在寫這邊文章的時候，代碼生成器需要知道的這組選項包括：

SQLITE_ENABLE_UPDATE_DELETE_LIMIT
SQLITE_OMIT_ALTERTABLE
SQLITE_OMIT_ANALYZE
SQLITE_OMIT_ATTACH
SQLITE_OMIT_AUTOINCREMENT
SQLITE_OMIT_CAST
SQLITE_OMIT_COMPOUND_SELECT
SQLITE_OMIT_EXPLAIN
SQLITE_OMIT_FOREIGN_KEY
SQLITE_OMIT_PRAGMA
SQLITE_OMIT_REINDEX
SQLITE_OMIT_SUBQUERY
SQLITE_OMIT_TEMPDB
SQLITE_OMIT_TRIGGER
SQLITE_OMIT_VACUUM
SQLITE_OMIT_VIEW
SQLITE_OMIT_VIRTUALTABLE

為了構建一個定製的融合文件，先下載原始的獨立源碼文件到一個unix或者類unix開發平台。確定獲取的原始源碼文件不是「預編譯過的源文件」。任何人都可以通過到下載頁或者直接從configuration management system.獲取完整的一套原始源碼文件。

假設sqlite源碼樹被存在一個名為「sqlite」的目錄下。計劃構建一個平行目錄下的名為「bld」的融合文件。首先通過運行sqlite源碼樹種的configure腳本運行或者通過製作一份源碼樹頂層的的makfile模板的一份，來構建一個合適的makefile.然後手動編輯這個Makfile去包含需要的編譯時間相關的選項。最終運行：
make sqlite3.c

在windows上使用MSVC:
nmake /f Makefile.msc sqlite3.c

sqlite3.c的make
target會自動構造一般的「sqlite3.c」合並的源碼文件，以及它的頭文件「sqlite3.h」，和包含TCL介面的融合源碼文件「tclsqlite3.c」。之後，需要的文件可以被拷貝到文件目錄下然後根據上述勾勒的過程編譯。

構建一個windows的動態鏈接庫DLL

為了在windows構建一個sqlite的dll使用，首先獲取對應的融合過的源碼文件，sqlit3.c和sqlite.h。這些可以從SQLite website上下載或者和上述告知的一樣去定製生成。

使用工作目錄下的源碼文件，一個dll可以在msvc中使用如下命令生成：
cl sqlite3.c -link -dll -out:sqlite3.dll

上述命令需要運行在msvc的MSVC Native Tools Command
Prompt.如何你已經在機器上安裝了msvc，你可能有多個版本的這種命令提示符，針對於x86和x64的自帶構建的，或者交叉編譯到ARM的。依賴要求的DLL去使用對應合適的命令提示符工具。

如果使用MinGW編譯器，命令是這樣的：
gcc -shared sqlite3.c -o sqlite3.dll

注意MinGW只生成32位的dll。另有一個分開的MinGW64工程可以用來生成64位的dll。可以推斷其命令行語法是類似的。需要注意的是最近的MSVC的版本生成的DLLs可能不能工作到WinXP或者更早版本的windows上。因此為了最大限度的兼容你的生成的dll，推薦MinGW。一個好的經驗法則是使用MinGW去生成32位的dlls，使用msvc去生成64位的dlls。