首页 > Unix/Linux, 杂项资源, 轶事趣闻 > 一个空格引发的惨剧

一个空格引发的惨剧

2011年6月20日 发表评论 阅读评论 56,880 人阅读    

你是否相信如果你的程序里没有检查一个变量会导致怎么系统瘫痪?无论你相不相信,这是我一个亲身经历过的案例,你可以在本站的程序员那些悲催的事儿中找到很多这样的事。这样的事昨天在发生,今天同样在发生。Unix40多年了,在这40年里,程序员发生过各种各样的的惨剧,但是大多数的事情一而再再而三的重演。

今天的你,可能在开发者各种各样NB的系统,你会相信你的一个空格也能导致系统瘫痪吗?也许你可能很难相信这个事。不过,再下面这个事将告诉你这个血淋淋的事实 —— 一个空格产生的bug可以让你的系统瘫痪。

bumblebee是一个开源项目,这个名字也就是变形金刚里的大黄蜂,这个项目是这样介绍自己的——

bumblebee is Optimus support for Linux, with real offloading, and not switchable graphics.. More important.. it works on Optimus Laptops without a graphical multiplexer..

Optimus 是NVIDIA的“优驰”技术,其可以将您的笔记本电脑PC提升到绝佳状态,提供出色的图形性能,并在需要时延长电池续航时间。这个项目是把这个技术移到Linux上来。

这个项目本来不出名,不过,程序在其安装脚本install.sh里的一个bug让这个项目一下子成了全世界最瞩目的项目,这个bug的fix如下:

@@ -348,7 +348,7 @@ case "$DISTRO" in
-  rm -rf /usr /lib/nvidia-current/xorg/xorg
+  rm -rf /usr/lib/nvidia-current/xorg/xorg

看明白了吗?空格。这个空格会导致什么样的问题呢?呵呵。你有没有感到菊花一紧?这个bug绝对的霸气外露!真是验证了“如何写出无法维护代码”的那句话——“测试你的程序是一种懦夫的行为”。

不过,最精彩还不是这个bug,而是全世界程序员的对这个bug 的 code review comments,真的相当的欢乐。请强势围望!

https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6#diff-1

重点是其中的很多图片——下面的图片众多。

clip_image001


clip_image002

clip_image007

clip_image010

clip_image011

clip_image012

clip_image014

clip_image016

clip_image019

clip_image020

clip_image021

(全文完)

