Webbench MAC下安装

Webbench是有名的网站压力测试工具,它是由 Lionbridge公司开发。
Webbech能测试处在相同硬件上,不同服务的性能以及不同硬件上同一个服务的运行状况。webBech的标准测试可以向我们展示服务器的两项内容:每秒钟相应请求数和每秒钟传输数据量。webbench不但能具有便准静态页面的测试能力,还能对动态页面(ASP,PHP,Java,CGI)进 行测试的能力。还有就是他支持对含有SSL的安全网站例如电子商务网站进行静态或动态的性能测试。
安装: Make install 需 sudo 权限, 需要写入 /usr/local/bin
- brew install ctags # 依赖安装
- curl -o webbench.tar.gz http://blog.zyan.cc/soft/linux/webbench/webbench-1.5.tar.gz
- tar -zxvf webbench-1.5.tar.gz
- cd webbench-1.5/
- mkdir -pv /usr/local/man/man1 # 关键
- sudo make && sudo make install # sudo 权限因为需要创建文件夹
Mac下自带apache压力测试:
- localhost:webbench-1.5 jesse$ webbench -c 500 -t 120 http://localhost/
- Webbench - Simple Web Benchmark 1.5
- Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
- Benchmarking: GET http://localhost/
- 500 clients, running 120 sec.
- Speed=33001 pages/min, 696314 bytes/sec.
- Requests: 64078 susceed, 1924 failed.
- localhost:webbench-1.5 jesse$
实例化php类的时候如何传参

当我们实例化一个php类的时候,要怎么传递参数呢?这取决于该类的构造方法。
例:
person.class.php
class person{
var $name;
var $color;
var $sex;
var $age;
function __construct($name,$age='',$sex='boy'){
$this->name = $name;
$this->age = $age;
$this->sex = $sex;
$this->color = 'yello';
}
function eat(){
echo $this->name.'要吃饭';
}
function xinxi(){
echo $this->name.' is '.$this->sex.' and age is '.$this->age.' fuse is '.$this->color;
}
}
?>
son.php
include('person.class.php');
$son = new person('cuihua',25,'girl');//此处的参数传递要和类的构造方法里面的参数顺序对应
//$son->xinxi();//cuihua is girl and age is 25 fuse is yello
$son->name = '田妞';
$son->eat();//田妞要吃饭
?>
搞定 koa 之generator 与 co

koa 是由 tj大神利用 generator 开发的 web 框架。要理解 koa,首先要先了解 generator 与 co。作为搞定 koa 的第一篇,我们便谈谈这个。文章首发在boke.io
generator介绍
function* Gene(){
yield 1;
yield 2;
}
var gene = Gene();
console.log(gene.next());//{ value: 1, done: false }
console.log(gene.next());//{ value: 2, done: false }
console.log(gene.next());//{ value: undefined, done: true }
console.log(gene.next());//Error: Generator has already finished 经@Ralph-Wang提醒从 v0.11.13 开始不抛错了,返回{ value: undefined, done: true }
从上面我们可以看到
generator 的定义和函数类似,只是在 function 后面多了一个*
调用generator 和调用函数一样,只是不像函数立即执行,而是会生成一个对象
generator 生成的对象存在一个 next 函数,调用 next 会返回 yield运算的结果对象,并停止。再次调用会在下一个 yield 处停止。
当所有的 yield 被执行完,调用 next 函数会返回{ value: undefined, done: true }。再次调用会报错
generator 与异步
看完 generator 的介绍,你心里回想这跟异步有毛关系?不着急听我接着说
串行请求两个网页的代码
var request = require('request');
var a = {};
var b = {};
request('http://www.google.com', function (error, response, body) {
if (!error && response.statusCode == 200) {
a.response = response;
a.body = body;
request('http://www.yahoo.com', function (error, response, body) {
if (!error && response.statusCode == 200) {
b.response = response;
b.body = body;
}
});
}
});
我们再看看最终我们是如何利用 generator请求网页的
co(function *(){
var a = yield request('http://google.com');
var b = yield request('http://yahoo.com');
console.log(a[0].statusCode);
console.log(b[0].statusCode);
})()
上面的代码可以看到,co 里面传入了一个 generator,里面用 yield 调用异步函数。从逻辑上看,里面的异步被变成了同步。
co 到底有什么魔法?可以把我们从异步中解救出来?
想想 generator 的特性,当我们执行第一个 next 的时候,会调用第一个 request,此时我们去调用 request 的逻辑,然后把 generator 的实例穿进去。当第一个 request 逻辑完成时,在调用这个 generator 的 next,这样就到了第二个 yield 的逻辑了。当然这需要一些逻辑的封装,也就是 co 了。
根据上面的分析,我们大概可以写出下面的代码
function co(Gene){
//先实例化一下
var gene = Gene();
//如果存在 next 函数
if(gene.next){
var fun = gene.next();//把异步函数返回过来,好继续封装
//fun 处理完,再调用 gene.next()
//...
}
}
从上面的代码可以看出
yield 后面的内容需要返回一个异步函数,这样我们才可进一步封装异步处理的逻辑。
fun 需要可以传入参数,这样才可以处理多个异步
需要一个递归调用,这样才可以持续调用 next,同时根据 next 返回对象中的done属性停止逻辑
需要考虑错误处理
今天就到这里,下一篇详细讲一下 co 的源码
co最简版实现,学习generator & co

