仓酷云

标题: 带来一篇Unix的缺点 [打印本页]

作者: 深爱那片海    时间: 2015-1-15 22:16
标题: 带来一篇Unix的缺点
看不懂man文档的人.在linux中,命令可分为系统基本命令和应用程序命令.系统基本命令是所有的unix类系统都支持的命令,走到哪都不变,只要是unix类系统上就肯定有.
  我想经由过程这篇文章注释一下我对Unix哲学实质的了解。我固然指出Unix的一个计划成绩,但目标并非冲击人们对Unix的乐趣。固然Unix在基本观点上有一个挺严峻的成绩,可是经由多年的开展以后,这个成绩生怕已被各类其余要素所填补(好比大批的人力)。可是假如入手下手无视这个成绩,我们大概就能够迟缓的改良体系的布局,从而使得它用起来加倍高效,便利和平安,那又何尝不成。同时也但愿这里对Unix命令实质的论述能匡助人敏捷的把握Unix,天真的使用它的潜力,制止它的弱点。



  一般所说的“Unix哲学”包含以下三条准绳[Mcllroy]:
  这三条准绳傍边,前两条实在早于Unix就已存在,它们形貌的实际上是程序计划最基础的准绳——模块化准绳。任何一个具有函数挪用的程序言语都具有这两条准绳。简言之,第一条针对函数,第二条针对换用。所谓“程序”,实际上是一个叫"main"的函数(详见下文)。
  以是只要第三条(用文本流做接口)是Unix所独有的。下文的“Unix哲学”假如不加润色,就特指这第三条准绳。可是很多的现实已显现出,这第三条准绳实在包括了本色性的毛病。它不仅一向在给我们打造无需有的成绩,而且在很年夜水平上损坏前两条准绳的实行。但是,这条准绳却被良多人奉为崇高。很多程序员在他们本人的程序和协定里大批的利用文本流来暗示数据,激发了各类头痛的成绩,却对此置若罔闻。
  Linux有它优于Unix的刷新的地方,可是我们必需看到,它实在仍是承继了Unix的这条哲学。Linux体系的命令行,设置文件,各类工具之间都经由过程非尺度化的文本传播递数据。这形成了信息格局的纷歧致和程序间合作的坚苦。但是,我如许说其实不即是Windows大概Mac就做得好良多,固然它们对此有所改善。实践上,几近一切罕见的操纵体系都遭到Unix哲学耳濡目染的影响,以致于它们身上或多或少都存在它的暗影。
  Unix哲学的影响是多方面的。从命令行到程序言语,到数据库,Web……盘算机和收集体系的各个方面无不显现出它的影子。在这里,我会把浩瀚的成绩与它们的本源——Unix哲学相干联。如今我就从最复杂的命令行入手下手吧,但愿你能从这些最复杂例子里看到Unix实行命令的历程,和个中存在的成绩。(文本流的本色就是字符串,以是鄙人文里这两个名词通用。)
一个Linux命令运转的基础历程

  几近每一个Linux用户都为它的命令行狐疑过。良多人(包含我在内)用了好几年Linux也没有完整的把握命令行的用法。固然看文档看书觉得都看破了,到时分仍是会呈现稀里糊涂的成绩,偶然乃至会泯灭泰半天的工夫在下面。实在假如看破了命令行的实质,你就会发明良多成绩实在不是用户的错。Linux遗传了Unix的“哲学”,用文本流来暗示数据和参数,才招致了命令行难学难用。
  我们起首来剖析一下Linux命令行的事情道理吧。下图是一个很复杂的Linux命令运转的历程。固然这不是全历程,可是更详细的细节跟我如今要说的主题有关。



  从上图我们能够看到,在ls命令运转的全部过程当中,产生了以下的事变:
  从下面的命令运转的过程当中,我们能够看到文本流(字符串)在命令行中的广泛存在:

  接上去你会看到如许的做法引发的成绩。
