《从业务模型学习shell》系列不是一本工具书，内容为笔者在生产实践中的一些经验总结，希望以更容易理解的语言和例子让读者得到收获，快速有效应用所学习的内容提高开发工作中的效率的同时少踩到坑。若对相关操作接触较少，建议在bash中完成相关练习操作。
转载请注明出处从业务模型学习shell 之 cd
一、从一个问题说起
在进入linux系统时的那一刻，你就应该知道cd命令了。对于cd命令，我们有一个基本的共识：改变当前的工作目录。
不知道你是否有过这样的经历，手速稍快点或者心情激动紧张时， 误把 cd / 打成了 cd //，你发现也能执行成功，这时候，你的命令窗应该是这样的：
[root@izbp159pvhq ~]# cd //
[root@izbp159pvhq //]# pwd
//
[root@izbp159pvhq //]#
这结果多少令人感到疑惑，它仿佛带着我们穿越了时空，到了一个不在原有认知内的空间。但pwd的结果又告诉我们，的确存在这样一个目录，他是逻辑正确的。
二、讲讲逻辑
2.1 绝对路径和相对路径
简单复习一下几个基本概念：
绝对路径：能够完整且唯一的表达出文件/资源所在路径，从树型目录结构顶部的根目录开始到某个目录或文件的路径，由一系列连续的目录组成，以斜杠或双斜杠开头，中间用斜杠分隔
相对路径：指由这个文件所在的路径引起的跟其它文件（或文件夹）的路径关系，不以斜杠开头
用户目录：对一般用户，用户目录为 /home/（用户名）；对于root用户，用户目录为/root
根目录：文件系统的最顶层是由根目录开始的，系统使用 / 来表示根目录
2.1.1 绝对路径下的//
常用的绝对路径操作方法：
1） cd / 进入到根目录
2） cd /usr/bin 进入到 根目录中 usr 目录下的bin目录
// 像这样的路径表达式，我们首先会想到的是，这是一个绝对路径，因为在linux中，以/ （根目录）开头的路径我们可以认为就是绝对路径。那么根目录下的根目录要怎么理解呢，应该还是根目录？
[root@izbp159pvhq //]# ls
bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
[root@izbp159pvhq //]#
的确， 和根目录中的查看结果是一致的，至此，机智的你可能发现， / 和 // 其实都是描述的根目录。
那么我们不禁想到 /// 、//// 诸如此类的目录，应该也都是表示根目录吧? 不妨验证一下
[root@izbp159pvhq ~]# cd /
[root@izbp159pvhq /]# ls
bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
[root@izbp159pvhq /]# cd //
[root@izbp159pvhq //]# ls
bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
[root@izbp159pvhq //]# cd ///
[root@izbp159pvhq /]# ls
bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
[root@izbp159pvhq /]# cd ////
[root@izbp159pvhq /]# ls
bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
答案是正确的，但是我们可以看到，输入 /// 、//// （甚至更多的/）时，我们是直接回到了根目录，而只有//比较特殊，有自己独立的//目录。
我们的猜想似乎又陷入了僵局，还是解释不清楚 // 到底是为何特殊。那我们暂且换个思路，看看多个/在相对路径中的表现是怎样的。
2.1.2 相对路径下的//
常用的相对路径操作方法
1）cd . 还在当前目录，没有发生变更
2）cd .. 表示返回上级目录
3）cd ../.. 表示返回向上2级的目录
4）cd ~ 表示进入用户目录
5）cd 不带任何参数，同样会回到用户目录
6）cd - 表示返回上一次访问的工作目录。 非常有用且常用
假如我们在访问相对路径时，添加了多个 /，会发生什么？
[root@izbp159pvhq bin]# pwd
/usr/bin
[root@izbp159pvhq bin]# cd ..//
[root@izbp159pvhq usr]# pwd
/usr
[root@izbp159pvhq usr]# cd -
/usr/bin
[root@izbp159pvhq bin]# cd ..//////..
[root@izbp159pvhq /]# pwd
/
[root@izbp159pvhq /]#
从执行结果可以看到，无论我们指定的相对路径中有多少个 /，和只有一个/的执行结果都是一致的。这里我们其实已有所预期了，那我们再看看// 目录还有什么特殊的魅力。
上文我们提到，// 像这样的路径表达式，我们容易理解为根目录下的根目录，我们按以下操作简单验证一下：
[root@izbp159pvhq /]# cd //
[root@izbp159pvhq //]# pwd
//
[root@izbp159pvhq //]# cd ..
[root@izbp159pvhq //]# pwd
//
[root@izbp159pvhq //]#
所以，所谓的根目录下的根目录这个说法其实是不能站住脚的。
2.2 // 目录的逻辑
经过上述的试验，我们发现//目录就像是另一个平行时空下的 /目录，似是而非。为什么会有这样的一个目录的设计呢，查阅相关资料，我们可以找到以下线索。
"Multiple successive slashes are considered to be the same as one slash."
从Single Unix规范（版本3）开始，基本定义§3.266路径名指出：“多个连续的斜杠被认为与一个斜杠相同。”
这就能解释上文相对路径中发现的，多个/ 与单个/实际等效的现象。而如果路径名正好以两个斜杠开头，则可能会被区别对待（请参阅：基本定义§4.11路径名解析）
定义中提到 "A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash." 即两个斜杠开头原则上应该当做一个斜杠，但在实现中是可以自定义的。
Linux本身不这样做，尽管某些应用程序可能会这样做，而其他unix-ish系统也会这样做（例如Cygwin）。
也就是说，两个斜杠开头的路径，其具体含义是因操作系统而异的，事实上，这是一个历史兼容性问题，在某些版本的Unix和早期的网络文件系统使用以下格式的路径：//主机名/路径 来访问服务器上的对应路径。
一般来说，我们是可以认为多个连续的斜杠被认为与一个斜杠相同。而在描述路径时，不重复的去使用斜杠也是一种良好的编写风格。
三、业务场景案例
其实关于cd命令， 我们常用的操作很简单，上文也只是在引文中简单介绍了常用方法，对于我们日常需求来说，已经完全足够了。下面以一个实际场景来看，开发中使用cd命令，还有什么秘密。
3.1 我不知道要去哪里，而它清楚
操作过版本发布的同学应该很有体会，我们的应用部署目录可能是以下这种结构
[root@izbp159pvhq publish]# ls
1.0 1.1 1.2 1.3 version.current version.pre
[root@izbp159pvhq publish]# cat version.current
1.3
这表示我们有4个版本的包在服务器上，且当前的生效版本名是配置在 version.current文件中，那常规的，我们需要先看version.current文件中的配置信息，再根据配置的文件夹名去访问对应的目录。
对于这种场景，我们通常使用命令嵌套的方式来处理:
我们通常使用 $() 或者 ``来对命令进行嵌套， 以上题背景为例
[root@izbp159pvhq publish]# cd $(cat version.current)
[root@izbp159pvhq 1.3]#
就能完成目录的查找和跳转。
其实在碰到这一类“使用上一个输出作为输入”的问题时，我们的第一反应可能会是使用管道，那么在这个场景下，管道可行吗？
3.2 它清楚我要它去哪里吗？
接着上述的问题，我们试着使用管道（|）来完成这个目录跳转的功能，借鉴常用的管道操作，我们可能会写下这样的命令：
[root@izbp159pvhq publish]# cat version.current | cd
[root@izbp159pvhq publish]#
可以发现这样是不起作用的，这是因为其实 cd是使用命令行参数的，它不接受标准输出，因此不会发生我们预期的跳转到 1.3当前版本目录。而到这一步，细心的你可能发现， 我们这个命令没有任何错误输出，但也没有做目录跳转，这又是一个令人费解的点了， 我们再做一些验证：
[root@izbp159pvhq publish]# cat version.config | cd
[root@izbp159pvhq publish]# cat version.config | cd //
[root@izbp159pvhq publish]# cat version.config | ls
1.0 1.1 1.2 1.3 version.current version.pre
[root@izbp159pvhq publish]# cat version.config | ls /
bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
[root@izbp159pvhq publish]#
同样是不接受标准输入的两个命令 cd,ls，cd 在管道右侧时看起来完全没有发挥作用，而ls 却能正确的执行，并且正确处理其命令行参数，这多少令人感到诧异。
实际上，根据对管道的学习，我们可以知道的是，我们创建一个管道时，会在内核中开辟一块缓冲区用于通信，它具有自己的“环境”，包括所有环境变量和当前工作目录。在其中指定管道的shell和所有“管道”在一起的多个子管道，每个子管道都有一个独立的环境。
也就是说， cat version.config | cd 这个管道命令实际上是分别在两个独立的环境运行的，而由于 管道命令中， 只有最后一个命令的输出才会打印出来且cd 是没有输出的。所以当管道命令执行完后，看起来没有发生任何变化。
我们可以用以下例子更清晰的理解这一点：
[root@izbp159pvhq publish]# cat version.config | (cd / && ls)
bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
[root@izbp159pvhq publish]#
从该命令的执行情况，我们可以看出，在管道中的cd命令是生效的，只不过退出管道后，我们还是在创建管道时的目录，并没有发生改变。关于更多管道相关的知识点，我之后再专题做总结。
结语
以上内容就是本次分享的cd实际应用的相关内容了，单从使用上来说，cd命令其实几乎没有学习成本，但实际应用中的一些细节却值得我们仔细品味。
后续将对更多linux命令的有关知识进行总结分享，感谢关注。若文中有写错的地方，还请留言指正，防止对他人产生误导！
感谢阅读，希望有所收获！