看了co的源码 比较难懂 了解了其原理后实现了一个最简版本https://github.com/yucong/simple-co 希望对想学习的tx有帮助~ yeild后面只支持thunk,co本身也是一个thunk
核心代码:
function co(generator) {
return function(fn) {
var gen = generator();
function next(err, result) {
if(err){
return fn(err);
}
var step = gen.next(result);
if (!step.done) {
step.value(next);
} else {
fn(null, step.value);
}
}
next();
}
}
用法:
var co = require('./co');
// wrap the function to thunk
function readFile(filename) {
return function(callback) {
require('fs').readFile(filename, 'utf8', callback);
};
}
co(function * () {
var file1 = yield readFile('./file/a.txt');
var file2 = yield readFile('./file/b.txt');
console.log(file1);
console.log(file2);
return 'done';
})(function(err, result) {
console.log(result)
});
会打印出:
content in a.txt
content in b.txt
done
================================
generator_co: http://liuxinxiu.com/generator_co/
js 判断各种数据类型

了解js的都知道, 有个typeof 用来判断各种数据类型,有两种写法:typeof xxx ,typeof(xxx)
如下实例:
typeof 2 输出 number
typeof null 输出 object
typeof {} 输出 object
typeof [] 输出 object
typeof (function(){}) 输出 function
typeof undefined 输出 undefined
typeof '222' 输出 string
typeof true 输出 boolean
这里面包含了js里面的五种数据类型 number string boolean undefined object和函数类型 function
看到这里你肯定会问了:我怎么去区分对象,数组和null呢?
接下来我们就用到另外一个利器:Object.prototype.toString.call
这是对象的一个原生原型扩展函数,用来更精确的区分数据类型。
我们来试试这个玩儿意儿:
var gettype=Object.prototype.toString
gettype.call('aaaa') 输出 [object String]
gettype.call(2222) 输出 [object Number]
gettype.call(true) 输出 [object Boolean]
gettype.call(undefined) 输出 [object Undefined]
gettype.call(null) 输出 [object Null]
gettype.call({}) 输出 [object Object]
gettype.call([]) 输出 [object Array]
gettype.call(function(){}) 输出 [object Function]
看到这里,刚才的问题我们解决了。
其实js 里面还有好多类型判断 [object HTMLDivElement] div 对象 , [object HTMLBodyElement] body 对象 ,[object Document](IE)或者 [object HTMLDocument](firefox,google) ......各种dom节点的判断,这些东西在我们写插件的时候都会用到。
可以封装的方法如下 :
var gettype=Object.prototype.toString
var utility={
isObj:function(o){
return gettype.call(o)=="[object Object]";
},
isArray:function(o){
return gettype.call(o)=="[object Array]";
},
isNULL:function(o){
return gettype.call(o)=="[object Null]";
},
isDocument:function(){
return gettype.call(o)=="[object Document]"|| [object HTMLDocument];
}
........
}
Redis 未授权访问缺陷可轻易导致系统被黑

