剧情回顾

在上一节中我们已经介绍了两种方式来扩展 git bash 命令,解决了一般性命令不足的问题,最后我们还留下了一个疑问,如果两种方式均无法扩展某些命令又该怎么办?

再介绍最后一个大招之前,我们首先来回忆一下前面两种扩展方式.

• bash 不足 cmd 来凑

git bash 命令行终端和 windows 系统自带的 cmd 命令行终端互为补充,某些 git bash 命令没有并不意味着 cmd也没有,所以遇到 git bash 无某些命令的情况下,首先应该去看看 cmd 有没有这个命令.

如果碰巧 cmd 存在该命令,那么既可以在 cmd 中直接运行该命令,也可以在 git bash 中借助 winpty+cmd原生命令 方式调用该命令.

示例:

1. F:\workspace\git-bash-extend>tree

2. 卷 常用 的文件夹 PATH 列表

3. 卷序列号为 62AE-62CA

4. F:.

5. ├─extend-cmd

6. ├─extend-gitforwindows-sdk

7. └─extend-gnuwin

cmd 命令行中有 tree 命令,不过该命令的后缀名是 .com 而不是 .exe.

1. Administrator@snowdreams1006 MINGW64 /f/workspace/git-bash-extend

2. $ winpty tree.com

3. 卷 常用 的文件夹 PATH 列表

4. 卷序列号为 62AE-62CA

5. F:.

6. ├─extend-cmd

7. ├─extend-gitforwindows-sdk

8. └─extend-gnuwin

git bash 命令行中没有 tree 命令,通过调用 cmd 命令行中的 tree.com 命令变相支持 tree 命令.

• bash 没有 gnuWin 填补

如果 git bash 命令行中没有的命令, cmd 也没有的话,那么应该想办法扩展 git bash 命令,最简单的方式是找同源的命令.

正所谓"物以类聚人以群分",如果有现成的命令可以直接扩展过来,岂不是很方便,幸运的是, gnuwin 开源项目适用于 git!

我们可以从 gnuwin32 项目下载所需的扩展命令并复制到 git bash 的安装位置下面的 /usr/bin 目录下即可轻松扩展更多命令.

示例:

1. Administrator@snowdreams1006 MINGW64 /f/workspace/git-bash-extend

2. $ tree

3. .

4. ├── extend-cmd

5. │   └── cmd.md

6. ├── extend-gitforwindows-sdk

7. │   └── gitforwindows-sdk.md

8. └── extend-gnuwin

9. └── gnuwin.md

10. 3 directories, 3 files

轻松扩展的 tree 命令,功能更强大更像 linux 系统的 tree 命令.

回顾问题

如果没有第三方现成的命令文件供我们轻松扩展,意味着前面两种方式均已失效!

如果真的遇到这种情况,一般会有两种方式来解决问题.

• 直接放弃,寻找新的替代方案

• 定制开发,创造自定义解决方案

两种方案没有谁对谁错,应该根据自身情况选择适合自己的哪一种,针对 git bash 命令不足的问题,我们具体分析一下是否可行.

直接放弃,另寻新欢

如果选择方案一,意味着我们需要放弃 git bash 命令行工具并寻求新的替代方案,也就是说我们首先需要弄清楚两个问题.

• 能不能直接放弃 git bash 命令行

GitBash 是命令行工具,是为了使用 git 而默认提供的命令行工具,与此同时, GitBash 还有一个双胞胎兄弟叫做 GitGUI 图形化工具.

由此可见, GitBash 并不是 Git 的关键核心,可有可无的工具类而已.

• 寻找哪一款替代方案?

既然已经决定放弃了 git bash 命令行,那么我们就要找一个功能更加强大的命令行工具来替代 git bash.

但是, windows 始终是 windows ,是不可能真正变成 linux 系统的,所以我们要寻找的第三方工具充其量也是一种模拟系统而已.

市面上, windows 的命令行工具有很多,有些是单纯的命令行工具有的是虚拟系统工具,但是不管怎么样,我们这一次要选择的命令行工具一定要满足以下几点.