(转载本站文章请注明作者和出处 酷 壳 – CoolShell.cn ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (13 人打了分,平均分: 4.85 )
Loading ... Loading ...
  1. QQending
    2011年6月20日08:29 | #1

    之前看到了~~笑了我半天~~评论太欢乐了

  2. Johnny
    2011年6月20日08:49 | #2

    评论很给力,呵呵

  3. sixfooter
    2011年6月20日08:56 | #3

    作为程序员, 我很同情这位老兄, 估计自责的死的心都有了。

    不过, 发布之前不安装测试一下, 也实在是…

  4. Neo
    2011年6月20日09:16 | #4

    测试你的程序是一种懦夫的行为!

    悲剧的rm /usr

    哈哈哈

  5. xt
    2011年6月20日09:24 | #5

    测试测试测试!!!…

  6. 2011年6月20日09:25 | #6

    呵呵,看来后面的评论的确比那个bug更有意思。看来用linux要小心啊 备份很重要啊

  7. 2011年6月20日09:36 | #7

    不只空格,一个点也可以引发悲剧(from BDWM)

    rm -rf ./etc

  8. huomosi
    2011年6月20日09:59 | #8

    评论很欢乐啊

  9. 腊月廿八
    2011年6月20日10:02 | #9

    这哥们的太搞了。
    So epic!
    But this is better than rm -rf / usr/lib/nvidia-current/xorg/xorg :)

  10. 2011年6月20日10:06 | #10

    QB: 为了拯救宇宙,我需要你的/usr来阻止热寂
    http://i.imgur.com/VKNmO.jpg

  11. duyt1001
    2011年6月20日10:28 | #11

    让我想起前同事(一个QA)的悲剧,他在rm -rf后习惯性地按了“y“确认,等到他意识到发生什么时,手指已经在往回提了。

  12. autoxbc
    2011年6月20日10:30 | #12

    古人云「君子不立危墙」,又云「瓜田不纳履,李下不整冠」,讲的都是避免使自己处于危险的境地。如果你有一条可以吊死自己的绳子,那么就不要随便打个结挂起来。rm 就是这条绳子,用他妈补全会死么?

  13. btw616
    2011年6月20日10:42 | #13

    @autoxbc
    哈哈哈哈

  14. Tydus
    2011年6月20日11:46 | #14

    这里果然出现了233话说其实最赞的是评论=v=

  15. Tydus
    2011年6月20日11:49 | #15

    Tydus :
    这里果然出现了233话说其实最赞的是评论=v=

    话说那张QB的呢……?

  16. zino
    2011年6月20日12:25 | #16

    McFog :
    QB: 为了拯救宇宙,我需要你的/usr来阻止热寂
    http://i.imgur.com/VKNmO.jpg

    = =

  17. zino
    2011年6月20日13:22 | #17
  18. zino
    2011年6月20日13:23 | #18
  19. y
    2011年6月20日13:51 | #19

    原帖子的评论太搞笑了.:D

  20. Mensch88
    2011年6月20日16:28 | #21

    呵呵,对于rm我也犯过同样的错误,都是一时手快加了个空格。那时候正在维护公司的svn repository,一个rm -rf /svn/ uselessproject 把公司的所有项目给删除了。从此以后每回打rm -rf心里总要哆嗦一下,确保无误之后才敢摁回车。

  21. 2011年6月20日16:47 | #22

    杯具的还有,一个公司的网管手欠,做了个 chmod 777 /* -R ,我勒个去,害的我折腾了30分钟给他修复,那可是他们公司的正在运行的服务器啊…

  22. water
    2011年6月20日18:41 | #23

    问楼上,chomd 777怎么恢复啊,不是一个一个手动改回来吧

  23. 2011年6月21日19:30 | #24

    搞笑

  24. SummerTown
    2011年6月21日20:05 | #25

    这个霸气得不行了,哈哈~

  25. 2011年6月22日11:26 | #26

    笑死我了,霸气啊

  26. 2011年6月22日11:28 | #27

    前天晚上到昨天晚上,无限无法进来。被攻击了?

    • 2011年6月22日16:23 | #28

      没有,因为升级系统硬件,迁移VPS,所以就宕机了老半天。

  27. SueprLucky
    2011年6月22日15:03 | #29

    我是来发广告的:
    BUMBLEBEE, the most famous /usr fucker! Download 4 Free!

  28. 2011年6月22日18:02 | #30

    陈Sir,扯个题外话。关于写代码速度问题。
    我这两天给企业做了个模块,从开始做到按照需求自测通过,花费一天时间。代码行数1K左右的样子。
    请问这个速度是否过于慢了?
    区区大二,想做点真正的东西

    • 2011年6月22日19:11 | #31

      关键不是写多少,关键也不是写多快,重要的是写的代码质量怎么样?不过,如果从最一般的感觉来看,1天写1000行代码算是高产了。

  29. wadefelix
    2011年6月22日19:31 | #32

    陈皓 :
    关键不是写多少,关键也不是写多快,重要的是写的代码质量怎么样?不过,如果从最一般的感觉来看,1天写1000行代码算是高产了。

    绝对的高产啊

  30. 2011年6月22日19:31 | #33

    @陈皓
    我曾经听说,一个“合格”的程序员,每周产量应当是“5000”行。
    而我又听说,一个程序员,每天有效工作时间为4小时(《UML面向对象建模基础》中国水利水电出版社)而实际上我一天写代码或者调试时间大约为16小时
    所以感觉压力很大啊

  31. 2011年6月22日21:52 | #35

    @陈皓
    真的?代码产量不用那么高是吧?
    心理压力一直有点大。。
    当然,也可能是我理解老师和书的意思有所偏差。

    另外,关于统一问题。
    windows环境下,我在使用文件操作的时候,大多数用的是非 windows api里的东西,但个别的东西,比如查看硬盘剩余容量——我实在不知道不用windows api以外还能用什么函数了(只是我不知道,并且没找到,不敢说不存在),所以就使用了GetDiskFreeSpaceEx这个函数。
    而其他比如删除文件什么的,我用的却是 remove()而不是DeleteFile()。而查看文件长度用的是struct stat buffer;
    在软件行业中,是否存在那么一个“潜规则”之类的东西,要求用某个固定系列的函数什么的?
    感觉自己这么做有点乱来啊

  32. 2011年6月23日11:58 | #36

    @Walkerinwind
    我感觉吧:
    1) 如果不是自己得心应手的方式方法,即使照做,而且顺利完成了,也不会有自信的;
    2) 如果是自己的心应手的方式方法,做完一点就多一点自信,即使做坏了,要找出自己的方式方法错在哪里,也会比照搬别人的方式方法来的容易得多,等自己的方式方法被纠正过来了,就更加有自信了。

  33. jnj
    2011年6月23日18:40 | #37

    @Walkerinwind
    我觉得 Walkerinwind 问的这些问题不是技术问题,而是社会经验的问题。Walk君勤学的同时如果能融会贯通,不照本宣科,一定大有作为。

  34. 2011年6月23日22:31 | #38

    rm -rf /usr 好霸气啊………

  35. Lq
    2011年6月24日11:18 | #39

    http://iregex.org/blog/safer-rm-command.html

    #safe remove, mv the files to .Trash with unique name
    #and log the acction
    function rm()
    {
    trash=”$HOME/.Trash”
    log=”/var/log/trash.log”
    stamp=`date “+%Y-%m-%d %H:%M:%S”` #current time

    while [ -f "$1" ]; do

    #remove the possible ending /
    file=`echo $1 |sed ‘s#\/$##’ `

    pure_filename=`echo $file |awk -F / ‘{print $NF}’ |sed -e “s#^\.##” `

    if [ `echo $pure_filename | grep "\." ` ]; then
    new_file=` echo $pure_filename |sed -e “s/\([^.]*$\)/$RANDOM.\1/” `
    else
    new_file=”$pure_filename.$RANDOM”
    fi

    trash_file=”$trash/$new_file”
    mv “$file” “$trash_file”

    if [ -w $log ]; then
    echo -e “[$stamp]\t$file\t=>\t[$trash_file]” |tee -a $log
    else
    echo -e “[$stamp]\t$file\t=>\t[$trash_file]”
    fi

    shift #increment the loop
    done
    }

  36. Justvistor
    2011年6月30日21:56 | #40

    默哀—–
    rm -rf /usr 不知有几人中招

    这让我想起当年在VMware中为Red Hat 9.0升级内核到2.6.20.8,第一次失败后重编译,在/boot下产生一些.old文件,看起来很不顺眼,于是想在/boot下敲入rm -rf *.old,一时手快成了rm -rf *
    当时傻了

  37. ymcheng
    2011年7月13日11:36 | #41

    rm命令害人不浅啊。以前辛苦一天的调试,结果 rm -rf 删错了,真的是欢乐开怀啊

  38. 观云
    2011年7月17日11:49 | #42

    @duyt1001
    话说 rm -rf以后会有提示输入y么?

  39. 2011年7月20日01:29 | #43

    幸亏我有一个习惯
    cd到父目录
    rm -rf 目录

    哈哈

  40. xiong111
    2011年7月28日22:03 | #44

    幸好不是rm -rf / usr/lib/nvidia-current/xorg/xorg
    -_-#!

  41. 2011年7月31日21:30 | #45

    @duyt1001
    rm -rf 还会给你机会按“y”?

  42. Tydus
    2011年8月18日15:17 | #46

    @Mike Ma
    正在养成……半个月前我刚被坑一次……连上adb然后不小心在/sdcard下rm -rf *然后恢复数据耗了我一下午……

  43. Some One
    2011年11月28日14:29 | #47

    @duyt1001
    rf 操作应该提示输入验证码,而不是 Y

  44. stushl
    2012年4月12日13:18 | #48

    ubuntu
    chmod 777 -R /usr
    运行之后发现sudo不能用了,给sudo +s之后可以用了,但认证权限对话框不能用,怎么修复?现在只能在命令行安装程序,ubuntu软件中心不能用

  45. ceofit
    2012年7月23日22:25 | #49

    哥们太搞了。

  46. bombless
    2012年11月29日17:09 | #50

    @Justvistor
    比较经典的其实是rm -rf *>old

  47. 2013年2月5日12:01 | #51

    好吧,我后面的同事把cp /mnt/*.rpm /home/ 打成rm /mnt/*.rpm /home/,结果你懂的。。。关键是每到一个月他又运行了一次,逗死我了。
    我在LFS时在编译最后一个包时,跳到了/usr目录,大家做个LFS应该都知道习惯性的把刚编译过的东西都删掉。所以我rm * -rf 了。结果我编了两天的linux哭了。

  48. 2013年3月13日20:51 | #52

    好吧,我干过这事…

  49. 2013年5月4日15:23 | #53

    楼主,原文的github链接已失效,新链接是这个:https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755cdbe0acce6#diff-1

评论分页
1 2 4875
  1. 2011年6月25日11:57 | #1
  2. 2011年7月5日04:01 | #2
  3. 2011年11月2日22:48 | #3
  4. 2012年3月11日22:22 | #4
  5. 2012年3月24日00:59 | #5
  6. 2012年3月24日19:52 | #6
  7. 2012年12月10日08:35 | #7
  8. 2012年12月10日09:17 | #8
  9. 2012年12月11日00:33 | #9
  10. 2012年12月11日08:40 | #10
  11. 2012年12月11日11:04 | #11
  12. 2012年12月12日13:39 | #12
  13. 2013年1月2日15:11 | #13
  14. 2013年1月9日08:24 | #14
  15. 2013年1月28日03:32 | #15
  16. 2013年2月16日20:25 | #16
  17. 2013年2月24日11:05 | #17
  18. 2013年3月12日23:09 | #18
  19. 2013年4月15日13:16 | #19
  20. 2013年6月4日02:35 | #20
  21. 2013年6月12日14:29 | #21
  22. 2013年8月17日22:24 | #22
  23. 2013年8月28日12:09 | #23
  24. 2013年11月10日16:16 | #24
  25. 2014年2月24日08:12 | #25
  26. 2014年2月24日14:09 | #26
  27. 2014年2月24日16:32 | #27
  28. 2014年2月24日18:23 | #28
  29. 2014年2月25日10:20 | #29
  30. 2014年2月28日12:51 | #30
  31. 2014年6月12日12:44 | #31