冰山一角

  在《Unix仇恨者手册》(TheUnix-HatersHandbook,以下简称UHH)这本书开首,作者枚举了Unix命令行用户界面的一系列罪行,咋一看还觉得是性情欠好的初学者在叱骂。但是细心看看,你会发明固然立场欠好,他们某些人的话内里有十分深入的事理。我们老是能够从骂我们的人身上学到一些器材,以是细心看了一下,发明实在这些命令行成绩的本源就是“Unix哲学”——用文本流(字符串)来暗示参数和数据。良多人都没无意识到,文本流的过分利用,激发了太多成绩。我会在前面列出这些成绩,不外我如今先举一些最复杂的例子来注释一下这个成绩的实质,你如今就能够本人下手试一下。
  你看到甚么了呢?你没有给ls任何选项,文件却出人意表的以“长格局”列了出来,而这个列内外面却没有你方才创建的谁人名叫"-l"的文件。好比我失掉以下输入:
  1. -rw-r--r--1wywy02011-05-2223:03bar.c-rw-r--r--1wywy02011-05-2223:03foo.c
复制代码
  究竟产生了甚么呢?重温一下下面的表示图吧,出格注重第二步。本来shell在挪用ls之前,把通配符*睁开成了目次下的一切文件,那就是"foo.c","bar.c",和一个名叫"-l"的文件。它把这3个字符串加上ls本人的名字,放进一个字符串数组{"ls","bar.c","foo.c","-l"},交给ls。接上去产生的是,ls拿到这个字符串数组,发明内里有个字符串是"-l",就觉得那是一个选项:用户想用“长格局”输入文件信息。由于"-l"被以为是选项,就没有被列出来。因而我就失掉下面的了局:长格局,还少了一个文件!
  这申明了甚么成绩呢?是用户的错吗?妙手们大概会笑,怎样有人会这么傻,在目次里创建一个叫"-l"的文件。可是就是如许的立场,招致了我们对毛病置若罔闻,乃至让它发扬光年夜。实在撇除内心的自卑感,从感性的概念看一看,我们就发明这统统都是体系计划的成绩,而不是用户的毛病。假如用户要上法庭状告Linux,他能够如许写:
  1. 告状状被告:用户luser原告:Linux操纵体系事由:条约纠葛1、原告的文件体系给用户供应了机制创建如许一个叫"-l"的文件,这暗示被告有权利用这个文件名。2、既然"-l"是一个正当的文件名,而"*"通配符暗示婚配“任何文件”,那末在被告利用"ls*"命令的时分,原告就应当像被告所希冀的那样,以一般的体例列出目次下一切的文件,包含"-l"在内。3、可是实践上被告没有到达他以为天经地义的了局。"-l"被ls命令以为是一个命令行选项,而不是一个文件。4、被告以为本人的正当权益遭到侵占。
复制代码
  我以为为了免除义务,一个体系必需供应实在的保证措施,而不但是行动上的商定来请求用户“当心”。就像假如你在街上挖个年夜洞施工,必需放上路障和警示灯。你不克不及只插一面小旌旗在那边,用一行小字写着:“后方施工,成果自信。”我想每个一般人城市判断是施工者的毛病。
  但是Unix关于它的用户却一向是像如许的施工者,它请求用户:“细心看manpage,不然成果自信。”实在不是用户想偷懒,而是这些条目太多,基本没有人能记得住。并且没被咬过之前,谁会往看那些偏远的内容啊。可是一被咬,就忏悔都来不及。完成一个复杂的义务都必要晓得这么多大概的圈套,那加倍庞大的义务可怎样办。实在Unix的这些小成绩累加起来,不晓得让人泯灭了几可贵的工夫。
  假如你想加倍确信这个成绩的伤害性,能够尝尝以下的做法。在这之前,请新建一个测试用的目次,以避免丧失你的文件!
  你会发明最初只剩下一个文件:"-rf"。原本"rm*"只能删除一般文件,如今因为目次里存在一个叫"-rf"的文件。rm觉得那是叫它举行强迫递回删除的选项,以是它把目次里一切的文件连同目次全都删失落了(除"-rf")。