• 方便集成 git 服务,这是初衷,不可违背.

• 命令行语法类似 linux 语法,降低学习成本.

• 自带包安装工具,这是最关键部分也是 git bash 没有提供的部分.

• 安装配置简单,无需繁琐的配置即可轻松上手.

根据以上几点,推荐一款 Babun 工具,正如官方标语宣传的那样,一款一会爱上的 WindowsShell .

Babun : a Windows shell you will love!

当然除了上述基本要求外,再谈一谈为什么推荐这一款软件?

• 安装简单,下载安装包执行安装脚本自动安装配置.

• 自带包管理工具,且静默安装无需过多交互式询问.

• 基于 Cygwin 预配置大量常用插件,包括 git 和 shell.

• 默认终端模拟器是 Mintty,支持两种类型的 shell,分别是 bash 和 zsh.

翻译成人话就是: Babun 和 GitBash 一脉相承,不仅是亲戚还是近亲, Babun 比 GitBash 体积更大,功能更强.

babun 初体验

下载 babun 并解压缩,然后双击 install.bat 脚本进行自动化安装.

自动安装成功后会自动创建桌面快捷方式并输出 babun 基本信息.

配置你的新欢

• 配置 git

默认已经集成 git ,因此我们可以像 git bash 那样使用 git.

1. { ~ } » git --version                                                                          ~

2. git version 2.1.4

接下来进行一些关于 git 的常规配置,彻底拥抱 babun.

1. # 添加用户名和邮箱

2. git config --global user.name "your name"

3. git config --global user.email "your@email.com"

4. # gitalias 插件提供的 git 别名配置项

5. gitalias['alias.cp']='cherry-pick'

6. gitalias['alias.st']='status -sb'

7. gitalias['alias.cl']='clone'

8. gitalias['alias.ci']='commit'

9. gitalias['alias.co']='checkout'

10. gitalias['alias.br']='branch'

11. gitalias['alias.dc']='diff --cached'

12. gitalias['alias.lg']="log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %Cblue<%an>%Creset' --abbrev-commit --date=relative --all"

13. gitalias['alias.last']='log -1 --stat'

14. gitalias['alias.unstage']='reset HEAD --'

• 更改默认 shell

1. # 查看当前shell类型: zsh

2. { ~ } » babun shell                                                                            ~

3. /bin/zsh

4. # 切换当前shell类型: zsh -> bash

5. { ~ } » babun shell /bin/bash                                                                  ~

6. /bin/zsh

7. /bin/bash

• 自定义配置

命令行窗口内通过命令运行的配置命令一般都是临时性的,下次电脑重启或者新开命令行窗口就会失效,如果想要永久性生效,一般会将配置写入到配置文件中, babun 也不例外,配置文件默认存放于 ~/.babunrc

1. # JVM options

2. export JAVA_OPTS="-Xms128m -Xmx256m"

3. # Modify these lines to set your locale

4. export LANG="en_US.UTF-8"

5. export LC_CTYPE="en_US.UTF-8"

6. export LC_ALL="en_US.UTF-8"

7. # Uncomment these lines to the set your machine's default locale (and comment out the UTF-8 ones)

8. # export LANG=$(locale -uU)

9. # export LC_CTYPE=$(locale -uU)

10. # export LC_ALL=$(locale -uU)

11. # Uncomment this to disable daily auto-update & proxy checks on startup (not recommended!)

12. # export DISABLE_CHECK_ON_STARTUP="true"

13. # Uncomment to increase/decrease the check connection timeout

14. # export CHECK_TIMEOUT_IN_SECS=4

15. # Uncomment this lines to set up your proxy

16. # export http_proxy=http://user:password@server:port

17. # export https_proxy=$http_proxy

18. # export ftp_proxy=$http_proxy

19. # export no_proxy=localhost

如果当前用户家目录下没有 .babunrc 配置文件,运行 touch~/.babunrc 自行创建该配置文件即可.

体验新欢之美

