add homebrew fish shell support

[Word2VecT]

No description provided.

[ccmywish]

@Word2VecT 非常感谢你的贡献 👍

Happy changing source~

[Word2VecT]

@ccmywish 事实上这是我第一次参与开源项目的贡献，我觉得很有意思和有意义！也对您表示感谢！

事实上，还有一个问题，这可能存在于之前的代码。

由 README 文件可以看到

存在绿色的命令运行成功提示

但是在我未修改的代码前，Homebrew 换源也是不会产生这样的语句的。

我大概看了看代码，应该是由于 Homebrew 换源是基于修改文件的，调用的函数为 chsrc_append_to_file，而示例调用的函数为 chsrc_run，该函数会调用 log_cmd_result。
但是我认为对于更改文件操作，在 bash，zsh，以及 fish 的文件修改后都输出命令运行成功是必要的，可以看到，现在的 homebrew 换源的输出方式无法将三个文件的操作很明显区分，此外，有命令运行成功的显示也可以与其他换源操作保持一致。

处于简洁性，我认为应该在每个文件的最后一个操作后或者遇到问题后输出运行结果提示，这样可能会有比较复杂的逻辑修改，但也有可能存在相关函数我没有注意到，因此也来寻求您的建议。

[ccmywish]

Hi，@Word2VecT

❤️

很高兴看到你说你是 "第一次参与开源项目的贡献"，chsrc 项目很荣幸能成为你启航的起点。

现在开源项目非常多，眼花缭乱，往往会让刚入行的年轻人眼高手低，心高气傲，非要参与高大上的项目不可。但是看到你对这个问题思考的这么细致，我为你感到高兴，因为一个认真开发的项目的维护工作，真如同柴米油盐酱醋茶，很多小事杂事要处理，这些小事很耗费时间，但是又完整的构建出了这个项目。

输出

关于输出，你可看 chsrc_append_to_file() 的这一行：

https://github.com/RubyMetric/chsrc/blob/main/include/chsrc.h#L1099

也就是说，往文件续写，实际上依然是调用了 chsrc_run() 去执行 echo 命令，但是刻意加上了一个标志 RunOpt_Dont_Notify_On_Success.

再看 chsrc_run() 运行失败时的处理:

https://github.com/RubyMetric/chsrc/blob/main/include/chsrc.h#L1022-L1029

也就是说，运行失败的时候，是会存在明显输出的。

所以，实际上 chsrc_append_to_file() 的设计就是：成功时不输出 运行成功，只有失败时才输出 运行失败。

上述的标志位其实是我后来刻意加上去的。原因在于：Homebrew 的这个换源调用了大量的 chsrc_append_to_file()，实际上就是在调用大量的 echo 命令去往里追加写，如果不加这个标志位，就会输出非常多的 “运行成功”，以至于无法区分 ~/.zshrc 和 ~/.bashrc 这两个不同文件的续写过程了。

改进

其实最好的改进方法是使用C语言标准库的函数，如 fwrite() 等直接往这个文件里续写，而不是去额外调用 echo 命令，当时纯属是因为 echo 实在是太容易实现了，更重要的是Windows也支持echo命令，所以就一直保留到现在。

如果你有兴趣完全用C语言实现替换，也欢迎你进行贡献。

[ccmywish]

另外，chsrc 项目尊重每一位贡献者的参与，请你留下你的贡献信息在：

具体的换源文件：https://github.com/RubyMetric/chsrc/blob/main/src/recipe/ware/Homebrew.c#L5

和项目主文件：https://github.com/RubyMetric/chsrc/blob/main/src/chsrc.c#L14

建议不要用昵称。你可以参考比较出名的大型项目，贡献者的提交信息都是用全名真名。

[Word2VecT]

@ccmywish 谢谢您的鼓励！因为这是我第一次参与开源贡献，很多注意事项不太清楚，请谅解～ 我将会改正。

上述的标志位其实是我后来刻意加上去的。原因在于：Homebrew 的这个换源调用了大量的 chsrc_append_to_file()，实际上就是在调用大量的 echo 命令去往里追加写，如果不加这个标志位，就会输出非常多的 “运行成功”，以至于无法区分～/.zshrc 和～/.bashrc 这两个不同文件的续写过程了。
我也考虑到了您说的，因此我的想法是在修改完 zshrc 后输出运行结果，修改 bashrc 后再输出，这样就可以把不同文件的修改分开了，现在的排版貌似也有点问题，目前 bashrc 文件的备份与 zshrc 的文件修改操作是连在一起的，这看起来有点奇怪。不知道您如何看？