注:近日曝出大规模利用 Redis 漏洞进行入侵的事件,会给用户的 Redis 运行环境以及 Linux 主机造成安全风险。若用户的Linux服务器中安装了Redis并对公网开放了Redis端口,则可能导致Redis数据丢失,服务器则存在被植入公钥用于SSH远程登录的风险。
关于Redis
Redis是一个高性能的key-value数据库。 redis的出现,很大程度补偿了memcached这类keyvalue存储的不足,在部 分场合可以对关系数据库起到很好的补充作用。它提供了Python,Ruby,Erlang,PHP客户端,使用很方便。
容易遭受入侵的环境
用户自建的运行了 Redis 服务的 Linux 主机,依root身份运行Redis服务,并在公网上开放了 6379 的 Redis 端口。
入侵现象
1)Redis 可能被执行过 flushall 命令
2)Redis 内建了名为 crackit 的 key
3)Redis 的 dir 参数指向了 /root/.ssh
4)/root/.ssh/authorized_keys 被覆盖或者包含 Redis 相关的内容
修复办法
5)以非 root 权限启动 Redis
6)增加 Redis 密码验证
7)禁止公网开放 Redis 端口, 例如可以在青云防火墙上禁用 6379 Redis 的端口
8)检查 authorized_keys 是否非法
详细内容请看下文:
漏洞概要
Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。
漏洞描述
Redis 安全模型的观念是: “请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的” 。
Redis 作者之所以放弃解决未授权访问导致的不安全性是因为, 99.99%使用Redis的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。
因为其他受信任用户需要使用Redis或者因为运维人员的疏忽等原因,部分Redis 绑定在0.0.0.0:6379,并且没有开启认证(这是Redis的默认配置),如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源ip访问等,将会导致Redis服务直接暴露在公网上,导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。
利用Redis自身的相关方法,可以进行写文件操作,攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。
漏洞影响
Redis 暴露在公网(即绑定在0.0.0.0:6379,目标IP公网可访问),并且没有开启相关认证和添加相关安全策略情况下可受影响而导致被利用。
通过ZoomEye 的搜索结果显示,有97700在公网可以直接访问的Redis服务。
根据 ZoomEye 最新于2015年11月12日0点探测结果显示:
总的存在无验证可直接利用 Redis 服务的目标全球有49099,其中中国有16477。其中被明着写入crackit的,也就是已经被黑的比例分别是全球65%(3.1万),中国67.5%(1.1万)。
1.1. 漏洞分析与利用
首先在本地生产公私钥文件:
- ? 1 $ssh-keygen –t rsa
然后将公钥写入foo.txt文件
- ? 1 $ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt
再连接Redis写入文件
这样就可以成功的将自己的公钥写入/root/.ssh文件夹的authotrized_keys文件里,然后攻击者直接执行:
- ? 1 $ ssh –i id_rsa root@192.168.1.11
即可远程利用自己的私钥登录该服务器。
当然,写入的目录不限于/root/.ssh 下的authorized_keys,也可以写入用户目录,不过Redis很多以root权限运行,所以写入root目录下,可以跳过猜用户的步骤。
Redis 未授权的其他危害与利用
数据库数据泄露
Redis 作为数据库,保存着各种各样的数据,如果存在未授权访问的情况,将会导致数据的泄露,其中包含保存的用户信息等
代码执行
Redis可以嵌套Lua脚本的特性将会导致代码执行, 危害同其他服务器端的代码执行, 样例如下
一旦攻击者能够在服务器端执行任意代码, 攻击方式将会变得多且复杂, 这是非常危险的.
通过Lua代码攻击者可以调用 redis.sha1hex() 函数,恶意利用 Redis 服务器进行 SHA-1 的破解。
敏感信息泄露
通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫
可以看到泄露了很多 Redis 服务器的信息, 有当前 Redis 版本, 内存运行状态, 服务端个数等等敏感信息。
全球无验证可直接利用 Redis 分布情况
Linux-以指定用户运行redis

redis中无配置启动用户信息,需要添加redis用户,后以其启动(1):
useradd -s /bash/false -M redis sudo -u redis /xxx/redis-server /xxx/etc/redis.conf >/dev/null 2>&1 &
以Linux下指定sun用户在linux开机时执行/home/sun/startrun.sh为例:
/bin/false和/sbin/nologin的区别

不会有任何提示,用户切换不过去
Linux如何查找大文件或目录总结

