@wizardoz 很多相关领域的新手都会遇到类似的场景，至少在我刚工作时，也遇到过几次特别想找人帮忙的情况，但找不到人，最后费了很多精力和时间自己搞定的。

@zcljy 这个是免费问答平台，先不说对英语不好的用户不友好，时效性等方面也很难有保障。

@runapp WSL 是不支持 traceroute 的

@goreliu

链接发错了，那个链接是去年的……

v2ex Windows 区第二个帖子是昨天新发的，现在贴不了链接了。

@goreliu 补充一下，之前用的手机，没法发图片。

wsl-terminal 用的是 mintty，复制粘贴相关的功能是比较全面的。

http://wx4.sinaimg.cn/large/487ed681ly1fjnj2awft7j20k40fmaad.jpg

支持选择时复制、复制富文本。可以配置鼠标右键或者中键粘贴，也可以配置右键菜单粘贴。

我之前在 V2EX 发过一个介绍 wsl-terminal 的帖子：

https://neue.v2ex.com/t/300618#reply54

最近几天更新了很多功能：
https://www.v2ex.com/t/391405

@yyfearth 如果是在 /mnt/* 下，双方对文件的操作都没有问题。如果是其他目录，Windows 下新建的文件，WSL 中看不到，但对已经存在的文件读写都是没问题的（官方不建议写）。

Win 10 的话可以用 wsl-terminal，https://goreliu.github.io/wsl-terminal/

@Rabbit52 较早的时候用过一阵，感觉功能很多很杂，但很少有我真正想要的功能，不够简洁，小问题比较多。另外我用的时候对 WSL 的支持不佳（比如不能输入中文，中文的显示也有问题），体积和资源占用也更大一些。

@bbsteel 很多人用 awk 和 sed 是上网搜代码然后直接粘贴，过一阵可能自己就不认识了，然后再搜命令是什么意思就不好搜了。事实标准没有什么意义，该出问题照样出问题。

@wweir 那不如交互用 zsh，写脚本用 bash，我以前就是这样用的。

@wweir 其实写 bash 用了一些比较进阶的语法，或者用了些 awk、sed 等命令的复杂用法，别人看不懂，也是一样的，而且解释起来更加麻烦。Shell 确实不适合写大东西，zsh 也是如此，把自己擅长的事情做好就很好了。如果 zsh 不兼容 bash 的话，用的人就会更少了，没人用的话其他的都就谈不上了。

@lozzow 这一点确实如此，但如果真想用的话，还是有很多办法的。

不是必须重启，需要的模块重新 insmod 下就行了，可以写个脚本。

一个版本就开个新帖子不大好不，另外我想请教下 x64, amd64, x86_amd64 这三个有啥区别。

一个例子：

## drool

drool 简介

### Markdown 存在的问题

1. aaa
2. bbb

### droop 的优势

1. aaa
2. bbb

### 效果演示

### 使用方法

### License

MIT


首先要把提纲列好，需要写几项内容，它们之间的递进关系。然后把具体的内容按合理的形式组织好。然后再考虑怎么断句能让内容呈现得更美观。最后考虑加亮某些关键内容等细节。这些不是只看 Markdown 的语法就可以掌握的。可以多看下一些软件主页的介绍、文章等。当你掌握了这些，才会真正发现 Markdown 的痛点，然后才可能提出切实可行的解决办法，需要循序渐进。

@dou4cc 如果要用一个列表，那么需要让别人清楚这个列表是在说什么事情。比如：

drool 解决了如下问题：
- aaa
- bbb

如果我对这个主题没兴趣，就直接跳过这一段。

排版是让文字更容易被别人理解，如果不能达到这个目的，那么排版就没有什么意义了。

简单提个建议吧，主页的 README 还是整理一下格式吧，这个 README 怎么也看不出是一个会用 Markdown 的人写出来的。然后就只能关掉走人了。

然后谈一下如何解决这些困扰：
1. 找一个文件，因此翻遍了整个 D 盘
2. 为按用途还是时间整理文件而选择困难
3. 同一个文档在硬盘里放得到处都是
4. 因为程序对路径名的依赖，不能修改为更合适的名字
5. 把 office 文件命名为 111/222/aaa/最终修改版，以保存历史版本
6. 不小心覆盖了旧文件，无从恢复
7. 给文件添加元信息，副作用是新旧文件不一致

1. 为什么找一个文件需要翻遍整个 D 盘，显示是放文件时没有有章可循的规则。如果 D 盘下全是 aaa 、 bb 、一些资料、 good 这样没有意义的目录名，那么怎么可能快速找到。如果按照既有的规则创建目录名，比如 文本、图片、音频、视频，我总不会去图片目录里找视频文件吧，又何谈翻遍整个 D 盘？

2. 那图片举例，很多人是有这个困扰。比如图片可以按拍摄地点、人物分类，也可以按时间、相机镜头分类。那么最好的办法就是用专门的图片管理软件。音乐、视频也是如此。唯一不大好处理的就是文档类（包括 Office 文件、 pdf 文件等），但这类文件也有特点，一般以按用途分类为主，如果想按时间找，可以按时间搜索，基本上也是不存在什么大问题的。如果需求更多，也有专门管理文档的软件。

3. 这个问题其实就是问题 1 和问题 2 的另一种描述，解决了前两个问题，这个问题也就不复存在。

4. 这个是程序的设计问题，或者说是软件开发规范的问题，怎么也赖不到文件系统层面上来。

5. 这个是软件自身的设计问题。如果一类文件是非常依赖版本的，那么它可以自己实现版本控制，就像图片里的图层似的，每次打开的时候都可以选择打开之前的某个版本。这同时也解决了文件分发的问题。在文件系统层面解决的话，文件分发就很难解决了，因为这个问题不是文件系统改解决的。当然如果一定要文件系统来解决的话，现在 Windows 已经有文件版本的功能了，可以直接使用，如果信不过这个功能而不去用（很多人宁愿自己改名字，也不想用 Windows 自带的文件版本功能），就是另一回事了。还有一种方案，是用 git 之类软件专门管理文件版本，如果是我的话，我会选择这种方法，它同样不依赖文件系统的实现，而且只文件分发上也没有问题（甚至解决了文件的网络同步问题），使用成本也不是很大。

6. 这个问题同 5 ，不赘述。

7. 不知道这里的元信息指什么，如果是标签之类，同问题 2 。如果是备注之类，那么备注不应该放到文件内容中吗？

综上，我感觉这些困扰没有一个是需要在文件系统层面解决的，归罪于文件系统实在是很冤。当然这些现有的解决方式未必合理，如果楼主想在软件层面解决，我是非常支持的。但如此“架空”一番就只能被别人当笑话看了。