echo和backslash

2012年2月14日 由 edsionte 1条评论 »

echo命令是一个看似简单的命令,当它和转义,命令替换等相遇时,则会发生许多令人迷惑的现象。

1.echo \z和echo “\z”的不同

echo命令比较特殊,对于它本身而言,转义符加上某些字符会引发一些特殊含义,这与转义本身的含义又相反。比如\n在echo中表示回车换行,\t表示水平制表符等。不过,echo命令在bash中默认是不开启对这些特殊转义符进行解释的,如果要开启则必须加上-e选项。
对于下述的命令:

$ echo -e "\\thello"
	hello

它的执行过程是:

1).”\\thello”首先被bash解释为”\thello”。

2).”\thello”作为echo的参数,由于加入了-e,因此echo将\t解释为水平制表符。

3).显示结果。

上述命令发生了两次转义,第一即为执行过程1中bash处理命令行时,第二次即为2中echo处理自身参数时。

对于弱引用而言,双引号中的所有字符都被当做普通字符,除了\,$和反引号(本文所述的反引号就主键盘上数字1左边的符号)。

在对字符串不加引用的情况下,\会发挥其转义的特性,即显示字符字面含义,即便该字符是普通字符,因此echo \z的结果为z。而双引号中所有字符都被解释成shell解释成了普通字符,”\z”被解释的结果为\z,并且\z并不是echo的特定转义符号,因此echo “\z”的结果为\z。

edsionte@edsionte-laptop:~/mytest$ echo \z
+ echo z
z
edsionte@edsionte-laptop:~/mytest$ echo "\z"
+ echo '\z'
\z

这里你也许有疑问:弱引用是不能关闭$,\和反引号的特殊含义的,为何echo “\z”中的\没有起到转义的作用呢?

这里需要注意的是,弱引用中\符号仅对$,\,反引号和双引号这几个特殊字符起转义作用,而其他字符前的\均不起作用,也就是说shell会忽略它,将这个\作为普通字符。

edsionte@edsionte-laptop:~/mytest$ t=a
+ t=a
edsionte@edsionte-laptop:~/mytest$ echo "\$t"
+ echo '$t'
$t
edsionte@edsionte-laptop:~/mytest$ echo "\*t"
+ echo '\*t'
\*t

通过上述的分析,也就简单解释了为何echo \z和echo “\z”会有不同的结果。

2.echo `echo \z`的疑惑

接下来要说明的不是上述一条命令,而是关于它的“一系列”命令。

$ cat test2echo.sh
#!/bin/bash

echo `echo \z`
echo `echo \\z`
echo `echo \\\z`
echo `echo \\\\z`
echo `echo \\\\\\z`
echo `echo \\\\\\\z`
$ bash test2echo.sh
z
z
\z
\z
\z
\\z

这几条echo命令中均嵌套了另一个echo命令,命令替换使用的是反引号而不是$()。从上面的结果可以看出当echo遇到\时发生了一些奇怪的现象,比如为何第3,4,5条echo命令的结果是一致的。

在解释上述这几个echo命令之前,我们先看下面的脚本:

$ cat testecho.sh
#!/bin/bash

echo \z
echo \\z
echo \\\z
echo \\\\z
echo \\\\\\z
echo \\\\\\\z
$ bash testecho.sh
z
\z
\z
\\z
\\\z
\\\z

上面的脚本的结果是比较容易想到的。第一条echo中的\由于对z进行转义;第二条echo中的第一个\对第二个\进行转义;第三条echo中的第一个\对第二个\进行转义,第三个\对z进行转义;后续的echo命令的规则都是一致的。

如果将testecho.sh中的结果作为test2echo.sh中每个内层echo的输出,那么会不会得到test2echo.sh最终的结果呢?比如echo `echo \\\z`,内部echo的结果是\z,那么这个双层echo可以看作是echo \z。按照上述1中的讨论,结果应该是z。看来处理过程并不是如此。

那么echo `echo \\\z`是否可以看作是echo “\z”?根据上述1中的讨论结果,结果正确。不过对于echo `echo \\\\z`,按照这样的处理并不成立。

接下来我们使用set命令来追踪test2echo.sh的执行过程:

$ cat test2echo.sh
#!/bin/bash

set -x