babun 看起来像是我们真的运行在 linux 系统一样,那么流畅顺滑,是一款遇上再也不会错过的 WindowsShell .

1. # tree 命令 babun 有

2. { ~ } » tree                                                                                   ~

3. .

4. ├── a

5. ├── bin -> /home/vm-win7/.local/bin

6. └── will

7. 1 directory, 2 files

8. # wget 命令 babun 也有

9. { ~ } » wget www.baidu.com                                                                     ~

10. --2019-05-24 14:33:01--  http://www.baidu.com/

11. Resolving www.baidu.com (www.baidu.com)... 115.239.211.112, 115.239.210.27

12. Connecting to www.baidu.com (www.baidu.com)|115.239.211.112|:80... connected.

13. HTTP request sent, awaiting response... 302 Found

14. Location: https://www.baidu.com/ [following]

15. --2019-05-24 14:33:02--  https://www.baidu.com/

16. Connecting to www.baidu.com (www.baidu.com)|115.239.211.112|:443... connected.

17. HTTP request sent, awaiting response... 200 OK

18. Length: unspecified [text/html]

19. Saving to: ‘index.html’

20. index.html                   [ <=> ] 152.70K --.-KB/s   in 0.05s

21. 2019-05-24 14:33:02 (2.98 MB/s) - ‘index.html’ saved [156365]

不论是 tree 命令还是 wget 命令, babun 默认全部集成,这下真的要彻底替代 cmd 了呢!

但是,不知道你是否注意到在推荐 babun 时,我们曾经说过 babun 和 git bash 不仅是亲戚而且还是近亲.

这句话又从何谈起?

首先, babun 是基于 Cygwin, git bash 或者说 gitforwindows 也是基于 Cygwin,两者一脉相承. 再者, babun 支持 shell 和 zsh 两种 shell,而 gitforwindows 仅支持 bash. 还有, babun 和 gitforwindows 的默认终端都是 mintty 模拟器.

最后一点是差异性比较大的, babun 是直接基于 Cygwin 而 gitforwindows 则是间接基于 Cygwin ,两者确实存在一定的差异性!

再问最后一个问题,我们为什么要使用 Cygwin 而抛弃 git bash ?

那是因为 git bash 默认提供的命令有限却又没有提供相应的包管理工具,导致我们无法自定义扩展更多命令.

所以,我们何不试一试 babun 的包管理工具呢?

• 包管理工具帮助文档

1. { ~ } » pact --help                                                                            ~

2. pact: Installs and removes Cygwin packages.

3. Usage:

4. "pact install <package names>" to install given packages

5. "pact remove <package names>" to remove given packages

6. "pact update <package names>" to update given packages

7. "pact show" to show installed packages

8. "pact find <patterns>" to find packages matching patterns

9. "pact describe <patterns>" to describe packages matching patterns

10. "pact packageof <commands or files>" to locate parent packages

11. "pact invalidate" to invalidate pact caches (setup.ini, etc.)

12. Options:

13. --mirror, -m <url> : set mirror

14. --invalidate, -i       : invalidates pact caches (setup.ini, etc.)

15. --force, -f : force the execution

16. --help

17. --version

• 安装第三方命令

1. { ~ } » pact install arj                                                                     ~ 2

2. Working directory is /setup

3. Mirror is http://mirrors.kernel.org/sourceware/cygwin/

4. --2019-05-24 14:26:46--  http://mirrors.kernel.org/sourceware/cygwin//x86/setup.bz2

5. Resolving mirrors.kernel.org (mirrors.kernel.org)... 198.145.21.9, 2001:19d0:306:6:0:1994:3:14

6. Connecting to mirrors.kernel.org (mirrors.kernel.org)|198.145.21.9|:80... connected.

7. HTTP request sent, awaiting response... 200 OK

8. Length: 3893609 (3.7M) [application/x-bzip2]

9. Saving to: ‘setup.bz2’

10. setup.bz2                100%[====================================>] 3.71M 5.89KB/s   in 4m 5s

11. 2019-05-24 14:30:51 (15.5 KB/s) - ‘setup.bz2’ saved [3893609/3893609]

