in reply to Why does unix mkdir and perl mkdir behave differently?

Perl's mkdir is an interface to the mkdir function, not the unix mkdir program which is a bit more sophisticated.

This is similar to how other calls work: you can type ln -s foo bar to command line if bar is a directory and it will act like ln -s foo bar/foo, but you can't do the same with the symlink call; rm will ask you if you want to remove a read-only file, while the unlink call won't; mv will move across file systems while rename won't; etc. Only this time the name of the utility is exactly the same as that of the system call.

(Note also that GNU coreutils has a few newer programs that correspond more to the system calls than the traditional utilities: link instead of ln, unlink instead of rm. A bit similar in spirit are stat and readlink instead of ls -l.)

Update: To clarify, the unix system call mkdir should behave this way, modifying the permission of the directory with umask, so the perl mkdir function behaves correctly. If you want to force specific permissions on the new directory, you have to call chmod after mkdir. Modifying the umask temporarily might not be enough if you want to control the extra bits (eg. setgid, sticky), as, depending on the system, these may get initialized independently of the umask and the permission value you pass to mkdir. For example, in linux, you typically need chmod to make a directory setgid.