echo `echo \z`
echo `echo \\z`
echo `echo \\\z`
echo `echo \\\\z`
echo `echo \\\\\\z`
echo `echo \\\\\\\z`
$ bash test2echo.sh
++ echo z
+ echo z
z
++ echo z
+ echo z
z
++ echo '\z'
+ echo '\z'
\z
++ echo '\z'
+ echo '\z'
\z
++ echo '\z'
+ echo '\z'
\z
++ echo '\\z'
+ echo '\\z'
\\z

通过加入-x选项我们可以发现内部echo的输出结果被单引号所引用,因此可以得知上述双层echo命令的结果都是内部echo的输出结果。因为每个内部echo的输出都通过单引号原封不动的作为外部echo的输入,并且单引号中的所有字符都是普通字符(除了单引号本身)。那么究竟是什么原因才导致这样令人迷惑的结果?

在上述问题1中我们已经说明过双引号中\对$,反引号,双引号和\起到转义作用,即显示这些字符的字面意思,那么这几个特殊字符前的\也将抽离所在字符串。同样,反引号中也存在这样的问题,如果反引号中有\,并且\后紧跟的字符是$,反引号,双引号和\这些字符时,那么这些特殊字符前的\将抽离。

按照上述的解释,test2echo.sh中各个echo的执行过程就明了了。以echo `echo \\\z`为例,它的执行过程如下:

1).\\\z由于反引号中的\前出现了\,因此第二个\被抽离,原始命令成为echo `echo \\z`。

2).执行反引号中的echo,原始命令成为echo ‘\z’

3).执行外部echo,结果为\z。

再举一例,比如上述的echo `echo \\\\\\\z`,它的执行过程如下:

1).内部\\\\\\\z由于反引号中的\前又出现了\,因此有三个\被抽离,原始命令成为echo `echo \\\\z`。

2).执行反引号中的echo,原始命令成为echo ‘\\z’

3).执行外部echo,结果为\\z。

其他命令的执行过程也是如此。每个命令中的反引号部分都先经过\的抽离,接着bash对字符串进行转移处理,再输入内部echo;内部echo处理完成后,传递给外部echo,最终输出结果。上述过程中的2)和3)均可以通过set -x来追踪。

3.echo `echo \z`和echo $(echo \z)的不同

从修改文件扩展名到子串删除

2012年1月30日 由 edsionte 没有评论 »

之前在这篇文章中已经列举了一种通用的批量修改文件后缀名的方法,今天看到变量替换${var%pattern},因此又有下面的一种方法:

#!/bin/bash

if [ $# -ne 3 ]
then
	echo "Usage:$(basename $0) old_name new_name dir"
	exit -1
fi

old_name="$1"
new_name="$2"
dir="$3"

for file in $(ls *.$old_name)
do
	newfile=${file%.$old_name}.$new_name
	mv $file $newfile
	echo "$file ===> $newfile"
done

exit 0

该脚本用到了变量替换中的子串删除方法:${var%pattern}。它的作用是从变量$var的末尾删除最小匹配$pattern字符串。与此对应的方法${var%%pattern}则是删除最大匹配$pattern字串。比如:

edsionte@edsionte-laptop:~/mytest$ var=abcd12345abc6789
edsionte@edsionte-laptop:~/mytest$ pattern=b*9
edsionte@edsionte-laptop:~/mytest$ echo "${var%$pattern}"
abcd12345a
edsionte@edsionte-laptop:~/mytest$ echo "${var%%$pattern}"
a

如果想从变量$var开头删除字符串$pattern,则可以使用${var#pattern}删除最小匹配的字符串,而${var##pattern}则可以删除最大匹配$pattern的字符串。比如:

edsionte@edsionte-laptop:~/mytest$ var=abcd12345abc6789
edsionte@edsionte-laptop:~/mytest$ pattern=a*c
edsionte@edsionte-laptop:~/mytest$ echo "${var#$pattern}"
d12345abc6789
edsionte@edsionte-laptop:~/mytest$ echo "${var##$pattern}"
6789

从变量中删除指定字符串是一种常见的操作。

删除日志文件的经典脚本

2012年1月29日 由 edsionte 没有评论 »

本文所示的删除/var/log下日志文件脚本源于abs这本书,虽然实际功能只是简单的清空该目录下的messages文件,但是这个脚本具有广义性,可以作为其他脚本的模板。

#!/bin/bash

LOG_DIR=/var/log
ROOT_UID=0
LINES=50
E_XCD=66
E_NOTROOT=67

为了更好的移植性,事先定义几个变量。比如用LOG_DIR指定日志所在目录,E_开头的变量为不同的错误码。

if [ "$UID" -ne "$ROOT_UID" ]
then
	echo "Must be root to run this script."
	exit $E_NOTROOT
fi

if [ -n "$1" ]
then
	lines=$1
else
	lines=$LINES
fi

由于删除/var/log下的文件需要root身份,因此一开始先判断运行该脚本的用户是否为root。接着判断参数1是否为空,lines指定默认日志保留的行数。

cd $LOG_DIR

if [ `pwd` != "$LOG_DIR" ]
then
	echo "Can't change to $LOG_DIR."
	exit $E_XCD
fi

判断是否成功进入了LOG_DIR所代表的目录。上述代码的更有效率的表示方法为:

# cd /var/log || {
#   echo "Cannot change to necessary directory." >&2
#   exit $E_XCD;
# }

最后才是实质性的日志删除功能:

tail -$lines messages > mesg.temp
mv mesg.temp messages

exit 0

最后只保留messages文件中lines行日志。

该脚本的功能虽然简单,但是却拥有用户身份检查、参数检查等功能,对其他脚本而言是个很好的模板。

Linux页框分配函数的实现分析

2012年1月11日 由 edsionte 没有评论 »

内核中有六个基本的页框分配函数,它们内部经过封装,最终都会调用alloc_pages_node()。这个函数的参数比alloc_pages()多了一个nid,它用来指定节点id,如果nid小于0,则说明在当前节点上分配页框。正确获取到节点id后,接下来调用__alloc_pages()。

static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int order)
{
        if (nid < 0)
                nid = numa_node_id();

        return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask));
}