12. Updated setup.ini

13. Installing arj

14. Found package arj

15. --2019-05-24 14:30:52--  http://mirrors.kernel.org/sourceware/cygwin//x86/release/arj/arj-3.10.22-3.tar.xz

16. Resolving mirrors.kernel.org (mirrors.kernel.org)... 198.145.21.9, 2001:19d0:306:6:0:1994:3:14

17. Connecting to mirrors.kernel.org (mirrors.kernel.org)|198.145.21.9|:80... connected.

18. HTTP request sent, awaiting response... 200 OK

19. Length: 134244 (131K) [application/x-xz]

20. Saving to: ‘arj-3.10.22-3.tar.xz’

21. arj-3.10.22-3.tar.xz     100%[====================================>] 131.10K 5.02KB/s   in 17s

22. 2019-05-24 14:31:10 (7.61 KB/s) - ‘arj-3.10.22-3.tar.xz’ saved [134244/134244]

23. Unpacking...

24. Package arj requires the following packages, installing:

25. cygwin

26. Package cygwin is already installed, skipping

27. Package arj installed

• 卸载第三方命令

1. { ~ } » pact remove arj                                                                        ~

2. Removing arj

3. Package arj removed

babun 在手, linux 我有!妈妈再也不用担心我的 WindowsShell 不好用了!

忠贞不二,开发扩展

方案一让我们另寻新欢,方案二让我们坚持己见,面对问题不逃避而是想办法解决.

再一次回忆一下需要解决的问题: git bash 命令行默认没有提供包管理工具以至于我们只能使用已集成的命令,所以不支持自定义扩展命令.

解铃还须系铃人

git bash 是 git 的命令行工具,而 git 原来仅仅支持 linux 系统,后来又支持了 windows ,值得注意的是,这种所谓的支持并不是原生支持,而是变相支持.

如果你打开 git 的官网 https://git-scm.com/download,你会发现 git 也是跨平台的呢,竟然支持 mac , windows 和 linux 三大主流操作系统!

然而,真相却不是这样的, windows 平台的 git 其实不是真正的 git,或者说 windows 和另外两个并不是一家人.

首先看一下 MacOS X 的下载页面介绍,请注意源码地址: https://github.com/git/git/

源码托管于 github,是 git 组织下面的 git 项目,其项目地址是 https://github.com/git/git/

接下来我们再看一下 LinuxandUnix 的下载页面,虽然下载页面推荐我们使用包管理工具进行安装,但仍然给我提供了源码地址: https://www.kernel.org/pub/software/scm/git/

虽然源码下载地址不是 github,但是我们却可以从项目地址中窥见一斑,仍然属于 scm/git/ 项目,也是亲儿子.

如果 mac 和 linux 是 git 原生支持的亲儿子,那么 windows 则是变相支持的干儿子.

windows 和 mac 一样,源码同样托管在 github,但是地址却不一样!项目地址: https://github.com/git-for-windows/git

这下局面瞬间清楚了, gitforwindows 并不是 git 原生支持的 windows 版本,或者说 windows 系统的 git 是另外一个团队开发的,这个开发团队就是 gitforwindows.

何不试试开发版

Git SCM for Windows官网提供两种版本,一个就是平时使用的发布版本,另一个就是开发版本.

既然发布版本没有提供包管理工具,自然我们只能寻求开发版本的帮助.

• 跳转到开发版本的下载地址 https://github.com/git-for-windows/build-extra/releases/tag/git-sdk-1.0.7,下载适合自己系统的版本.
  

  
  

• 双击 git-sdk-installer-1.0.7-64.7z.exe 进行自动安装,安装时间相当长,没有一两个小时也得有小上午时间,安装期间可以接着做其他事情.
  

  
  

• 安装完毕后可以进行自我测试,验证开发板是否比发布版更大更强.
  

  
  

小试牛刀,应有尽有, tree 和 wget 等命令全都有!

千呼万唤始出来

gitforwindows 主要是由 msys2 和 mingw 等众多组件二次开发而来的 windows 版本的 git.

