blocks|key|634568|text|我想相当简单的解释是Unix工具只在Unix上可用。然而，绝大多数用户运行的是Windows。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|634569|我记得上一次我尝试安装Nokogiri时，它失败了，因为它不能运行uname+-p。完全没有充分的理由这样做。可以通过运行uname+-p获得的所有信息也可以从Ruby中获得。此外，uname+-p实际上甚至不是Unix，它是一个非标准的GNU扩展，甚至不能保证在Unix上工作，例如，它在几个Linux发行版上完全崩溃。|offset|length|style|CODE|634570|因此，您可以使用Unix并失去90%25的用户，也可以使用Ruby。|634571|entityMap^0|0|X|8|1P|8|2J|8|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]|$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|K|$]]

I guess the rather simple explanation is that Unix tools are only available on Unix. The vast majority of users, however, run Windows.

I remember the last time I tried to install Nokogiri, it failed because it couldn't run <code>uname -p</code>. There was absolutely no valid reason to do that. All the information that can be obtained by running <code>uname -p</code> is also available from within Ruby. Plus, <code>uname -p</code> is actually not even Unix, it's a non-standard GNU extension which isn't even guaranteed to work on Unix, and is for example completely broken on several Linux distributions.

So, you could either use Unix and lose 90% of your users, or use Ruby.

blocks|key|737094|text|它似乎并没有完全迷失。我读到了最近的一篇blog+entry+by+Ryan+Tomayko文章，它强调了UNIX的哲学以及the+Unicorn+HTTP+Server是如何接受它的。然而，他确实有同样的普遍感觉，即ruby社区在总体上忽略了UNIX的哲学。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|737095|entityMap|0|LINK|mutability|MUTABLE|url|http://tomayko.com/writings/unicorn-is-unix|1|http://unicorn.bogomips.org/PHILOSOPHY.html^0|K|Q|0|1Q|N|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

It does not appear to be completely lost. I read a recent entry <a href="http://tomayko.com/writings/unicorn-is-unix" rel="nofollow noreferrer">blog entry by Ryan Tomayko</a> that aggrandized the UNIX philosophy and how it is embraced by <a href="http://unicorn.bogomips.org/PHILOSOPHY.html" rel="nofollow noreferrer">the Unicorn HTTP Server</a>. However, he did have the same general feeling that the ruby community is ignoring the UNIX philosophy in general.

blocks|key|634603|text|我认为，随着Emacs的创建，Unix哲学开始失宠。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|634604|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think that the Unix philosophy started falling out of favor with the creation of Emacs.

blocks|key|737183|text|我投赞成票。主观的，但优秀的编程问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|737184|这只是一段个人趣闻，当时我们正在为保险公司重写一个批量打印输出程序。我们因为在shell中“编程”而被顾问责备。我们意识到它是如何脱节的，语言也是如此的不同以至于不完整。|737185|也许吧。|737186|突然之间，多处理器Intel+boxen变得司空见惯，而fork()在新的应用程序时代(想想VB时代)并没有像每个人总是被警告的那样糟糕。批量打印程序(查询数据库，转换为troff输出，然后通过msgsnd转换为PostScript，然后以数十万计输出到LPD队列)在所有系统上都能很好地扩展，并且在VB运行时发生变化时不需要重写。|offset|length|style|CODE|737187|Perl回答你的问题：我同意Korn先生的观点，但这不是Perl的错，是Perl程序员认为Perl就足够了。在多进程系统中，它可能已经足够好了。|737188|我希望Ruby、Perl、Python甚至Java开发人员都能在shell管道中保持优势。隐式扩展和接口、职责分离和模块化设计的开发哲学具有内在价值。|737189|如果处理得当，随着我们的大规模核心处理单元的出现，Unix哲学可能会再次获得支持。|737190|entityMap^0|0|0|0|2D|5|2P|6|3J|3|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@$H|X|I|Y|J|K]|$H|Z|I|10|J|K]|$H|11|I|12|J|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|14|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|15|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|S|$]]

My vote is yes. Subjective, but excellent programming question.

Just a personal anecdote during a time when we were re-writing a mass print output program for insurance carriers. We were literally scolded by advisors for "programming" in the shell. We made aware how it was too disconnected and the languages were too disparate to be complete.

Maybe.

All of a sudden multi-processor Intel boxen became commonplace and fork() didn't really perform as horribly as everyone was always warned in the new age of applications (think VB days). The bulk print programs (which queried a db, transformed to <code>troff</code> output and then to PostScript via <code>msgsnd</code> and then off to the <code>LPD</code> queue in hundreds of thousands) scaled perfectly well against all the systems and didn't require rewrites when the VB runtimes changed.

To your question:
I'm with Mr. Korn, but it is not Perl's fault, it is the Perl programmers who decide that Perl is sufficient enough. In multi-process systems maybe it is good enough.

I hope that Ruby, Perl, Python, and (gasp) even Java developers can keep their edge in the shell pipeline. There is inherent value in the development philosophy for implicit scaling and interfacing, separation of duties, and modular design.

