$scalarref = \$foo;
$arrayref = \@ARGV;
$hashref = \%ENV;
$coderef = \&handler;
$globref = \*foo;看起來不難,不過下面馬上就提到陷阱,這兩個其實是一樣的:
@list = (\$a, \@b, \%c);
@list = \($a, @b, %c);解法是用 [] 做。
$scalarref = \$foo;
$arrayref = \@ARGV;
$hashref = \%ENV;
$coderef = \&handler;
$globref = \*foo;@list = (\$a, \@b, \%c);
@list = \($a, @b, %c);use Math::Complex;
use Math::Polynomial::Solve qw/poly_roots/;
my @x = poly_roots(1, 0, 0, 0, 0, 2);
foreach (@x) { print $_, "\n"; }0.929316490603147-0.675187952399881i
0.929316490603147+0.675187952399881i
-0.35496731310463-1.09247705577745i
-0.35496731310463+1.09247705577745i
-1.14869835499703
signal(SIGPIPE, SIG_IGN) 堵掉,#bsdchat 上面看到這個 patch 把他叫做「掩耳盜鈴」,當作沒聽到,幹就對了 XD:Problem Report bin/97768 : NFS rpc.lockd will die automatically。signal() 在 fork() 後才做,所以 uid=root 那隻沒有處理 SIGPIPE,只好再跟 maintainer 講,問看看能不能把 signal() 放到 fork() 前。(主要是他對 rpc.lockd 比較熟,可能會比較清楚各類後遺症 XD)signal() 搬到 fork() 前的 cvs commit 紀錄:cvs commit: src/usr.sbin/rpc.lockd kern.c,這個 patch 的 rpc.lockd 到現在都還活得很好,看起來在 6/1 那天就會進 RELENG_6 了 :)lock_proc.c 這個檔案從 1.17 到 1.18 的 patch (6.0-RELEASE 是 1.18):NFS locking question。transmit_result() 與 transmit4_result() 的修正,不知道 4.x 有沒有 svc_getcaller(),如果有的話可以試著 patch 看看...
ldapadd 的地方就不會動了,會有錯誤訊息:testbase [/home/staff/gslin/work] -gslin- ldapadd -x -D 'cn=Manager,dc=testbase,dc=gslin,dc=org' -W -f test.ldif
Enter LDAP Password:
adding new entry "dc=testbase,dc=gslin,dc=org"
ldap_add: Naming violation (64)
additional info: value of naming attribute 'dc' is not present in entry
my-domain.com 的例子就成功了,至少知道問題在哪裡了 o_O