shell中的特殊符号（bash）

|

单管道符号，将前面的命令执行结果传递给后面的命令
比如：ps -ef | grep top

||

连接两条命令的双管道符号，如果前面的命令执行成功则不执行后面的命令，前

面的指令执行失败则执行后面的指令

比如：ls || echo 123则不执行后面的指令

比如：lk || echo 123则前面指令执行失败，执行后面的指令

shell层理解：如果前一个命令的退出码 ≠ 0（失败），才执行后一个命令

&

and符号：后台执行程序
比如：top & 的话直接在后台运行top
注意：terminal kill & is over

top &                   # 后台运行，但还“挂在”终端

nohup top &      # 后台运行，不再依赖终端

disown                # 把已运行的后台任务与终端解绑

shell层理解：& 的本质是让 shell 不等待该进程结束，而不是让进程“变成守护进程”

&&

连接两条命令的双and符号：如果前面的命令执行成功后面的命令也执行，如果前面的命令执行失败则不执行后面的命令

比如：echo 123 && ls 前面的指令执行成功，那么也执行后面的指令

比如：ech1 123 && ls 前面的指令执行失败，那么后面的指令不执行

～

家目录波浪符：一般在ubuntu里面直接回到/home/your users如果是mac的话/Users/your users

注意：在shell中～会被展开，但是在脚本或者是单引号中是不会被展开的

``

反引号嵌套指令，把现在指令的执行结果返回给前面的指令

比如：touch "`date`".txt 那么date指令的结果将会给touch指令作为参数来创建当前时间的txt

然后“”包裹整date命令是为了使date中的空格转译为普通参数

比如：tar -zcf /test.tar.gz find /home/test/ -name "`mytest.conf`"

注意：``反引号优先级最高，所以“”包裹date会被优先执行，然后变成参数

注意：在生产中最好先声明变量，然后直接引用变量如$commadn避免陷入转义地狱，实际生产中尽量直接使用$加commadn来使用。直接使用``来包裹的话不是现代的使用方法，使用时候需要注意。

shell层理解：``（命令替换）：在 shell 解析阶段先执行命令，将 stdout 结果替换到命令行中，然后再进行分词、展开等处理

""

双引号：包裹住的内容会变成普通的参数，如果要把双引号内部的参数转译直接\对应参数即可

比如：find ~ -name " test" 2>/dev/null
注意： 双引号内将1.允许变量展开2.允许命令替换3.禁止空格分词4.禁止通配符展开

转译只针对少数字符：\" \$ \` \\

‘’

单引号：被单引号所包裹的内容都作为字符串

比如：echo 'ls /'的话那么直接输出echo ls /

注意：所有东西都不展开，包裹在内的字符全部都是字符串

$

dollar符：一般是表示变量或者调用变量注意变量名字要全大写，并不是小写不行，大写是约定俗成的习惯

比如：echo $SHELL看一下变量里面的值

比如：cat $ABC 直接打印变量里面的值（当然首先要保证$ABC存在）

;

分号：命令连接符，连接多条命令，如果需要执行多条命令的话直接使用连接符号即可

比如：cd /home/test/ ; pwd

\

转译符：直接把指令转译为一个字符串

比如 scp /home/test/abc.txt root@999.999.999.999:\/home/test/

注意：转译的是下一个字符而不是全部字符

!

叹号：在shell中表示历史命令调用或在find中表示取反

比如：history的第50条命令我需要再使用，那么我直接在shell中！50即可
比如：在find中find ~ -name " ! test" 2>/dev/null的话那么我直接取反值

>

重定向符：直接把内容输入到对应的命令或者对应的文件中，注意会覆盖以前的内容

比如：cat $ABC > /home/test/test.txt

>>

追加重定向符：可以把内容在不抹除追加前的内容情况下追加输入对应的值

比如：cat $ABC >> /home/test/test.txt

<

stdin的输入重定向符：直接把stdin对应的内容重定向到对应的指令

比如：我cat < test.txt 那么cat指令将会从stdin读取，原本stdin会是我的键盘输入的内容，但是现在stdin里面的内容是test.txt里面的内容。这就是因为<把内容直接写入了stdin了

以下为对比：

1.如果我直接cat mytest.txt将会发生如下行为

shell 打开文件 mytest.txt

↓

把文件描述符交给 cat

↓

cat 直接从“文件参数”读内容

↓

cat 写到 stdout

2.如果我现在cat < mytest.txt将会发生如下行为

shell 把 mytest.txt 打开

↓

把 cat 的 stdin（fd 0）指向这个文件

↓

cat 开始“读 stdin”

↓

cat 把读到的内容写到 stdout

<<

追加输入重定向符：上面的<逻辑直接变成了<<追加输入了

比如：

cat <<EOF > nginx.conf

server {

    listen 80;

    server_name example.com;

}

EOF

上面的命令解读，现在cat接收到的命令现在并不是直接来自stdin而是来自EOF和shell临时构建的一个文本，输入到了nginx.conf里面

那里面的内容是server{

Listen 80;

Server_name mytest.com;

}

EOF