外表办理计划

  岂非这申明我们应当克制任何故"-"开首的文件名的存在,由于如许会让程序分不清选项文件名?但是不幸的是,因为Unix给程序员的“天真性”,并非每一个程序都以为以"-"开首的参数是选项。好比,Linux下的tar,ps等命令就是破例。以是这个计划不年夜可行。
  从下面的例子我们能够看出,成绩的来历仿佛是由于ls基本不晓得通配符*的存在。是shell把通配符睁开今后给ls。实在ls失掉的是文件名和选项夹杂在一同的字符串数组。以是UHH的作者提出的一个意见:“shell基本不该该睁开通配符。通配符应当间接被送给程序,由程序本人挪用一个库函数来睁开。”
  这个计划的确可行:假如shell把通配符间接给ls,那末ls会只看到"*"一个参数。它会挪用库函数在文件体系里往寻觅以后目次下的一切文件,它会很分明的晓得"-l"是一个文件,而不是一个选项,由于它基本没有从shell那边失掉任何选项(它只失掉一个参数:"*")。以是成绩貌似就办理了。
  可是如许每个命令都本人反省通配符的存在,然后往挪用库函数来注释它,年夜年夜增添了程序员的事情量和堕落的几率。何况shell不仅睁开通配符,另有情况变量,花括号睁开,~睁开,命令交换,算术运算睁开……这些让每一个程序都本人往做?这恰好违背了第一条Unix哲学——模块化准绳。并且这个办法并非与日俱增的,它只能办理这一个成绩。我们还将碰到文本流引发的更多的成绩,它们没法用这个办法办理。上面就是一个如许的例子。
冰山又一角

  这些看似微乎其微的成绩内里实在包括了Unix实质的成绩。假如不克不及准确熟悉到它,我们跳出了一个成绩,还会进进另外一个。我讲一个本人的亲自履历吧。我前年炎天在Google练习快停止的时分产生了如许一件事变……
  因为我的项目对一个开源项目标依附干系,我必需在Google的Perforce代码库中提交这个开源项目标一切文件。这个开源项目内里有9000多个文件,而Perforce是云云之慢,在提交举行到一个小时的时分,俄然报错加入了,说有两个文件找不到。又试了两次(特地进来喝了咖啡,打了台球),仍是失利,如许一天就快已往了。因而我搜刮了一下这两个文件,的确不存在。怎样会呢?我是用公司手册上的命令行把项目标文件导进到Perforce的呀,怎样会惹是生非?这条命令是如许:
  1. find-name*.java-print|xargsp4add
复制代码
  它的事情道理是,find命令在目次树下找到一切的以".java"开头的文件,把它们用空格符离隔做成一个字符串,然后交给xargs。以后xargs以空格符把这个字符串拆开成多个字符串,放在"p4add"前面,组分解一条命令,然后实行它。基础上你能够把find设想成Lisp里的"filter",而xargs就是"map"。以是这条命令转换成Lisp款式的伪码就是:
  1. (map(lambda(x)(p4addx))(filter(lambda(x)(regexp-match?"*.java"x))(files-in-current-dir)))
复制代码
  成绩出在那里呢?经由一下战书的狐疑以后我终究发明,本来这个开源项目里某个目次下,有一个叫做"AppLauncher.java"的文件。因为它的名字内里含有一个空格,被xargs拆开成了两个字符串:"App"和"Launcher.java"。固然这两个文件都不存在了!以是Perforce在提交的时分埋怨找不到它们。我告知组里的卖力人这个发明后,他说:“这些家伙,怎样能给Java程序起如许一个名字?也太菜了吧!”
  可是我却不以为是这个开源项目标程序员的毛病,这实在显现了Unix的成绩。这个成绩的本源是由于Unix的命令(find,xargs)把文件名以字符串的情势传送,它们默许的“协定”是“以空格符离隔文件名”。而这个项目里恰好有一个文件的名字内里有空格符,以是招致了歧义的发生。该怪谁呢?既然Linux同意文件名内里有空格,那末用户就有权利用这个功效。到头来因而出了成绩,用户却被叫做菜鸟,为何本人不当心,不看manpage。
