Ubuntu中文论坛

我遇到过一个人，他的unix服务器很陈旧，缺少很多有用的工具，想把一个文本去掉行尾的^M，这时候就用到管道了
cat -v file|sed 's/\^M//g'

goodluck1982 写了：多谢LS的支持！

其实我发帖的出发点是：好多新手一开始就看到满眼的 cat .. | grep ...，根本不知道grep是可以直接用的！这对初学者是很不利的。

呵呵，好久了，

其实吾跟倾向于用重定向。感觉，重定向，可以更省时间。
g xxx < yyy

cat可以做些预处理，比如加上行号什么的，有不少参数很实用。
不同的工具可以完成相同的工作，个人喜好也有关系吧

我用grep从来都是跟在管道后面, 所以, 懒得记其它用法...

*nix下每个命令都有太多的参数, 我选择不全记, 只要能达到我的目的就行...

lz都好久没来了，等回来了再发表观点.. XD

学习了，尽管不太明白……

goodluck1982 写了：

greco 写了：只感觉语义比较清晰， cat 什么 然后 grep 什么

我觉得直接 grep什么 语意最清晰！
反而加了 cat什么 ，容易让人迷惑，这个cat到底是干什么地？

这是一个逻辑习惯，比如ls、ps等命令习惯上用管道和grep链接。cat也这么用了。这样对脑子记忆命令有好处。这是合法的理由吧。

goodluck1982 写了：我以前也是用 wq 的
但自从知道了 x 后
就很少再用 wq 了
我比较追求简洁的东西

而且即使是在脚本里用grep，cat+管道所带来的效率提升
对最常见的任务来说也是完全可以忽略的

这个说是个人习惯你就不服气，硬说别人的习惯是不好的。

脑子里少记忆一点东西绝对是简洁的一个方面。看每个人的思维习惯了。你说少打一个字母就是“简洁“？

个人的一点理解

用管道的理由：
并不是所有命令都接受文件输入，但是只要某个程序支持标准输入输出就能使用管道（不支持标准输入输出但支持利用参数指定文件也可以使用管道），它几乎能让任意两个程序进行沟通，这很方便！
对程序员来说，处理标准输入输出(stdin,stdout)更熟悉也更方便，当然也可以用freopen()之类的方法重定向一下，之后用处理stdin和stdout相同的函数，但是在看不到上下文的情况下，比较容易搞混
另外从命令上来说，cat xxx | grep yyy 语义非常明确，将cat xxx的输出 作为 grep yyy 的输入，而grep yyy xxx 则没那么明确了，你需要对程序参数的顺序非常清楚才可以，可惜程序参数顺序是没有任何标准的（有些大家都爱用的习惯或者规则，但并不是所有程序员都爱遵守规则XD），有的files参数在options之后，而有的可以在前。而且处理程序参数是个dirty job...
另外，还有个灰常NB的应用，我们可以wget一个远程主机上的文件，将内容输出到标准输出，这样就可以通过管道来给程序传递远程主机上的文件内容。这样使用起来就很灵活了。

不用管道的理由：
不用新建process，省掉了部分资源开销（但是这个开销实际上只有装载的开销）

另外，用管道并不是等前个命令执行完毕后再传给后面的命令，这很好理解，如果cat一个1G的文件，难道要全部保存在内存里再输入到其他程序？？ 如果这样，效率将异常底下，实际上管道里只要有输入了，后面的程序就会读取并处理（当然两这个操作不能同时执行，写入时管道会被锁住，写入完毕后解锁，读取也是一样，这属于进程同步的范畴了）。

这个习惯的确不好，但是ee说的差别也是存在的。我以前也遇到过，具体问题具体分析吧。

学习了，长久下来习惯了用吸管吃饭

<、<<、cat 转文件为流所必须，>、>> 转流为文件所必须，tee 分流所必须，| 导流所必须……众过滤器则在川流之间，各司其职无可替代。
grep 本就以其过滤器身份登场，初识 grep 只知其流处理能力，不知其能处理文件，转文件为流再传之，很是自然。
cat file | grep key 中规中矩，grep key file 巧用其器。两种对比，习惯任何一种都无所谓好坏，只要不误事便无可非议！常常偏激地否定某种习惯才是很不好的思维习惯！

还有。
单个文件不要cat xxx | less

直接less xxx。我当初也是被先人的cat xxx | xxx误导了好久


cat我的理解还是用来合并多个文本的