__alloc_pages()第三个参数根据nid和gfp_mask得到适当的zonelist链表。该过程通过node_zonelist()完成。

如果内存分配标志flags中设置了__GFP_THISNODE,则表明使用当前节点对应的zonelist,否则使用备用zonelist,也就是说当本地节点中zone不足时,在其他节点中申请页框。

static inline struct zonelist *node_zonelist(int nid, gfp_t flags)
{
        return NODE_DATA(nid)->node_zonelists + gfp_zonelist(flags);
}

__alloc_pages()内部再次封装__alloc_pages_nodemask()。

static inline struct page *
__alloc_pages(gfp_t gfp_mask, unsigned int order, struct zonelist *zonelist)
{
        return __alloc_pages_nodemask(gfp_mask, order, zonelist, NULL);
}

现在进入__alloc_pages_nodemask(),它作为页框分配函数的核心部分。如果一切顺利,那么所需内存将会进入get_page_from_freelist(),这个函数可以看作是伙伴算法的前置函数,它通过分配标志和分配阶判断是否能进行此次内存分配。如果可以分配,则它进行实际的内存分配工作,既利用伙伴算法进行分配内存。否则,进入__alloc_pages_slowpath(),此时内核需要放宽一些分配条件,然后在__alloc_pages_slowpath()中再调用几次get_page_from_freelist()。这种情况在内存分配过程中很常见,大多数情况下第一次调用get_page_from_freelist()都会失败。

struct page *
__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,struct zonelist *zonelist, nodemask_t *nodemask)
{
        enum zone_type high_zoneidx = gfp_zone(gfp_mask);
        struct zone *preferred_zone;
        struct page *page;
        int migratetype = allocflags_to_migratetype(gfp_mask);

        gfp_mask &= gfp_allowed_mask;

        lockdep_trace_alloc(gfp_mask);

        might_sleep_if(gfp_mask & __GFP_WAIT);

        if (should_fail_alloc_page(gfp_mask, order))
                return NULL;

        first_zones_zonelist(zonelist, high_zoneidx, nodemask, &preferred_zone);
        if (!preferred_zone)
                return NULL;

        page = get_page_from_freelist(gfp_mask|__GFP_HARDWALL, nodemask, order,
                        zonelist, high_zoneidx, ALLOC_WMARK_LOW|ALLOC_CPUSET,
                        preferred_zone, migratetype);
        if (unlikely(!page))
                page = __alloc_pages_slowpath(gfp_mask, order,
                                zonelist, high_zoneidx, nodemask,
                                preferred_zone, migratetype);

        trace_mm_page_alloc(page, order, gfp_mask, migratetype);
        return page;
}