厥后我细心看了一下find和xargs的manpage,发明实在它们的计划者实在已意想到这个成绩。以是find和xargs各有一个选项:"-print0"和"-0"。它们可让find和xargs不必空格符,而用"NULL"(ASCII字符0)作为文件名的分开符,如许就能够制止文件名里有空格招致的成绩。但是,仿佛每次碰到如许的成绩老是事后方知。岂非用户真的必要晓得这么多,不寒而栗,才干无效的利用Unix吗?
文本流不是牢靠的接口

  这些例子实在从分歧的正面显现了统一个实质的成绩:用文本流来传送数占有严峻的成绩。是的,文本流是一个“通用”的接口,可是它却不是一个“牢靠”大概“便利”的接口。Unix命令的事情道理基础是如许:

  这个中次要有两个历程:
  编码的貌似很复杂,你只必要任意计划一个“语法”,好比“用空格离隔”,就可以输入了。但是编码的计划远远不是设想的那末简单。如果编码格局没有计划好,解码的人就贫苦了,轻则必要正则表达式才干提掏出文本里的信息,碰到庞大一点的编码(好比程叙文本),就得用parser。最严峻的成绩是,因为勉励利用文本流,良多程序员很随便的计划他们的编码体例而不经由周密思索。这就形成了Unix的几近每一个程序都有各自分歧的输入格局,使得解码成为十分头痛的成绩,常常呈现歧义和搅浑。
  下面find/xargs的成绩就是由于find编码的分开符(空格)和文件名里大概存在的空格相搅浑——此空格非彼空格也。而之前的ls和rm的成绩就是由于shell把文件名和选项都“编码”为“字符串”,以是ls程序没法经由过程解码来分辨它们的究竟是文件名仍是选项——此字符串非彼字符串也!
  假如你利用过Java大概函数式言语(Haskell大概ML),你大概会懂得一些范例实际(typetheory)。在范例实际里,数据的范例是多样的,Integer,String,Boolean,List,record……程序之间传送的所谓“数据”,只不外就是这些范例的数据布局。但是依照Unix的计划,一切的范例都得被转化成String以后在程序间传送。如许带来一个成绩:因为无布局的String没有充足的表达力来辨别别的的数据范例,以是常常会呈现歧义。比拟之下,假如用Haskell来暗示命令行参数,它应当是如许:
  1. dataParameter=OptionString|FileString|...
复制代码
  固然两种器材的本色都是String,可是Haskell会给它们加上“标签”以辨别Option仍是File。如许当ls吸收到参数列表的时分,它就从标签判别哪一个是选项,哪一个是参数,而不是经由过程字符串的内容来瞎猜。
文本流带来太多的成绩

  综上所述,文本流的成绩在于,原本复杂了然的信息,被编码成为文本流以后,就变得难以提取,乃至丧失。后面说的都是小成绩,实在文本流的带来的严峻成绩良多,它乃至制造了全部的研讨范畴。文本流的头脑影响了太多的计划。好比:

  另有良多的例子,你只必要在你的身旁往发明。
甚么是“人类可读”和“通用”接口?

  当我提到文本流做接口的各类坏处时,常常有人会指出,固然文本流不成靠又贫苦,可是它比别的接口更通用,由于它是独一人类可读(human-readable)的格局,任何编纂器都能够间接看到文本流的内容,而别的格局都不是如许的。关于这一点我想说的是:
  以是,文本流的基本就不是“人类可读”和“通用”的关头。真实的关头在于“尺度化”。假如别的的数据范例被尺度化,那末我们能够在任何编纂器,扫瞄器,终端里到场对它们的撑持,完整到达人类和呆板都可轻松读取,就像我们明天读取文本和JPEG一样。
办理计划

  实在有一个复杂的体例能够与日俱增的办理一切这些成绩:
Unix命令行的实质

  固然文本流引发了这么多成绩,可是Unix仍是不会灭亡,由于究竟有这么多的下层使用已依附于它,它几近是全部Internet的顶梁柱。以是这篇文章关于以后情况的一个实践意义,大概是能够匡助人们敏捷的了解Unix的命令行机制,而且勉励程序员在新的使用中利用布局化的数据。Unix命令固然过于庞大并且功效冗余,可是假如你看破了它们的实质,就可以十拿九稳的学会它们的利用办法。简而言之,你能够用一般的编程头脑来注释一切的Unix命令:
