Use correct syntax markup for shell
Approved by: carlavilla
This commit is contained in:
Li-Wen Hsu
parent
55c95407aa
commit
a9a9e66105
666 changed files with 17924 additions and 17924 deletions
|
|
@ -153,14 +153,14 @@ Tcl 許多的版本都可在 上運作，而最新的 Tcl 版本為 Tcl 8.4， P
|
|||
|
||||
幸運的是，你可以不用理會以上細節，編譯器都會自動完成。 因為 `cc` 只是是個前端程式(front end)，它會依照正確的參數來呼叫相關程式幫你處理。 只需打：
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc foobar.c
|
||||
....
|
||||
|
||||
上述指令會把 [.filename]#foobar.c# 開始編譯，並完成上述動作。 如果你有許多檔案需要編譯，那請打類似下列指令即可：
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc foo.c bar.c
|
||||
....
|
||||
|
|
@ -172,7 +172,7 @@ Tcl 許多的版本都可在 上運作，而最新的 Tcl 版本為 Tcl 8.4， P
|
|||
`-o _檔名_`::
|
||||
`-o` 編譯後的執行檔檔名，如果沒有使用這選項的話， 編譯好的程式預設檔名將會是 [.filename]#a.out#
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc foobar.c 執行檔就是 a.out
|
||||
% cc -o foobar foobar.c 執行檔就是 foobar
|
||||
|
|
@ -181,7 +181,7 @@ Tcl 許多的版本都可在 上運作，而最新的 Tcl 版本為 Tcl 8.4， P
|
|||
`-c`::
|
||||
使用 `-c` 時，只會編譯原始碼，而不作連結(linking)。 當只想確認語法是否正確或使用 Makefile 來編譯程式時，這個選項非常有用。
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc -c foobar.c
|
||||
....
|
||||
|
|
@ -191,7 +191,7 @@ Tcl 許多的版本都可在 上運作，而最新的 Tcl 版本為 Tcl 8.4， P
|
|||
`-g`::
|
||||
`-g` 將會把一些給 gdb 用的除錯訊息包進去執行檔裡面，所謂的除錯訊息例如： 程式在第幾行出錯、那個程式第幾行做什麼函式呼叫等等。除錯資訊__非常__好用。 但缺點就是：對於程式來說，額外的除錯訊息會讓編譯出來的程式比較肥些。 `-g` 的適用時機在於：當程式還在開發時使用就好， 而當你要釋出你的 "發行版本(release version)" 或者確認程式可運作正常的話，就不必用 `-g` 這選項了。
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc -g foobar.c
|
||||
....
|
||||
|
|
@ -203,7 +203,7 @@ Tcl 許多的版本都可在 上運作，而最新的 Tcl 版本為 Tcl 8.4， P
|
|||
+
|
||||
只有當要釋出發行版本、或者加速程式時，才需要使用最佳化選項。
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc -O -o foobar foobar.c
|
||||
....
|
||||
|
|
@ -225,7 +225,7 @@ Tcl 許多的版本都可在 上運作，而最新的 Tcl 版本為 Tcl 8.4， P
|
|||
|
||||
一般來說，在撰寫程式時就應要注意『移植性』。 否則。當想把程式拿到另外一台機器上跑的時候，就可能得需要重寫程式。
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc -Wall -ansi -pedantic -o foobar foobar.c
|
||||
....
|
||||
|
|
@ -239,7 +239,7 @@ Tcl 許多的版本都可在 上運作，而最新的 Tcl 版本為 Tcl 8.4， P
|
|||
+
|
||||
規則很簡單，如果有個函式庫叫做 [.filename]#libsomething.a#， 就必須在編譯時加上參數 `-l _something_` 才行。 舉例來說，數學函式庫叫做 [.filename]#libm.a#， 所以你必須給 `cc` 的參數就是 `-lm`。 一般情況下，通常會把這參數必須放在指令的最後。
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc -o foobar foobar.c -lm
|
||||
....
|
||||
|
|
@ -248,7 +248,7 @@ Tcl 許多的版本都可在 上運作，而最新的 Tcl 版本為 Tcl 8.4， P
|
|||
+
|
||||
如果你正在編譯的程式是 C++ 程式碼，你還必須額外指定 {lg-plus-plus} 或者是 {lstdc-plus-plus}。 如果你的 FreeBSD 是 2.2(含)以後版本， 你可以用指令 {c-plus-plus-command} 來取代 `cc`。 在 FreeBSD 上 {c-plus-plus-command} 也可以用 {g-plus-plus-command} 取代。
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc -o foobar foobar.cc -lg++ 適用 FreeBSD 2.1.6 或更早期的版本
|
||||
% cc -o foobar foobar.cc -lstdc++ 適用 FreeBSD 2.2 及之後的版本
|
||||
|
|
@ -261,14 +261,14 @@ Tcl 許多的版本都可在 上運作，而最新的 Tcl 版本為 Tcl 8.4， P
|
|||
|
||||
==== 我用 sin() 函示撰寫我的程式， 但是有個錯誤訊息(如下)，這代表著？
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
/var/tmp/cc0143941.o: Undefined symbol `_sin' referenced from text segment
|
||||
....
|
||||
|
||||
當使用 `sin()` 這類的數學函示時， 你必須告訴 cc 要和數學函式庫作連結(linking)，就像這樣：
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc temp.c -lm
|
||||
....
|
||||
|
|
@ -296,14 +296,14 @@ int main() {
|
|||
|
||||
編譯後執行程式，得到下面這結果：
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc temp.c -lm
|
||||
....
|
||||
|
||||
加了上述內容之後，再重新編譯，最後執行：
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% ./a.out
|
||||
2.1 ^ 6 = 85.766121
|
||||
|
|
@ -315,7 +315,7 @@ int main() {
|
|||
|
||||
記得，除非有指定編譯結果的執行檔檔名，否則預設的執行檔檔名是 a.out。 用 `-o _filename_` 參數， 就可以達到所想要的結果，比如：
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc -o foobar foobar.c
|
||||
....
|
||||
|
|
@ -324,7 +324,7 @@ int main() {
|
|||
|
||||
與 不同的是，除非有指定執行檔的路徑， 否則 系統並不會在目前的目錄下尋找你想執行的檔案。 在指令列下打 `./foobar` 代表 "執行在這個目錄底下名為 [.filename]#foobar# 的程式"， 或者也可以更改 `PATH` 環境變數設定如下，以達成類似效果：
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
bin:/usr/bin:/usr/local/bin:.
|
||||
....
|
||||
|
|
@ -335,7 +335,7 @@ bin:/usr/bin:/usr/local/bin:.
|
|||
|
||||
大多數的 系統都會在路徑 [.filename]#/usr/bin# 擺放執行檔。 除非有指定使用在目前目錄內的 [.filename]#test#，否則 shell 會優先選擇位在 [.filename]#/usr/bin# 的 [.filename]#test#， 要指定檔名的話，作法類似：
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% ./test
|
||||
....
|
||||
|
|
@ -417,14 +417,14 @@ No, fortunately not (unless of course you really do have a hardware problem...).
|
|||
|
||||
Yes, just go to another console or xterm, do
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% ps
|
||||
....
|
||||
|
||||
to find out the process ID of your program, and do
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% kill -ABRT pid
|
||||
....
|
||||
|
|
@ -444,7 +444,7 @@ If you want to create a core dump from outside your program, but do not want the
|
|||
|
||||
When you are working on a simple program with only one or two source files, typing in
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc file1.c file2.c
|
||||
....
|
||||
|
|
@ -453,7 +453,7 @@ is not too bad, but it quickly becomes very tedious when there are several files
|
|||
|
||||
One way to get around this is to use object files and only recompile the source file if the source code has changed. So we could have something like:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc file1.o file2.o … file37.c …
|
||||
....
|
||||
|
|
@ -501,7 +501,7 @@ install:
|
|||
|
||||
We can tell make which target we want to make by typing:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% make target
|
||||
....
|
||||
|
|
@ -591,7 +591,7 @@ If you want to have a look at these system makefiles, they are in [.filename]#/u
|
|||
|
||||
The version of make that comes with FreeBSD is the Berkeley make; there is a tutorial for it in [.filename]#/usr/shared/doc/psd/12.make#. To view it, do
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% zmore paper.ascii.gz
|
||||
....
|
||||
|
|
@ -635,7 +635,7 @@ Which one to use is largely a matter of taste. If familiar with one only, use th
|
|||
|
||||
Start up lldb by typing
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% lldb -- progname
|
||||
....
|
||||
|
|
@ -644,7 +644,7 @@ Start up lldb by typing
|
|||
|
||||
Compile the program with `-g` to get the most out of using `lldb`. It will work without, but will only display the name of the function currently running, instead of the source code. If it displays a line like:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
Breakpoint 1: where = temp`main, address = …
|
||||
....
|
||||
|
|
@ -687,7 +687,7 @@ This program sets i to be `5` and passes it to a function `bazz()` which prints
|
|||
|
||||
Compiling and running the program displays
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc -g -o temp temp.c
|
||||
% ./temp
|
||||
|
|
@ -697,7 +697,7 @@ anint = -5360
|
|||
|
||||
That is not what was expected! Time to see what is going on!
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% lldb -- temp
|
||||
(lldb) target create "temp"
|
||||
|
|
@ -745,7 +745,7 @@ Process 9992 stopped
|
|||
|
||||
Hang on a minute! How did anint get to be `-5360`? Was it not set to `5` in `main()`? Let us move up to `main()` and have a look.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
(lldb) up Move up call stack
|
||||
frame #1: 0x000000000020130b temp`main at temp.c:9:2 lldb displays stack frame
|
||||
|
|
@ -788,7 +788,7 @@ To examine a core file, specify the name of the core file in addition to the pro
|
|||
|
||||
The debugger will display something like this:
|
||||
|
||||
[source,bash,subs="verbatim,quotes"]
|
||||
[source,shell,subs="verbatim,quotes"]
|
||||
....
|
||||
% lldb -c [.filename]#progname.core# -- [.filename]#progname#
|
||||
(lldb) target create "[.filename]#progname#" --core "[.filename]#progname#.core"
|
||||
|
|
@ -798,7 +798,7 @@ Core file '/home/pauamma/tmp/[.filename]#progname.core#' (x86_64) was loaded.
|
|||
|
||||
In this case, the program was called [.filename]#progname#, so the core file is called [.filename]#progname.core#. The debugger does not display why the program crashed or where. For this, use `thread backtrace all`. This will also show how the function where the program dumped core was called.
|
||||
|
||||
[source,bash,subs="verbatim,quotes"]
|
||||
[source,shell,subs="verbatim,quotes"]
|
||||
....
|
||||
(lldb) thread backtrace all
|
||||
* thread #1, name = 'progname', stop reason = signal SIGSEGV
|
||||
|
|
@ -816,7 +816,7 @@ One of the neatest features about `lldb` is that it can attach to a program that
|
|||
|
||||
To do that, start up another `lldb`, use `ps` to find the process ID for the child, and do
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
(lldb) process attach -p pid
|
||||
....
|
||||
|
|
@ -848,14 +848,14 @@ Now all that is needed is to attach to the child, set PauseMode to `0` with `exp
|
|||
|
||||
Start up gdb by typing
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% gdb progname
|
||||
....
|
||||
|
||||
although many people prefer to run it inside Emacs. To do this, type:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
M-x gdb RET progname RET
|
||||
....
|
||||
|
|
@ -866,7 +866,7 @@ Finally, for those finding its text-based command-prompt style off-putting, ther
|
|||
|
||||
Compile the program with `-g` to get the most out of using `gdb`. It will work without, but will only display the name of the function currently running, instead of the source code. A line like:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
... (no debugging symbols found) ...
|
||||
....
|
||||
|
|
@ -903,7 +903,7 @@ This program sets i to be `5` and passes it to a function `bazz()` which prints
|
|||
|
||||
Compiling and running the program displays
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% cc -g -o temp temp.c
|
||||
% ./temp
|
||||
|
|
@ -913,7 +913,7 @@ anint = 4231
|
|||
|
||||
That was not what we expected! Time to see what is going on!
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% gdb temp
|
||||
GDB is free software and you are welcome to distribute copies of it
|
||||
|
|
@ -935,7 +935,7 @@ bazz (anint=4231) at temp.c:17 gdb displays stack frame
|
|||
|
||||
Hang on a minute! How did anint get to be `4231`? Was it not set to `5` in `main()`? Let us move up to `main()` and have a look.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
(gdb) up Move up call stack
|
||||
#1 0x1625 in main () at temp.c:11 gdb displays stack frame
|
||||
|
|
@ -969,7 +969,7 @@ A core file is basically a file which contains the complete state of the process
|
|||
|
||||
To examine a core file, start up `gdb` in the usual way. Instead of typing `break` or `run`, type
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
(gdb) core progname.core
|
||||
....
|
||||
|
|
@ -978,7 +978,7 @@ If the core file is not in the current directory, type `dir /path/to/core/file`
|
|||
|
||||
The debugger should display something like this:
|
||||
|
||||
[source,bash,subs="verbatim,quotes"]
|
||||
[source,shell,subs="verbatim,quotes"]
|
||||
....
|
||||
% gdb [.filename]#progname#
|
||||
GDB is free software and you are welcome to distribute copies of it
|
||||
|
|
@ -997,7 +997,7 @@ In this case, the program was called [.filename]#progname#, so the core file is
|
|||
|
||||
Sometimes it is useful to be able to see how a function was called, as the problem could have occurred a long way up the call stack in a complex program. `bt` causes `gdb` to print out a back-trace of the call stack:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
(gdb) bt
|
||||
#0 0x164a in bazz (anint=0x5) at temp.c:17
|
||||
|
|
@ -1014,7 +1014,7 @@ One of the neatest features about `gdb` is that it can attach to a program that
|
|||
|
||||
To do that, start up another `gdb`, use `ps` to find the process ID for the child, and do
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
(gdb) attach pid
|
||||
....
|
||||
|
|
@ -1097,7 +1097,7 @@ Unfortunately, there is far too much here to explain it in detail; however there
|
|||
* Emacs already has a pre-defined function called `next-error`. In a compilation output window, this allows you to move from one compilation error to the next by doing `M-n`; we define a complementary function, `previous-error`, that allows you to go to a previous error by doing `M-p`. The nicest feature of all is that `C-c C-c` will open up the source file in which the error occurred and jump to the appropriate line.
|
||||
* We enable Emacs's ability to act as a server, so that if you are doing something outside Emacs and you want to edit a file, you can just type in
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% emacsclient filename
|
||||
....
|
||||
|
|
@ -1400,7 +1400,7 @@ Now, this is all very well if you only want to program in the languages already
|
|||
|
||||
The first thing to do is find out if whizbang comes with any files that tell Emacs about the language. These usually end in [.filename]#.el#, short for "Emacs Lisp". For example, if whizbang is a FreeBSD port, we can locate these files by doing
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% find /usr/ports/lang/whizbang -name "*.el" -print
|
||||
....
|
||||
|
|
@ -1409,14 +1409,14 @@ and install them by copying them into the Emacs site Lisp directory. On FreeBSD,
|
|||
|
||||
So for example, if the output from the find command was
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
/usr/ports/lang/whizbang/work/misc/whizbang.el
|
||||
....
|
||||
|
||||
we would do
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# cp /usr/ports/lang/whizbang/work/misc/whizbang.el /usr/local/shared/emacs/site-lisp
|
||||
....
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue