Re: Unsuccessful stat on filename containing newline in RegistryCooker.pm
On 02/14/2013 02:39 AM, Michael A. Capone wrote:
> [Wed Feb 13 16:27:33 2013] [error] [client 192.168.254.21] Unsuccessful
> stat on filename containing newline at
> /usr/local/lib64/perl5/ModPerl/RegistryCooker.pm line 787.\n
>
> ... which in turn results in a 500 Server Error.
The culprit here is only partly modperl. Line 787 reads
stat ...
This is the plain perl stat function. Nothing to do with modperl.
The reason why it throws an exception is line 26 which reads:
use warnings FATAL => 'all';
See:
$ perl -le 'stat "fritz\r\n"; print "no exception"'
no exception
$ perl -Mwarnings -le 'stat "fritz\r\n"; print "no exception"'
Unsuccessful stat on filename containing newline at -e line 1.
no exception
$ perl -Mwarnings=FATAL,all -le 'stat "fritz\r\n"; print "no exception"'
Unsuccessful stat on filename containing newline at -e line 1.
Only the last one dies. Perl itself explains:
$ perl -Mdiagnostics -Mwarnings=FATAL,all \
-le 'stat "fritz\r\n"; print "no exception"'
Unsuccessful stat on filename containing newline at -e line 1 (#1)
(W newline) A file operation was attempted on a filename, and that
operation failed, PROBABLY because the filename contained a newline,
PROBABLY because you forgot to chomp() it off. See perlfunc/chomp.
Uncaught exception from user code:
Unsuccessful stat on filename containing newline at -e line 1.
at -e line 1
It also shows a way how to prevent it:
$ perl -Mwarnings=FATAL,all \
-le '{no warnings "newline"; stat "fritz\r\n";}
print "no exception"'
no exception
I agree with you that the behavior is unexpected. Also, the XXX comment
in line 783 points out that my_finfo() is a temporary solution. So,
perhaps it would be best to use APR::Finfo here. If family allows it
I'll fix it over the weekend.
Torsten
AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
> [Wed Feb 13 16:27:33 2013] [error] [client 192.168.254.21] Unsuccessful > stat on filename containing newline at > /usr/local/lib64/perl5/ModPerl/RegistryCooker.pm line 787.\n I am confused, because a filename is able to contain newlines. 0 Alexander_helix41 ~/2>ll | cat total 1 -rw-r--r-- 1 Alexander Kein 6 Feb 28 12:20 new line 0 Alexander_helix41 ~/2>ll | xxd 000: 746f 7461 6c20 310a 2d72 772d 722d 2d72 total 1.-rw-r--r 010: 2d2d 2031 2041 6c65 7861 6e64 6572 204b -- 1 Alexander K 020: 6569 6e20 3620 4665 6220 3238 2031 323a ein 6 Feb 28 12: 030: 3230 206e 6577 0a6c 696e 650a20 new.line. 0 Alexander_helix41 ~/2> I am pretty shure, I tested the capability of filenames on a Linux (ext2) or Solaris (ufs) filesystem, a long time ago The outcome was, that you can use 254 different characters, except the '\0' and the '/'. But I agree, it is an annoyance it should be forbidden. ;) Greetings, Alexander -- Deutsche Telekom AG Seamless ICT Security Infrastructure & Management im Auftrag T-Systems International GmbH Dipl. Inf Alexander Elgert Langwadener Strasse 17 64625 Bensheim +49 176 22 717 661 (Mobil) +49 671 83419-12 (Tel) +49 671 83419-30 (Fax) E-Mail: alexander.elg...@gmx.de
Re: AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
On 02/28/2013 12:31 PM, alexander.elg...@external.t-systems.com wrote: > >> > [Wed Feb 13 16:27:33 2013] [error] [client 192.168.254.21] Unsuccessful >> > stat on filename containing newline at >> > /usr/local/lib64/perl5/ModPerl/RegistryCooker.pm line 787.\n > I am confused, because a filename is able to contain newlines. The point here is not the capabilities of the file system. The point is that Perl is obviously intended by its makers to be used by stupid programmers who put in at least "use warnings" and who's problems commonly include reading lists of file names from a newline-delimited file where they tend to forget the chomp command. Torsten
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
alexander.elg...@external.t-systems.com wrote: ... I am pretty shure, I tested the capability of filenames on a Linux (ext2) or Solaris (ufs) filesystem, a long time ago The outcome was, that you can use 254 different characters, except the '\0' and the '/'. But I agree, it is an annoyance it should be forbidden. ;) The person who invented that spaces and other unprintable characters were allowed in filenames and paths should be found, his PC and iPhone should be confiscated, he should be exiled to an isolated island in the middle of the Arctic Ocean, and he should be nominated for an IgNobel. The person at Microsoft who decided that "C:\Program Files" was an acceptable place to install programs should be sent along as his butler.
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
On 2/28/2013 7:29 AM, André Warnier wrote: The person who invented that spaces and other unprintable characters were allowed in filenames and paths should be found, his PC and iPhone should be confiscated, he should be exiled to an isolated island in the middle of the Arctic Ocean, and he should be nominated for an IgNobel. +1 though I would leave him with the iPhone and only an industry-standard micro-USB charger. The person at Microsoft who decided that "C:\Program Files" was an acceptable place to install programs should be sent along as his butler. It's better than c:\windows in the old days. +0. Regards, KAM
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
On 28 February 2013 13:29, André Warnier wrote: > alexander.elg...@external.t-systems.com wrote: > ... > >> I am pretty shure, I tested the capability of filenames on a Linux (ext2) >> or Solaris (ufs) filesystem, a long time ago >> The outcome was, that you can use 254 different characters, except the >> '\0' and the '/'. >> >> But I agree, it is an annoyance it should be forbidden. ;) >> > > The person who invented that spaces and other unprintable characters were > allowed in filenames and paths should be found, his PC and iPhone should be > confiscated, he should be exiled to an isolated island in the middle of the > Arctic Ocean, and he should be nominated for an IgNobel. The person at > Microsoft who decided that "C:\Program Files" was an acceptable place to > install programs should be sent along as his butler. What a stupid thing to say. You can use those things on pretty much every file system and OS. Ever since your grandmother started using a computer and thought it was pretty darn stupid for young whippersnappers like yourself to tell her that she couldnt name a file "good recipies". A special place in hell is reserved for programmers that write code that assumes that spaces and other unprintables are illegal in a filename. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
On 02/28/2013 03:14 PM, demerphq wrote: > A special place in hell is reserved for programmers that write code > that assumes that spaces and other unprintables are illegal in a > filename. +1 Torsten
AW: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
Hi all, please, please don't forget to restrict yourself to the 8.3 naming convention. Anything else is troublesome... ... the executable perl.exe is not named by accident but follows deep wisdom. ;-) McA -Ursprüngliche Nachricht- Von: demerphq [mailto:demer...@gmail.com] Gesendet: Donnerstag, 28. Februar 2013 15:14 An: mod_perl list Betreff: Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm On 28 February 2013 13:29, André Warnier wrote: > alexander.elg...@external.t-systems.com wrote: > ... > >> I am pretty shure, I tested the capability of filenames on a Linux (ext2) >> or Solaris (ufs) filesystem, a long time ago >> The outcome was, that you can use 254 different characters, except the >> '\0' and the '/'. >> >> But I agree, it is an annoyance it should be forbidden. ;) >> > > The person who invented that spaces and other unprintable characters were > allowed in filenames and paths should be found, his PC and iPhone should be > confiscated, he should be exiled to an isolated island in the middle of the > Arctic Ocean, and he should be nominated for an IgNobel. The person at > Microsoft who decided that "C:\Program Files" was an acceptable place to > install programs should be sent along as his butler. What a stupid thing to say. You can use those things on pretty much every file system and OS. Ever since your grandmother started using a computer and thought it was pretty darn stupid for young whippersnappers like yourself to tell her that she couldnt name a file "good recipies". A special place in hell is reserved for programmers that write code that assumes that spaces and other unprintables are illegal in a filename. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
demerphq wrote: On 28 February 2013 13:29, André Warnier wrote: alexander.elg...@external.t-systems.com wrote: ... I am pretty shure, I tested the capability of filenames on a Linux (ext2) or Solaris (ufs) filesystem, a long time ago The outcome was, that you can use 254 different characters, except the '\0' and the '/'. But I agree, it is an annoyance it should be forbidden. ;) The person who invented that spaces and other unprintable characters were allowed in filenames and paths should be found, his PC and iPhone should be confiscated, he should be exiled to an isolated island in the middle of the Arctic Ocean, and he should be nominated for an IgNobel. The person at Microsoft who decided that "C:\Program Files" was an acceptable place to install programs should be sent along as his butler. What a stupid thing to say. My comment was meant as light and humorous. I am sorry that it was misunderstood, and sorry that you feel like starting to call names. Relax. You can use those things on pretty much every file system and OS. 1) not without quoting them, you can't. Which is the whole point. and 2) which does not mean that it was a good idea to start with, nor that it is a good idea to keep going along with it. The layout of the keys on the computer keyboard on which you are now typing was designed originally for mechanical writing machines, and its purpose was to slow down typing, so that the levers would not cross eachother. Does it still make sense ? no. Do we keep on using them ? yes. Ever since your grandmother started using a computer and thought it was pretty darn stupid for young whippersnappers like yourself to tell her that she couldnt name a file "good recipies". Sir, you flatter me. Being called a young whippersnapper hasn't happened to me in a long, long time. My grandmother - peace to her soul - never even heard about computers. But had she used them, she could also not have saved a file named "bills/to-pay", nor a file named "good recipes" (she could spell) written in the special reddish ink color that she used in her cookbooks. And had she wanted to call me on the telephone, she would have had to dial a number composed of the digits 0-9, she could not have just typed my name. A special place in hell is reserved for programmers that write code that assumes that spaces and other unprintables are illegal in a filename. If that is their only sin, then I'd assume that this special place would be rather nice, relatively speaking. And I'd happily join them, because I freely admit that I have made that same mistake several times (in my youth of course). But it is probably pretty crowded. Let me put this another way. Would you be willing to have your salary docked, until it has paid for the time lost over the last 20 years, due to mistakes inadvertently made by programmers with 10 years or more of experience, in failing to properly quoting paths or filenames because they could have spaces in them ? Or to put in yet another way : would you publically declare here that you have *never* yourself made such a mistake ? It has also been a while since I have personally programmed something without taking this fact into account. Which does not mean that I like it. And I have seen several generations of programmers working for me, who are still making that same mistake. The point is that one must take it into account, and has to add extra programming steps *every time* to take this into account. And it did not necessarily have to be so. If "\0" and "/" or "\" and "<" and ">" and "|" and "&" are disallowed in filenames on most systems, I fail to see how disallowing spaces would be such a dramatic drawback. But I can easily imagine how disallowing spaces in filenames would save the world many thousand work hours every year. Would you pretend the opposite ? Like the keyboards, it can probably not be changed anymore, so we are stuck with it. But I often think nostalgically about what would have happened (or not happened) if that original designer had just said "hey, let's not allow spaces in paths and filenames; they can use underlines instead".
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
On 02/28/2013 09:32 AM, Torsten Förtsch wrote: On 02/28/2013 03:14 PM, demerphq wrote: A special place in hell is reserved for programmers that write code that assumes that spaces and other unprintables are illegal in a filename. Yes, right next door to another place in hell that is reserved for people who put spaces and other unprintables in filenames. David
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
David Booth wrote: On 02/28/2013 09:32 AM, Torsten Förtsch wrote: On 02/28/2013 03:14 PM, demerphq wrote: A special place in hell is reserved for programmers that write code that assumes that spaces and other unprintables are illegal in a filename. Yes, right next door to another place in hell that is reserved for people who put spaces and other unprintables in filenames. :-) Which is probably why it is called hell, after all.
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
> alexander.elg...@external.t-systems.com wrote: > ... > > I am pretty shure, I tested the capability of filenames on a Linux (ext2) > > or Solaris (ufs) filesystem, a long time ago > > The outcome was, that you can use 254 different characters, except the '\0' > > and the '/'. Apple's older pre-Unix-backended MacOS models allowed "/" characters in filenames. > > But I agree, it is an annoyance it should be forbidden. ;) > > The person who invented that spaces and other unprintable characters were > allowed in > filenames and paths should be found, his PC and iPhone should be confiscated, > he should be > exiled to an isolated island in the middle of the Arctic Ocean, and he should > be nominated > for an IgNobel. Heheh. The makers of the Commodore 64 are off-limits because 8-bit gaming was practically revolutionized by it. (Yes, that's right, spaces were permitted in filenames on the Commodore 64, so this silliness came about before the PC and the Mac gained popularity.) > The person at Microsoft who decided that "C:\Program Files" was an > acceptable place to install programs should be sent along as his > butler. That really was a ridiculous decision, and lately they've taken it to new heights by adding yet another "C:/Program Files (x86)/" path that contains two spaces and parenthesis. Given that "C:/Documents and Settings/" has since been changed to "C:/Users/" I'll take that as a sign of hope that a "C:/Programs/" directory may be on the horizon (but I'm not holding my breath). Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Beautiful British Columbia, Canada http://www.inter-corporate.com/
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
Randolf Richardson wrote: alexander.elg...@external.t-systems.com wrote: ... I am pretty shure, I tested the capability of filenames on a Linux (ext2) or Solaris (ufs) filesystem, a long time ago The outcome was, that you can use 254 different characters, except the '\0' and the '/'. Apple's older pre-Unix-backended MacOS models allowed "/" characters in filenames. But I agree, it is an annoyance it should be forbidden. ;) The person who invented that spaces and other unprintable characters were allowed in filenames and paths should be found, his PC and iPhone should be confiscated, he should be exiled to an isolated island in the middle of the Arctic Ocean, and he should be nominated for an IgNobel. Heheh. The makers of the Commodore 64 are off-limits because 8-bit gaming was practically revolutionized by it. (Yes, that's right, spaces were permitted in filenames on the Commodore 64, so this silliness came about before the PC and the Mac gained popularity.) Thanks for this tidbit. I really thought that some marketing guru at Microsoft was the original culprit. The person at Microsoft who decided that "C:\Program Files" was an acceptable place to install programs should be sent along as his butler. That really was a ridiculous decision, and lately they've taken it to new heights by adding yet another "C:/Program Files (x86)/" path that contains two spaces and parenthesis. Given that "C:/Documents and Settings/" has since been changed to "C:/Users/" I'll take that as a sign of hope that a "C:/Programs/" directory may be on the horizon (but I'm not holding my breath). I wouldn't either, not without a couple of scuba-diving breathing bottles. If only because - on a Spanish Windows PC, the directory is called "C:\Archivos de Programas" - on a Portuguese Windows PC, it is called "C:\Arquivos de Programas" - on a greek Windows PC, it is "Αρχεία Εφαρμογών" - on a German Windows PC, it is called "C:\Programme" (that must definitely be an oversight) (And yes, I know that one can sometimes use %ProgramFiles% instead, but why would one have to do that ? Doesn't anyone who ever used a computer understand the word "programs" ?) In truth, Microsoft is not alone there. An Apache httpd by default installs under a (created) directory named "Apache Software Foundation" of all things. One would think that /they/ at least would know better. But no. Why make it simple when annoying will do ? Gimme C:\Perl anytime. I am ranting, and I know it. But the basic fact is that " ", in 99% of programming languages and OS shells, is a meta-character that normally acts as a separator between arguments, keywords, parameters, whatever. So electing to allow it in paths and filenames was a bad decision, which has cost so far millions of unproductive hours to be spent, and will cost many more millions before a reasonable parade is found. Whether it has been lost by good_programmers or bad_programmers is a moot point; there are only so many star programmers around, and the others need a job too. If the time lost because of that original mistake had been put to productive use instead, we might today have an environment where we just tell our computer in general terms what needs to be done, and it produces a first draft of the code to do it. Or we might have a HTTP 2.0 where the default character set is Unicode and UTF-8 is the default encoding. But I guess that this is another subject for another rant sometime.
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
On 28/02/13 01:12 PM, André Warnier wrote: Randolf Richardson wrote: In truth, Microsoft is not alone there. An Apache httpd by default installs under a (created) directory named "Apache Software Foundation" of all things. One would think that /they/ at least would know better. But no. Why make it simple when annoying will do ? Huh, I didn't know that. I would have thought that I would of screwed up at least once and found that out. During the dot com boom I worked as production DBA for a company where the developers didn't think it necessary to produce a text version of the deployment instructions. Since I couldn't read the MSWord document on a command line unix machine it didn't get deployed that week :( Funny the next week the instructions were in text in a file called README.txt :) Still had to deal with spaces in the mount point and filename though. :( Dave -- Dave Morgan Operations Manager, Cool Places In Canada http://www.coolplaces.ca dave.mor...@coolplaces.ca 403 288 8759 / 866 938 0516
AW: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
Dave Morgan [dave.mor...@coolplaces.ca] > Still had to deal with spaces in the mount point and filename though. :( No problem, just use -print0 ... $ uname -s SunOS $ find . -print0 find: bad option -print0 find: [-H | -L] path-list predicate-list $ so long: unset LC_ALL LC_COLLATE LANG LC_CTYPE LC_MESSAGES LC_MONETARY LC_NUMERIC NLS_LANG G r e e t i n g s, ;) Alexander -- Deutsche Telekom AG Seamless ICT Security Infrastructure & Management im Auftrag T-Systems International GmbH Dipl. Inf Alexander Elgert Langwadener Strasse 17 64625 Bensheim +49 176 22 717 661 (Mobil) +49 671 83419-12 (Tel) +49 671 83419-30 (Fax) E-Mail: alexander.elg...@gmx.de