页框分配函数的主要执行路径都在__alloc_pages_slowpath()中,因为大多数情况下第一次内存分配的尝试都会失败。在经历一系列的参数检查之后,该函数通过调用wake_all_kswapd()唤醒每个zone所属node中的kswapd守护进程。这个守护进程负责换出很少使用的页,以提高目前系统可以用的空闲页框。

在kswapd交换进程被唤醒之后,该函数开始尝试新一轮的分配。它首先通过gfp_to_alloc_flags()对分配标志进行调整,以便有更多的可能分配到内存。之后再次调用get_page_from_freelist()尝试分配所需的页框。

static inline struct page *
__alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
        struct zonelist *zonelist, enum zone_type high_zoneidx,
        nodemask_t *nodemask, struct zone *preferred_zone,
        int migratetype)
{
        const gfp_t wait = gfp_mask & __GFP_WAIT;
        struct page *page = NULL;
        int alloc_flags;
        unsigned long pages_reclaimed = 0;
        unsigned long did_some_progress;
        struct task_struct *p = current;

        if (order >= MAX_ORDER) {
                WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
                return NULL;
        }

        if (NUMA_BUILD && (gfp_mask & GFP_THISNODE) == GFP_THISNODE)
                goto nopage;

restart:
        wake_all_kswapd(order, zonelist, high_zoneidx);
        alloc_flags = gfp_to_alloc_flags(gfp_mask);
        page = get_page_from_freelist(gfp_mask, nodemask, order, zonelist,
                        high_zoneidx, alloc_flags & ~ALLOC_NO_WATERMARKS,
                        preferred_zone, migratetype);
        if (page)
                goto got_pg;

如果设置了ALLOC_NO_WATERMARKS标志,那么此时会忽略水印,并此时进入__alloc_pages_high_priority()。该函数内部会至少会再调用一次get_page_from_freelist(),如果设置了__GFP_NOFAIL标志,则不断的循环等待并尝试进行内存分配。

rebalance:
        if (alloc_flags & ALLOC_NO_WATERMARKS) {
                page = __alloc_pages_high_priority(gfp_mask, order,
                                zonelist, high_zoneidx, nodemask,
                                preferred_zone, migratetype);
                if (page)
                        goto got_pg;
        }

到目前为止,分配函数已经尝试好几次进行页框分配。如果现在仍未分配到请求的内存,那么接下来将进入一个比较耗时的阶段。内核通过将很少使用的页换出到磁盘上,以便在物理内存中有更多的空闲页框。这个过程可能会产生阻塞,也就是说会产生睡眠,因此它比较耗时。

__alloc_pages_direct_reclaim()的作用就是先通过try_to_free_pages()回收一些最近很少用的页,将其写回磁盘上的交换区,以便在物理内存中腾出更多的空间。接着,内核会再次调用get_page_from_freelist()尝试分配内存。

        if (!wait)
                goto nopage;

        if (p->flags & PF_MEMALLOC)
                goto nopage;

        if (test_thread_flag(TIF_MEMDIE) && !(gfp_mask & __GFP_NOFAIL))
                goto nopage;

        page = __alloc_pages_direct_reclaim(gfp_mask, order,
                                        zonelist, high_zoneidx,
                                        nodemask,
                                        alloc_flags, preferred_zone,
                                        migratetype, &did_some_progress);
        if (page)
                goto got_pg;

如果内核进行了上述的回收和重新分配的过程后,仍未分配成功,那么此时内核不的不考虑是否发生了OOM(out of memory)。如果当前请求内存的进程发生了OOM,也就是说该进程试图拥有过多的内存,那么此时内核会调用OOM killer杀死它。并且跳转到restart处,重新进行内存分配。

        if (!did_some_progress) {
                if ((gfp_mask & __GFP_FS) && !(gfp_mask & __GFP_NORETRY)) {
                        if (oom_killer_disabled)
                                goto nopage;
                        page = __alloc_pages_may_oom(gfp_mask, order,
                                        zonelist, high_zoneidx,
                                        nodemask, preferred_zone,
                                        migratetype);
                        if (page)
                                goto got_pg;

                        if (order > PAGE_ALLOC_COSTLY_ORDER &&
                                                !(gfp_mask & __GFP_NOFAIL))
                                goto nopage;

                        goto restart;
                }
        }
        pages_reclaimed += did_some_progress;
        if (should_alloc_retry(gfp_mask, order, pages_reclaimed)) {
                congestion_wait(BLK_RW_ASYNC, HZ/50);
                goto rebalance;
        }

页框分配函数结束时候一般有两种情况,其中之一即为分配失败,并没有得到所需页框,从nopage标号处开始执行。

nopage:
        if (!(gfp_mask & __GFP_NOWARN) && printk_ratelimit()) {
                printk(KERN_WARNING "%s: page allocation failure."
                        " order:%d, mode:0x%x\n",
                        p->comm, order, gfp_mask);
                dump_stack();
                show_mem();
        }
        return page;

另一种情况,也就是得到了所需页框,那么直接返回这组页框首页框描述符。

got_pg:
        if (kmemcheck_enabled)
                kmemcheck_pagealloc_alloc(page, order, gfp_mask);
        return page;

}