Approached properly, with our massively-cored processing units on the horizon, the Unix philosophy may again gain ground.

blocks|key|1935305|text|管道和简单工具的Unix哲学是用于文本的。它仍然是相关的，但可能不像以前那么相关了：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1935306|1935307|我们看到越来越多的工具，它们的输出在设计上并不容易被其他程序解析。|unordered-list-item|1935308|我们看到越来越多的XML，在这些工具中，通过筛选器传输文本没有什么特别的好处，而正则表达式则是一场冒险的赌博。|1935309|我们正在看到更多的交互性，而在Unix管道中，信息只是单向流动的。|1935310|1935311|但是，尽管世界发生了一点变化，我仍然同意Korn的批评。创建不能与其他程序互操作的大型、整体式程序绝对是糟糕的设计，无论使用哪种语言。规则一如既往：|1935312|1935313|记住，你自己程序的输出可能是另一个程序的输入。|1935314|如果你的程序处理单一类型的数据(例如，学生提交的代码的性能，这是我上周一直在做的)，请确保对该数据的输入和输出使用相同的格式。|1935315|为了与现有Unix工具进行互操作，输入和输出应该是ASCII码和面向行的。许多IETF+Internet协议(SMTP、NNTP、HTTP)都是编写大程序的标准examples.|1935316|Instead，考虑编写几个小程序通过shell管道与现有程序连接。例如，不久前，xkcd+blog有一个可怕的管道，可以在/usr/share/dict/words.|offset|length|style|CODE|1935317|Work中查找变形词，直到逐渐变成shell脚本，使您的交互式shell也可以用来编写脚本。(我使用的是ksh，但任何与POSIX兼容的shell都是一个合理的选择。)|1935318|1935319|总之，有两种高度相关的重用代码的方法|1935320|1935321|编写的小程序在通过外壳管道连接时能够很好地结合在一起(Unix).|1935322|Write小型库在通过import、#include、load、require或use+(Ruby、C%2B%2B+STL、C+Interfaces+and+Implementations和许多其他)连接时能够很好地结合在一起。|1935323|1935324|在第一个范例中，依赖关系结构很简单(总是线性的)，因此很容易理解，但您可以表达的内容更有限。在第二种范式中，您的依赖结构可以是任何非循环图-更具表现力的图，但这包括创建不必要的复杂性的能力。|1935325|这两种范式仍然是相关和重要的；对于任何特定的项目，您选择哪一个更多地与您的客户和您的起点有关，而不是与该范式的任何内在优点有关。当然，它们并不是相互排斥的！|1935326|entityMap|0|LINK|mutability|MUTABLE|url|http://blog.xkcd.com/2009/04/27/a-problem/|1|http://www.cs.princeton.edu/software/cii/^0|0|0|0|0|0|0|0|0|0|0|0|1Q|L|15|9|0|0|1G|3|0|0|0|0|0|B|6|I|8|R|4|W|7|14|3|1M|W|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1R|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|1S|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|1W|8|@]|9|@]|A|$]]|$1|P|3|Q|5|E|7|1X|8|@]|9|@]|A|$]]|$1|R|3|S|5|E|7|1Y|8|@]|9|@]|A|$]]|$1|T|3|U|5|E|7|1Z|8|@$V|20|W|21|X|Y]]|9|@$V|22|W|23|1|24]]|A|$]]|$1|Z|3|10|5|E|7|25|8|@$V|26|W|27|X|Y]]|9|@]|A|$]]|$1|11|3|-4|5|6|7|28|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|29|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|2A|8|@]|9|@]|A|$]]|$1|15|3|16|5|E|7|2B|8|@]|9|@]|A|$]]|$1|17|3|18|5|E|7|2C|8|@$V|2D|W|2E|X|Y]|$V|2F|W|2G|X|Y]|$V|2H|W|2I|X|Y]|$V|2J|W|2K|X|Y]|$V|2L|W|2M|X|Y]]|9|@$V|2N|W|2O|1|2P]]|A|$]]|$1|19|3|-4|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|2R|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|2S|8|@]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|2T|8|@]|9|@]|A|$]]]|1F|$1G|$5|1H|1I|1J|A|$1K|1L]]|1M|$5|1H|1I|1J|A|$1K|1N]]]]

The Unix philosophy of pipes and simple tools is for text. It is still relevant, but perhaps not as relevant as it used to be:

<ul>
<li>We are seeing more tools whose output is not designed to be easily parseable by other programs.</li>
<li>We are seeing much more XML, where there is no particular advantage to piping text through filters, and where regular expressions are a risky gamble.</li>
<li>We are seeing more interactivity, whereas in Unix pipes information flows in one direction only.</li>
</ul>

But although the world has changed a little bit, I still agree with Korn's criticism. It is definitely poor design to create large, monolithic programs that cannot interoperate with other programs, no matter what the language. The rules are the same as they have always been:

<ul>
<li>Remember your own program's output may be another program's input.</li>
<li>If your program deals in a single kind of data (e.g., performance of code submitted by students, which is what I've been doing for the last week), make sure to use the same format for both input and output of that data.</li>
<li>For interoperability with existing Unix tools, inputs and outputs should be ASCII and line-oriented. Many IETF Internet protocols (SMTP, NNTP, HTTP) are sterling examples.</li>
<li>Instead of writing a big program, consider writing several small programs connected with existing programs by shell pipelines. For example, a while back the <a href="http://blog.xkcd.com/2009/04/27/a-problem/" rel="noreferrer">xkcd blog</a> had a scary pipeline for finding anagrams in <code>/usr/share/dict/words</code>.</li>
<li>Work up to shell scripts gradually by making your interactive shell one you can also script with. (I use <code>ksh</code> but any POSIX-compatible shell is a reasonable choice.)</li>
</ul>

In conclusion there are really two highly relevant ways of reusing code:

<ul>
<li>Write small programs that fit together well when connected by shell pipelines (Unix).</li>
<li>Write small libraries that fit together well when connected by <code>import</code>, <code>#include</code>, <code>load</code>, <code>require</code>, or <code>use</code> (Ruby, C++ STL, <a href="http://www.cs.princeton.edu/software/cii/" rel="noreferrer">C Interfaces and Implementations</a>, and many others).</li>
</ul>

In the first paradigm, dependency structure is simple (always linear) and therefore easy to understand, but you're more limited in what you can express. In the second paradigm, your dependency structure can be any acyclic graph&mdash;lots more expressive power, but that includes the power to create gratuitous complexity.

Both paradigms are still relevant and important; for any particular project, which one you pick has more to do with your clients and your starting point than with any intrinsic merit of the paradigm. And of course they are not mutually exclusive!

blocks|key|2146122|text|不是的。Unix和Ruby还活得很好|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2146123|Unix和Ruby都活得很好，Unix供应商苹果公司的股票正在进入轨道，linux在运行服务器、开发和实验室系统方面有着不可撤销的地位，微软的桌面软件帝国被谷歌等强大的SaaS野人和一大群盟友包围着。|2146124|Unix从未有过如此光明的未来，Ruby是它的关键盟友之一。|2146125|我不确定软件工具模式是不是Unix的一个关键元素。它在当时是很棒的，因为竞争对手的CLI工具一般笨拙，边界毫无价值，但Unix引入了许多其他东西，包括优雅的进程和I/O模型。|2146126|此外，我认为您会发现许多Ruby程序在内部使用各种Unix和软件工具接口。检查popen()和各种处理方法。|2146127|我认为Ruby只是有它自己的影响范围。|2146128|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

<h3>No. Unix and Ruby are alive and well</h3>

Unix and Ruby are both alive and well, Unix vendor Apple's stock is headed into orbit, linux has an irrevocable dug-in position running servers, development, and lab systems, and Microsoft's desktop-software empire is surrounded by powerful SaaS barbarians like Google and an army of allies.

Unix has never had a brighter future, and Ruby is one of its key allies.

I'm not sure the software-tools pattern is such a key element of Unix anyway. It was awesome in its day given the general clunky borderline-worthless quality of competing CLI tools but Unix introduced many other things including an elegant process and I/O model.

Also, I think you will find that many of those Ruby programs use various Unix and software-tools interfaces internally. Check for popen() and various Process methods.

I think Ruby simply has its own sphere of influence.

David Korn, a proponent of the Unix philosophy, chided Perl programmers a few years ago in <a href="http://news.slashdot.org/article.pl?sid=01/02/06/2030205&amp;mode=thread" rel="nofollow noreferrer">a Slashdot interview</a> for writing monolithic Perl scripts without making use of the Unix toolkit through pipes, redirection, etc. "Unix is not just an operating system," he said, "it is a way of doing things, and the shell plays a key role by providing the glue that makes it work."

It seems that reminder could apply equally to the Ruby community. Ruby has great features for working together with other Unix tools through popen, STDIN, STDOUT, STDERR, ARGF, etc., yet it seems that increasingly, Rubyists are opting to use Ruby bindings and Ruby libraries and build monolithic Ruby programs.

I understand that there may be performance reasons in certain cases for going monolithic and doing everything in one Ruby process, but surely there are a lot of offline and asynchronous tasks that could be well handled by Ruby programs working together with other small programs each doing one thing well in the Unix fashion, with all the advantages that this approach offers. 

Maybe I'm just missing something obvious. Is the Unix Philosophy still as relevant today as it was 10 years ago?

Is the Unix Philosophy falling out of favor in the Ruby community?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

几年前，Unix哲学的支持者David Korn在中指责Perl程序员编写单片的Perl脚本，而没有通过管道、重定向等使用Unix工具包。"Unix不仅仅是一个操作系统，“他说，”它是一种做事的方式，而shell起着关键的作用，它提供了使其工作的粘合剂。“似乎提醒也同样适用于Ruby社区。Ruby通过popen，STD...

问Unix的理念是否在Ruby社区中失宠了？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Unix的理念是否在Ruby社区中失宠了？EN