msys2 和 mingw 都是一种在 windows 系统上打造 linux 运行体验的解决方案,其中 msys2 是在 msys 基础上重构开发的项目,而 msys2 项目默认提供有包管理工具 Pacman.

因此, gitforwindows 也可以使用 Pacman 包管理工具进行依赖安装.

如需查看官方解释请查看 : https://github.com/git-for-windows/build-extra

• 什么是包管理工具

现代软件开发需要一种管理依赖关系的方式,即跟踪所需的软件库及其版本.

例如,适用于 Linux的 apt-get 或者 yum,适用于 MacOSX 的 homebrew,适用于 windows 的某些第三方工具.

GitforWindows 基于 MSYS2，它捆绑了 ArchLinux 的 Pacman 工具,因此接下来我们的包管理工具就是 Pacman.

• 如何使用包管理工具

如需在命令行中查看帮助文档,支持 manPacman 和 Pacman--help 两种方式.

1. $ Pacman --help

2. 用法: Pacman <操作> [...]

3. 操作:

4. Pacman {-h --help}

5. Pacman {-V --version}

6. Pacman {-D --database} <选项> <软件包>

7. Pacman {-F --files} [选项] [软件包]

8. Pacman {-Q --query} [选项] [软件包]

9. Pacman {-R --remove} [选项] <软件包>

10. Pacman {-S --sync} [选项] [软件包]

11. Pacman {-T --deptest} [选项] [软件包]

12. Pacman {-U --upgrade} [选项] <文件>

13. 使用 'Pacman {-h --help}' 及某个操作以查看可用选项

• 安装第三方包

1. # 下载默认版本

2. pacman -S <package-name>

3. # 下载最新版本

4. pacman -Sy <package-name>

• 升级第三方包

1. # 升级到最新版本

2. pacman -Syu <package-name>

3. # 全部升级到最新版本

4. pacman -Syu

• 删除第三方包

1. # 删除第三方包

2. pacman -R <package-name>

• 列出第三方包

1. # 列出已安装的第三方包

2. pacman -Q

3. # 列出第三方包的内容

4. pacman -Ql <package-name>

5. # 查明文件属于哪一个包

6. pacman -Qo <file-name>

轻松扩展 git bash 总结

git bash 作为 windows 电脑上使用的 git 命令行工具,确实很方便,不仅支持 git 命令还支持常见的基本命令.

但 git bash 命令行并不能完全替代 cmd,是因为 windows 系统版本的 git 并不是真正的 git,而是由 gitforwindows 组织进行移植开发的特供版.

gitforwindows 项目借鉴了 msys2 和 mingw 等项目,旨在于打造类似于 linux 的运行环境,以便 git 所需的脚本命令能够正常运行.

同时为了 git 服务的精简, gitforwindows 的发布版移除了很多不必要的开发组件,其中就包括 msys2 的包管理工具 Pacman.

所以,平时使用的 git bash 由于没有包安装工具,所以不能轻松扩展更多命令,如果想要扩展更多命令,这里提供了两种思路.

一种思路是直接放弃,寻找新的替代方案,推荐的替代方案是 babun ,因为 babun 和 gitforwindows 血缘相近!

另一种思路就是源码开发,不论是直接在源码工具运行还是再次打包重新编译成发布版都可以扩展更多自定义命令,不过开发版的要求更高,需要了解 msys2 和 mingw 等诸多概念,这里就不再赘述了.

实际使用 git 的过程中,如果真的遇到了需要扩展更多命令的情况,请参考方法一,方法二和方法三依次尝试,因为难度系数逐步加大,找到适合自己的解决方案才是好方案.

最后,感谢大家的阅读,如果觉得本文对你有所帮助或者你有别的想法,欢迎留言评论告诉我,谢谢!

本文作者：雪之梦技术驿站，你在互联网的路上匆匆而来，雪之梦技术驿站助你满载而去。

声明：本文为 脚本之家专栏作者 投稿，未经允许请勿转载。

长按扫码赞赏我