通过上述的过程可以看到,页框分配函数__alloc_pages()会多次尝试进行分配内存。而具体的页框分配操作是在get_page_from_freelist()中完成的,它根据伙伴算法分配所需大小的页框。

请求页框API简介

2012年1月4日 由 edsionte 没有评论 »

 

在用户态下程序中,我们可以通过malloc()动态申请内存空间。在内核空间中,专门有一个内核子系统处理对连续页框的内存分配请求,这个内核子系统即为管理区页框分配器(zoned page frame allocator)。该分配器包含六个专门用于分配页框的API,这些API都是基于伙伴算法而实现的,因此这些API申请的页框数只能为2的整数幂大小。

内存分配器API

1.alloc_pages()

该宏用来分配2的order次方个连续的页框,如果申请成功返回第一个所分配页框的描述符地址,申请失败的话返回NULL。

#define alloc_pages(gfp_mask, order) \
                alloc_pages_node(numa_node_id(), gfp_mask, order)

2.alloc_page()

该函数用来分配一个单独的页框,它可以看作是alloc_pages()当order等于0时的特殊情况。

#define alloc_page(gfp_mask) alloc_pages(gfp_mask, 0)

3.__get_free_pages()

通过该函数可以申请长为2的order次方大小的连续页框,但是它返回的是这段连续页框中第一个页所对应的线性地址。从源码中可以看出,该函数内部仍然调用了alloc_pages函数,并利用page_address函数将页描述符地址转换为线性地址。

unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order)
{
        struct page *page;

        VM_BUG_ON((gfp_mask & __GFP_HIGHMEM) != 0);

        page = alloc_pages(gfp_mask, order);
        if (!page)
                return 0;
        return (unsigned long) page_address(page);
}

4.__get_free_page()

该宏可以看作是__get_free_pages函数的特殊情况,它用于申请一个单独的页框。

#define __get_free_page(gfp_mask) \
__get_free_pages((gfp_mask),0)

5.get_zeroed_page()

该函数用来获取一个填满0的页框,其中__GFP_ZERO参数用来体现这一点。

unsigned long get_zeroed_page(gfp_t gfp_mask)
{
        return __get_free_pages(gfp_mask | __GFP_ZERO, 0);
}

6.__get_dma_pages()

该宏获得的页框用于DMA操作。

#define (gfp_mask, order) \
                __get_free_pages((gfp_mask) | GFP_DMA,(order))

请求页框的标志

从上述几个分配器API中可以看到,除了用于指示请求页框大小的order参数外,还包括一组标志gfp_mask,它指明了如何寻找空闲的页框。下面仅说明几个常见的分配标志。

__GFP_DMA:该标志指明只能从ZONE_DMA内存管理区获得页框。

__GFP_HIGHMEM:如果该标志被设置,则按照ZONE_HIGHMEM,ZONE_NORMAL和ZONE_DMA的请求顺序获得页框,既首先在ZONE_HIGHMEME区请求所需大小的页框,如果该区无法满足请求页框的大小,则再向ZONE_DMA区发出请求。如果该标志没有被设置,则按照默认的ZONE_NORMAL和ZONE_DMA内存管理区的顺序获取页框。

__GFP_ZERO:如果设置了该标志,那么所申请的页框必须被填满0。

API关系图

本文所介绍的这几个API本质上都调用了alloc_pages(),而alloc_pages()又在其内部调用了alloc_pages_node(),它们之间的关系如下图所示:

从图中可以看出,alloc_pages_node()是所有分配器API的核心函数。