你在 Ubuntu 下面也是同样的效果。

~ 是 shell 解释的，你在任何一个编程语言里面直接写 open("~/...") 都会定位到 ~ 文件夹。除非你特别处理了，比如 Python 有 os.path.expanduser("~/...") 就能解释 ~ 了。

所以在任何配置文件里面都不要写 ~。在写 shell 脚本的时候也要千万注意不要把 ~ 放到单引号里面，因为 shell 不会解释单引号里面的东西。

@xuegj1010 所以你能不能把整个代码发上来，包括怎么产生这两个变量的。。。

你的 agentman 怕不是一个迭代器。迭代器遍历完了就消耗完了，不会自动重启的。

你下面的小例子，bg() 每次都产生了一个新的迭代器。所以可以重复遍历。

别的客户端我不知道，我惯用
Spark，感觉不错。

假的，脸滚键盘写出来的。

@huangyizheng 全盘倒其实挺好的，只要能出现初次配置的界面。不然你怎么远程傻瓜式安装呢

每个人有各自需求吧，比如我科班出身，用 VHDL 写过简易版 CPU，也在教学班内核上写过内存管理、进程调度、文件系统的代码，Linux 也折腾过几年，现在已经不想在这种事情上浪费时间了，淘宝找人装一个能用就好

Flask 竟然集成了数据库？现在怕不是 8102 年。

别整 Markdown 了那个先天缺陷严重。我现在是 OneNote + git 管理的 LaTeX，前者是小笔记，后者是整理过的专题笔记。网页剪辑几年前用过，但后来发现其实没用，剪了一堆从来不会去看的。该掌握的立刻就掌握了，没掌握的剪辑了也没用。而立刻掌握的唯一途径是立刻思考，立刻整理，立刻融入自己的笔记里面

@zhicheng 快排本来就是模板级别的算法。别人考信息奥赛的，初中就人人背得的东西，为啥成年程序员背不得？

工程性毕设的论文思路：

1、为什么做这个项目，以及别人工作的对比。这段至少一千五能写得出来吧？多写点三千五千都不成问题。
2、整体的设计思路。包括技术选型的理由（和别的技术的对比），划分哪些顶层组件。这个至少两千字写得出来的吧？放点设计图，五页撑得起来吧？问我怎么画图，朴素一点的用 PowerPoint，高端一点的 Visio。Mac 用 Omnigraffle。
3、分组件阐述详细设计。放点 UML 图，放点伪代码，十页二十页都没问题。
4、评测，包括性能测试、功能测试、用户体验调查。这个也至少五页凑的出来吧？
5、总结，未来工作的展望。也不强求了，一千字搞得出来吧？

所以楼主到底怎么才憋不出来字数的？！

我印象中纯工程性的毕设，只要把项目整个详细地描述一遍，重要部分贴点伪代码，然后放点 UML 图，分分钟上万字、几十页的节奏。

楼主你竟然撑不起场面，你到底写了多少行代码的项目？

恕我直言，我觉得 node_modules 这么庞大的原因主要还是人的问题：

1、依赖分开来管理是好事，解决版本冲突，降低了引入一个依赖的代价。但这导致 Node 社区发布库不再“谦逊”，随便一个小功能就能开个库，并且随便一个项目就几十个库引用过去。这是人的问题。
2、npm install -s 让人根本不用手工编辑 package.json。这本来是好事，比起 pip 还要手工写 requirements.txt 。但是手工写的肯定比自动产生的要精简得多啊。

写 Python 项目的时候，我时不时删掉不再引用的库、尽可能避免引入库、只写直接引用的库，都是常事。虽然麻烦，但是习惯了之后，还是挺顺的流程。什么 pip freeze，是邪道，这种库除非是终端产品，不然谁敢去用？

由于工具链的落后性，才形成了社区对待依赖库的谨慎态度。我觉得 Node 工具链不错，但是社区还是缺这么一个态度的。

买彩票的期望收益很容易算。买域名没法算。所以你没法严谨地证明买域名从期望上是亏钱的。