Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Never forget to RTFM properly - a story

by robartes (Priest)
on Mar 19, 2003 at 16:25 UTC ( #244368=perlmeditation: print w/ replies, xml ) Need Help??

This is a story just for amusement. There should be very little hard new information in this, but I thought I'd just post it to give people a laugh or two. I know I needed them :).

Tripped up by Unix semantics

Or: how our hero does not RTFM properly

The situation

Our hero, a confused Perl coder with a strong Unix background, is putting the finishing touches to a script that installs a fix to the production environment that needs to be installed now. Part of the script calls for the creation of a directory structure involving multiple symbolically linked directories (ugly as that is). It is in the creation of these links that our hero went off into the wild blue yonder. Read on for an account of the adventure.

The wild blue yonder

"Right," goes our hero, "Unix has ln and ln -s to create hard links and soft links, respectively..

This is wrong - or at least incomplete: Unix does indeed have the ln command that does both forms of link, but the underlying system calls are different: link(2) vs. symlink(2). However, our hero did not make the connection to the underlying system calls, and went looking for a Perl function to do the same. Lessee:

perldoc -f link link OLDFILE,NEWFILE Creates a new filename linked to the old filename. Returns true for success, false otherwise.

Sweet! Sounds like just the ticket!

Ticket to the wild blue yonder, that is.

Deep into the wild blue yonder

Right, off goes our hero to test his script on a harmless server somewhere. As root of course (bad sysadmin!). You see what's coming. The script works flawlessly (why did our hero not mistype just once? He usually does. Several times.), doing what it was intended to do. Unfortunately, what it was intended to do was also wrong.

It appears of course, that link creates hard links (as in, both filesystem entries have the same inode). symlink creates soft links (or symlinks, amazingly). Anyway, hard linking directories is not a good idea (it can easily create cyclic filesystem structures), so most Unixen make this very difficult, although not impossible. Perl of course, being the social language it is, persuades the OS to create hard links to directories, if the user really, really wants to. Unfortunately, removing a hard linked directory is not possible using rm or Perl's unlink. Not even using the magically dangerous rm -rf incantation.

Return from the wild blue yonder

This was discovered when our hero tried to clean up after himself and tried to erase the directory structury his script had created:

# rm -rf directory Could not remove directory: File exists.

Eh? ... of course it exists ... that's why I want to remove it ... Hang on it's a hard link. Let's google: oh fun, we need to use unlink(2) to unlink it. So our hero dusts off his C compiler and whips up a quick program to remove the hardlink. No damage done. Phew. That was fun. Can I go again? Please?

The lesson

Our hero got caught by confusing Unix command semantics (where soft links and hard links are made by the same command with different options) and actual underlying system calls (which is what Perl usually uses). Combine this with the fact that general lack of sleep caused our hero to not consider the fact that link does not have any options to specify the type of link somewhat suspicious, and you get the result described above.

Next time, RTFM! Looking through perlfunc would have shown our hero that there was something like symlink. Even if you think you are familiar with the issues, RTFM anyway, you never know what might come up :).

Update: Added readmore tags.

CU
Robartes-

Comment on Never forget to RTFM properly - a story
Select or Download Code
Re: Never forget to RTFM properly - a story (-U)
by tye (Cardinal) on Mar 19, 2003 at 16:40 UTC

    perldoc perlrun says:

    -U
    allows Perl to do unsafe operations. Currently the only "unsafe" operations are the unlinking of directories while running as superuser, and running setuid programs with fatal taint checks turned into warnings.
    So I think you should file a bug report against Perl saying that linking directories as superuser should also be "unsafe".

    Oh, and next time you won't have to resort to C to undo the problem. (:

                    - tye
Re: Never forget to RTFM properly - a story
by awkmonk (Monk) on Mar 19, 2003 at 18:18 UTC

    I may as well stick my two penn'th in.

    RTFM'ing would be fine for a good in depth script, but it seems that for a quick one off script (as it appears that this was), you already understood the syntax, differences et al of the unix system i.e. a shell script could probably do the trick just as easily.

    If you need to use Perl, then why not just do a system() call to do the job. This isn't very Perlish I know, but when it all goes horribly wrong and lots of people are breathing down your neck to fix it NOW, they won't give two wotsits how you've coded it, just that the problem is now fixed.

    Of course this does imply that you've RTFMed the unix manual and know the difference between soft and hard links.

    So yes, RTFM, just make sure it's the right one!

Re: Never forget to RTFM properly - a story
by bart (Canon) on Mar 20, 2003 at 00:38 UTC
    Personally, I blame Perl's docs as well. The entry of link in perlfunc should point to symlink as well, and vice versa. Just like unlink mentions rmdir. That surely would have triggered some neurons.

    perlfunc does neither.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://244368]
Approved by broquaint
Front-paged by diotalevi
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (9)
As of 2014-11-25 02:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (148 votes), past polls