my $inputfile;
print "\nDrag and drop a file here:\n";
chomp ($inputfile = <STDIN>);
$inputfile =~ s/^ *[\"\']?([^\"\']*)[\"\']?/$1/; # strip whitespace an
+d quotes
if (-e "$inputfile") {print "\nOK, file found\n";} else {print "\nERRO
+R: file not found\n";}
[download]

You're quite right. It doesn't work as is on OS X 10.5. Here's something you might adjust to see the reason it's failing-

print -e $inputfile ?
    "OK, file found\n" : qq{ERROR: file "$inputfile" not found\n};
[download]

Drag and drop a file here:
/Users/cow/Downloads/104937653.pdf 
ERROR: file "/Users/cow/Downloads/104937653.pdf " not found
[download]

You can see the extra space that dragging and dropping in the Terminal is adding. I expect this is a quirk of the OS's GUI, I don't have anything but OS X at home to try this on.

So, you're right, in this case using one of the modules would not have helped. A trim routine such as s/\s\z//; will fix this problem (though the file may have leading or trailing spaces so you'd have to be careful). The reason it took awhile and so many messages to get to this answer is your original post didn't distill the issue down to something easy to try or read. If this one had been your first post, you would have got your answer (from me or someone else) immediately.

You should still consider using a file handling package. They will ultimately save you a lot of time and catch edge cases that might matter to end users even if you think them irrelevant or karma inducing.

The reason it took awhile and so many messages to get to this answer is your original post didn't distill the issue down to something easy to try or read. If this one had been your first post, you would have got your answer (from me or someone else) immediately.

Well, it did include the request to run a simple ready-made diagnostic script that cleared up the issue immediately as soon as somebody ran it.

Note that if your filename contains single or double quotes, you'll strip them and subsequently Perl won't find the file under the mangled name. A somewhat saner approach might be to find out how exactly filenames arrive in your program when dragged into it.

As an example, on Windows, filenames dropped into the console window get surrounded by double quotes. So, on Windows it would make sense to strip one leading and the trailing double quote. Windows allows single quotes in filenames, so stripping them out is ill-advised.

Well, to be honest, I have no sympathy for people who put lunatic things like quotes in their file names.
I also assumed that quotes weren't allowed in filenames, and I maintain that sane people don't use them even if their OS allows them to.
If you ask me, Windows shouldn't allow accented characters in filenames, either, and I don't particularly mind that the aligner fails on such files.

That said, you are probably right. One issue is that different versions of the various OSes work differently in different circumstances and I don't want to make bold assumptions. E.g. XP seems to always use double quotes, Vista doesn't even allow drag & drop into the console... I'm not sure what Win7 does. For all I know, it might use quotes only if there is a space or other escape-worthy character in the file path. At least one major OS (Ubuntu, I think) does this. I.e. you get /folder/test_file.txt but '/folder/test file.txt'. So the code could easily break if a newer/older OS version works differently or you didn't test thoroughly enough.
Researching all these permutations seemed like too much trouble for the few crazies who use impossible filenames.