[33093] in Perl-Users-Digest
Perl-Users Digest, Issue: 4369 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Feb 12 14:09:19 2015
Date: Thu, 12 Feb 2015 11:09:05 -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 Thu, 12 Feb 2015 Volume: 11 Number: 4369
Today's topics:
Re: First time installing a CPAN module; questions on s <hjp-usenet3@hjp.at>
Re: First time installing a CPAN module; questions on s <rweikusat@mobileactivedefense.com>
Re: I am trying to find the programmer that wrote the P <m@rtij.nl.invlalid>
Re: recursive regex <m@rtij.nl.invlalid>
Re: recursive regex <gravitalsun@hotmail.foo>
Re: recursive regex <rweikusat@mobileactivedefense.com>
Re: recursive regex <rweikusat@mobileactivedefense.com>
Re: recursive regex <gravitalsun@hotmail.foo>
Re: recursive regex <rweikusat@mobileactivedefense.com>
The future of CGI.pm (was: I am trying to find the prog <hjp-usenet3@hjp.at>
Re: The future of CGI.pm <rweikusat@mobileactivedefense.com>
Re: The future of CGI.pm <netnews@invalid.com>
Re: The future of CGI.pm <rweikusat@mobileactivedefense.com>
Re: Traversing through sub dirs and read file contents <hjp-usenet3@hjp.at>
Re: Traversing through sub dirs and read file contents <m@rtij.nl.invlalid>
Re: Traversing through sub dirs and read file contents <bauhaus@futureapps.invalid>
Re: Why can I get away with this? <hjp-usenet3@hjp.at>
Re: Why can I get away with this? <m@rtij.nl.invlalid>
Re: Why can I get away with this? <m@rtij.nl.invlalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 11 Feb 2015 22:10:32 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: First time installing a CPAN module; questions on skipped tests.
Message-Id: <slrnmdnha8.5sv.hjp-usenet3@hrunkner.hjp.at>
On 2015-02-09 21:48, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> 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'):
While this will be true in most cases, the exceptions are numerous
enough that I will always run the test cases and investigate any
failures. Many Perl Modules aren't self-contained but interfaces to some
external system (e.g. a (shared) library, a server, etc.). A
well-designed test suite for such a module also acts as an integration
test suite, it will tell me whether it will work with the specific
installation of the external system I want to use it with. A rather
notorious example is DBD::Oracle, which is supposed to work with any
version of the Oracle client libraries against any version of the Oracle
RDBMS (supported by the client library). Given that both the client and
the server are available for many platforms in several flavours and that
the sysadmin can fall into several subtle (and not so subtle) traps
during installation, running the test suite is very helpful in smoking
out problems before the new version is installed.
> A failing test doesn't mean the code won't work for an actual use case
> and vice versa.
That's always true. But it doesn't make tests useless.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Wed, 11 Feb 2015 21:51:11 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: First time installing a CPAN module; questions on skipped tests.
Message-Id: <8761b86rsg.fsf@doppelsaurus.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2015-02-09 21:48, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>> 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'):
>
> While this will be true in most cases, the exceptions are numerous
> enough that I will always run the test cases and investigate any
> failures. Many Perl Modules aren't self-contained but interfaces to some
> external system (e.g. a (shared) library, a server, etc.). A
> well-designed test suite for such a module also acts as an integration
> test suite, it will tell me whether it will work with the specific
> installation of the external system I want to use it with. A rather
> notorious example is DBD::Oracle, which is supposed to work with any
> version of the Oracle client libraries against any version of the Oracle
> RDBMS (supported by the client library). Given that both the client and
> the server are available for many platforms in several flavours and that
> the sysadmin can fall into several subtle (and not so subtle) traps
> during installation, running the test suite is very helpful in smoking
> out problems before the new version is installed.
I can't really comment on that as I'm not dealing with environments
where 'test suites' may be useful as self-defense mechanism against
something someone else got wrong
>> A failing test doesn't mean the code won't work for an actual use case
>> and vice versa.
>
> That's always true. But it doesn't make tests useless.
however, I didn't find anything useful in 'running tests' so far.
------------------------------
Date: Thu, 12 Feb 2015 11:19:07 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: I am trying to find the programmer that wrote the Perl scripts for QuizPlease in about 1997.
Message-Id: <r9buqb-s82.ln1@news.rtij.nl>
On Wed, 11 Feb 2015 17:13:20 +0200, George Mpouras wrote:
> if you know what you are doing you can have far better performance than
> using these http frameworks.
Ah, no.
The overhead of these frameworks can be very, extremely low, almost as
low as raw CGI. Theoretically raw CGI can be faster, as you can dispatch
faster. But that is the only area where raw CGI can be faster.
But that argument holds only for very simple web servers, where using CGI
may already be a better choice for other reasons. As soon as you need any
dispatch mechanism, it's likely that any advantage is lost right there
and then.
And where frameworks have, not the edge, but a huge advantage is that I
can deploy in different ways. I can achieve tremendous performance using
scaled out services that is impossible to achieve using raw CGI.
Well not impossible, but then I have to write a mechanism to dispatch
requests to application servers, do load balancing, keep track of which
application servers die, etc, etc. I don't want to do that. Others have
already done that. There are libraries for that. They are called http
frameworks. It's doubtful I can do better than these mature frameworks.
So unless you are measuring response times on unloaded servers -- a
meaningless statistic in the real world --, raw CGI can never achieve the
performance you can achieve using a good framework. Not by a little
margin, by a huge margin.
> Usually you only want to parse the url arguments or write a service. For
> me CGI is the no 1 choice.
I prefer Dancer for anything serious, but use CGI as well all the time. I
have no problem installing it from CPAN though.
M4
------------------------------
Date: Thu, 12 Feb 2015 00:14:07 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: recursive regex
Message-Id: <va4tqb-3lm.ln1@news.rtij.nl>
On Wed, 11 Feb 2015 15:40:24 +0000, Rainer Weikusat wrote:
> my $re = '(\$(?:'.join('|', map { substr($_, 1) } sort { length($b) <=>
> length($a) } keys(%macro)).'))';
my $re = '(\$(?:'.join('|', map { substr($_, 1) } reverse sort keys(
%macro)).'))';
should work as well. If it is better, I leave up to you.
M4
------------------------------
Date: Thu, 12 Feb 2015 02:07:51 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: recursive regex
Message-Id: <mbgqsq$1rag$1@news.ntua.gr>
On 12/2/2015 1:14 πμ, Martijn Lievaart wrote:
> On Wed, 11 Feb 2015 15:40:24 +0000, Rainer Weikusat wrote:
>
>> my $re = '(\$(?:'.join('|', map { substr($_, 1) } sort { length($b) <=>
>> length($a) } keys(%macro)).'))';
>
> my $re = '(\$(?:'.join('|', map { substr($_, 1) } reverse sort keys(
> %macro)).'))';
>
> should work as well. If it is better, I leave up to you.
>
> M4
>
there is no absolute correct solution because you
always must make an assumtion of who wins.
the sorter , the a-z order etc
------------------------------
Date: Thu, 12 Feb 2015 03:53:08 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: recursive regex
Message-Id: <87k2znaiqj.fsf@doppelsaurus.mobileactivedefense.com>
Martijn Lievaart <m@rtij.nl.invlalid> writes:
> On Wed, 11 Feb 2015 15:40:24 +0000, Rainer Weikusat wrote:
>
>> my $re = '(\$(?:'.join('|', map { substr($_, 1) } sort { length($b) <=>
>> length($a) } keys(%macro)).'))';
>
> my $re = '(\$(?:'.join('|', map { substr($_, 1) } reverse sort keys(
> %macro)).'))';
>
> should work as well. If it is better, I leave up to you.
What made you think this wasn't obvious?
------------------------------
Date: Thu, 12 Feb 2015 15:51:24 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: recursive regex
Message-Id: <877fvnp1qb.fsf@doppelsaurus.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>> On Wed, 11 Feb 2015 15:40:24 +0000, Rainer Weikusat wrote:
>>
>>> my $re = '(\$(?:'.join('|', map { substr($_, 1) } sort { length($b) <=>
>>> length($a) } keys(%macro)).'))';
>>
>> my $re = '(\$(?:'.join('|', map { substr($_, 1) } reverse sort keys(
>> %macro)).'))';
>>
>> should work as well. If it is better, I leave up to you.
>
> What made you think this wasn't obvious?
I don't really feel comfortable with leaving it at that. In order to
ensure that the longest match wins when matching happens from
left-to-right, it's sufficient to sort the keys by length. Sorting them
'as strings' instead will work, too, provided that a string which is a
prefix of another string is 'globally' considered to be 'alphabetically
smaller' than the other, it just does a (relative) lot of useless work
by comparing string contents which don't really matter and is slightly
obfuscated because it suggests that they do matter. OTOH, it's less code
and the time/ effort need to create the regex very likely doesn't matter
for the problem at hand.
------------------------------
Date: Thu, 12 Feb 2015 19:17:04 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: recursive regex
Message-Id: <mbin6k$hsg$1@news.ntua.gr>
On 12/2/2015 5:51 μμ, Rainer Weikusat wrote:
> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>>> On Wed, 11 Feb 2015 15:40:24 +0000, Rainer Weikusat wrote:
>>>
>>>> my $re = '(\$(?:'.join('|', map { substr($_, 1) } sort { length($b) <=>
>>>> length($a) } keys(%macro)).'))';
>>>
>>> my $re = '(\$(?:'.join('|', map { substr($_, 1) } reverse sort keys(
>>> %macro)).'))';
>>>
>>> should work as well. If it is better, I leave up to you.
>>
>> What made you think this wasn't obvious?
>
> I don't really feel comfortable with leaving it at that. In order to
> ensure that the longest match wins when matching happens from
> left-to-right, it's sufficient to sort the keys by length. Sorting them
> 'as strings' instead will work, too, provided that a string which is a
> prefix of another string is 'globally' considered to be 'alphabetically
> smaller' than the other, it just does a (relative) lot of useless work
> by comparing string contents which don't really matter and is slightly
> obfuscated because it suggests that they do matter. OTOH, it's less code
> and the time/ effort need to create the regex very likely doesn't matter
> for the problem at hand.
>
>
and the speed winner is ....
use Benchmark qw(cmpthese);
my %macro=(
'$MON' =>'00',
'$MONITOR' =>'11',
'$LEVEL' =>'22',
'$CONDITION' =>'33',
'$EPOCHTIMEOFEVENT'=>'44',
'$COMMANDOUTPUT' =>'55',
'$DESCRIPTION' =>'66');
my $reg_bylength = '(\$(?:'.join('|', map { substr($_, 1) } sort {
length($b) <=> length($a) } keys(%macro)).'))';
my $reg_byname = '(?:\\'.join('|\\', reverse sort keys %macro).')';
$reg_bylength =~qr/$reg_bylength/;
$reg_byname =~qr/$reg_byname/;
my $string = 'hello $MONITORsys$LEVEL $CONDITION world! $A $MONATIR';
cmpthese(300000,{
byname => sub{ $_=$string; s/$reg_byname/$macro{$&}/ge },
bylength => sub{ $_=$string; s/$reg_bylength/$macro{$&}/ge}}
);
------------------------------
Date: Thu, 12 Feb 2015 17:50:00 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: recursive regex
Message-Id: <87r3tvnho7.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> On 12/2/2015 5:51 μμ, Rainer Weikusat wrote:
>> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>>> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>>>> On Wed, 11 Feb 2015 15:40:24 +0000, Rainer Weikusat wrote:
>>>>
>>>>> my $re = '(\$(?:'.join('|', map { substr($_, 1) } sort { length($b) <=>
>>>>> length($a) } keys(%macro)).'))';
>>>>
>>>> my $re = '(\$(?:'.join('|', map { substr($_, 1) } reverse sort keys(
>>>> %macro)).'))';
>>>>
>>>> should work as well. If it is better, I leave up to you.
>>>
>>> What made you think this wasn't obvious?
>>
>> I don't really feel comfortable with leaving it at that. In order to
>> ensure that the longest match wins when matching happens from
>> left-to-right, it's sufficient to sort the keys by length. Sorting them
>> 'as strings' instead will work, too, provided that a string which is a
>> prefix of another string is 'globally' considered to be 'alphabetically
>> smaller' than the other, it just does a (relative) lot of useless work
>> by comparing string contents which don't really matter and is slightly
>> obfuscated because it suggests that they do matter. OTOH, it's less code
>> and the time/ effort need to create the regex very likely doesn't matter
>> for the problem at hand.
>>
>>
>
> and the speed winner is ....
.... absolutely not important for a contrived example. BTW, something
you might want take into account:
WARNING: Once Perl sees that you need one of $&, "$`", or "$'"
anywhere in the program, it has to provide them for every
pattern match. This may substantially slow your program. Perl
uses the same mechanism to produce $1, $2, etc, so you also pay
a price for each pattern that contains capturing parentheses.
(To avoid this cost while retaining the grouping behaviour, use
the extended regular expression "(?: ... )" instead.) But if
you never use $&, "$`" or "$'", then patterns without capturing
parentheses will not be penalized. So avoid $&, "$'", and "$`"
if you can
I haven't tested if this really makes a difference, though.
------------------------------
Date: Wed, 11 Feb 2015 21:43:43 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: The future of CGI.pm (was: I am trying to find the programmer that wrote the Perl scripts for QuizPlease in about 1997.)
Message-Id: <slrnmdnfnv.5sv.hjp-usenet3@hrunkner.hjp.at>
On 2015-02-11 11:15, Justin C <justin.1410@purestblue.com> wrote:
> CGI is deprecated. It'll be pulled from core (if it hasn't been
> already). I'd suggest CGI::Application but it depends on CGI :/
It's not dead yet! But even the current maintainer says "Please stop":
https://www.youtube.com/watch?v=BBYag43ojjM
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Wed, 11 Feb 2015 21:13:02 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: The future of CGI.pm
Message-Id: <87a90k6tk1.fsf@doppelsaurus.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2015-02-11 11:15, Justin C <justin.1410@purestblue.com> wrote:
>> CGI is deprecated. It'll be pulled from core (if it hasn't been
>> already). I'd suggest CGI::Application but it depends on CGI :/
>
> It's not dead yet! But even the current maintainer says "Please stop":
>
> https://www.youtube.com/watch?v=BBYag43ojjM
I've watched about half of this but the content is really succinctly expressed in
the (almost) opening statements: "I took this over because I thought this
would help me learn how to migrate away from it." (paraphrase).
IMNSHO, CGI.pm is an aesthetically unpleasant convenience: It can parse
CGI-parameters, so one doesn't have to write that oneself. It has enough
support for 'HTML generation' that it's possible to build something
useful on that (I have enough experience with 'templating
baby-languages' that I'm sure that I certainly don't want to use
something that restricted if I'm not required to). I never thought it
was complicated ...
------------------------------
Date: Wed, 11 Feb 2015 18:21:34 -0800
From: HASM <netnews@invalid.com>
Subject: Re: The future of CGI.pm
Message-Id: <8761b7q381.fsf@127.0.0.1>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
>> CGI is deprecated. It'll be pulled from core (if it hasn't been
>> already). I'd suggest CGI::Application but it depends on CGI :/
> It's not dead yet! But even the current maintainer says "Please stop":
> https://www.youtube.com/watch?v=BBYag43ojjM
I must have about 100 cgi.pm scripts running.
Hopefully is not going to disappear before I have to hand them over :-)
-- HASM
------------------------------
Date: Thu, 12 Feb 2015 15:32:10 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: The future of CGI.pm
Message-Id: <87bnkzp2md.fsf@doppelsaurus.mobileactivedefense.com>
HASM <netnews@invalid.com> writes:
> "Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
>>> CGI is deprecated. It'll be pulled from core (if it hasn't been
>>> already). I'd suggest CGI::Application but it depends on CGI :/
>
>> It's not dead yet! But even the current maintainer says "Please stop":
>> https://www.youtube.com/watch?v=BBYag43ojjM
>
> I must have about 100 cgi.pm scripts running.
> Hopefully is not going to disappear before I have to hand them over :-)
There's something like 'version 4 of CGI.pm' (seems to be current) which
is mostly about fixing bugs and getting rid of seriously ancient
compatibilty features[*] and at least a version 5 is also planned. That
is supposed to 'deprecate' the HTML-generation routines, possibly
moving them to 'individual modules'. I stopped watching the talk at that
point because the guy then started pimping template toolkit and unless
one's needs are very simple, something whose highest-level constructs[**]
are basic loops and conditionals is not a very good choice for anything.
[*] cgi-lib.pl and mod_perl version 1.x. According to himself, the
maintainer originally wanted to remove mod_perl support altogether but
found that unnamed people he didn't feel comfortable with ignoring were
using it.
[**] I've looked for and found
http://www.template-toolkit.org/docs/manual/VMethods.html#section_Defining_Custom_Virtual_Methods
before writing this. In time, this will gain support for (hierarchical)
namespaces, modularization and OOP and shed the bizarre 1970s-style
constructs. I'll wait until the before considering it seriously (OTOH, I
think Perl is a great language for programming and I doubt this will
ever match it)/
------------------------------
Date: Wed, 11 Feb 2015 21:58:47 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Traversing through sub dirs and read file contents
Message-Id: <slrnmdngk7.5sv.hjp-usenet3@hrunkner.hjp.at>
On 2015-02-09 08:00, Georg Bauhaus <bauhaus@futureapps.invalid> wrote:
> On 08.02.15 22:01, Henry Law wrote:
>> On 08/02/15 14:09, Rainer Weikusat wrote:
>>> File::Find is a walking horror
>>
>> Well, IANPH but I use it all the time for doing what it's designed to
>> do: follow a tree and let me do whatever I want with directories and
>> files it finds. It may have some exotic fault that I wot not of, but
>> for the base use case it works flawlessly.
>>
>
> One thing the OP mentioned was "a lot of files" per directory.
> Then, looking at
>
> @filenames = readdir DIR;
>
> in File::Find, isn't that indicative of a classic design choice
> that may not be optimal (or not working at all), in the OP's case?
That depends on what the OP means by "a lot of files". Hundreds?
Thousands? Tens of thousands? Millions? Billions? Probably hundreds or
thousands. And it probably doesn't matter unless we get into at least
the 100k to 1M files per directory range, possibly even higher.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Thu, 12 Feb 2015 00:41:35 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Traversing through sub dirs and read file contents
Message-Id: <fu5tqb-3lm.ln1@news.rtij.nl>
On Wed, 11 Feb 2015 21:58:47 +0100, Peter J. Holzer wrote:
> That depends on what the OP means by "a lot of files". Hundreds?
> Thousands? Tens of thousands? Millions? Billions? Probably hundreds or
> thousands. And it probably doesn't matter unless we get into at least
> the 100k to 1M files per directory range, possibly even higher.
As a side note, current file systems may handle that many files in a
directory gracefully, but maybe not. Older file systems most definitely
did not handle such situations well, if at all.
So the question may very well be whether to support that or to declare it
'to obscene' to support. I find it a rare to non-existent condition.
[ I have used disk editors to 'erase' directories on ext2 file systems
followed by an fsck. That would at least finish in finite time. An rm *
in the offending directory (or anything else I could think of using
syscalls) would literally take days. And that was less than 1M files. On
a fast machine (for those days) with fast I/O with 10K SCSI disks in
optimal RAID. ]
M4
------------------------------
Date: Thu, 12 Feb 2015 13:34:49 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: Traversing through sub dirs and read file contents
Message-Id: <mbi6k4$3kk$1@dont-email.me>
On 12.02.15 00:41, Martijn Lievaart wrote:
> On Wed, 11 Feb 2015 21:58:47 +0100, Peter J. Holzer wrote:
>
>> That depends on what the OP means by "a lot of files". Hundreds?
>> Thousands? Tens of thousands? Millions? Billions? Probably hundreds or
>> thousands. And it probably doesn't matter unless we get into at least
>> the 100k to 1M files per directory range, possibly even higher.
>
> As a side note, current file systems may handle that many files in a
> directory gracefully, but maybe not.
Exactly. Add to that an increasing number of virtual machine file
systems. ls | while ... op ... in Unix shells or some form of
explicit iteration in Perl (or in general) may take a few more
characters to program, but they work nice(1)ly and efficiently.
Any of the shorter expressions, such as `$ op *' in Unix shells
or `map { op } @big_I/O_thing' in Perl, may look nice in
a publication, but their brevity ignores TIME and SPACE.
The lack of suitably optimizing lazy evaluation of list-ish
objects in both sh/Unix and Perl suggest processing items
one by one. Sometimes strict iteration seems to be needed even
with optimizing Haskell compilers, which have the most advanced
lazy evaluation techniques, AFAIK.
And that's about one of the many lines in File::Find.
------------------------------
Date: Wed, 11 Feb 2015 21:50:35 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Why can I get away with this?
Message-Id: <slrnmdng4r.5sv.hjp-usenet3@hrunkner.hjp.at>
On 2015-02-10 08:11, Martijn Lievaart <m@rtij.nl.invlalid> wrote:
> 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.
How is "I observed that \0 terminates a file name, therefore I conclude
that \0 cannot be part of a file name" not logical? It may be an
overgeneralisation (e.g. there might be an escape mechanism), but the
conclusion sounds logical to me.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Thu, 12 Feb 2015 00:20:59 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Why can I get away with this?
Message-Id: <rn4tqb-3lm.ln1@news.rtij.nl>
On Wed, 11 Feb 2015 15:34:11 +0000, Rainer Weikusat wrote:
> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>> That is not what you originally said, and this makes sense yes. It's
>> actually what I also said, just in other words.
>
> I'm sorry but that's a misunderstanding on your part: That's exactly
> what I originally said: This is the C convention. Hence, anything which
> supports a C API will 'necessarily' adhere to it (with 'necessarily'
Nope. That is just not a logical conclusion. It is convenient, it is
logical, given this problem domain. But it is not necessary at all.
> really supposed to mean 'very likely because throwing rocks at people
> who take the C convention for granted make little sense').
I don't follow what you are saying here. Probably a language issue
(English is not my native language)
>
> [...]
>
>> Besides that, you stated that such would be unusable from Perl, which
>> is obviously bogus. Perl handles embedded nulls just fine.
>
> I certainly didn't.
You are right, it was Robbie Hatley who said that. Sorry for that.
M4
------------------------------
Date: Thu, 12 Feb 2015 00:32:05 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Why can I get away with this?
Message-Id: <lc5tqb-3lm.ln1@news.rtij.nl>
On Wed, 11 Feb 2015 21:50:35 +0100, Peter J. Holzer wrote:
> On 2015-02-10 08:11, Martijn Lievaart <m@rtij.nl.invlalid> wrote:
>> 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.
>
> How is "I observed that \0 terminates a file name, therefore I conclude
> that \0 cannot be part of a file name" not logical? It may be an
> overgeneralisation (e.g. there might be an escape mechanism), but the
> conclusion sounds logical to me.
File names cannot contain nulls. Therefore we can use C strings in the
API. C strings cannot contain nulls. Therefore file names cannot contain
nulls.
See anything wrong with that reasoning? :-)
Do note that the context here is Windows, so the posix heritage does not
apply. Otherwise the argument would indeed be different. And very
possibly, there is some OS with some file system that does allow embedded
nulls in the name.
[ A quick Google later ]
Actually, there seems to be an OS that allows it. See http://tinyurl.com/
npapnyb
:-)
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 4369
***************************************
