# 13_questions_of_shell **Repository Path**: fly542/questions_of_shell_13 ## Basic Information - **Project Name**: 13_questions_of_shell - **Description**: No description available - **Primary Language**: Unknown - **License**: GPL-2.0 - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2021-06-30 - **Last Updated**: 2021-06-30 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # 13_questions_of_shell shell十三问--shell教程（markdown 版本） ##shell十三问之1: 何为shell？ _______________________________________ `shell`是什么东西之前，不妨让我们重新审视`使用者`和`计算机系统`的关系： （此处为使用者和计算机系统的关系图） 我们知道计算机的运作不能离开硬件，但使用者却无法直接操作硬件， 硬件的驱动只能通过一种称为“`操作系统`(`OS`，`Opertating System`)”的软件来管控。 事实上，我们每天所谈的“`linux`”，严格来说只是一个`操作系统`(`OS`), 我们称之为“`内核`(`kernel`)”。 然而，从使用者的角度来说，使用者没有办法直接操作一个`kernel`， 而是通过`kernel`的“外壳”程序，也就是所谓的`shell`，来与`kernel`沟通。 这也正是`kernel`跟`shell`的形象命名的的关系。如图： （此处为kernel-->shell关系图；) 从技术的角度来说，`shell`是一个使用者与系统的`交互界面(interface)`, 只能让使用者通过`命令行`(`command line`)来使用系统来完成工作。 因此，`shell`最简单的定义就是----`命令解释器`( `Command Interpreter`): - 将使用者的命令翻译给kernel来处理； - 同时，将kernel的处理结果翻译给使用者。 每次当我们完成`系统登入`(`login`), 我们就取得一个交互模式的shell， 也称之为`login shell` 或者 `primary shell`。 若从`进程`(`process`)的角度来说，我们在shell所下达的命令，均是shell所产生的`子进程`。 这种现象，我暂可称之为`fork`。 如果是执行`shell脚本`(`shell script`)的话，脚本中命令则是由另一个非交互模式的 `子shell`(`sub shell`)来执行的。 也就是primary shell产生sub shell的进程，而该sub shell 进程再产生script中所有命令的进程。 (关于进程，我们日后有机会在补充) 这里， 我们必须知道：`kernel` 与 `shell` 是不同的两套软件，而且都是可以被替换的： - 不同的`OS`使用不同的`kernel`; - 同一个kernel之上，也可以使用不同的`shell`; 在`Linux`的预设系统中，通常可以找到好几种不同的`shell`, 且通常会被记录在如下文件中： ```shell /etc/shells ``` 不同的`shell`有着不同的功能，且彼此各异，或者说“大同小异”。 常见的`shell`主要分为两大主流： 1. sh： - burne shell (sh) - burne again shell (bash) 2. csh： - c shell (csh) - tc shell (tcsh) - korn shell (ksh) (FIXME) 大部分的Linux操作系统的预设shell都是`bash`，其原因大致如下两种： - 自由软件 - 功能强大 bash是gnu project最成功的产品之一，自推出以来深受广大`Unix`用户的喜爱， 且也逐渐成为不少组织的系统标准。 ##shell十三问之2：shell prompt(PS1)与Carriage Return(CR)关系 _____________________________________________________________ 当你成功登陆一个shell终端的文字界面之后，大部分的情形下， 你会在屏幕上看到一个不断闪烁的方块或者底线(视不同的版本而别)， 我们称之为`游标`(`cursor`). `cursor`作用就是告诉你接下来你从键盘输入的按键所插入的位置， 且每输入一个键，`cursor`便向右移动一个格子， 如果连续输入太多的话，则自动接在下一行输入。 假如你刚完成登陆，还没有输入任何按键之前， 你所看到的`cursor`所在的位置的同一行的左边部分，我们称之为`提示符`(`prompt`)。 `提示符`的格式或因不同的版本而各有不同， 在Linux上，只需留意最接近`游标`的一个提示符号，通常是如下两者之一： - $: 给一般用户账号使用; - \#: 给root(管理员)账号使用; 事实上，shell prompt的意思很简单： 告诉shell使用者，您现在可以输入命令行了。 我们可以说，使用者只有在得到shell prompt才能打命令行， 而`cursor`是指示键盘在命令行的输入位置，使用者每输入一个键， `cursor`就往后移动一个格，直到碰到命令行读进`CR`(`Carriage Return`, 由`Enter`键产生)字符为止。 `CR`的意思也很简单： 使用者告诉shell：老兄，你可以执行的我命令行了。 严格来说： 所谓的命令行， 就是在`shell prompt`与`CR`之间所输入的文字。 (**question：为何我们这里坚持使用`CR`字符而不说`Enter`按键呢？ 答案在后面的学习中给出**)。 不同的命令可以接受的命令的格式各有不同， 一般情况下，一个标准的命令行格式为如下所列： ```shell command-name options argument ``` 若从技术的细节上来看， shell会依据`IFS`(`Internal Field Seperator`) 将 command line 所输入的文字给拆解为`字段`(`word`). 然后在针对特殊的字符(meta)先做处理，最后在重组整行command line。 (**注意：请务必理解以上两句的意思，我们日后的学习中常回到这里思考**。) 其中`IFS`是shell预设使用的字段位分隔符号，可以由一个及多个如下按键组成： - 空白键(White Space) - 表格键(Tab) - 回车键(Enter) 系统可以接受的命令的名称(command-name)可以从如下途径获得： - 确的路径所指定的外部命令 - 命令的别名(alias) - shell内建命令(built-in) - $PATH之下的外部命令 每一个命令行均必须包含命令的名称，这是不能缺少的。 ##shell十三问之3：别人echo、你也echo，是问echo知多少？ ----------------------------------------------------- 承接上一章介绍的`command line`, 这里我们用`echo`这个命令加以进一步说明。 > **温习** > 标准的`command line`三个组成部分：`command_name option argument` `echo`是一个非常简单、直接的Linux命令： ```shell $echo argument ``` `echo`将argument送出到`标准输出`(`stdout`),通常是在监视器(monitor)上输出。 > **Note：** > 在linux系统中任何一个进程默认打开三个文件：stdin、stdout、stderr. > stdin 标准输入 > stdout 标准输出 > stderr 标准错误输出 为了更好理解，不如先让我们先跑一下`echo`命令好了： ```shell $echo $ ``` 你会发现只有一个空白行，然后又回到了`shell prompt`上了。 这是因为`echo`在预设上，在显示完argument之后，还会送出以一个换行符号 (`new-line charactor`). 但是上面的command `echo`并没有任何argument，那结果就只剩一个换行符号。 若你要取消这个换行符号， 可以利用`echo`的`-n` 选项: ```shell $echo -n $ ``` 不妨让我们回到`command line`的概念上来讨论上例的echo命令好了： `command line`只有command_name(`echo`)及option(`-n`),并没有显示任何`argument`。 要想看看`echo`的`argument`，那还不简单接下来，你可以试试如下的输入： ```shell $echo first line first line $echo -n first line first line $ ``` 以上两个`echo`命令中，你会发现`argument`的部分显示在你的屏幕， 而换行符则视 `-n` 选项的有无而别。 很明显的，第二个`echo`由于换行符被取消了， 接下来的`shell prompt`就接在输出结果的同一行了... ^_^。 事实上，`echo`除了`-n` 选项之外，常用选项有： - -e: 启用反斜杠控制字符的转换(参考下表) - -E: 关闭反斜杠控制字符的转换(预设如此) - -n: 取消行末的换行符号(与-e选项下的\c字符同意) 关于`echo`命令所支持的反斜杠控制字符如下表： |转义字符|字符的意义| ---------|----------| |\a | ALERT / BELL(从系统的喇叭送出铃声)| |\b | BACKSPACE, 也就是向左退格键| |\c | 取消行末之换行符号 |\E | ESCAPE, 脱字符键| |\f | FORMFEED, 换页字符| |\n | NEWLINE, 换行字符 | |\r | RETURN, 回车键| |\t | TAB, 表格跳位键| |\v | VERTICAL TAB, 垂直表格跳位键| |\n | ASCII 八进制编码(以x开头的为十六进制)，此处的n为数字 |\\ | 反斜杠本身| > **Note：** > 上述表格的资料来自O'Reilly出版社的**Learning the Bash Shell, 2nd Ed**. 或许，我们可以通过实例来了解`echo`的选项及控制字符： 例一： ```shell $ echo -e "a\tb\tc\n\d\te\tf" a b c d e f $ ``` 上例中，用\t来分割abc还有def，及用\n将def换至下一行。 例二： ```shell $echo -e "\141\011\142\011\143\012\144\011\145\011\146" a b c d e f ``` 与例一中结果一样，只是使用ASCII八进制编码。 例三： ```shell $echo -e "\x61\x09\x62\x09\x63\x0a\x64\x09\x65\x09\x66" a b c d e f ``` 与例二差不多，只是这次换用ASCII的十六进制编码。 例四： ```shell $echo -ne "a\tb\tc\nd\te\bf\a" a b c d f $ ``` 因为e字母后面是退格键(\b)，因此输出结果就没有e了。 在结束的时听到一声铃响，是\a的杰作。 由于同时使用了-n选项，因此`shell prompt`紧接在第二行之后。 若你不用-n的话，那你在\a后再加个\c，也是同样的效果。 事实上，在日后的`shell`操作及`shell script`设计上， `echo`命令是最常被使用的命令之一。 比方说，使用`echo`来检查变量值： ```shell $ A=B $ echo $A B $ echo $? 0 ``` > **Note:** > 关于变量的概念，我们留到以下的两章跟大家说明。 好了，更多的关于`command line`的格式， 以及`echo`命令的选项， 请您自行多加练习、运用了... ##shell十三问之4：""(双引号)与''(单引号)差在哪？ ------------------------------------------------ 还是回到我们的`command line`来吧... 经过前面两章的学习，应该很清楚当你在`shell prompt`后面敲打键盘, 直到按下`Enter`键的时候，你输入的文字就是`command line`了， 然后`shell`才会以进程的方式执行你所交给它的命令。 但是，你又可知道：你在`command line`中输入的每一个文字， 对`shell`来说，是有类别之分的呢？ 简单而言，(我不敢说精确的定义，注1), `command line`的每一个`charactor`, 分为如下两种： - literal：也就是普通的纯文字，对`shell`来说没特殊功能； - meta: 对`shell`来说，具有特定功能的特殊保留元字符。 > **Note:** > 对于`bash shell`在处理`comamnd line`的顺序说明， > 请参考O'Reilly出版社的**Learning the Bash Shell，2nd Edition**， > 第177-180页的说明，尤其是178页的流程图：Figure 7-1 ... `literal`没什么好谈的， 像abcd、123456这些"文字"都是literal...(so easy? ^_^) 但meta却常使我们困惑...(confused?) 事实上，前两章，我们在`command line`中已碰到两个 似乎每次都会碰到的meta： - `IFS`：有`space`或者`tab`或者`Enter`三者之一组成(我们常用space) - `CR`: 由`Enter`产生； `IFS`是用来拆解`command line`中每一个词(word)用的， 因为`shell command line`是按词来处理的。 而`CR`则是用来结束`command line`用的，这也是为何我们敲`Enter`键， 命令就会跑的原因。 除了常用的`IFS`与`CR`, 常用的meta还有： |meta字符| meta字符作用| |--------|-------------| |= |设定变量| |$ | 作变量或运算替换(请不要与`shell prompt`混淆)|命令 |>| 输出重定向(重定向stdout)| |<|输入重定向(重定向stdin)| |\||命令管道| |&|重定向file descriptor或将命令至于后台(bg)运行| |()|将其内部的命令置于nested subshell执行，或用于运算或变量替换| |{}|将期内的命令置于non-named function中执行，或用在变量替换的界定范围| |;|在前一个命令执行结束时，而忽略其返回值，继续执行下一个命令| |&&|在前一个命令执行结束时，若返回值为true，继续执行下一个命令| |\|\||在前一个命令执行结束时，若返回值为false，继续执行下一个命令| |!|执行histroy列表中的命令| |... | ...| 假如我们需要在`command line`中将这些保留元字符的功能关闭的话， 就需要quoting处理了。 在`bash`中，常用的quoting有以下三种方法： - hard quote：''(单引号)，凡在hard quote中的所有meta均被关闭； - soft quote：""(双引号)，凡在soft quote中大部分meta都会被关闭，但某些会保留(如$); - escape: \ (反斜杠)，只有在紧接在escape(跳脱字符)之后的单一meta才被关闭； > **Note:** > 在soft quote中被豁免的具体meta清单，我不完全知道， > 有待大家补充，或通过实践来发现并理解。 下面的例子将有助于我们对quoting的了解： ```shell $ A=B C #空白符未被关闭，作为IFS处理 $ C：command not found. $ echo $A $ A="B C" #空白符已被关掉，仅作为空白符 $ echo $A B C ``` 在第一个给A变量赋值时，由于空白符没有被关闭， `command line` 将被解释为： `A=B 然后碰到，接着执行C命令` 在第二次给A变量赋值时，由于空白符被置于soft quote中， 因此被关闭，不在作为`IFS`； `A=BC` 事实上，空白符无论在soft quote还是在hard quote中， 均被关闭。Enter键字符亦然： ```shell $ A=`B > C > ' $ echo "$A" B C ``` 在上例中，由于`enter`被置于hard quote当中，因此不再作为`CR`字符来处理。 这里的`enter`单纯只是一个断行符号(new-line)而已， 由于`command line`并没得到`CR`字符， 因此进入第二个`shell prompt`(`PS2`, 以>符号表示)， `command line`并不会结束，直到第三行， 我们输入的`enter`并不在hard quote里面， 因此没有被关闭， 此时，`command line`碰到`CR`字符，于是结束，交给shell来处理。 上例的`Enter`要是被置于soft quote中的话，`CR`字符也会同样被关闭： ```shell $ A="B > C > " $ echo $A B C ``` 然而，由于 `echo $A`时的变量没有置于soft quote中， 因此，当变量替换完成后，并作命令行重组时，`enter`被解释为`IFS`， 而不是new-line字符。 同样的，用escape亦可关闭CR字符： ```shell $ A=B\ > C\ > $ echo $A BC ``` 上例中的，第一个`enter`跟第二个`enter`均被escape字符关闭了， 因此也不作为`CR`来处理，但第三个`enter`由于没有被escape， 因此，作为`CR`结束`command line`。 但由于`enter`键本身在shell meta中特殊性，在 \ escape字符后面 仅仅取消其`CR`功能， 而不保留其IFS功能。 你或许发现光是一个`enter`键所产生的字符，就有可能是如下这些可能： - CR - IFS - NL(New Line) - FF(Form Feed) - NULL - ... 至于，什么时候解释为什么字符，这个我就没法去挖掘了， 或者留给读者君自行慢慢摸索了...^-^ 至于soft quote跟hard quote的不同，主要是对于某些meta的关闭与否，以$来做说明： ```shell $ A=B\ C $ echo "$A" B C $ echo '$A' $A ``` 在第一个`echo`命令行中，$被置于soft quote中，将不被关闭， 因此继续处理变量替换， 因此，`echo`将A的变量值输出到屏幕，也就是"B C"的结果。 在第二个`echo`命令行中，$被置于hard quote中，则被关闭， 因此，$只是一个$符号，并不会用来做变量替换处理， 因此结果是$符号后面接一个A字母：$A. > **练习与思考:** 如下结果为何不同？ > tips: 单引号和双引号，在quoting中均被关闭了。 ```shell $ A=B\ C $ echo '"$A"' #最外面的是单引号 "$A" $ echo "'$A'" #最外面的是双引号 'B C' ``` ------------------------------------ 在CU的shell版里，我发现很多初学者的问题， 都与quoting的理解有关。 比方说，若我们在awk或sed的命令参数中， 调用之前设定的一些变量时，常会问及为何不能的问题。 要解决这些问题，关键点就是：**区分出 shell meta 与 command meta** 前面我们提到的那些meta，都是在command line中有特殊用途的， 比方说{}就是将一系列的command line置于不具名的函数中执行(可简单视为command block)， 但是，awk却需要用{}来区分出awk的命令区段(BEGIN,MAIN,END). 若你在command line中如此输入： ```shell $ awk {print $0} 1.txt ``` 由于{}在shell中并没有关闭，那shell就将{print $0}视为command block， 但同时没有`;`符号作命令分隔，因此，就出现awk语法错误结果。 要解决之，可用hard quote: ```shell awk '{print $0}' ``` 上面的hard quote应好理解，就是将原来的 {、、$、}这几个shell meta关闭， 避免掉在shell中遭到处理，而完整的成为awk的参数中command meta。 > **Note:** > awk中使用的$0 是awk中内建的field nubmer，而非awk的变量， > awk自身的变量无需使用$. 要是理解了hard quote的功能，在来理解soft quote与escape就不难： ```shell awk "{print \$0}" 1.txt awk \{print \$0\} 1.txt ``` 然而，若要你改变awk的$0的0值是从另一个shell变量中读进呢？ 比方说：已有变量$A的值是0， 那如何在`command line`中解决 awk的$$A呢？ 你可以很直接否定掉hard quote的方案： ```shell $ awk '{print $$A}' 1.txt ``` 那是因为$A的$在hard quote中是不能替换变量的。 聪明的读者(如你！)，经过本章的学习，我想，你应该可以理解为 为何我们可以使用如下操作了吧： ```shell A=0 awk "{print \$$A}" 1.txt awk \{print\ \$$A\} 1.txt awk '{print $'$A'}' 1.txt awk '{print $'"$A"'}' 1.txt ``` 或许，你能给出更多方案... ^_^ 更多练习： - http://bbs.chinaunix.net/forum/viewtopic.php?t=207178 一个关于read命令的小问题： 很早以前觉得很奇怪：执行read命令，然后读取用户输入给变量赋值， 但如果输入是以空格键开始的话，这空格会被忽略，比如： ```shell read a #输入： abc echo "$a" #只输出abc ``` 原因: 变量a的值，从终端输入的值是以IFS开头，而这些IFS将被shell解释器忽略(trim)。 应该与shell解释器分词的规则有关； ```shell read a #输入：\ \ \ abc echo "$a" #只输出abc ``` 需要将空格字符转义 > **Note:** > IFS Internal field separators, normally space, tab, and newline (see Blank Interpretation section). > ...... > Blank Interpretation > After parameter and command substitution, the results of substitution > are scanned for internal field separator characters (those found in IFS) > and split into distinct arguments where such characters are found. > Explicit null arguments ("" or '') are retained. > Implicit null arguments(those resulting from parameters that have no values) > are removed. > (refre to: man sh) 解决思路： 1. shell command line 主要是将整行line给分解(break down)为每一个单词(word); 2. 而词与词之间的分隔符就是IFS (Internal Field Seperator)。 3. shell会对command line作处理(如替换，quoting等), 然后再按词重组。(注：别忘了这个重组特性) 4. 当你用IFS来事开头一个变量值，那shell会先整理出这个词，然后在重组command line。 5.然而，你将IFS换成其他，那shell将视你哪些space/tab为“词”，而不是IFS。那在重组时，可以得到这些词。 若你还是不理解，那来验证一下下面这个例子： ```shell $ A=" abc" $ echo $A abc $ echo "$A" #note1 abc $ old_IFS=$IFS $ IFS=; $ echo $A abc $ IFS=$old_IFS $ echo $A abc ``` > **Note:** > 1. 这里是用 soft quoting 将里面的 space 关闭，使之不是 meta(IFS)， > 而是一个literal(white space); > 2. IFS=; 意义是将IFS设置为空字符，因为;是shell的元字符(meta); 问题二：为什么多做了几个分号，我想知道为什么会出现空格呢？ ```shell $ a=";;;test" $ IFS=";" $ echo $a test $ a=" test" $ echo $a test $ IFS=" " $ echo $a test ``` 解答： 这个问题，出在`IFS=;`上。 因为这个`;`在问题一中的command line上是一个meta, 并非`";"`符号本身。 因此，`IFS=;`是将IFS设置为 null charactor (不是space、tab、newline)。 要不是试试下面这个代码片段： ```shell $ old_IFS=$IFS $ read A ;a;b;c $ echo $A ;a;b;c $ IFS=";" #Note2 $ echo $A a b c ``` > **Note:** > 要关闭`;`可用`";"`或者`';'`或者`\;`。 - http://bbs.chinaunix.net/forum/viewtopic.php?t=216729 思考问题二：文本处理：读文件时，如何保证原汁原味。 ```shell cat file | while read i do echo $i done ``` 文件file的行中包含若干空，经过read只保留不重复的空格。 如何才能所见即所得。 ```shell cat file | while read i do echo "X${i}X" done ``` 从上面的输出，可以看出read，读入是按整行读入的; 不能原汁原味的原因： 1. 如果行的起始部分有IFS之类的字符，将被忽略; 2. `echo $i`的解析过程中，首先将$i替换为字符串， 然后对echo 字符串中字符串分词，然后命令重组，输出结果; 在分词，与命令重组时，可能导致多个相邻的IFS转化为一个; ```shell cat file | while read i do echo "$i" done ``` 以上代码可以解决原因2中的，command line的分词和重组导致meta字符丢失； 但仍然解决不了原因1中，read读取行时，忽略行起始的IFS meta字符。 回过头来看上面这个问题：为何要原汁原味呢？ cat命令就是原汁原味的，只是shell的read、echo导致了某些shell的meta字符丢失; 如果只是IFS meta的丢失，可以采用如下方式： 将IFS设置为null，即`IFS=;`, 在此再次重申此处`;`是shell的meta字符,而不是literal字符; 因此要使用literal的 `;`应该是`\;` 或者关闭meta 的(soft/hard) quoting的`";"`或者`';'`。 因此上述的解决方案是： ```shell old_IFS=$IFS IFS=; #将IFS设置为null cat file | while read i do echo "$i" done IFS=old_IFS #恢复IFS的原始值 ``` 现在，回过头来看这个问题，为什么会有这个问题呢； 其本源的问题应该是没有找到解决原始问题的最合适的方法， 而是采取了一个迂回的方式来解决了问题； 因此，我们应该回到问题的本源，重新审视一下，问题的本质。 如果要精准的获取文件的内容，应该使用od或者hexdump会更好些。 ##shell十三问之5:问var=value 在export前后的差在哪? ---------------------------------------------------- 这次让我们暂时丢开`command line`, 先了解一下bash变量(variable)吧... 所谓的变量，就是利用一个固定的"名称"(name), 来存取一段可以变化的"值"(value)。 ###1. 变量设定(set) 在bash中， 你可以用"="来设定或者重新定义变量的内容： ```shell name=value ``` 在设定变量的时候，得遵守如下规则： - 等号左右两边不能使用分隔符号(IFS),也应避免使用shell的保留元字符(meta charactor); - 变量的名称(name)不能使用$符号; - 变量的名称(name)的首字符不能是数字(number)。 - 变量的名称(name)的长度不可超过256个字符。 - 变量的名称(name)及变量的值的大小写是有区别的、敏感的(case sensitive，) 如下是一些变量设定时常见的错误： ```shell A= B #=号前后不能有IFS 1A=B #变量名称不能以数字开头 $A=B #变量的名称里有$ a=B #这跟a=b是不同的,(这不是错误，提醒windows用户) ``` 如下则是可以接受的设定： ```shell A=" B" #IFS被关闭，参考前面的quoting章节 A1=B #并非以数字开头 A=$B #$可用在变量的值内 This_Is_A_Long_Name=b #可用_连接较长的名称或值，且有大小区别； ``` ###2. 变量替换(substitution) shell 之所以强大，其中的一个因素是它可以在命令行中对变量作 替换(substitution)处理。 在命令行中使用者可以使用$符号加上变量名称(除了用=定义变量名称之外)， 将变量值给替换出来，然后再重新组建命令行。 比方: ```shell $ A=ls $ B=la $ C=/tmp $ $A -$B $C ``` 以上命令行的第一个`$`是`shell prompt`, 并不在命令行之内。 必须强调的是，我们所提的变量替换，只发生在`command line`上面。 (是的，请让我们再次回到命令行吧！) 仔细分析,最后那行 `command line`,不难发现在被执行前(在输入`CR`字符之前)， `$`符号对每一个变量作替换处理(将变量的值替换出来再重组命令行), 最后会得出如下命令行： ```shell ls -la /tmp ``` 还记得第二章，我请大家"务必理解"的那两句吗？ 若你忘了，我这里重贴一遍： > **Note:** > 若从技术的细节来看，`shell`会依据`IFS`(Internal Field Seperator) > 将`command line`所输入的文字拆解为"字段"(word/field)。 > 然后再针对特殊字符(meta)先作处理，最后重组整行`command line`。 这里的`$`就是`command line`中最经典的meta之一了， 就是作变量替换的。在日常的shell操作中， 我们常会使用`echo`命令来查看特定的变量的值， 例如： ```shell $ echo $A -$B $C ``` 我们已学过，`echo`命令只单纯将其argument送至"标准输出"(stdout, 通常是我们的屏幕)。 所以上面的命令会在屏幕上得到如下结果： ```shell ls -al /tmp ``` 这是由于`echo`命令在执行时，会先将`$A` (ls)、`$B` (la)跟`$C` (/tmp)给替换出来； 利用shell对变量的替换处理能力，我们在设定变量时就更为灵活了： ```shell A=B B=$A ``` 这样，B的变量值就可继承A变量"当时"的变量值了。 不过，不要以"数学逻辑"来套用变量的设定，比方说： ```shell A=B B=C ``` 这样，并不会让A的变量值变成C。再如： ```shell A=B B=$A A=C ``` 同样也不会让B的值变成C。 上面是单纯定义了两个不同名称的变量： A 与 B, 它们的取值分别是C与B。 若变量被重复定义的话，则原有值为新值所取代。(这不正是"可变的量"吗？^_^) 当我们在设定变量的时候，请记住这点：**用一个名称存储一个数值**， 仅此而已。 此外， 我们也可以利用命令行的变量替换能力来"扩充"(append)变量的值： ```shell A=B:C:D A=$A:E ``` 这样， 第一行我们设定A的值为"B:C:D", 然后,第二行再将值扩充为"B:C:D:E"。 上面的扩充的范例，我们使用分隔符号(:)来达到扩充的目的， 要是没有分隔符的话，如下是有问题的： ```shell A=BCD B=$AE ``` 因为第二次是将A的值继承$AE的替换结果，而非$A再加E。 要解决此问题，我们可用更严谨的替换处理： ```shell A=BCD A=${A}E ``` 上例中，我们使用{}将变量名称范围给明确定义出来， 如此一来， 我们就可以将A的变量值从BCD给扩充为BCDE。 > **Tips:** > 关于${name}事实上还可以做到更多的变量处理能力， > 这些均属于比较进阶阶段的变量处理，现阶段暂不介绍了， > 请大家自行参考资料。 ###3. export 变量 严格来说，我们在当前shell中所定义的变量，均属于 "本地变量"(local variable), 只有经过`export`命令的 "输出"处理，才能成为"环境变量"(environment variable)： ```shell $ A=B $ export A ``` 或者 ```shell $ export A=B ``` 经过`export`输出处理之后，变量A就能成为一个环境变量 供其后的命令使用。在使用`export`的时候，请别忘记 shell在命令行对变量的"替换"(substitution)处理。 比方说： ```shell $ A=B $ B=C $ export $A ``` 上面的命令并未将A输出为"环境变量"，而是将B导出 这是因为在这个命令行中，$A会首先被替换为B,然后在"塞回" 作`export`的参数。 要理解这个`export`，事实上需要从process(进程)的角度来理解才能透彻。 我们将于下一章为大家说明process(进程)的概念，敬请留意。 ####4. 取消变量(unset) 要取消一个变量，在bash中可使用`unset`命令来处理： ```shell unset A ``` 与`export`一样，`unset`命令行，也同样会作 变量替换(这其实是shell的功能之一)， 因此: ```shell $ A=B $ B=C $ unset $A ``` 事实上，所取消的是变量B而不是A。 此外，变量一旦经过unset取消之后， 其结果是将整个变量拿掉，而不是取消变量的值。 如下两行其实是很不一样的： ```shell $ A= $ unset A ``` 第一行只是将变量A设定为"空值"(null value), 但第二行则是让变量A不存在。 虽然用眼睛来看， 这两种变量的状态在如下的命令结果中都是一样的： ```shell $ A= $ echo $A $ unset A $ echo $A ``` 请学员务必能识别null value 与 unset的本质区别， 这在一些进阶的变量处理上是很严格的。 比方说： ```shell $ str= #设为null $ var=${str=expr} #定义var $ echo $var $ echo $str $ unset str #取消str $ var=${str=expr} #定义var $ echo $var expr $ echo $str expr ``` 聪明的读者(yes, you!)，稍加思考的话， 应该不难发现为何同样的var=${str=expr} 在str为null与unset之下的不同吧？ 若你看不出来，那可能是如下原因之一： - 你太笨了 - 不了解 var=${str=expr} 这个进阶处理 - 对本篇说明还没有来得及消化吸收 - 我讲得不好 不知，您选哪个呢？...... ^_^. ##shell十三问之6：exec跟source差在哪？ ------------------------------------- 这次让我们从CU shell版的一个实例帖子来谈起吧： (论坛改版后，原链接已经失效) 例中的提问原文如下： > **帖子提问:** > cd /etc/aa/bb/cc可以执行 > 但是把这条命令放入shell脚本后，shell脚本不执行！ > 这是什么原因？ 意思是：运行shell脚本，并没有移动到/etc/aa/bb/cc目录。 我当时如何回答暂时别去深究，先让我们了解一下进程 (process)的概念好了。 首先，我们所执行的任何程序，都是父进程(parent process)产生的一个 子进程(child process),子进程在结束后，将返回到父进程去。 此现象在Linux中被称为`fork`。 (为何要称为fork呢？ 嗯，画一下图或许比较好理解...^_^) 当子进程被产生的时候，将会从父进程那里获得一定的资源分配、及 (更重要的是)继承父进程的环境。 让我们回到上一章所谈到的"环境变量"吧： **所谓环境变量其实就是那些会传给子进程的变量**。 简单而言, "遗传性"就是区分本地变量与环境变量的决定性指标。 然而，从遗传的角度来看，我们不难发现环境变量的另一个重要特征： **环境变量只能从父进程到子进程单向传递。 换句话说：在子进程中环境如何变更，均不会影响父进程的环境。** 接下来，在让我们了解一下shell脚本(shell script)的概念. 所谓shell script 讲起来很简单，就是将你平时在shell prompt输入的多行 `command line`, 依序输入到一个文件文件而已。 再结合以上两个概念(process + script)，那应该不难理解如下的这句话的意思了： 正常来说，当我们执行一个shell script时，其实是先产生一个sub-shell的子进程， 然后sub-shell再去产生命令行的子进程。 然则，那让我们回到本章开始时，所提到的例子在重新思考： > **帖子提问:** > cd /etc/aa/bb/cc可以执行 > 但是把这条命令放入shell脚本后，shell脚本不执行！ > 这是什么原因？ 意思是：运行shell脚本，并没有移动到/etc/aa/bb/cc目录。 我当时的答案是这样的： > 因为，我们一般跑的shell script是用sub-shell去执行的。 > 从process的概念来看，是 parent process产生一个child process去执行， > 当child结束后，返回parent, 但parent的环境是不会因child的改变而改变的。 > 所谓的环境变量元数很多，如effective id(euid)，variable, working dir等等... > 其中的working dir($PWD) 正是楼主的疑问所在： > 当用sub-shell来跑script的话，sub-shell的$pwd会因为cd而变更， > 但返回primary shell时，$PWD是不会变更的。 能够了解问题的原因及其原理是很好的，但是？ 如何解决问题，恐怕是我们更应该感兴趣的是吧？ 那好，接下来，再让我们了解一下`source`命令好了。 当你有了`fork`的概念之后，要理解`soruce`就不难： 所谓`source`，就是让script在当前shell内执行、 而不是产生一个sub-shell来执行。 由于所有执行结果均在当前shell内执行、而不是产生一个sub-shell来执行。 因此, 只要我们原本单独输入的script命令行，变成`source`命令的参数， 就可轻而易举地解决前面提到的问题了。 比方说，原本我们是如此执行script的： ```shell $ ./my_script.sh ``` 现在改成这样既可： ```shell $ source ./my_script.sh ``` 或者： ```shell $ . ./my_script.sh ``` 说到这里，我想，各位有兴趣看看`/etc`底下的众多设定的文件， 应该不难理解它们被定义后，如何让其他script读取并继承了吧？ 若然，日后，你有机会写自己的script， 应也不难专门指定一个设定的文件以供不同的script一起"共用"了... ^_^ okay,到这里，若你搞懂`fork`与`source`的不同， 那接下来再接受一个挑战： > 那`exec`又与`source`/`fork`有何不同呢？ 哦...要了解`exec`或许较为复杂，尤其是扯上`File Decscriptor`的话... 不过，简单来说： > `exec` 也是让script在同一个进程上执行，但是原有进程则被结束了。 > 简言之，原有进程能否终止，就是`exec`与`source`/`fork`的最大差异了。 嗯，光是从理论去理解，或许没那么好消化， 不如动手"实践+思考"来得印象深刻哦。 下面让我们为两个简单的script，分别命名为1.sh以及2.sh 1.sh ```shell #!/bin/bash A=B echo "PID for 1.sh before exec/source/fork:$$" export A echo "1.sh: \$A is $A" case $1 in exec) echo "using exec..." exec ./2.sh ;; source) echo "using source..." . ./2.sh ;; *) echo "using fork by default..." ./2.sh ;; esac echo "PID for 1.sh after exec/source/fork:$$" echo "1.sh: \$A is $A" ``` 2.sh ```shell #!/bin/bash echo "PID for 2.sh: $$" echo "2.sh get \$A=$A from 1.sh" A=C export A echo "2.sh: \$A is $A" ``` 然后分别跑如下参数来观察结果： ```shell $ ./1.sh fork $ ./1.sh source $ ./1.sh exec ``` 好了，别忘了仔细比较输出结果的不同及背后的原因哦... 若有疑问，欢迎提出来一起讨论讨论~~~~ happy scripting！ ^_^ ##shell十三问之7：()与{}差在哪？ -------------------------------- 嗯，这次轻松一下，不讲太多... ^_^ 先说一下，为何要用()或者{}好了。 许多时候，我们在shell操作上，需要在 一定的条件下执行多个命令，也就是说， 要么不执行，要么就全执行，而不是每次 依序的判断是否要执行下一个命令。 或者，要从一些命令执行的先后次序中得到结果， 如算术运算的2*(3+4)那样... 这时候，我们就可以引入"`命令群组`"(`command group`) 的概念：将许多命令集中处理。 在shell `command line`中，一般人或许不太计较`()`与 `{}`这两对符号的差异，虽然两者都可以将多个命令当作群组处理， 但若从技术细节上，却是很不一样的： - `()` 将`command group`置于`sub-shell`(`子shell`)中去执行，也称 `nested sub-shell`。 - `{}` 则是在同一个`shell`内完成，也称`non-named command group`。 若你对上一章的fork与source的概念还记得的话， 那就不难理解两者的差异了。 要是在 `command group`中扯上变量及其他环境的修改， 我们可以根据不同的需求来使用`()`或`{}`。 通常而言, 若所作的修改是临时的，且不想影响原有或以后的设定， 那我们就使用`nested sub-shell`, 即`()`; 反之，则用`non-named command group`, 即`{}`。 是的，光从`command line`来看，`()` 与 `{}`差别就讲完了，够轻松吧~~~, ^_^ 然而，这两个`meta`用在其他`command meta`或领域中(如Regular Expression)， 还是有很多差别的。 只是，我不打算再去说明了，留给读者慢慢发掘好了... 我这里只想补充一个概念，就是`function`。 所谓`function`，就是用一个名字去命名一个`command group`, 然后再调用这个名字去执行`command group`。 从`non-named command group`来推断， 大概你也可以推测到我要说的是`{}`了吧？(yes! 你真聪明 ^_^) 在bash中，function的定义方式有两种： - 方式一： ```shell function function_name { command1 command2 command3 ..... } ``` - 方式二： ```shell function_name () { command1 command2 command3 ...... } ``` 用哪一种方式无所谓， 只是碰到所定义的名称与现有的命令或者别名冲突的话， 方式二或许会失败。 但方式二起码可以少打个`function`这一串英文字符， 对懒人来说(如我)，有何乐而不为呢？...^_^ `function` 在一定程度上来说，也可以称为"函数"， 但请不要与传统编程所使用的"函数"(library)搞混了， 毕竟两者差异很大。 唯一相同的是，我们都可以随时用"已定义的名称"来调用它们... 若我们在shell操作中，需要不断地重复某些命令， 我们首先想到的，或许是将命令写成shell脚本(shell script)。 不过，我们也可以写成function, 然后在command line中打上function_name就可当一般的shell script使用了。 若只是你在shell中定义的`function`, 除了用`unset` function_name取消外， 一旦你退出shell， function也跟着消失。 然而，在script中使用function却有许多好处， 除了提高整体script的执行性能外(因为已经载入)， 还可以节省许多重复的代码...... 简单而言，若你会将多个命令写成script以供调用的话， 那你可以将function看成script中script。... ^_^ 而且通过上一章节介绍的`source`命令， 我们可以自行定义许许多多好用的function， 在集中写在特定文件中， 然后，在其他的script中用`source`将它们载入，并反复执行。 若你是`RedHat Linux`的使用者， 或许，已经猜出 `/etc/rc.d/init.d/functions`这个文件时啥作用了~~~ ^_^ okay，说要轻松点的嘛，那这次就暂时写到这吧。 祝大家学习愉快，^_^ ##shell十三问之8: $(())与$()还有${}差在哪？ -------------------------------------------- 我们上一章介绍了()与{}的不同， 这次让我们扩展一下，看看更多的变化： $()与${}又是啥玩意儿呢？ 在bash shell中, `$()`与\`\`(反引号)都是用来做 `命令替换`(command substitution)的。 所谓的`命令替换`与我们第五章学过的变量替换差不多， 都是用来`重组命令行`： 完成 \`\` 或者`$()`里面的 命令，将其结果替换出来， 再重组命令行。 例如： ```shell $ echo the last sunday is $(date -d "last sunday" +%Y-%m-%d) ``` 如此便可方便得到上一个星期天的日期了...^_^ 在操作上， 用$()或\`\`都无所谓, 只是我个人比较喜欢用$(),理由是： 1. \`\`(反引号)很容易与''(单引号)搞混乱，尤其对初学者来说。 有时在一些奇怪的字形显示中，两种符号是一模一样的(只取两点)。 当然了有经验的朋友还是一眼就能分辨两者。只是，若能更好的避免混乱， 又何乐而不为呢？ ^_^ 2. 在多次的复合替换中， \`\`需要额外的转义(escape, \)处理，而$()则比较直观。 例如，一个错误的使用的例子： ```shell command1 `command2 `command3` ` ``` 原来的本意是要在command2 \`command3\` , 先将command3替换出来给command2处理， 然后再将command2的处理结果，给command1来处理。 然而真正的结果在命令行中却是分成了\`command2\`与 \`\`。 正确的输入应该如下： ```shell command1 `command2 \`command3\` ` ``` 要不然换成$()就没有问题了： ```shell command1 $(commmand2 $(command3)) ``` 只要你喜欢，做多少层的替换都没有问题~~~^_^ 不过，$()并不是没有弊端的... 首先，\`\`基本上可用在所有的unix shell中使用， 若写成 shell script，其移植性比较高。 而$()并不是每一种shell都能使用，我只能说， 若你用bash2的话，肯定没问题... ^_^ 接下来，再让我们看看${}吧...它其实就是用来做 变量替换用的啦。 一般情况下，$var与${var}并没有啥不一样。 但是用${}会比较精准的界定变量名称的范围， 比方说: ```shell $ A=B $ echo $AB ``` 原本是打算先将$A的结果替换出来， 然后在其后补一个字母B； 但命令行上， 真正的结果却是替换变量名称为AB的值出来... 若使用${}就没有问题了： ```shell $ A=B $ echo ${A}B $ BB ``` 不过，假如你只看到`${}`只能用来界定变量名称的话， 那你就实在太小看bash了。 为了完整起见，我这里再用一些例子加以说明`${}`的一些 特异功能： 假设我们定义了一个变量file为： ```shell file=/dir1/dir2/dir3/my.file.txt ``` 我们可以用`${}`分别替换获得不同的值： ####1. shell字符串的非贪婪(最小匹配)左删除 ----------- ```shell ${file#*/} #其值为：dir1/dir2/dir3/my.file.txt ``` 拿掉第一个`/`及其左边的字符串，其结果为： `dir1/dir2/dir3/my.file.txt` 。 ```shell ${file#*.} #其值为：file.txt ``` 拿掉第一个`.`及其左边的字符串，其结果为： `file.txt` 。 ####2. shell字符串的贪婪(最大匹配)左删除： ------ ```shell ${file##*/} #其值为：my.file.txt ``` 拿掉最后一个`/`及其左边的字符串，其结果为： `my.file.txt` ```shell ${file##*.} #其值为：txt ``` 拿掉最后一个`.`及其左边的字符串，其结果为： `txt` ####3. shell字符串的非贪婪(最小匹配)右删除： ---------- ```shell ${file%/*} #其值为：/dir1/dir2/dir3 ``` 拿掉最后一个`/`及其右边的字符串，其结果为： `/dir1/dir2/dir3`。 ```shell ${file%.*} #其值为：/dir1/dir2/dir3/my.file ``` 拿掉最后一个`.`及其右边的字符串，其结果为： `/dir1/dir2/dir3/my.file`。 ####4. shell字符串的贪婪(最大匹配)右删除： ----- ```shell ${file%%/*} #其值为：其值为空。 ``` 拿掉第一个`/`及其右边的字符串，其结果为： 空串。 ```shell ${file%%.*} #其值为：/dir1/dir2/dir3/my。 ``` 拿掉第一个`.`及其右边的字符串，其结果为： /dir1/dir2/dir3/my。 > **Tips:** > 记忆方法： > `#`是去掉左边(在键盘上`#`在`$`的左边); > `%`是去掉右边(在键盘上`%`在`$`的右边); > 单个符号是最小匹配; > 两个符号是最大匹配; ####5. shell字符串取子串： ---- ```shell ${file:0:5} #提取最左边的5个字符：/dir1 ${file:5:5} #提取第5个字符及其右边的5个字符:/dir2 ``` shell字符串取子串的格式：`${s:pos:length}`, 取字符串s的子串：从pos位置开始的字符(包括该字符)的长度为length的的子串; 其中pos为子串的首字符，在s中位置； length为子串的长度; > **Note:** 字符串中字符的起始编号为0. ####6. shell字符串变量值的替换： ----- ```shell ${file/dir/path} #将第一个dir替换为path：/path1/dir2/dir3/my.file.txt ${file//dir/path} #将全部的dir替换为path：/path1/path2/path3/my.file.txt ``` shell字符串变量值的替换格式： - 首次替换： `${s/src_pattern/dst_pattern}` 将字符串s中的第一个src_pattern替换为dst_pattern。 - 全部替换： `${s//src_pattern/dst_pattern}` 将字符串s中的所有出现的src_pattern替换为dst_pattern. ####7. ${}还可针对变量的不同状态(没设定、空值、非空值)进行赋值： ------ - `${file-my.file.txt}` #如果file没有设定，则使用 使用my.file.txt作为返回值, 否则返回${file};(空值及非空值时，不作处理。); - `${file:-my.file.txt}` #如果file没有设定或者${file}为空值, 均使用my.file.txt作为其返回值，否则，返回${file}.(${file} 为非空值时，不作处理); - `${file+my.file.txt}` #如果file已设定(为空值或非空值), 则使用my.file.txt作为其返回值，否则不作处理。(未设定时，不作处理); - `${file:+my.file.txt}` #如果${file}为非空值, 则使用my.file.txt作为其返回值，否则，(未设定或者为空值时)不作处理。 - `${file=my.file.txt}` #如果file为设定，则将file赋值为my.file.txt，同时将${file}作为其返回值；否则，file已设定(为空值或非空值)，则返回${file}。 - `${file:=my.file.txt}` #如果file未设定或者${file}为空值, 则my.file.txt作为其返回值， 同时，将${file}赋值为my.file.txt，否则，(非空值时)不作处理。 - `${file?my.file.txt}` #如果file没有设定，则将my.file.txt输出至STDERR, 否侧， 已设定(空值与非空值时)，不作处理。 - `${file:?my.file.txt}` #若果file未设定或者为空值，则将my.file.txt输出至STDERR，否则， 非空值时，不作任何处理。 > **Tips:** > 以上的理解在于，你一定要分清楚，`unset`与`null`以及non-null这三种状态的赋值； >一般而言，与null有关，若不带`:`, null不受影响； > 若带 `:`, 则连null值也受影响。 ####8. 计算shell字符串变量的长度：`${#var}` -------------- ```shell ${#file} #其值为27, 因为/dir1/dir2/dir3/my.file.txt刚好为27个字符。 ``` ####9. bash数组(array)的处理方法 ------------------- 接下来，为大家介绍一下bash的数组(array)的处理方法。 一般而言, `A="a b c def"` 这样的变量只是将`$A`替换为一个字符串， 但是改为 `A=(a b c def)`, 则是将`$A`定义为数组.... #####1). 数组替换方法可参考如下方法： ```shell ${A[@]} #方法一 ${A[*]} #方法二 ``` 以上两种方法均可以得到：a b c def, 即数组的全部元素。 #####2). 访问数组的成员: ```shell ${A[0]} ``` 其中，`${A[0]}`可得到a, 即数组A的第一个元素， 而 `${A[1]}`则为数组A的第二元素，依次类推。 #####3). 数组的length： ```shell ${#A[@]} #方法一 ${#A[*]} #方法二 ``` 以上两种方法均可以得到数组的长度: 4, 即数组的所有元素的个数。 回忆一下，针对字符串的长度计算，使用`${#str_var}`; 我们同样可以将该方法应用于数组的成员: ```shell ${#A[0]} ``` 其中，`${#A[0]}`可以得到：1，即数组A的第一个元素(a)的长度; 同理，`${#A[3]}`可以得到: 3, 即数组A的第4个元素(def)的长度。 #####4). 数组元素的重新赋值： ```shell A[3]=xyz ``` 将数组A的第四个元素重新定义为xyz。 > **Tips:** > 诸如此类的... > 能够善用bash的$()与${}可以大大提高及 > 简化shell在变量上的处理能力哦~~~^_^ ####10. $(())作用: ---- 好了，最后为大家介绍`$(())`的用途吧： **`$(())`是用来作整数运算的**。 在bash中， `$(())`的整数运算符号大致有这些： - \+\- * / #分别为"加、减、乘、除"。 - % #余数运算,(模数运算) - & | ^ ! #分别为"AND、OR、XOR、NOT"运算。 例如： ```shell $ a=5; b=7; c=2; $ echo $(( a + b * c )) 19 $ echo $(( (a + b)/c )) 6 $ echo $(( (a * b) % c )) 1 ``` 在`$(())`中的变量名称, 可以在其前面加 `$`符号来替换， 也可以不用，如： `$(( $a + $b * $c ))` 也可以得到19的结果。 此外，`$(())`还可作不同进制(如二进制、八进制、十六进制)的运算， 只是输出结果均为十进制的。 ```shell echo $(( 16#2a )) #输出结果为：42，(16进制的2a) ``` 以一个实用的例子来看看吧 : 假如当前的umask是022,那么新建文件的权限即为： ```shell $ umask 022 $ echo "obase=8; $(( 8#666 & (8#777 ^ 8#$(umask)) ))" | bc 644 ``` 事实上，单纯用`(())`也可以重定义变量值，或作testing： ```shell a=5; ((a++)) #可将$a 重定义为6 a=5; ((a--)) #可将$a 重定义为4 a=5; b=7; ((a< b)) #会得到0 (true)返回值。 ``` 常见的用于`(())`的测试符号有如下这些： |符号|符号名称| |----|--------| | < | 小于号 | | > | 大于号 | | <= | 小于或等于| | >= | 大于或等于| | == | 等于| | != | 不等于| > **Note:** > 使用`(())`作整数测试时， > 请不要跟`[]`的整数测试搞混乱了。 > 更多的测试，我们将于第10章为大家介绍。 怎样？ 好玩吧... ^_^ okay,这次暂时说这么多... 上面的介绍，并没有详列每一种可用的状态， 更多的，就请读者参考手册文件(man)吧... ##shell十三问之9：$@与$*差在哪？ ------ 要说$@与$*之前， 需得先从shell script的positional parameter谈起... 我们都已经知道变量(variable)是如何定义和替换的， 这个不再多讲了。 #### 1. shell script的positional parameter -------------- 但是，我们还需要知道有些变量是shell内定的， 且其名称是我们不能随意修改的。 其中，就有positional parameter在内。 在shell script中，我们可用$0, $1, $2, $3 ... 这样的变量分别提取命令行中的如下部分: ```shell script_name parameter1 parameter2 parameter3 ... ``` 我们很容易就能猜出, `$0`就是代表 shell script名称(路径)本身， 而`$1`就是其后的第一个参数，如此类推... 须得留意的是`IFS`的作用, 也就是`IFS`被quoting处理后， 那么positional parameter也会改变。 如下例： ```shell my.sh p1 "p2 p3" p4 ``` 由于p2与p3之间的空白键被soft quoting所关闭了， 因此，my.sh的中$2是"p2 p3",而$3则是p4... 还记得前两章，我们提到function时， 我们不是说过，它是script中的script吗？^_^ 是的，function一样可以读取自己的(有别于script的) positional parameter, 唯一例外的是$0而已。 举例而言： 假设my.sh里有一个函数(function)叫my_fun, 若在script中跑`my_fun fp1 fp2 fp3`, 那么，function内的$0就是my.sh，而$1是fp1而不是p1了... 不如写个简单的my.sh script 看看吧： ```shell #!/bin/bash my_fun() { echo '$0 inside function is '$0 echo '$1 inside function is '$1 echo '$2 inside function is '$2 } echo '$0 outside function is '$0 echo '$1 outside function is '$1 echo '$2 outside function is '$2 my_fun fp1 "fp2 fp3" ``` 然后在command line中跑一下 script就知道了： ```shell chmod 755 my.sh ./my.sh p1 "p2 p3" $0 outside function is ./my.sh $1 outside function is p1 $2 outside function is p2 p3 $0 inside function is ./my.sh $1 inside function is fp1 $2 inside function is fp2 fp3 ``` 然而，在使用positional parameter的时候， 我们要注意一些陷阱哦： **$10不是替换第10个参数， 而是替换第一个参数，然后在补一个0于其后;** 也就是说， `my.sh one two three four five six seven eight nine ten` 这样的command line, my.sh里的$10不是ten而是one0 哦...小心小心 要抓到ten的话，有两种方法： - 方法一：使用我们上一章介绍的${}, 也就是用${10}即可。 - 方法二：就是shift了。 用通俗的说法来说， **所谓的shift就是取消positional parameter中最左边的参数($0不受影响)**。 其预设值为1，也就是shift 或shift 1 都是取消$1, 而原本的$2则变成$1, $3则变成$2... 那亲爱的读者，你说要shift掉多少个参数， 才可用$1取得到${10} 呢？ ^_^ okay，当我们对positional parameter有了基本的概念之后， 那再让我们看看其他相关变量吧。 #### 2. shell script的positional parameter的number -------------- 先是$#, 它可抓出positional parameter的数量。 以前面的`my.sh p1 "p2 p3"`为例： 由于"p2 p3"之间的`IFS`是在soft quote中， 因此，$#就可得到的值是2. 但如果p2与p3没有置于quoting中话， 那$#就可得到3的值了。 同样的规则，在function中也是一样。 因此，我们常在shell script里用如下方法， 测试script是否有读进参数： ```shell [ $# = 0 ] ``` 假如为0, 那就表示script没有参数，否则就是带有参数... #### 3. shell script中的$@与$* ------------- 接下来就是**$@与$*: 精确来讲，两者只有在soft quote中才有差异， 否则，都表示“全部参数” ($0除外)**。 若在comamnd line上， 跑`my.sh p1 "p2 p3" p4`的话， 不管$@还是$\*, 都可得到 p1 p2 p3 p4就是了。 但是，**如果置于soft quote中的话：** - **"$@"则可得到 "p1" "p2 p3" "p4" 这三个不同字段(word);** - **"$*"则可得到 "p1 p2 p3 p4" 这一整个单一的字段。** 我们修改一下前面的my.sh，使之内容如下： ```shell #!/bin/bash my_fun() { echo "$#" } echo 'the number of parameter in "$@" is ' $(my_fun "$@") echo 'the number of parameter in "$*" is ' $(my_fun "$*") ``` 然后再执行: ```shell ./my.sh p1 "p2 p3" p4 ``` 就知道，$@与$*差在哪了... ^_^ ##shell十三问之10：&& 与 || 差在哪？ ------------------------------------ 好不容易，进入了两位数的章节了... 一路走来，很辛苦吧？也很快乐吧？ ^_^ 在解答本章题目之前，先让我们了解一个概念： return value。 我们在shell下跑的每一个command或function， 在结束的时候都会传回父进程一个值，称为 `return value`。 在shell command line中可用`$?`， 这个变量得到最"新"的一个`return value`， 也就是刚刚结束的那个进程传回的值。 `Return Value`(RV)的取值为0-255之间， 由进程或者script的作者自行定义： - 若在script里，用exit RV 来指定其值; 若没有指定, 在结束时，以最后一个命令的RV，为script的RV值。 - 若在function里，则用return RV 来代替exit RV即可。 **`Return Value`的作用：用来判断进程的退出状态(exit status)**. 进程的退出状态有两种： - 0值为"真"(true) - 非0值为"假"(false) 举个例子来说明好了： 假设当前目录内有一个my.file的文件， 而no.file是不存在的： ```shell $ touch my.file $ ls my.file $ echo $? #first echo 0 $ ls no.file ls: no.file: No such file or directory $ echo $? #second echo 1 $ echo $? #third echo 0 ``` 上例的： - 第一个echo是关于`ls my.file`的RV，可得到0的值，因此为true。 - 第二个echo是关于`ls no.file`的RV，得到非0的值，因此为false。 - 第三个echo是关于`echo $?`的RV，得到0值， 因此为true。 请记住： 每一个command在结束时，都会返回`return value`，不管你跑什么命令... 然而，有一个命令却是“专门”用来测试某一条而返回`return value`， 以供true或false的判断， 它就是`test`命令。 若你用的是bash， 请在command line下， 打`man test`，或者 `man bash` 来了解这个`test`的用法。 这是你可用作参考的最精准的文件了，要是听别人说的，仅作参考就好... 下面，我只简单作一些辅助说明，其余的一律以 `man`为准： 首先，`test`的表达式，我们称为expression，其命令格式有两种： ```shell test expression ``` 或者 ```shell [ expression ] ``` > **Note:** > 请务必注意 `[]` 之间的空白键! 用哪一种格式无所谓，都是一样的效果。 (我个人比较喜欢后者...) 其次，bash的`test`目前支持的测试对象只有三种： - string：字符串，也就是纯文字。 - integer：整数(0或正整数、不含负数或小数) - file: 文件 请初学者，一定要搞清楚这三者的差异， 因为`test`所使用的expression是不一样的。 以A=123这个变量为例： - `[ "$A" = 123 ]` #是字符串测试，测试$A是不是1、2、3这三个字符。 - `[ "$A" -eq 123 ]` #是整数测试，以测试$A是否等于123. - `[-e "$A" ]` #文件测试，测试123这份文件是否存在. 第三， 当expression测试为“真”时， `test`就返回0(true)的`return value`; 否则，返回非0(false). 若在 expression 之前加一个`!`(感叹号)，则在expression为假时，return value为0, 否则, return value 为非0值。 同时，`test`也允许多重复合测试： - expression1 -a expression2 #当两个expression都为true，返回0，否则，返回非0； - expression1 -o expression2 #当两个expression均为false时，返回非0，否则，返回0； 例如： ```shell [ -d "$file" -a -x "$file" ] ``` 表示当$file是一个目录，且同时具有x权限时，test才会为true。 第四，在command line中使用`test`时，请别忘记命令行的“重组”特性， 也就是在碰到meta时，会先处理meta，在重新组建命令行。 (这个概念在第2章和第4章进行了反复强调) 比方说， 若`test`碰到变量或者命令替换时， 若不能满足 expression的格式时，将会得到语法错误的结果。 举例来说好了： 关于`[ string1 = string2 ]`这个test格式， 在等号两边必须要有字符串，其中包括空串(null串,可用soft quote或者hard quote取得)。 假如$A目前没有定义，或被定义为空字符串的话， 那如下的用法将会失败： ```shell $ unset A $ [ $A = abc ] [: =: unary oprator expected ``` 这是因为命令行碰到$这个meta时，会替换$A的值， 然后，再重组命令行，那就变成了： `[ = abc ]`, 如此一来，=的左边就没有字符串存在了， 因此，造成test的语法错误。 但是，下面这个写法则是成立的。 ```shell $ [ "$A" = abc ] $ echo $? 1 ``` 这是因为命令行重组后的结果为： `[ "" = abc ]`, 由于等号的左边我们用soft quote得到一个空串， 而让test的语法得以通过... 读者诸君，请务必留意这些细节哦， 因为稍一不慎，将会导致`test`的结果变了个样。 若您对`test`还不是很有经验的话， 那在使用test时，不妨先采用如下这一个"法则": ** 若在`test`中碰到变量替换，用soft quote是最保险的***。 若你对quoting不熟的话，请重新温习第四章的内容吧...^_^ okay, 关于更多的`test`的用法，老话一句：请看其man page (`man test`)吧！^_^ 虽然洋洋洒洒读了一大堆，或许你还在嘀咕...那...那个`return value`有啥用？ 问得好: 告诉你：return value的作用可大了， 若你想要你的shell变"聪明"的话，就全靠它了： 有了return value， 我们可以让shell根据不同的状态做不同的事情... 这时候，才让我来揭晓本章的答案吧~~~~^_^ `&&` 与 `||` 都是用来"组建" 多个command line用的； - `command1 && command2` # command2只有在command1的RV为0(true)的条件下执行。 - `command1 || command2` # command2 只有在command1的RV为非0(false)的条件下执行。 以例子来说好了： ```shell $ A=123 $ [ -n "$A" ] && echo "yes! it's true." yes! it's true. $ unset A $ [ -n "$A" ] && echo "yes! it's true." $ [ -n "$A" ] || echo "no, it's Not true." no, it's Not true ``` > **Note:** > `[ -n string ]`是测试string长度大于0, 则为true。 上例中，第一个`&&`命令之所以会执行其右边的`echo`命令， 是因为上一个`test`返回了0的RV值； 但第二个，就不会执行，因为`test`返回了非0的结果... 同理，`||`右边的`echo`会被执行，却正是因为左边的`test`返回非0所引起的。 事实上，我们在同一个命令行中，可用多个`&&` 或 `||` 来组建呢。 ```shell $ A=123 $ [ -n "$A" ] && echo "yes! it's true." || echo "no, it's Not ture." yes! it's true. $ unset A $ [ -n "$A" ] && echo "yes! it's true." || echo "no, it's Not ture." no, it's Not true ``` 怎样，从这一刻开始，你是否觉得我们的shell是“很聪明”的呢？ ^_^ 好了，最后布置一道练习题给大家做做看： 下面的判断是：当$A被赋值时，在看看其是否小于100，否则输出too big！ ```shell $ A=123 $ [ -n "$A" ] && [ "$A" -lt 100 ] || echo 'too big!' $ too big! ``` 若我取消A，照理说，应该不会输出文字啊，(因为第一个条件不成立)。 ```shell $ unset A $ [ -n "$A" ] && [ "$A" -lt 100 ] || echo 'too big!' $ too big! ``` 为何上面的结果也可得到呢？ 又如何解决呢？ > **Tips:** >修改的方法有很多种， >其中一种方法可以利用第7章中介绍过 `command group`... 快告诉我答案，其余免谈.... 解决方法1：`sub-shell`： ```shell $ unset A $ [ -n "$A" ] && ( [ "$A" -lt 100 ] || echo 'too big!' ) ``` 解决方法二：`command group`: ```shell $ unset A $ [ -n "$A" ] && { [ "$A" -lt 100 ] || echo 'too big!'} ``` ##shell十三问之11：>与< 差在哪？ ---------------- 这次的题目，之前我在CU的shell版说明过了： (原帖的连接在论坛改版后，已经失效) 这次我就不重写了，将帖子的内容“抄”下来就是了... #### 1. 文件描述符(fd, File Descriptor) ---------- 谈到`I/O redirection`,不妨先让我们认识一下`File Descriptor`(`fd`，文件描述符)。 进程的运算，在大部分情况下，都是进行数据(data)的处理， 这些数据从哪里，读进来？又输出到哪里呢？ 这就是file descriptor(fd)的功用了。 在shell的进程中，最常使用的`fd`大概有三个，分别为: - 0：standard Input (`STDIN`) - 1: standard output(`STDOUT`) - 2: standard Error output （`STDERR`） 在标准情况下，这些fd分别跟如下设备(device)关联： - `stdin`(0): keyboard - `stdout`(1): monitor - `stderr`(2): monitor > **Tips:** > linux中的文件描述符(fd)用整数表示。 > linux中任何一个进程都默认打开三个文件, > 这三个文件对应的文件描述符分别是：0, 1, 2; > 即stdin, stdout, stderr. 我们可以用如下命令测试一下： ```shell $ mail -s test root this is a test mail。 please skip. ^d (同时按下ctrl 跟d键) ``` 很明显，`mail`进程所读进的数据，就是从 `stdin` 也就是keyboard读进的。 不过，不见得每个进程的`stdin`都跟`mail`一样 从`keyboard`读进，因为进程的作者可以从文件参数读进`stdin`， 如： ```shell $ cat /etc/passwd ``` 但，要是`cat`之后没有文件参数则如何呢？ 哦， 请你自己玩玩看...^_^ ```shell $ cat ``` > **Tips:** > 请留意数据输出到哪里去了， > 最后别忘了按`ctrl+d`(`^d`), 退出stdin输入。 至于`stdout`与`stderr`，嗯...等我有空再续吧...^_^ 还是，有哪位前辈来玩接龙呢？ 相信，经过上一个练习后， 你对`stdin`与`stdout`应该不难理解了吧？ 然后，让我们看看`stderr`好了。 事实上，`stderr`没什么难理解的： 说白了就是“错误信息”要往哪里输出而已... 比方说, 若读进的文件参数不存在的， 那我们在monitor上就看到了： ```shell $ ls no.such.file ls: no.such.file: No such file or directory ``` 若同一个命令，同时成生`stdout`与`stderr`呢？ 那还不简单，都送到monitor来就好了： ```shell $ touch my.file $ ls my.file on.such.file ls: no.such.file: No such file or directory my.file ``` okay, 至此，关于fd及其名称、还有相关联的设备， 相信你已经没问题了吧？ --------------------------------------- #### 2. I/O 重定向(I/O Redirection) --------------------------------------- 那好，接下来让我们看看如何改变这些fd的预设数据通道。 - 用`<` 来改变读进的数据通道(stdin),使之从指定的文件读进。 - 用`>` 来改变输出的数据通道(stdout，stderr),使之输出到指定的文件。 -------- #####2.1 输入重定向`n<`(input redirection) -------- 比方说： ```shell $ cat < my.file ``` 就是从my.file读入数据 ```shell $ mail -s test root < /etc/passwd ``` 则是从/etc/passwd读入... 这样一来，stdin将不再是从keyboard读入， 而是从指定的文件读入了... 严格来说，**`<`符号之前需要指定一个fd的(之前不能有空白)，但因为0是`<`的预设值，因此，`<`与`0<`是一样的***。 okay，这样好理解了吧？ 那要是用两个`<`，即`<<`又是啥呢？ **这是所谓的`here document`, 它可以让我们输入一段文本， 直到读到`<<` 后指定的字符串**。 比方说： ```shell $ cat <n`(output redirection) ------------- 当你搞懂了`0<` 原来就是改变`stdin`的数据输入通道之后， 相信要理解如下两个redirection就不难了： - `1>` #改变stdout的输出通道； - `2>` #改变stderr的输出通道； 两者都是将原来输出到monitor的数据， 重定向输出到指定的文件了。 **由于1是`>`的预设值， 因此，`1>`与`>`是相同的，都是改变`stdout`**. 用上次的ls的例子说明一下好了: ```shell $ ls my.file no.such.file 1>file.out ls: no.such.file: No such file or directory ``` 这样monitor的输出就只剩下`stderr`的输出了， 因为`stdout`重定向输出到文件file.out去了。 ```shell $ ls my.file no.such.file 2>file.err my.file ``` 这样monitor就只剩下了`stdout`, 因为`stderr`重定向输出到文件file.err了。 ```shell $ ls my.file no.such.file 1>file.out 2>file.err ``` 这样monitor就啥也没有了， 因为`stdout`与`stderr`都重定向输出到文件了。 呵呵，看来要理解`>`一点也不难啦是不？ 没骗你吧？ ^_^ **不过有些地方还是要注意一下的**。 ```shell $ ls my.file no.such.file 1>file.both 2>file.both ``` 假如`stdout`(1)与`stderr`(2)都同时在写入file.both的话， 则是采取"覆盖"的方式：后来写入覆盖前面的。 让我们假设一个`stdout`与`stderr`同时写入到file.out的情形好了； - 首先`stdout`写入10个字符 - 然后`stderr`写入6个字符 那么，这时原本的`stdout`输出的10个字符， 将被`stderr`输出的6个字符覆盖掉了。 那如何解决呢？所谓山不转路转，路不转人转嘛， 我们可以换一个思维： 将`stderr`导进`stdout` 或者将`stdout`导进到`stderr`, 而不是大家在抢同一份文件，不就行了。 bingo就是这样啦： - 2>&1 #将`stderr`并进`stdout`输出 - 1>&2 或者 >&2 #将`stdout`并进`stderr`输出。 于是，前面的错误操作可以改写为: ```shell $ ls my.file no.such.file 1>file.both 2>&1 $ ls my.file no.such.file 2>file.both >&2 ``` 这样，不就皆大欢喜了吗？ ~~~ ^_^ 不过，光解决了同时写入的问题还不够， 我们还有其他技巧需要了解的。 故事还没有结束，别走开广告后，我们在回来.... ------ #####2.3 I/O重定向与linux中的`/dev/null` ------ okay，这次不讲I/O Redirection, 请佛吧... (有没有搞错？`网中人`是否头壳烧坏了？...)嘻~~~^_^ 学佛的最高境界，就是"四大皆空"。 至于是空哪四大块，我也不知，因为我还没有到那个境界.. 这个“空”字,却非常值得反复把玩： ---色即是空，空即是色 好了，施主要是能够领会"空"的禅意，那离修成正果不远了。 在linux的文件系统中，有个设备文件: `/dev/null`. 许多人都问过我，那是什么玩意儿？ 我跟你说好了，那就是"空"啦。 没错空空如也的空就是null了... 请问施主是否忽然有所顿悟了呢？ 然则恭喜了。 这个null在 I/O Redirection中可有用的很呢？ - 将fd `1`跟fd `2`重定向到/dev/null去，就可忽略stdout, stderr的输出。 - 将fd `0`重定向到/dev/null，那就是读进空(nothing). 比方说，我们在执行一个进程时，会同时输出到stdout与stderr， 假如你不想看到stderr(也不想存到文件)， 那就可以： ```shell $ ls my.file no.such.file 2>/dev/null my.file ``` 若要相反：只想看到stderr呢？ 还不简单将stdout，重定向的/dev/null就行： ```shell $ ls my.file no.such.file >/dev/null ls: no.such.file: No such file or directory ``` 那接下来，假如单纯的只跑进程，而不想看到任何输出呢？ 哦，这里留了一手，上次没讲的法子,专门赠与有缘人... ^_^ 除了用 `>/dev/null 2>&1`之外，你还可以如此： ```shell $ ls my.file no.such.file &>/dev/null ``` > **Tips:** >将&>换成>&也行！ ------ #####2.4 重定向输出append (`>>`) ------- okay？ 请完佛，接下来，再让我们看看如下情况： ```shell $ echo "1" > file.out $ cat file.out 1 $ echo "2" > file.out $ cat file.out 2 ``` 看来，我们在重定向stdout或stderr进一个文件时， 似乎永远只能获得最后一次的重定向的结果. 那之前的内容呢？ 呵呵，要解决这个问题，很简单啦，将`>`换成`>>` 就好了； ```shell $ echo "3" >> file.out $ cat file.out 2 3 ``` 如此一来，被重定向的文件的之前的内容并不会丢失， 而新的内容则一直追加在最后面去。so easy?... 但是，只要你再次使用`>`来重定向输出的话， 那么，原来文件的内容被truncated(清洗掉)。 这是，你要如何避免呢？ ----备份， yes，我听到了，不过，还有更好的吗？ 既然与施主这么有缘分，老衲就送你一个锦囊妙法吧： ```shell $ set -o noclobber $ echo "4" > file.out -bash：file: cannot overwrite existing file. ``` 那，要如何取消这个限制呢? 哦，将`set -o `换成 `set +o`就行了： ```shell $ set +o noclobber $ echo "5" > file.out $ cat file.out 5 ``` 再问：那有办法不取消而又“临时”改写目标文件吗？ 哦，佛曰：不可告也。 啊，~~~开玩笑的，开玩笑啦~~~^_^， 哎，早就料到人心是不足的了 ```shell $ set -o noclobber $ echo "6" >| file.out $ cat file.out 6 ``` 留意到没有： **在`>`后面加个`|`就好， 注意： `>`与`|`之间不能有空白哦**... ----- #####2.5 I/O Redirection的优先级 ----- 呼....(深呼吸吐纳一下吧)~~~ ^_^ 再来还有一个难题要你去参透呢: ```shell $ echo "some text here" >file $ cat < file some text here $cat < file >file.bak $cat < file.bak some text here $cat < file >file ``` 嗯？注意到没有？ ---怎么最后那个cat命令看到file是空的呢？ why？ why？ why？ 前面提到：`$cat < file > file`之后， 原本有内容的文件，结果却被清空了。 要理解这个现象其实不难， 这只是priority的问题而已： ** 在IO Redirection中, stdout与stderr的管道先准备好， 才会从stdin读入数据。** 也就是说，在上例中，`>file`会将file清空， 然后才读入 `< file`。 但这时候文件的内容已被清空了，因此就变成了读不进任何数据。 哦，~~~原来如此~~~^_^ 那...如下两例又如何呢？ ```shell $ cat <> file $ cat < file >>file ``` 嗯...同学们，这两个答案就当练习题喽， 下课前交作业。 > **Tips:** > 我们了解到`>file`能够快速把文件file清空； > 或者使用`:>file`同样可以清空文件， >`:>file`与`>file`的功能： >若文件file存在，则将file清空; 否则，创建空文件file (等效于`touch file`); >二者的差别在于`>file`的方式不一定在所有的shell的都可用。 > `exec 5<>file; echo "abcd" >&5; cat <&5` >将file文件的输入、输出定向到文件描述符5， >从而描述符5可以接管file的输入输出； >因此，`cat <>file`等价于`cat < file`。 > >而`cat < file >>file`则使file内容成几何级数增长。 好了， I/O Redirection也快讲完了， sorry,因为我也只知道这么多而已啦~~~嘻~~~^_^ 不过，还有一样东东是一定要讲的，各位观众(请自行配乐~!#@$%): 就是`pipe line`也。 -------------- #####2.6 管道(pipe line) ------------- 谈到`pipe line`，我相信不少人都不会陌生： 我们在很多command line上常看到`|`符号就是pipe line了。 不过，pipe line究竟是什么东东呢？ 别急别急...先查一下英文字典，看看pipe是什么意思？ 没错他就是“水管”的意思... 那么，你能想象一下水管是怎样一个根接一根的吗？ 又， 每根水管之间的input跟output又如何呢？ 灵光一闪：原来pipe line的I/O跟水管的I/O是一模一样的： **上一个命令的stdout接到下一个命令的stdin去了** 的确如此。不管在command line上使用了多少个pipe line， 前后两个command的I/O是彼此连接的 (恭喜：你终于开放了 ^_^ ) 不过...然而...但是... ...stderr呢？ 好问题不过也容易理解： 若水管漏水怎么办？ 也就是说：在pipe line之间, 前一个命令的stderr是不会接进下一个命令的stdin的， 其输出，若不用2>file的话，其输出在monitor上来。 这点请你在pipe line运用上务必要注意的。 那，或许你有会问: **有办法将stderr也喂进下一个命令的stdin吗？** (贪得无厌的家伙)，方法当然是有的，而且，你早已学习过了。 提示一下就好：**请问你如何将stderr合并进stdout一同输出呢？ 若你答不出来，下课后再来问我...(如果你脸皮足够厚的话...) 或许，你仍意犹未尽，或许，你曾经碰到过下面的问题： 在`cmd1 | cmd2 | cmd3 | ...` 这段pipe line中如何将cmd2的输出保存到一个文件呢？ 若你写成`cmd1 | cmd2 >file | cmd3`的话， 那你肯定会发现`cmd3`的stdin是空的，(当然了，你都将 水管接到别的水池了) 聪明的你或许会如此解决： ```shell cmd1 | cmd2 >file; cmd3 < file ``` 是的，你可以这样做，但最大的坏处是： file I/O会变双倍，在command执行的整个过程中， file I/O是最常见的最大效能杀手。 凡是有经验的shell操作者，都会尽量避免或降低file I/O的频度。 那上面问题还有更好的方法吗？ 有的，那就是`tee`命令了。 **所谓的`tee`命令是在不影响原本I/O的情况下， 将stdout赋值到一个文件中去。** 因此，上面的命令行，可以如此执行： ```shell cmd1 | cmd2 | tee file | cmd3 ``` 在预设上，`tee`会改写目标文件， 若你要改为追加内容的话，那可用-a参数选项。 基本上，pipe line的应用在shell操作上是非常广泛的。 尤其是在text filtering方面， 如，cat, more, head, tail, wc, expand, tr, grep, sed, awk...等等文字处理工具。 搭配起pipe line 来使用，你会觉得 command line 原来活得如此精彩的。 常让人有“众里寻他千百度，蓦然回首，那人却在灯火阑珊处”之感... 好了，关于I/O Redirection的介绍就到此告一段落。 若日后，有空的话，在为大家介绍其他在shell上好玩的东西。 ##shell十三问之12：你要if还是case呢？ -------------------------------------- 还记得我们在第10章所介绍的`return value`吗？ 是的，接下来的介绍的内容与之有关， 若你的记忆也被假期所抵消的话， 那建议您还是回去温习温习再回来... 若你记得`return value`，我想你也应该记得了 `&&` 与 `||` 什么意思吧? 用这两个符号再搭配 command group的话， 我们可让shell script变得更加聪明哦。 比方说： ```shell cmd1 && { cmd2 cmd3 ; } || { cmd4 cmd5 } ``` 意思是说： 若 cmd1的`return value`为true的话， 然后执行cmd2与cmd3， 否则执行cmd4与cmd5. 事实上， 我们在写shell script的时候， 经常需要用到这样、那样的条件 以作出不同的处理动作。 用`&&`与`||`的确可以达成条件执行的结果， 然而，从“人类语言”上来理解， 却不是那么直观。 更多时候，我们还是喜欢用`if...then...else...` 这样的的keyword来表达条件执行。 在bash shell中，我们可以如此修改上一段代码： ```shell if cmd1 then cmd2 cmd3 else cmd4 cmd5 fi ``` 这也是我们在shell script中最常用的`if`判断式： 只要`if`后面的command line返回true的return value (我们常用`test`命令返回的return value)， 然则就执行`then`后面的命令，否则，执行`else`之后的命令， `fi`则是用来结束判断式的keyword。 在`if`的判断式中，`else`部分可以不用，但`then`是必需的。 (若`then`后不想跑任何command，可用`:`这个`null command`代替)。 当然，then或else后面，也可以再使用更进一层的条件判断式， 这在shell script的设计上很常见。 若有多项条件需要"依序"进行判断的话， 那我们则可使用`elif`这样的keyword： ```shell if cmd1; then cmd2; elif cmd3; then cmd4 else cmd5 fi ``` 意思是说： 若cmd1为true，然则执行cmd2； 否则在测试cmd3，若为true则执行cmd4； 倘若cmd1与cmd3均不成立，那就执行cmd5。 `if`判断式的例子很常见，你可从很多shell script中 看得到，我这里不再举例子了... 接下来为要为大家介绍的是`case`判断式。 虽然`if`判断式已可应付大部分的条件执行了， 然而，在某些场合中，却不够灵活， **尤其是在string式样的判断上**，比方如下： ```shell QQ() { echo -n "Do you want to continue? (Yes/No): " read YN if [ "$YN" = Y -o "$YN" = y -o "$YN" = "Yes" -o "$YN" = "yes" -o "$YN" = YES] then QQ else exit 0 fi } QQ ``` 从例中，我们看得出来， 最麻烦的部分是在判断YN的值可能有好几种样式。 聪明的你或许会如此修改： ```shell QQ() { echo -n "Do you want to continue? (Yes/No): " read YN if echo "$YN" | grep -q '^[Yy]\([Ee][Ss]\)*$' then QQ else exit 0 fi } QQ ``` 也就是用`Regular Expression`来简化代码。 (我们有机会，再来介绍`RE`) 只是...是否有其他更方便的方法呢？ 有的，就是用`case`判断式即可： ```shell QQ() { echo -n "Do you want to continue? (Yes/No): " read YN case "$YN" in [Yy]|[Yy][Ee][Ss]) QQ ;; *) exit 0 ;; esac } QQ ``` 我们常用的`case`的判断式来判断某一变量 在不同的值(通常是string)时，作出不同的处理， 比方说， **判断script参数，以执行不同的命令**。 若你有兴趣，且用linux系统的话， 不妨挖一挖`/etc/init.d/*`中的那堆script中的`case`用法. 如下就是一例： ```shell case "$1" in start) start ;; stop) stop ;; status) rhstatus ;; restart|reload) restart ;; condrestart) [ -f /var/lock/subsys/syslog ] && restart || : ;; *) echo $"Usage: $0 {start|stop|status|restart|condrestart}" exit 1 esac ``` (若你对 postional parameter的印象已经模糊了，请重看第9章吧。) okay，是十三问还剩一问而已，过几天再来搞定之...^_^ ##shell十三问之13： for what？ while与until差在哪？ ------------------------ 终于，来到了shell十三问的最后一问了... 长长吐一口气~~~~ 最后要介绍的是shell script设计中常见的`循环`(`loop`). 所谓的`loop`就是script中的一段在一定条件下反复执行的代码。 bash shell中常用的`loop`有如下三种： - for - while - until ###1. for loop -------------- `for` loop 是从一个清单列表中读进变量的值， 并依次的循环执行`do`到`done`之间的命令行。 例： ```shell for var in one two three four five do echo ----------------- echo '$var is '$var echo done ``` > 上例的执行结果将会是： > 1. for会定义一个叫var的变量，其值依次是one two three four five。 > 2. 因为有5个变量值，因此，`do`与`done`之间的命令行会被循环执行5次。 > 3. 每次循环均用`echo`产生3个句子。而第二行中不在hard quote之内的$var会被替换。 > 4. 当最后一个变量值处理完毕，循环结束。 我们不难看出，在`for` loop中，变量值的多寡，决定循环的次数。 然而，变量在循环中是否使用则不一定，得视设计需求而定。 倘若`for` loop没有使用in这个keyword来制变量清单的话，其值将从 `$@`(或`$*`)中继承： ```shell for var; do ...... done ``` > **Tips:** > 若你忘记了`positional parameter, 请温习第9章... `for` loop用于处理“清单”(list)项目非常方便， 其清单除了明确指定或从`postional parameter`取得之外， 也可以从`变量替换`或者`命令替换`取得... (再一次提醒：别忘了命令行的“重组”特性) 然而，对于一些“累计变化”的项目(整数的加减)，for也能处理： ```shell for ((i = 1; i <= 10; i++)) do echo "num is $i" done ``` ###2. while loop --------- 除了`for` loop, 上面的例子， 我们也可改用`while` loop来做到： ```shell num=1 while [ "$num" -le 10 ]; do echo "num is $num" num=$(($num + 1)) done ``` `while` loop的原理与`for` loop稍有不同： 它不是逐次处理清单中的变量值， 而是取决于`while` 后面的命令行的return value： - 若为true， 则执行`do`与`done`之间的命令， 然后重新判断`while`后的return value。 - 若为false，则不再执行`do`与`done`之间的命令而结束循环。 > 分析上例： > 1. 在`while`之前，定义变量num=1. > 2. 然后测试(`test`)$num是否小于或等于10. > 3. 结果为true，于是执行`echo`并将num的值加1. > 4. 再作第二轮测试，此时num的值为1+1=2，依然小于或等于10，因此，为true，循环继续。 > 5. 直到num为10+1=11时，测试才会失败...于是结束循环。 我们不难发现： **若`while`的测试结果永远为true的话，那循环将一直永久执行下去**： ```shell while:; do echo looping... done ``` 上面的**`:`是bash的null command，不做任何动作， 除了返回true的return value**。 因此这个循环不会结束，称作死循环。 死循环的产生有可能是故意设计的(如跑daemon)， 也可能是设计的错误。 若要结束死循环，可通过signal来终止(如按下ctrl-c). (关于process与signal，等日后有机会再补充，十三问略过。) ####3.until loop ------- 一旦你能够理解`while` loop的话，那就能理解`until` loop: **与`while`相反， `until`是在return value 为false时进入循环，否则，结束。 因此，前面的例子，我们也可以轻松的用`until`来写： ```shell num=1 until [ ! "$num" -le 10 ]; do echo "num is $num" num=$(($num + 1)) done ``` 或者： ```shell num=1 until [ "$num" -gt 10 ]; do echo "num is $num" num=$(($num + 1)) done ``` okay, 关于bash的三个常用的loop暂时介绍到这里。 ###4. shell loop中的break与continue ------------------- 在结束本章之前，再跟大家补充两个loop有关的命令： - `break` - `continue` 这两个命令常用在复合式循环里， 也就是`do ... done`之间又有更进一层的loop， 当然，用在单一循环中也未尝不可啦... ^_^ `break`用来中断循环，也就是强迫结束循环。 若`break`后面指定一个数值n的话，则从里向外中断第n个循环， 预设值为 `break 1`，也就是中断当前循环。 在使用break时，需要注意的是，它与`return`及`exit`是不同的： - `break`是结束loop； - `return`是结束function； - `exit`是结束script/shell; 而`continue`则与`break`相反：强迫进入下一次循环动作. 若你理解不来的话，那你可简单的看成： 在`continue`在`done`之间的句子略过而返回到循环的顶端... 与`break`相同的是：`continue`后面也可以指定一个数值n， 以决定继续哪一层(从里往外计算)的循环， 预设值为 `continue 1`,也就是继续当前的循环。 在shell script设计中，若能善用loop， 将能大幅度提高script在复杂条件下的处理能力。 请多加练习吧... --------------------- ## shell是十三问的总结语 ------------------------ 好了，该是到了结束的时候了。 婆婆妈妈地跟大家啰嗦了一堆shell的基础概念。 目的不是要告诉大家“答案”，而是要带给大家“启发”... 在日后的关于shell的讨论中，我或许经常用"连接"的方式 指引十三问中的内容。 以便我们在进行技术探讨时，彼此能有一些讨论的基础， 而不至于各说各话、徒费时力。 但更希望十三问能带给你更多的思考与乐趣， 至为重要的是通过实践来加深理解。 是的，我很重视**实践**与**独立思考**这两项学习要素。 若你能够掌握其中的真谛，那请容我说声： **恭喜十三问你没白看了** ^_^ p.s. 至于补充问题部分，我暂时不写了。 而是希望： 1. 大家补充题目。 2. 一起来写心得。 Good luck and happy studing！ -------------------------------- ##shell十三问原作者**`网中人`**签名中的bash的fork bomb -------------- 最后，Markdown整理者补上本书的原作者**网中人**的个性签名： > ** 君子博学而日叁省乎己，则知明而行无过矣。** > 一个能让系统shell崩溃的shell 片段： ```shell :() { :|:& }; : # <--- 这个别乱跑！好奇会死人的！ echo '十人|日一|十十o' | sed 's/.../&\n/g' # <--- 跟你讲就不听，再跑这个就好了... ``` 原来是一个bash的fork炸弹：ref：http://en.wikipedia.org/wiki/Fork_bomb ```shell :() { :|:& } : ``` > 代码分析： > (即除最后一行外) > 定义了一个 shell 函数，函数名是`:`， > 而这个函数体执行一个后台命令`:|:` > 即冒号命令(或函数，下文会解释)的输出 通过管道再传给冒号命令做输入 >最后一行执行“:”命令 在各种shell中运行结果分析： > 这个代码只有在 **bash** 中执行才会出现不断创建进程而耗尽系统资源的严重后果; > 在 ksh (Korn shell), sh (Bourne shell)中并不会出现， > 在 ksh88 和传统 unix Bourne shell 中冒号不能做函数名， > 即便是在 unix-center freebsd 系统中的 sh 和 pdksh（ksh93 手边没有，没试）中冒号可以做函数名，但还是不会出现那个效果。 >原因是 sh、ksh 中内置命令的优先级高于函数，所以执行“:”， 总是执行内置命令“:”而不是刚才定义的那个恐怖函数。 > 但是在 **bash** 中就不一样，bash 中函数的优先级高于内置命令， > 所以执行“:”结果会导致不断的递归，而其中有管道操作， > 这就需要创建两个子进程来实现，这样就会不断的创建进程而导致资源耗尽。 众所周知，bash是一款极其强大的shell，提供了强大的交互与编程功能。 这样的一款shell中自然不会缺少“函数”这个元素来帮助程序进行模块化的高效开发与管理。 于是产生了由于其特殊的特性，bash拥有了fork炸弹。 Jaromil在2002年设计了最为精简的一个fork炸弹的实现。 > 所谓fork炸弹是一种恶意程序，它的内部是一个不断在fork进程的无限循环. > fork炸弹并不需要有特别的权限即可对系统造成破坏。 > fork炸弹实质是一个简单的递归程序。 > 由于程序是递归的，如果没有任何限制， > 这会导致这个简单的程序迅速耗尽系统里面的所有资源. ##shell十三问之14: [^ ] 跟[! ]差在哪？ (wildcard) -------------------------------------- 这个题目说穿了， 就是要探讨Wildcard与Regular Expression的差别的。 这也是很多初学shell的朋友很容易混淆的地方。 首先，让我们回到十三问之第2问， 再一次将我们提到的command line format 温习一次： ```shell command_name options arguments ``` 同时，也再来理解一下，我在第5章所提到的变量替换的特性： ```shell 先替换，再重组 command line! ``` 有了这个两个基础后，再让我们来看Wildcard是什么回事吧。 ### Part-I Wildcard （通配符） --------------------------- 首先， ``` `Wildcard` 也是属于 `command line` 的处理工序，作用于 `arguments` 里的 `path` 之上。 ``` 没错，它不用在`command_name`，也不用在`options`上。 而且，若argument不是path的话，那也与wildcard无关。 换句更为精确的定义来讲， ``` `wildcard`是一种命令行的路径扩展(path expansion)功能。 ``` 提到这个扩展，那就不要忘了 command line的“重组”特性了！ 是的，这与`变量替换`(variable subtitution)及 `命令替换`(command substitution)的重组特性是一样的。 也就是在`wildcard`进行扩展后， 命令行会先完成重组，才会交给shell来处理。 了解了`wildcard`的扩展与重组特性后， 接下来，让我们了解一些常见的wildcard吧。 |wildcard | 功能 | |-----------|--------------------| | \* | 匹配0个或多个字符| | ? | 匹配任意单一字符| | [list] | 匹配list中任意单一字符| | [!list] | 匹配不在list中任意单一字符| | {string1,string2,...}| 匹配string1或者stsring2或者(...)中其一字符串| Note: list 中可以指定单个字符，如abcd, 也可以指定ASCII字符的起止范围，如 a-d。 即[abcd] 与 [a-d] 是等价的，称为一个自定义的字符类。 例如： ```shell a*b # a 与 b 之间可以有任意个字符（0个或多个），如aabcb, axyzb, a012b,ab等。 a?b # a 与 b 之间只能有一个字符，但该字符可以任意字符，如 aab, abb, acb, azb等。 a[xyz]b # a 与 b 之间只能有一个字符，但这个字符只能是x或者y或者z，如：axb, ayb, azb这三个。 a[!0-9]b# a 与 b 之间只能有一个字符，但这个字符不能是阿拉伯数字，如aab，ayb，a-b等。 a{abc,xyz,123}b # a 与 b之间只能是abc或者xyz或者123这三个字串之一，扩展后是aabcb，axyzb，a123b。 ``` 1. `[! ]` 中的`!` 只有放在第一位时，才有取反的功效。 eg: `[!a]*` 表示当前目录下不以a开头的路径名称； `/tmp/[a\!]*`表示/tmp目录下所有以a 或者 ! 开头的路径名称； 思考：为何!前面要加\呢？提示是十三问之4. 2. `[ - ]`中`-`左右两边均有字符时，才表示一个范围，否则,仅作`-`(减号)字符来处理。 举例： `/tmp/*[-z]/[a-zA-Z]*` 表示/tmp 目录下所有以z或者-结尾的子目录中， 以英文字母(不分大小写)开头的目录名称。 3. 以\*或?开头的wildcard不能匹配隐藏文件(即以.开头的文件名)。 eg: `*.txt`并不能匹配`.txt`但能匹配1.txt这样的路径名。 但1*txt及1?txt均可匹配1.txt这样的路径名。 基本上，要掌握wildcard并不难， 只要多加练习，再勤于思考，就能灵活运用了。 再次提醒： ``` 别忘了wildcard的"扩展" + "重组" 这个重要特性，而且只作用在 argument的path上。 ``` 比方说， 假如当前目录下有： a.txt b.txt c.txt 1.txt 2.txt 3.txt 这几个文件。 当我们在命令行中执行`ls -l [0-9].txt`的命令行时， 因为wildcard处于argument的位置上， 于是根据匹配的路径，扩展为: 1.txt 2.txt 3.txt， 在重组出`ls -l 1.txt 2.txt 3.txt` 这样的命令行。 因此，你在命令行上敲 `ls -l [0-9].txt` 与 `ls -l 1.txt 2.txt 3.txt` 输出的结果是一样， 原因就是在于此。 ##shell十三问之15: [^ ] 跟[! ]差在哪？ (RE: Regular Expression） ------------------------------------------------------------ ### Part-II Regular Expression (正则表达式) ------------------------------------------ 接下来的Regular Expression(RE) 可是个大题目，要讲的很多。 我这里当然不可能讲得很全。 只希望能带给大家一个基本的入门概念，就很足够了... 先来考一下英文好了：What is expression? 简单来说，就是"表达"，也就是人们在沟通的时候所要陈述的内容。 然而，生活中，表达方要清楚的将意思描述清楚， 而让接收方完整无误地领会，可不是件容易的事情。 因而才会出现那么多的"误会", 真可叹句"表达不易"啊...... 同样的情形也发生在计算机的数据处理过程中， 尤其是当我们在描述一段"文字内容"的时候.... 那么，我们不禁要问： 有何方法可以让大家的误会降至最低程度， 而让表达的精确度达到最高程度呢？ 答案就是"标准化"了， 也就是我们这里要谈的`Regular Expression`啦...^_^ 然而，在进入`RE`介绍之前，不妨先让我们温习一下shell十三问之第4问， 那就是关于quoting的部分。 **关键是要能够区分 shell command line上的meta与literal的这两种不同的字符类型**。 然后，我这里也跟你讲： **RE 表达式里字符也分meta与literal这两种**。 呵，不知亲爱的读者是否被我搞混乱了呢？... ^_^ 这也难怪啦，因为这的确是最容易混淆的地方， 刚学`RE`的朋友很多时候，都死在这里！ 因此，请特别小心理解哦... 简单而言，除非你将`RE`写在特定程序使用的脚本里， 否则，我们的`RE`也是通过 command line输入的。 然而， **不少RE所使用的meta字符，跟shell 的meta字符是冲突的**。 比方说， **`*`这个字符，在RE里是一个modifier(修饰符);而在command line上，确是wildcard(通配符)**。 那么，我们该如何解决这样的冲突呢？ 关键就是看你对shell十三问的第4问中所提的quoting是否足够理解了！ 若你明白到 **shell quoting 就是用来在command line上关闭shell meta这一基本原理**， 那你就能很轻松的解决 RE meta与shell meta的冲突问题了： **用shell quoting 关闭掉shell meta就是了**。 就这么简单... ^_^ 再以刚提到`*`字符为例， 若在command line的path中没有quoting处理的话， 如abc\* 就会被作为wildcard expression来扩充及重组了。 若将其置于quoting中，即"abc\*"，则可以避免wildcard expand的处理。 好了，说了大半天，还没有进入正式的RE介绍呢.... 大家别急，因为我的教学风格就是要先建立基础，循序渐进的... ^_^ 因此, 我这里还要再啰嗦一个观念，才会到RE的说明啦...(哈...别打我...) 当我们在谈到RE时，千万别跟wildcard搞混在一起！ 尤其是 ``` 在command line的位置里，wildcard只作用于argument的path上； 而RE却只用于"字符串处理" 的程序中，这与路径名一点关系也没有。 ``` > **Tips:** > RE 所处理的字符串，通常是指纯文本或通过stdin读进的内容。 okay，够了够了，我已看到一堆人开始出现不耐烦的样子了... ^_^ 现在，就让我们登堂入室，揭开RE的神秘面纱吧， 这样可以放过我了吧？ 哈哈... 在RE的表达式里，主要分为两种字符：`literal`与`meta`。 所谓`literal`就是在RE里不具有特殊功能的字符，如abc，123等； 而`meta`,在RE里具有特殊的功能。 要关闭之，需要在`meta`之前使用escape(\)转义字符。 然而，在介绍`meta`之前，先让我们来认识一下字符组合(character set)会更好些。 一、所谓的char set就是将多个连续的字符作为一个集合。 例如： | char set | 意义 |-------------|---------------------------- | abc | 表示abc三个连续的字符，但彼此独立而非集合。(可简单视为三个char set)| | (abc) | 表示abc这三个连续字符的集合。(可简单视为一个char set)| | abc\|xyz | 表示abc或xyz这连个char set之一| |[abc] | 表示单一字符，可为a或b或c;与wildcard的[abc]原理相同，称之为字符类。| |[^abc] |表示单一字符，不为a或b或c即可。(与wildcard [!abc]原理相同)| | . | 表示任意单个字符，(与wildcard的?原理相同)| note: abc|xyz 表示abc或xyz这连个char set之一 在认识了RE的char set这个概念之后，然后，在让我们多认识几个RE中常见的meta字符： 二、 锚点(anchor): 用以标识RE在句子中的位置所在。 常见的有： |锚点 | 说明| |-------|-------| | ^ | 表示句首。如，^abc表示以abc开头的句子。| | $ | 表示句尾。如，abc$表示以abc结尾的句子。| | \< | 表示词首。如，\ | 表示词尾。如，abc\>表示以abc结尾的词。| 三、 修饰符(modifier)：独立表示时本身不具意义，专门用以修饰前一个char set出现的次数。 常见的有： | modifier | 说明| |------------|----------------------------------- | * | 表示前一个char set出现0次或多次，即任意次。如ab*c表示a与c之间可以有0个或多个b。| | ? | 表示前一个char set出现0次或1次，即至多出现1次。如ab?c 表示a与c之间可以有0个或1个b。| | + | 表示前一个char set出现1次或多次，即至少出现1次。如ab+c 表示a与c之间可以有1个或多个b。| | {n} | 表示前一个char set出现n次。如ab{n}c 表示a与c之间可以有n个b。| | {n, } | 表示前一个char set至少出现n次。如ab{n}c 表示a与c之间至少有n个b。| | {n, m} | 表示前一个char set至少出现n次，至多出现m次。如ab{n，m}c 表示a与c之间至少有n个b，至多有m个b。| 然而，当我们在识别modifier时，却很容易忽略"边界(boundary)字符"的重要性。 以`ab{3,5}c`为例，这里的a与c就是边界字符了。 若没有边界字符的帮忙，我们很容易做出错误的解读。 比方说: 我们用`ab{3,5}`这个RE（少了c这个边界字符) 可以抓到"abbbbbbbbbb"(a后面有10个b)的字符串吗？ 从刚才的modifier的说明，我们一般认为，我们要的b是3到5个， 若超出了此范围，就不是我们所要表达的。 因此，我们或许会很轻率地认为这个RE抓不到结果（上述"abbbbbbbbbb"字符串）。 然而，答案却是可以的！为什么呢？ 让我们重新解读`ab{3,5}`这个RE看看： 我们要表达的是a后接3到5个b即可，但3到5个b后面，我们却没有规定什么， 因此，在RE后面可以是任意的字符串，当然包括b也可以啦！(明白了吗？) 同样，我们用`b{3,5}c`也同样可以抓到"abbbbbbbbbbc" 这样的字符串。 但当我们用`ab{3,5}c`这样的RE时， 由于同时有a与c这连个边界字符，就截然不同了！ 有空在思考一下，为何我们用下面这些RE都抓到abc这样的字符串呢？ ``` x* ax*, abx*, ax*b abcx*, abx*c, ax*bc bx*c, bcx*, x*bc ``` 但, 若我们在这些RE前后分别加`^`与`$`这样的anchor，那又如何呢？ 刚学RE时，只要能掌握上面这些基本的meta的大概就可以入门了。 一如前述，RE是一种规范化的文字表达式， 主要用于某些文字处理工具之间，如： grep， perl， vi，awk，sed，等等， 常用于表示一段连续的字符串，查找和替换。 然而每种工具对RE表达式的具体解读或有一些细微差别， 不过节本原理还是一致的。 只要掌握RE的基本原理，那就一理通百理了， 只是在实践时，稍加变通即可。 比方以grep来说， 在Linux上，你可以找到grep，egrep，fgrep这些程序， 其差异大致如下： grep： 传统的grep程序，在没有任何选项(options)的情况下，只输出符合RE字串的句子， 其常见的选项如下： | 选项 (option)| 用途| | -----|---------------------------- | -v | 反模式， 只输出“不含”RE的字符串的行。| | -r |　递归模式，可同时处理所有层级的子目录里的文件| | -q | 静默模式，不输出任何结果(stderr 除外，常用于获取return value，符合为true，否则，为false.| | -i | 忽略大小写| | -w | 整词匹配，类似 \| | -n | 同时输出行号| | -l | 输出匹配RE的文件名| | -o | 只输出匹配RE的字符串。(gna新版独有，不见得所有版本支持)| | -E | 切换为egrep| egrep：为grep的扩充版本，改良了许多传统grep不能或者不便的操作， - grep下不支持`?`与`+`这两种meta，但egrep支持； - grep 不支持`a|b`或（`abc|xyz`）这类“或一”的匹配，但egrep支持； - grep 在处理`{n,m}`时，需要\\{ 与 \\}处理，但egrep不需。 等诸如此类的。我个人建议能用egrep就不用grep啦...^_^ fgrep: 不作RE处理，表达式仅作一般的字符串处理，所有的meta均市区功能。 好了，关于RE的入门，我们暂时就介绍到这里。 虽然有点乱，且有些观念也不恨精确， 不过，姑且算是对大家的一个交差吧...^_^ 若这两天有时间的话，我在举些范例来分析一下，以帮助大家更好的理解。 假如更有可能的话，也顺道为大家介绍一下sed这个工具。 --------------------------------------- ### Part-III eval --------------------------------------- 讲到command line的重组特性， 真的需要我们好好的加以解释的。 如此便能抽丝剥茧的一层层的将整个command line分析的 一清二楚，而不至于含糊。 假如这个重组的特性理解了，那我们介绍一个好玩的命令：`eval`. 我们在变量替换的过程中，常会碰到所谓的复式变量的问题： 如： ```shell a=1 A1=abc ``` 我们都知道`echo $A1`就可以得到abc的结果。 然而，我们能否用$A$a来取代$A1，而同一样替换为abc呢？ 这个问题我们可用很轻松的用`eval`来解决： ```shell eval echo \$A$a ``` 说穿了，`eval` 只不过是在命令行完成替换重组后， 在来一次替换重组罢了... 就是这么简单啦～～～ ^_^ ##shell十三问之16：学习总结与原帖目录 --------------------------------- 本人(markdown译者)是解决工作中shell脚本的一个问题， 偶尔的一次机会遇到了CU论坛中这样一个神贴：**shell十三问**. shell十三问是CU的shell版的台湾的**网中人**是2003年用繁体发布的。 第一次读到shell十三问，由于是繁体，第一感觉有点抵触， 但是还是耐着性子读完了一贴，没想到竟然读懂了， 而且还被**网中人**的幽默的写作风格，独到的思维方式， 循序渐进的认识事物的过程所折服。 尽管帖子是10多年前写的，今天看来也几乎没有一点过时的感觉。 从这个方面来说，shell十三问应该shell的(思想)精华本质所在， 就像武功的内功心法，可能我说的点过， 但是我曾经看过一本shell脚本学习指南，看完后的感觉，还是有感念很朦胧， 而shell十三问是我最容易理解和接受的，这也是我整理的Markdown版本初衷。 为什么不让好东西让更多的人熟知呢，恰好年前项目管理开始迁移到git上， 在git上认识一个好东西Markdown，用它可以很简单地整理出条例清晰篇章。 在年假的时候，觉得这个假期该做点什么， 毕竟马总都说了，改变世界，不如改变自己。 本人整理的 [简体中文Markdown版本的shell十三问][shell-markdown] 的链接地址： https://github.com/wzb56/13_questions_of_shell 网中人的CU原帖[shell十三问][0]地址：http://bbs.chinaunix.net/thread-218853-1-1.html 我简单将原文整理如下： 我在CU的日子并不长，有幸在shell版上与大家结缘。 除了跟前辈学习到不少技巧之外，也常看到不少朋友的问题。 然而，在众多问题中，我发现许多瓶颈都源于shell的基础而已。 每次要解说，却总有千言万语不知从何而起之感...... 这次，我不是来回答，而是准备了关于shell基础的十三个问题要问大家。 希望的shell的学习者们能够通过寻找答案的过程，好好的将shell基础打扎实一点。 当然了，这些问题我也会逐一解说一遍。 只是，我不敢保证什么时候能够完成这趟任务。 除了时间关系外，个人功力实在有限，很怕匆忙间误导观众就糟糕了。 若能抛砖引玉，诱得，其他前辈出马补充，那才是功德一件。 ###shell十三问： 1. [为何叫做 shell?][1] 2. [shell prompt(PS1) 与 Carriage Return(CR) 的关系？][2] (2008-10-30 02:05 最后更新) 3. [別人 echo、你也 echo ，是问 echo 知多少？][3]( 2008-10-30 02:08 最后更新) 4. [" "(双引号) 与 ' '(单引号)差在哪？][4] (2008-10-30 02:07 最后更新) 5. [var=value 在export前后差在哪？][5] (2008-10-30 02:12 最后更新) 6. [exec 跟 source 差在哪?][6] (2008-10-30 02:17 最后更新) 7. [( ) 与 { } 差在哪？][7] 8. [$(( )) 与 $( ) 还有${ } 差在哪？][8] (2008-10-30 02:20 最后更新) 9. [$@ 与 $* 差在哪？][9] 10. [&& 与 || 差在哪？][10] (2008-10-30 02:21 最后更新) 11. [> 与 < 差在哪？][11] (2008-10-30 02:24 最后更新) 12. [你要 if 还是 case 呢？] [12] (2008-10-30 02:25最后更新) 13. [for what? while 与 until 差在哪？][13] (2008-10-30 02:26最后更新) 14. [[^ ] 跟 [! ] 差在哪？][14] 15. [Part-I: Wildcard][14] (2008-10-30 02:25 最後更新) 16. [Part-II Regular Expression][15] (2008-10-30 02:26 最后更新) -------------- 说明： 1. 欢迎大家补充/扩充问题。 2. 我接触电脑的中文名称时是在台湾，因此一些术语或与大陆不同，请自行转换。 3. 我会不定时"逐题"说明(以 Linux 上的 bash 为环境) 同时，也会在任何时候进行无预警的修改。请读者自行留意。 4. 本人于本系列所发表的任文章均可自由以电子格式(非印刷)引用、修改、转载， 且不必注明出处(若能注明 CU 更佳)。当然，若有错漏或不当结果，本人也不负任何责任。 5. 若有人愿意整理成册且付印者，本人仅保留著作权，版权收益之 30% 須捐赠于 CU 论坛管理者，剩余不究。 --------- 建议參考谈论: 1. shaoping0330 兄关于变量替换的补充：（链接在改版后已经失效） 2. shaoping0330 兄[关于 RE][16] 的说明: 3. 关于 nested subshell 的讨论:（链接在改版后已经失效） 4. [关于 IFS 的讨论][18]: --------- * 感谢 lkydeer 兄整理 [word/pdf 版本][19]方便大家参考： [shell-mardown]: https://github.com/wzb56/13_questions_of_shell [0]: http://bbs.chinaunix.net/thread-218853-1-1.html [1]: http://bbs.chinaunix.net/forum.php?mod=viewthread&tid=218853&page=2#pid1454336 [2]: http://bbs.chinaunix.net/forum.php?mod=viewthread&tid=218853&page=2#pid1467910 [3]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=3#pid1482452 [4]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=4#pid1511745 [5]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=5#pid1544391 [6]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=6#pid1583329 [7]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=6#pid1595135 [8]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=7#pid1617953 [9]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=7#pid1628522 [10]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=7#pid1634118 [11]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=7#pid1636825 [12]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=8#pid1679488 [13]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=8#pid1692457 [14]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=16#pid2930144 [15]: http://bbs.chinaunix.net/viewthread.php?tid=218853&extra=&page=16#pid2934852 [16]: http://bbs.chinaunix.net/forum/viewtopic.php?t=393964 [18]: http://bbs.chinaunix.net/forum/viewtopic.php?t=512925 [19]: http://bbs.chinaunix.net/viewthread.php?tid=963890&extra=page%3D2