将 C 语言完全替换是指用 fwrite() 等 C 语言的函数，而不使用 echo 吗？这样的话会有什么好处呢？

此外我还有两个问题：

1. 为什么默认是选择替换 zshrc 且不进行判断，是考虑到 MacOS 的默认 shell 是 zsh 吗？但我感觉这并不绝对，macOS Catalina 后默认终端才是 zsh，之前是 bash，Linux 上也能使用 Homebrew，因此是否有必要对 zshrc 的存在性进行判断？还是有其他原因？
2. 有些指令是 shell 间不通用的，比如 set 只能在 fish shell 中执行，其功能与 zsh 与 bash 中的 export 相似，但 export 并不能在 fish 中执行，是否支持直接运行相关的指令？还是说正是因为不支持才采用修改文件的方法？

[ccmywish]

排版

目前 bashrc 文件的备份与 zshrc 的文件修改操作是连在一起的，这看起来有点奇怪

是的，所以应该在下图 1 的位置加一个空白行。这样很简单就分割开两个文件了，新加入的 fish shell 也是，可以加一个空白行

现在的排版貌似也有点问题

你指的应该是上图 2 那一个看似多余的空白行。那个正是 echo 带来的坏处之一。因为那一行是为了续写到 ~/.zshrc 或 ~/. bashrc 时，与其它环境变量隔开。echo 是把所有字符串，包括这一个空行都输出都终端上了，所以就看起来排版有问题

fwrite 的好处

所以用 fwrite()

1. 可以解决上面那个 echo 带来的排版问题
2. echo 毕竟是在命令行上执行的，非常怕遇上需要非常多转义从而根本无法处理的情况
3. fwrite() 可以一次性写完，不用多次 echo

后两个问题

1. 默认选择使用 .zshrc 是因为，

   1. Homebrew 的主要用户依然是 macOS 用户，Linux用户虽然能用，但是用的毕竟很少
   2. 苹果主推 zsh，而不是 bash。我现在手头上没有 mac，但是我之前用的时候发现 macOS 上的 bash 已经非常老了，苹果似乎很久不更新了，你可以查一下版本

2. 第二个问题

chsrc 最后都用的是 system() 来执行命令，而 system() 不会调用 Fish，Zsh，连 Bash 也不会调用，只会调用 sh. 所以，特殊的 Shell 内嵌的指令都不能用。我不知道 fish shell 的 set 会不会写入到 config 文件里，按你的意思可能是这样，但是 bash, zsh 显然没有这样的功能。

chsrc 有一个核心的特征你需要留意，那就是极度的跨平台，这就是为什么选择了C语言。C的跨平台性强过任何其它所有语言。既然有这样的特点，就需要把抽象出来的文件操作函数如 chsrc_append_to_file() 也要实现的跨平台。所以不能依赖个别平台个别软件提供的指令。要实现通用的手段。

[Word2VecT]

@ccmywish 👍！您的回答完美的解答了我的疑惑，我也理解了 chsrc 的设计理念。我愿意用C语言完全重写，我 9 号开学，争取这两天完成，顺便添加并修改相关个人信息。

那是不是修改 chsrc_append_to_file 的实现，改用 fwrite() 即可？还是说写一个另外的函数实现以避免冲突？抱歉我问的问题可能比较低级…… 我还没有学习过软件工程等相关知识，sorry

[ccmywish]

因为已经有一些 recipe 在使用 chsrc_append_to_file() 了，你需要考虑在维持它们调用方式不改变的情况下重写该函数。

就是用 fwrite() 等函数来实现。

chsrc 非常多地方都在体现真正软件工程的实践，比如代码的规范，比如函数的命名，recipe 的拆分。基本上你见到的 chsrc 的每一点，我们都能回答 “为什么”。如果有不懂的地方，首先是照猫画虎，看看已有的代码是怎么写的。

希望这次任务，你将能有所收获，并在日后学习软件工程的时候，能和这些天的回忆相碰撞。

我重新开了个issue: #76