[33091] in Perl-Users-Digest
Perl-Users Digest, Issue: 4367 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Feb 10 05:17:24 2015
Date: Tue, 10 Feb 2015 02:17:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 10 Feb 2015 Volume: 11 Number: 4367
Today's topics:
eval <gravitalsun@hotmail.foo>
Re: eval (hymie!)
Re: eval <news@todbe.com>
Re: eval <see.my.sig@for.my.address>
Re: eval <derykus@gmail.com>
Re: eval <peter@makholm.net>
Re: eval <gravitalsun@hotmail.foo>
Re: eval <gravitalsun@hotmail.foo>
Re: First time installing a CPAN module; questions on s <see.my.sig@for.my.address>
Re: First time installing a CPAN module; questions on s <see.my.sig@for.my.address>
Re: First time installing a CPAN module; questions on s <rweikusat@mobileactivedefense.com>
Re: Traversing through sub dirs and read file contents <gamo@telecable.es>
Re: Whitespace in code <see.my.sig@for.my.address>
Re: Whitespace in code <news@todbe.com>
Why can I get away with this? <see.my.sig@for.my.address>
Re: Why can I get away with this? <news@todbe.com>
Re: Why can I get away with this? <see.my.sig@for.my.address>
Re: Why can I get away with this? <gravitalsun@hotmail.foo>
Re: Why can I get away with this? <m@rtij.nl.invlalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 10 Feb 2015 02:48:17 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: eval
Message-Id: <mbbkgf$lnf$1@news.ntua.gr>
I have problem to make this work correctly without warnings. I do not
want to "correct" the code or the data. I want the errors handled correctly
use strict; use warnings;
my $code = '$val >= 20 ? 1:0';
for my $val ('brak it', 30 , 10) {
my $result = eval "$code";
if ($@) {
print "code evaluation failed because $@\n"
}
else {
print "eval succeed, result is $result\n"
}
}
------------------------------
Date: 10 Feb 2015 03:03:46 GMT
From: hymie@lactose.homelinux.net (hymie!)
Subject: Re: eval
Message-Id: <54d97512$0$22801$882e7ee2@usenet-news.net>
In our last episode, the evil Dr. Lacto had captured our hero,
George Mpouras <gravitalsun@hotmail.foo>, who said:
>I have problem to make this work correctly without warnings.
Have you considered taking out the "use warnings" command?
--hymie! http://lactose.homelinux.net/~hymie hymie@lactose.homelinux.net
------------------------------
Date: Mon, 09 Feb 2015 21:56:14 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: eval
Message-Id: <mbc6ha$e9e$1@dont-email.me>
On 2/9/2015 16:48, George Mpouras wrote:
> I have problem to make this work correctly without warnings. I do not want to "correct" the code or the data. I want the errors handled correctly
>
>
>
> use strict; use warnings;
> my $code = '$val >= 20 ? 1:0';
>
> for my $val ('brak it', 30 , 10) {
> my $result = eval "$code";
if ($val !~ /^\d+$/) {
print "Skip alpha\n"; next;
}
> if ($@) {
> print "code evaluation failed because $@\n"
> }
> else {
> print "eval succeed, result is $result\n"
> }
> }
------------------------------
Date: Mon, 09 Feb 2015 22:09:56 -0800
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: eval
Message-Id: <882dndnWL_UvPUTJnZ2dnUVZ572dnZ2d@giganews.com>
On 2/9/2015 4:48 PM, George Mpouras wrote:
> I have problem to make this work correctly without warnings.
> I do not want to "correct" the code or the data. I want the
> errors handled correctly
>
>
>
> use strict; use warnings;
> my $code = '$val >= 20 ? 1:0';
>
> for my $val ('brak it', 30 , 10) {
> my $result = eval "$code";
>
> if ($@) {
> print "code evaluation failed because $@\n"
> }
> else {
> print "eval succeed, result is $result\n"
> }
> }
That won't trap any errors, because the error caused by 'brak it'
is a syntax error, trapped at run time BEFORE eval runs. And I
think it's actually tacitly corrected for you, by replacing
'brak it' with something safe like 0 or ''.
The following code, however, DOES invoke eval's error trapping,
by generating a RUN-TIME error (divide by zero), which puts an
error flag in $@:
#! /usr/bin/perl
use strict;
use warnings;
my $result;
my $code = q{$result = 17.3 / $val};
for my $val (7.4, 3.9, 0)
{
print "\n";
$@ = "XXXX";
eval "$code";
print "\$code = $code\n";
print "\$result = $result\n";
print "\$@ = $@\n";
}
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Tue, 10 Feb 2015 00:23:40 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: eval
Message-Id: <5c336af5-249f-4057-a387-524aa24024d0@googlegroups.com>
On Monday, February 9, 2015 at 4:48:18 PM UTC-8, George Mpouras wrote:
> I have problem to make this work correctly without warnings. I do not
> want to "correct" the code or the data. I want the errors handled correctly
>
>
>
> use strict; use warnings;
> my $code = '$val >= 20 ? 1:0';
>
> for my $val ('brak it', 30 , 10) {
> my $result = eval "$code";
^^^^^^
eval "no warnings; $code"
> ...
--
Charles DeRykus
------------------------------
Date: Tue, 10 Feb 2015 09:59:04 +0100
From: Peter Makholm <peter@makholm.net>
Subject: Re: eval
Message-Id: <87bnl2jg6f.fsf@vps1.hacking.dk>
George Mpouras <gravitalsun@hotmail.foo> writes:
> I have problem to make this work correctly without warnings. I do not
> want to "correct" the code or the data. I want the errors handled
> correctly
How du you expect your code to behave?
By reading the code it should probably print a warning in the initial
iteration, but otherwise print 'eval succeed' three times with the
results 0, 1, 0.
Isn't that what you get?
Remember that by design Perl will happily convert between integers and
stings for you. Thus it isn't really an error to compare a non-digit
string with an integer. But it is a common mistake, so Perl will warn
you if you ask it for warnings.
So the short answer is that if you want errors to be handled correctly
you have to start by icorreclty creating errors. One option would be to
handle all warnings as fatal errors. You can do that by replacing 'use
warnings' with 'use warnings qw(FATAL)'.
But note that by enabling FATAL warnings you risk problems with forward
portability. The perl developers might add new warnings which would the
break you previously working script.
//Makholm
------------------------------
Date: Tue, 10 Feb 2015 11:48:48 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: eval
Message-Id: <mbck51$13q3$1@news.ntua.gr>
On 10/2/2015 10:23, C.DeRykus wrote:
> On Monday, February 9, 2015 at 4:48:18 PM UTC-8, George Mpouras wrote:
>> I have problem to make this work correctly without warnings. I do not
>> want to "correct" the code or the data. I want the errors handled correctly
>>
>>
>>
>> use strict; use warnings;
>> my $code = '$val >= 20 ? 1:0';
>>
>> for my $val ('brak it', 30 , 10) {
>> my $result = eval "$code";
> ^^^^^^
> eval "no warnings; $code"
>> ...
>
>
it is a rulebase software . Using this, user will not get email
notification that must correct the his rule syntax
------------------------------
Date: Tue, 10 Feb 2015 11:54:18 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: eval
Message-Id: <mbckfb$14lr$1@news.ntua.gr>
On 10/2/2015 10:59, Peter Makholm wrote:
> use warnings qw(FATAL)
Very good I think what you suggest is doing the trick.
my $code = '$val >= 20 ? 1:0';
for my $val ('break it', 30 , 10) {
my $result = eval "use warnings qw(FATAL); $code";
if ($@) {
print "code evaluation failed because $@\n";
# sendmail etc
}
else {
print "eval succeed, result is $result\n"
}
}
------------------------------
Date: Mon, 09 Feb 2015 09:54:00 -0800
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: First time installing a CPAN module; questions on skipped tests.
Message-Id: <AJidnVD8RO6laUXJnZ2dnUVZ57w3t52d@giganews.com>
On 02/05/2015 04:32 AM, Justin C wrote:
> On 2015-02-05, Robbie Hatley <see.my.sig@for.my.address> wrote:
> > I got a hankering to have statistics function calls available
> > so I don't have to write my own routines for mean, median, mode,
> > standard deviation, etc. So I downloaded a CPAN module:
> > Statistics::Descriptive as a "*.tar.gz" file.
>
> I don't know what OS you're working on, but if you're on Linux your
> distro may have a pre-packaged binary....
I do most of my perl programming on buses these days, so by necessity
that's on my notebook. Perl is running on Bash, on Cygwin, on mintty,
on Windows 8.1. So in this configuration, Bash is basically a shell
on a shell on a shell on Windows. So the user interface is Unix-like,
but the underlying OS is Microsoft Windows 8.1.
(Vist http://www.cygwin.com/ for more on Cygwin.)
> Unless you require a more recent version than your distro has
> available this is likely the most simple method of getting the
> modules you want.
Cygwin uses "distros" and a "package manager" like Unix does,
but while it includes all of the "standard" Perl library modules,
it doesn't include much from CPAN. They apparently intend the user
to manually download and install any modules he wants from "CPAN.org".
> Perl modules, under debian are always 'lib' then 'module name'
> (susbtituting '::' for '-') and ending with '-perl'. For example:
> libarchive-zip-perl is Archive::Zip
> libdbd-mysql-perl is DBD::MySQL
Cygwin annoyingly changes the nomenclature. For example, "Data::Dumper"
isn't listed as "lib-data-dumper-perl", but as "perl-Data-Dump".
And "Statistics::Descriptive" isn't listed at all. (Same with most CPAN
stuff.)
> A bonus of using your distro's pre-packaged version is that any
> dependency issues and confilicts have been resolved for you.
>
> One last reason to prefer the distro's package is that there is
> a risk of breaking your system if you install a newer version of
> a module the system relies upon, and it's not fully backward
> compatible.
Yes, those are problems will will have to be diagnosed and fixed
manually if they arise. (By going to cpan.org and tracing the
dependency trees and see which modules/versions depend on which
modules/versions. Annoying, yes.)
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
https://www.facebook.com/robbie.hatley
------------------------------
Date: Mon, 09 Feb 2015 09:55:46 -0800
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: First time installing a CPAN module; questions on skipped tests.
Message-Id: <AJidnVP8RO4_aUXJnZ2dnUVZ57w3t52d@giganews.com>
On 02/05/2015 07:19 AM, Rainer Weikusat wrote:
> You might want to consider using 'the cpan shell' for this
> [installing CPAN modules] which also provides 'nice features'
> like installing dependencies automatically.The traditional
> way of doing so is
> perl -MCPAN -e shell
Ok, on searching CPAN's list of 27K+ modules I see hundreds with
CPAN in the name, but only one that's called just "CPAN":
CPAN-2.05.tar.gz , maintained by an Andreas Koenig.
Is that the one you mean?
(I'm tempted to install Cygwin's own Perl module dependency
checker, called "perl-Module-ScanDeps: Perl recursive dependency
scanner module", but I think I'll try CPAN's "CPAN" module first.)
> ... I'd usually skip that [test phase] entirely: If the code
> doesn't work for me, I'll notice this soon enough, and whether
> or not it works in some artificial environment solely intended
> for demonstrating that it does is no concern of mine....
That's the age old difference between alpha and beta testing:
what passes alpha in the lab always has chance of failing beta
in field, yes. But I tend to prefer doing alpha tests on things
anyway. Provides an extra layer of problem avoidance.
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
https://www.facebook.com/robbie.hatley
------------------------------
Date: Mon, 09 Feb 2015 21:48:01 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: First time installing a CPAN module; questions on skipped tests.
Message-Id: <87386esqni.fsf@doppelsaurus.mobileactivedefense.com>
Robbie Hatley <see.my.sig@for.my.address> writes:
> On 02/05/2015 07:19 AM, Rainer Weikusat wrote:
>> You might want to consider using 'the cpan shell' for this
>> [installing CPAN modules] which also provides 'nice features'
>> like installing dependencies automatically.The traditional
>> way of doing so is
>> perl -MCPAN -e shell
>
> Ok, on searching CPAN's list of 27K+ modules I see hundreds with
> CPAN in the name, but only one that's called just "CPAN":
> CPAN-2.05.tar.gz , maintained by an Andreas Koenig.
> Is that the one you mean?
"It seems so". All versions I've ever used were automatically installed
together with perl.
[...]
>> ... I'd usually skip that [test phase] entirely: If the code
>> doesn't work for me, I'll notice this soon enough, and whether
>> or not it works in some artificial environment solely intended
>> for demonstrating that it does is no concern of mine....
>
> That's the age old difference between alpha and beta testing:
> what passes alpha in the lab always has chance of failing beta
> in field, yes. But I tend to prefer doing alpha tests on things
> anyway. Provides an extra layer of problem avoidance.
Insofar my understanding of the terms 'alpha' and 'beta' goes, the
former refers to a state where 'the software' (whatever it is) isn't
entirely useles anymore but planned features are still being implemented
and the latter to one where the implementation of feature has been
completed but is not yet stable enough to be considered generally
usable. Regardless of this, an integrated test suite may be of some use
when modifying the code itself (but it may as well not, at least not
without extending it) but doesn't provide anything useful to someone who
just wants to use it (except maybe 'warm, fuzzy feeling'): A failing
test doesn't mean the code won't work for an actual use case and vice
versa.
------------------------------
Date: Mon, 09 Feb 2015 09:27:31 +0100
From: gamo <gamo@telecable.es>
Subject: Re: Traversing through sub dirs and read file contents
Message-Id: <mb9r1p$5iq$4@speranza.aioe.org>
El 08/02/15 a las 14:16, smilesonisamal@gmail.com escribió:
> On Saturday, February 7, 2015 at 10:13:27 PM UTC+5:30, George Mpouras wrote:
>> On 7/2/2015 7:58 πμ, smilesonisamal@gmail.com wrote:
>>> Hi all,
>>> I have written a small program to recursively go through the sub dirs(~400) and read the file
contents from each of the sub-dirs. Currently the program runs very slow
in win7 32 bit . Is there a
way I can speed up the execution?
>>>
>>> Regards
>>> Pradeep
>>>
>>
>> Your code have some errors; also it is not clear if you want to read a
>> specific file or all of them.
>>
>> What exactly do you want to do for every file ?
>> What exactly do you want to do for every directory ?
>
> Sorry for not being clear.
> Each sub directories have lot of files and so I want to read at least one file to check the files are
readable are not for simplicity. For reading all the files inside the
sub-directories will take lot of
time as there are lot of files and requires sophisticated algorithms
for fast performance.
>
> I dont want to perform any special operations on the files/dirs except reading it after finding the file.
>
> For exp:
> Base-dir -> Exp C:\Perl\Bin
> Lets say there is a file inside directory called C:\Perl\bin\ppm\ppm-shell.bat.
>
> So my program should traverse through all the files starting from C:\Perl\bin directory and find the
file ppm-shell.bat and reads it.
>
I can't help you 100% because I don't use windows.
But you can adapt something like:
#!/usr/bin/perl
use warnings;
# no warnings 'recursion';
use strict;
my $filename = $ARGV[0] // "core";
my $dir = '/';
chdir $dir;
go ($dir);
sub go{
my ($dir) = shift;
# print "DIR: $dir\n";
my @l = glob (".* *");
for my $i (@l){
next if ($i =~ /^\.\.$/ || $i =~ /^\.$/);
if ($i eq $filename){
# if (-f $filename){
# unless (-l $filename || -p $filename || -s $filename){
# double check
print "SUCCESS: $dir$filename\n"; # or whatever
# }
# }
}
my $newdir = $dir.$i."/";
next unless -d $newdir;
next if ($newdir =~ /\/proc\// || $newdir =~ /\/sys\//);
if ( (chdir $newdir) ) {
go ($newdir);
}
}
}
HTH
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Mon, 09 Feb 2015 09:57:39 -0800
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: Whitespace in code
Message-Id: <AJidnVL8RO6OaEXJnZ2dnUVZ57w3t52d@giganews.com>
On 02/08/2015 02:12 AM, Peter J. Holzer wrote:
> ...Perl generally doesn't care about line endings, but the OS may: for
> example, a CR in the shebang line can prevent execution on Linux...
SNORT!!! Yes, I noticed. That had me pulling my hair out and yelling
curses at my computer for an hour because none of the Perl scripts
I'd written on Windows were working on Linux. Then I got to thinking
"It's just text files, so what's the difference between Windows text
files and Linux text files?" and the answer hit me like a ton of bricks.
Since then, I've switched to a different text editor on my Win8.1
notebook, "Notepad++" (see "http://www.notepad-plus-plus.org/" for
more info), and I keep it's line endings set to "Linux" so scripts
I write on Windows are now usable on Linux. (NP++ also has syntax
highlighting for a variety of programming languages, incl Perl,
and it's user editable, so one can add new keywords -- eg, "say" --
as they get added to Perl.)
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
https://www.facebook.com/robbie.hatley
------------------------------
Date: Mon, 09 Feb 2015 21:50:45 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: Whitespace in code
Message-Id: <mbc671$dkc$1@dont-email.me>
On 2/9/2015 09:57, Robbie Hatley wrote:
>
> Since then, I've switched to a different text editor on my Win8.1
> notebook, "Notepad++" (see "http://www.notepad-plus-plus.org/" for
> more info), and I keep it's line endings set to "Linux" so scripts
> I write on Windows are now usable on Linux. (NP++ also has syntax
> highlighting for a variety of programming languages, incl Perl,
> and it's user editable, so one can add new keywords -- eg, "say" --
> as they get added to Perl.)
Haven't tried it, but I would suggest you try a Win32 native port of
Vim or Emacs - I've been using vim (gvim) the entire time I've been
using a PC and it's predecessor (vi) the entire time I was on UNIX.
Emacs is probably more powerful, but I'm very used to the vi feel and
would have trouble switching. http://www.vim.org/download.php
set fileformats=unix or set fileformats=unix,dos in your .vimrc file
will handle line endings - all of my files have UNIX line endings and
that helps when you upload to a UNIX website server.
I would also recommend using a UNIX shell on Windows:
ftp://ftp.astron.com/pub/tcsh/ or possibly another UNIX shell port
instead of the dumb cmd.exe.
------------------------------
Date: Mon, 09 Feb 2015 21:28:07 -0800
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Why can I get away with this?
Message-Id: <5O6dnYFKgbV4C0TJnZ2dnUVZ57ydnZ2d@giganews.com>
I noticed a puzzling comment in The Camel Book a few days ago:
"While it's not 'nice' to use a newline as a file name extension,
that doesn't mean it can't happen." I thought to myself, "But
that's impossible, at least in Windows... isn't it?"
So, I was inspired to write the following absolutely psychotic
Perl script to test this out (I'm not sure if you should even
try running this at home; I can't guarantee what would happen):
#! /usr/bin/perl
use v5.14;
use strict;
use warnings;
my $filename = "\a\e\f.\n\r\t\0";
open MYFILE, ">", $filename;
print MYFILE "Oh, my.\n";
close MYFILE;
open MYFILE, "<", $filename;
print while <MYFILE>;
close MYFILE;
exit 0;
To my surprise, that script not only compiles and runs without
error, but successfully creates a file then reads back its
contents, even though the file name consists almost solely of
characters which I thought were illegal in file names!
Why can I get away with this?
Does this have to do with Perl bypassing the OS's (Win 8.1
on the machine I tested this on) inherent file name validity
checking, and accessing the file system's file tables directly?
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Mon, 09 Feb 2015 22:03:24 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: Why can I get away with this?
Message-Id: <54D99F2C.4060004@todbe.com>
On 2/9/2015 21:28, Robbie Hatley wrote:
>
> I noticed a puzzling comment in The Camel Book a few days ago:
> "While it's not 'nice' to use a newline as a file name extension,
> that doesn't mean it can't happen." I thought to myself, "But
> that's impossible, at least in Windows... isn't it?"
> So, I was inspired to write the following absolutely psychotic
> Perl script to test this out (I'm not sure if you should even
> try running this at home; I can't guarantee what would happen):
>
> #! /usr/bin/perl
> use v5.14;
> use strict;
> use warnings;
> my $filename = "\a\e\f.\n\r\t\0";
> open MYFILE, ">", $filename;
> print MYFILE "Oh, my.\n";
> close MYFILE;
> open MYFILE, "<", $filename;
> print while <MYFILE>;
> close MYFILE;
> exit 0;
>
> To my surprise, that script not only compiles and runs without
> error, but successfully creates a file then reads back its
> contents, even though the file name consists almost solely of
> characters which I thought were illegal in file names!
>
> Why can I get away with this?
>
> Does this have to do with Perl bypassing the OS's (Win 8.1
> on the machine I tested this on) inherent file name validity
> checking, and accessing the file system's file tables directly?
Illegal characters in Windows filenames:
\ / ? : * " > < |
And 259 character max path len.
------------------------------
Date: Mon, 09 Feb 2015 23:23:41 -0800
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: Why can I get away with this?
Message-Id: <SeidnWmECLdmLETJnZ2dnUVZ572dnZ2d@giganews.com>
On 2/9/2015 10:03 PM, $Bill wrote:
> Illegal characters in Windows filenames:
> \ / ? : * " > < |
> And 259 character max path len.
Yikes. That's all they disallow??? Then file name characters could be
bell sounds, form-feed commands, "end of transmission" signals,
"Negative Acknowledgement" characters, Hanzi, Tamil, etc, etc, etc.
This is blasphemy! This is madness!
Then.....
I could have a file named.....
#! /usr/bin/perl
use v5.14;
use strict;
use warnings;
use utf8;
binmode STDOUT, ":encoding(UTF-8)";
use charnames qw(:full);
our $FileName = "\x01犬草\n\x02\N{MALE SIGN}猫\x03\x04\a\0";
print "\n\$FileName = $FileName\n\n";
Oh, my.
Wait, there's actually one other character which *MUST* be disallowed
in file names in nearly every file system, and that's '\0', except
perhaps as the vary last character of a file name. The reason I say that
is, if you put '\0' at the beginning or middle of a file name, when Perl
or the OS tries to read back the file name, it stops reading characters
when it hits the null terminator, so that THIS file name:
$FileName = "斊詥觬榹苵\0匞寨蹼粿砺";
would be foreshortened on readback to:
$FileName = "斊詥觬榹苵";
and give "file not found" errors.
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Tue, 10 Feb 2015 09:59:26 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Why can I get away with this?
Message-Id: <mbcdnv$ieg$1@news.ntua.gr>
On 10/2/2015 07:28, Robbie Hatley wrote:
>
> Perl script to test this out (I'm not sure if you should even
> characters which I thought were illegal in file names!
>
at Linux there are only two disallowed characters \0 and /
------------------------------
Date: Tue, 10 Feb 2015 09:11:12 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Why can I get away with this?
Message-Id: <02roqb-v4c.ln1@news.rtij.nl>
On Mon, 09 Feb 2015 23:23:41 -0800, Robbie Hatley wrote:
> Wait, there's actually one other character which *MUST* be disallowed in
> file names in nearly every file system, and that's '\0', except perhaps
> as the vary last character of a file name. The reason I say that is, if
> you put '\0' at the beginning or middle of a file name, when Perl or the
> OS tries to read back the file name, it stops reading characters when it
> hits the null terminator, so that THIS file name:
>
> $FileName = "斊詥觬榹苵\0匞寨蹼粿砺";
>
> would be foreshortened on readback to:
>
> $FileName = "斊詥觬榹苵";
>
> and give "file not found" errors.
I guess you have a C background, because the above is not logical at all.
However, it is still true, see https://msdn.microsoft.com/en-us/library/
aa365247%28VS.85%29
M4
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4367
***************************************