在Windows系统中,我们可以使用TreeSize工具查找一些大文件或文件夹,非常的方便高效,在Linux系统中,如何去搜索一些比较大的文件呢?下面我整理了一下在Linux系统中如何查找大文件或文件夹的方法。
1: 如何查找大文件?
其实很多时候,你需要了解当前系统下有哪些大文件,比如文件大小超过100M或1G(阀值视具体情况而定)。那么如何把这些大文件搜索出来呢?例如我要搜索当前目录下,超过800M大小的文件
- [root@getlnx01 u03]# pwd
- /u03
- [root@getlnx01 u03]# find . -type f -size +800M
- ./flash_recovery_area/backup/backupsets/ora_df873519197_s46815_s1
- ./flash_recovery_area/backup/backupsets/ora_df873523646_s46822_s1
- ./flash_recovery_area/backup/backupsets/ora_df873521714_s46818_s1
- ./flash_recovery_area/backup/backupsets/ora_df873522876_s46820_s1
- ./flash_recovery_area/backup/backupsets/ora_df873517396_s46813_s1
- ./flash_recovery_area/backup/backupsets/ora_df873523321_s46821_s1
- ./flash_recovery_area/backup/backupsets/ora_df873515765_s46811_s1
- ./flash_recovery_area/backup/backupsets/ora_df873520789_s46817_s1
- ./flash_recovery_area/backup/backupsets/ora_df873524162_s46823_s1
- ./flash_recovery_area/backup/backupsets/ora_df873518302_s46814_s1
- ./flash_recovery_area/backup/backupsets/ora_df873519953_s46816_s1
- ./flash_recovery_area/backup/backupsets/ora_df873516500_s46812_s1
- ./flash_recovery_area/backup/backupsets/ora_df873513413_s46809_s1
- ./flash_recovery_area/backup/backupsets/ora_df873514789_s46810_s1
- ./oradata/epps/invsubmat_d08.dbf
- ./oradata/epps/gmtinv_d08.dbf
- ./oradata/epps/gmtinv_x01.dbf
- ./oradata/epps/undotbs02.dbf
- ./oradata/epps/gmtinv_d07.dbf
- ./oradata/epps/undotbs01.dbf
- ./oradata/epps/gmtinv_x02.dbf
如上命令所示,我们仅仅能看到超过800M大小的文件的文件名称,但是对文件的信息(例如,文件大小、文件属性)一无所知,那么能否更详细显示一些文件属性或信息呢,当然可以,如下所示
- [root@getlnx01 u03]# find . -type f -size +800M -print0 | xargs -0 ls -l
- -rw-r----- 1 oracle oinstall 2782846976 Mar 6 11:51 ./flash_recovery_area/backup/backupsets/ora_df873513413_s46809_s1
- -rw-r----- 1 oracle oinstall 1878433792 Mar 6 11:53 ./flash_recovery_area/backup/backupsets/ora_df873514789_s46810_s1
- -rw-r----- 1 oracle oinstall 1378492416 Mar 6 11:54 ./flash_recovery_area/backup/backupsets/ora_df873515765_s46811_s1
- -rw-r----- 1 oracle oinstall 1641381888 Mar 6 11:56 ./flash_recovery_area/backup/backupsets/ora_df873516500_s46812_s1
- -rw-r----- 1 oracle oinstall 1564065792 Mar 6 11:58 ./flash_recovery_area/backup/backupsets/ora_df873517396_s46813_s1
- -rw-r----- 1 oracle oinstall 1663492096 Mar 6 12:00 ./flash_recovery_area/backup/backupsets/ora_df873518302_s46814_s1
- -rw-r----- 1 oracle oinstall 1368244224 Mar 6 12:02 ./flash_recovery_area/backup/backupsets/ora_df873519197_s46815_s1
- -rw-r----- 1 oracle oinstall 1629069312 Mar 6 12:04 ./flash_recovery_area/backup/backupsets/ora_df873519953_s46816_s1
- -rw-r----- 1 oracle oinstall 1629954048 Mar 6 12:06 ./flash_recovery_area/backup/backupsets/ora_df873520789_s46817_s1
- -rw-r----- 1 oracle oinstall 1202192384 Mar 6 12:07 ./flash_recovery_area/backup/backupsets/ora_df873521714_s46818_s1
- -rw-r----- 1 oracle oinstall 1189388288 Mar 6 12:10 ./flash_recovery_area/backup/backupsets/ora_df873522876_s46820_s1
- -rw-r----- 1 oracle oinstall 1089257472 Mar 6 12:11 ./flash_recovery_area/backup/backupsets/ora_df873523321_s46821_s1
- -rw-r----- 1 oracle oinstall 1097687040 Mar 6 12:12 ./flash_recovery_area/backup/backupsets/ora_df873523646_s46822_s1
- -rw-r----- 1 oracle oinstall 1051009024 Mar 6 12:13 ./flash_recovery_area/backup/backupsets/ora_df873524162_s46823_s1
- -rw-r----- 1 oracle oinstall 4294975488 Apr 3 15:07 ./oradata/epps/gmtinv_d07.dbf
- -rw-r----- 1 oracle oinstall 4194312192 Apr 1 22:36 ./oradata/epps/gmtinv_d08.dbf
- -rw-r----- 1 oracle oinstall 4294975488 Apr 3 15:54 ./oradata/epps/gmtinv_x01.dbf
- -rw-r----- 1 oracle oinstall 4294975488 Apr 3 15:57 ./oradata/epps/gmtinv_x02.dbf
- -rw-r----- 1 oracle oinstall 4294975488 Apr 1 22:35 ./oradata/epps/invsubmat_d08.dbf
- -rw-r----- 1 oracle oinstall 8589942784 Apr 4 09:55 ./oradata/epps/undotbs01.dbf
- -rw-r----- 1 oracle oinstall 8589942784 Apr 4 09:15 ./oradata/epps/undotbs02.dbf
当我们只需要查找超过800M大小文件,并显示查找出来文件的具体大小,可以使用下面命令:
- [root@getlnx01 u03]# find . -type f -size +800M -print0 | xargs -0 du -h
- 1.3G ./flash_recovery_area/backup/backupsets/ora_df873519197_s46815_s1
- 1.1G ./flash_recovery_area/backup/backupsets/ora_df873523646_s46822_s1
- 1.2G ./flash_recovery_area/backup/backupsets/ora_df873521714_s46818_s1
- 1.2G ./flash_recovery_area/backup/backupsets/ora_df873522876_s46820_s1
- 1.5G ./flash_recovery_area/backup/backupsets/ora_df873517396_s46813_s1
- 1.1G ./flash_recovery_area/backup/backupsets/ora_df873523321_s46821_s1
- 1.3G ./flash_recovery_area/backup/backupsets/ora_df873515765_s46811_s1
- 1.6G ./flash_recovery_area/backup/backupsets/ora_df873520789_s46817_s1
- 1004M ./flash_recovery_area/backup/backupsets/ora_df873524162_s46823_s1
- 1.6G ./flash_recovery_area/backup/backupsets/ora_df873518302_s46814_s1
- 1.6G ./flash_recovery_area/backup/backupsets/ora_df873519953_s46816_s1
- 1.6G ./flash_recovery_area/backup/backupsets/ora_df873516500_s46812_s1
- 2.6G ./flash_recovery_area/backup/backupsets/ora_df873513413_s46809_s1
- 1.8G ./flash_recovery_area/backup/backupsets/ora_df873514789_s46810_s1
- 4.1G ./oradata/epps/invsubmat_d08.dbf
- 4.0G ./oradata/epps/gmtinv_d08.dbf
- 4.1G ./oradata/epps/gmtinv_x01.dbf
- 8.1G ./oradata/epps/undotbs02.dbf
- 4.1G ./oradata/epps/gmtinv_d07.dbf
- 8.1G ./oradata/epps/undotbs01.dbf
- 4.1G ./oradata/epps/gmtinv_x02.dbf
如果你还需要对查找结果按照文件大小做一个排序,那么可以使用下面命令:
- [root@getlnx01 u03]# find . -type f -size +800M -print0 | xargs -0 du -h | sort -nr
- 1004M ./flash_recovery_area/backup/backupsets/ora_df873524162_s46823_s1
- 8.1G ./oradata/epps/undotbs02.dbf
- 8.1G ./oradata/epps/undotbs01.dbf
- 4.1G ./oradata/epps/invsubmat_d08.dbf
- 4.1G ./oradata/epps/gmtinv_x02.dbf
- 4.1G ./oradata/epps/gmtinv_x01.dbf
- 4.1G ./oradata/epps/gmtinv_d07.dbf
- 4.0G ./oradata/epps/gmtinv_d08.dbf
- 2.6G ./flash_recovery_area/backup/backupsets/ora_df873513413_s46809_s1
- 1.8G ./flash_recovery_area/backup/backupsets/ora_df873514789_s46810_s1
- 1.6G ./flash_recovery_area/backup/backupsets/ora_df873520789_s46817_s1
- 1.6G ./flash_recovery_area/backup/backupsets/ora_df873519953_s46816_s1
- 1.6G ./flash_recovery_area/backup/backupsets/ora_df873518302_s46814_s1
- 1.6G ./flash_recovery_area/backup/backupsets/ora_df873516500_s46812_s1
- 1.5G ./flash_recovery_area/backup/backupsets/ora_df873517396_s46813_s1
- 1.3G ./flash_recovery_area/backup/backupsets/ora_df873519197_s46815_s1
- 1.3G ./flash_recovery_area/backup/backupsets/ora_df873515765_s46811_s1
- 1.2G ./flash_recovery_area/backup/backupsets/ora_df873522876_s46820_s1
- 1.2G ./flash_recovery_area/backup/backupsets/ora_df873521714_s46818_s1
- 1.1G ./flash_recovery_area/backup/backupsets/ora_df873523646_s46822_s1
- 1.1G ./flash_recovery_area/backup/backupsets/ora_df873523321_s46821_s1
不过如上截图所示,有时候排列的顺序并不完全是按大小一致,这个是因为du命令的参数h所致,你可以统一使用使用MB来显示,这样就能解决这个问题。到这里,这个在Linux系统查找大文件的命令已经非常完美了,当然如果你还有很多的需求,那么可以在这个命令上做修改、调整.
2: 如何查找Linux下的大目录
譬如有时候磁盘空间告警了,而你平时又疏于管理、监控文件的增长,那么我需要快速的了解哪些目录变得比较大,那么此时我们可以借助du命令来帮我们解决这个问题。
- [root@getlnx01 u03]# du -h --max-depth=1
- 16K ./lost+found
- 33G ./flash_recovery_area
- 37G ./oradata
- 70G .
如果你想知道flash_recovery_area目录下面有哪些大文件夹,那么可以将参数max-depth=2 ,如果你想对搜索出来的结果进行排序,那么可以借助于sort命令。如下所示
- [root@getlnx01 u03]# du -h --max-depth=2 | sort -n
- 3.5G ./flash_recovery_area/EPPS
- 16K ./lost+found
- 29G ./flash_recovery_area/backup
- 33G ./flash_recovery_area
- 37G ./oradata
- 37G ./oradata/epps
- 70G .
- [root@getlnx01 u03]# du -hm --max-depth=2 | sort -n
- 1 ./lost+found
- 3527 ./flash_recovery_area/EPPS
- 29544 ./flash_recovery_area/backup
- 33070 ./flash_recovery_area
- 37705 ./oradata
- 37705 ./oradata/epps
- 70775 .
[root@getlnx01 u03]# cd /
[root@getlnx01 /]# du -hm --max-depth=2 | sort -n
有时候搜索出来的结果太多了(譬如,我从根目录开始搜索),一直在刷屏,如果我只想查出最大的12个文件夹,怎么办呢?此时就要借助head命令来显示了
- [root@getlnx01 /]# du -hm --max-depth=2 | sort -nr | head -12
- 407480 .
- 167880 ./u04
- 158685 ./u02/oradata
- 158685 ./u02
- 152118 ./u04/oradata
- 70775 ./u03
- 37705 ./u03/oradata
- 33070 ./u03/flash_recovery_area
- 5995 ./u01/app
- 5995 ./u01
- 3551 ./usr
- 1558 ./usr/share
- [root@getlnx01 /]#
查看具体目录:du -sh /www/cnmo/
查看整体概况:df -h
Linux Shell 汇总

1、查看当前操作系统类型
- #!/bin/sh
- SYSTEM=`uname -s`
- if [ $SYSTEM = "Linux" ] ; then
- echo "Linux"
- elif [ $SYSTEM = "FreeBSD" ] ; then
- echo "FreeBSD"
- elif [ $SYSTEM = "Solaris" ] ; then
- echo "Solaris"
- else
- echo "What?"
- fi