数据间接存储带来的大概性

  因为存储的是布局化的数据,任何撑持这类格局的工具都可让用户间接操纵这个数据布局。这会带来意想不到的优点。
  另有良多良多,仅限于我们的设想力。
程序言语,操纵体系,数据库三位一体

  假如main函数能够承受多品种型的参数,而且能够有keywordargument,它能前往一个或多个分歧范例的工具作为前往值,并且假如这些工具能够被主动存储到一种特别的“数据库”里,那末shell,管道,命令行选项,乃至连文件体系都没有需要存在。我们乃至能够说,“操纵体系”这个观点变得“通明”。由于如许一来,操纵体系的实质不外是某种程序言语的“运转时体系”(runtimesystem)。这有点像JVM之于Java。实在从实质上讲,Unix就是C言语的运转时体系。
  假如我们再进一步,把与数据库的毗连做成通明的,即用统一种程序言语来“隐性”(implicit)的会见数据库,而不是像SQL之类的公用数据库言语,那末“数据库”这个观点也变得通明了。我们失掉的会是一个十分复杂,一致,便利,并且壮大的体系。这个体系内里只要一种程序言语,程序员间接编写初级言语程序,用一样的言语从命令行实行它们,并且不必忧虑数据放在甚么中央。如许能够年夜年夜的减小程序员事情的庞大度,让他们专注于成绩自己,而不是体系的外部布局。
  实践上,相似如许的体系在汗青上早已存在过(LispMachine,System/38,Oberon),并且收到了不错的效果。可是因为某些缘故原由(汗青的,经济的,政治的,手艺的),它们都灭亡了。可是不能不说它们的这类体例比Unix现有的体例优异,以是何不学过去?我信任,跟着程序言语和编译器手艺开展,它们的这类复杂而一致的计划理念,有一天会改动这个天下。
写学习日记,这是学习历程的见证,同时我坚持认为是增强学习信念的法宝。以上是我学习Linux的心得体会,希望对大家的学习有所帮助,由于水平有限,本文难免有所欠缺,望请指正。
作者: 深爱那片海    时间: 2015-1-17 17:25
眼看这个学期的Linux课程已经告一段落了,我觉得有必要写一遍心得体会来总结一下这学期对着门课程的学习。
作者: 因胸联盟    时间: 2015-1-22 06:51
一些显而易见的小错误还是用vi改正比较方便。以后的大一点的程序就得在Linux下调试了,因为有的头文件在VC里面说找不到。?
作者: 莫相离    时间: 2015-1-30 23:42
和私有操作系统不同,各个Linux的发行版本的技术支持时间都较短,这对于Linux初学者是往往不够的。
作者: 金色的骷髅    时间: 2015-2-6 17:19
任何人都可以根据自己的喜好来定制适合自己的操作系统,Linux?是抢占式多任务多用户操作系统.
作者: 蒙在股里    时间: 2015-2-17 20:58
对我们学习操作系统有很大的帮助,加深我们对OS的理解。?
作者: 第二个灵魂    时间: 2015-3-5 23:17
现在的linux操作系统如redhat,难点,红旗等,都是用这么一个内核,加上其它的用程序(包括X)构成的。
作者: 分手快乐    时间: 2015-3-12 16:37
笔者五分钟后就给出了解决方法: “首先备份原文件到其他目录,然后删掉/usr/local/unispim/unispimsp.ksc,编辑 /usr/local/unispim/unispimsp.ini,最后重启动计算机
作者: 海妖    时间: 2015-3-12 16:37
随着Linux应用的扩展,出现了不少Linux社区。有一些非常优秀的社区往往是Linux高手的舞台,如果在探讨高级技巧的论坛张贴非常初级的问题经常会没有结果。
作者: 兰色精灵    时间: 2015-3-20 00:56
在系统检测不到与Linux兼容的显卡,那么此次安装就可能不支持图形化界面安装,而只能用文本模式安装等等。




欢迎光临 仓酷云 (http://ckuyun.com/) Powered by Discuz! X3.2