perl bug File::Basename and Perl's nature

[Xah Lee]

Just bumped into another irresponsibilit y in perl.

the crime in question this time is the module File::Basename.

Reproduction:

1. create a directory containing a file of this name: "cdrom.html ".
2. "use File::Basename; ", with the line:
($name,$path,$s uffix) = fileparse($File ::Find::name, ('.html',
'.m'));
3. Notice that your cdrom.html will be parsed into "cdr" with suffix
"om.html".

expletive Perl and Perl slinging morons.

Now, if you peruse the "documentat ion" of "perldoc File::Basename" ,
you'll see that it shouldn't be so. AND, the writting as usuall is
fantastic incompetent. To illustrate, i quote:

--begin quote

fileparse

The fileparse() routine divides a file
specification into three parts: a leading path, a
file name, and a suffix. The path contains
everything up to and including the last directory
separator in the input file specification. The
remainder of the input file specification is then
divided into name and suffix based on the
optional patterns you specify in
@suffixlist. Each element of this list can be a
qr-quoted pattern (or a string which is
interpreted as a regular expression), and is
matched against the end of name. If this
succeeds, the matching portion of name is removed
and prepended to suffix. By proper use of
@suffixlist, you can remove file types or
versions for examination.

--end quote

Note the last sentence: "By proper use of @suffixlist, you can remove
file types or versions for examination." Now, this is in sync with the
usual verbiages of unix man pages, of mentioning irrevalent things.
Why the fuck do i need to know what is version, or examination what??
Not every morons in this world is using unix with its morinic
convention of appending things to file names as a versioning system,
and not every moron in this world need to "exam" things. The unix
irrevalency, inprecision, driveling are paragoned above.

Here is a better documentation for the fileparse subroutine.

fileparse

fileparse divides a file name into 3 parts:
directory string, file name, file name
suffix. fileparse($file name, @suffixes) returns a
array of 3 elements ($name, $dir_path,
$suffix). The concocted result of
"dir_path$name$ suffix" is guaranteed to equal to
$filename. The @suffixes is a array of strings,
for example ('\.html', '\.txt', '\.png'). These
strings are interpreted to be regular
expressions, and is matched against the end of
$filename.


But NOOO, perl morons are too enamored with driveling to write such
functional spec, after all, the code is sloppy and they don't REALLY
know what the code really does. This is not just one incompetence.
Perl is filled with them.

This report is on Perl version:
This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
(with 1 registered patch, see perl -V for more detail)

--

To the rookie programers out there, i advice against learning Perl.
(i suggest Python instead) Please see

http://xahlee.org/UnixResource_dir/perlr.html

Xah
xah@xahlee.org

http://xahlee.org/PageTwo_dir/more.html

[Walter Roberson]

Re: perl bug File::Basename and Perl's nature

In article <7fe97cc4.04012 42131.22acf485@ posting.google. com>,
Xah Lee <xah@xahlee.org > wrote:
:the crime in question this time is the module File::Basename.

:1. create a directory containing a file of this name: "cdrom.html ".
:2. "use File::Basename; ", with the line:
: ($name,$path,$s uffix) = fileparse($File ::Find::name, ('.html',
:'.m'));
:3. Notice that your cdrom.html will be parsed into "cdr" with suffix
:"om.html".

:Now, if you peruse the "documentat ion" of "perldoc File::Basename" ,
:you'll see that it shouldn't be so.

The program did what it was documented to do.

: The
: remainder of the input file specification is then
: divided into name and suffix based on the
: optional patterns you specify in
: @suffixlist. Each element of this list can be a
: qr-quoted pattern (or a string which is
: interpreted as a regular expression), and is
: matched against the end of name. If this
: succeeds, the matching portion of name is removed
: and prepended to suffix.

So the suffixlist is a set of *patterns*. And '.m' is a *pattern*
that means "any character followed by the character 'm'.

Probably what you wanted to code was:

($name,$path,$s uffix) = fileparse($File ::Find::name, ('\.html', '\.m'));


: Here is a better documentation for the fileparse subroutine.

Your "better" documentation does not describe how the directory string
is derived.


:Not every morons in this world is using unix with its morinic
:convention of appending things to file names as a versioning system,

There is no widespread unix convention of appending things to
file names as a versioning system. The convention of appending
a version was probably most common in VMS, which used filenames
of the form $device:[directory.direc tory]filename.filety pe;version
such as $DISK0:[ROBERSON.SOURCE]HELLO.C;17

The use of extension information was present in CPM (1973) -- borrowed
from VMS. CPM begat QDOS which begat DOS which begat Windows.

The VMS structure of filename.filety pe;version was adopted as the
ISO9660 filesystem for CDROMs. You don't *see* that because there
are common extensions to provide filename mapping, but every
ISO standard CDROM filesystem uses that structure underneath.
Including the common Rockridge extensions, and including when you
put a Joilet filesystem on a CDROM.
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare. -- Blair Houghton.

[Rich Krauter]

Re: perl bug File::Basename and Perl's nature

You're supposed to pass in regexes, perhaps? So your '.m' argument
actually means "anything followed by an m" and not literally "a dot
followed by an m". Just a guess, but that would explain your problem.
Rich

On Sun, 2004-01-25 at 00:31, Xah Lee wrote:
[color=blue]
> Just bumped into another irresponsibilit y in perl.
>
> the crime in question this time is the module File::Basename.
>
> Reproduction:
>
> 1. create a directory containing a file of this name: "cdrom.html ".
> 2. "use File::Basename; ", with the line:
> ($name,$path,$s uffix) = fileparse($File ::Find::name, ('.html',
> '.m'));
> 3. Notice that your cdrom.html will be parsed into "cdr" with suffix
> "om.html".
>
> expletive Perl and Perl slinging morons.
>
> Now, if you peruse the "documentat ion" of "perldoc File::Basename" ,
> you'll see that it shouldn't be so. AND, the writting as usuall is
> fantastic incompetent. To illustrate, i quote:
>
> --begin quote
>
> fileparse
>
> The fileparse() routine divides a file
> specification into three parts: a leading path, a
> file name, and a suffix. The path contains
> everything up to and including the last directory
> separator in the input file specification. The
> remainder of the input file specification is then
> divided into name and suffix based on the
> optional patterns you specify in
> @suffixlist. Each element of this list can be a
> qr-quoted pattern (or a string which is
> interpreted as a regular expression), and is
> matched against the end of name. If this
> succeeds, the matching portion of name is removed
> and prepended to suffix. By proper use of
> @suffixlist, you can remove file types or
> versions for examination.
>
> --end quote
>
> Note the last sentence: "By proper use of @suffixlist, you can remove
> file types or versions for examination." Now, this is in sync with the
> usual verbiages of unix man pages, of mentioning irrevalent things.
> Why the fuck do i need to know what is version, or examination what??
> Not every morons in this world is using unix with its morinic
> convention of appending things to file names as a versioning system,
> and not every moron in this world need to "exam" things. The unix
> irrevalency, inprecision, driveling are paragoned above.
>
> Here is a better documentation for the fileparse subroutine.
>
> fileparse
>
> fileparse divides a file name into 3 parts:
> directory string, file name, file name
> suffix. fileparse($file name, @suffixes) returns a
> array of 3 elements ($name, $dir_path,
> $suffix). The concocted result of
> "dir_path$name$ suffix" is guaranteed to equal to
> $filename. The @suffixes is a array of strings,
> for example ('\.html', '\.txt', '\.png'). These
> strings are interpreted to be regular
> expressions, and is matched against the end of
> $filename.
>
>
> But NOOO, perl morons are too enamored with driveling to write such
> functional spec, after all, the code is sloppy and they don't REALLY
> know what the code really does. This is not just one incompetence.
> Perl is filled with them.
>
> This report is on Perl version:
> This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
> (with 1 registered patch, see perl -V for more detail)
>
> --
>
> To the rookie programers out there, i advice against learning Perl.
> (i suggest Python instead) Please see
> http://xahlee.org/UnixResource_dir/perlr.html
>
> Xah
> xah@xahlee.org
> http://xahlee.org/PageTwo_dir/more.html[/color]

[Malcolm Dew-Jones]

Re: perl bug File::Basename and Perl's nature

Xah Lee (xah@xahlee.org ) wrote:
: Just bumped into another irresponsibilit y in perl.

: the crime in question this time is the module File::Basename.

: Reproduction:

: 1. create a directory containing a file of this name: "cdrom.html ".
: 2. "use File::Basename; ", with the line:
: ($name,$path,$s uffix) = fileparse($File ::Find::name, ('.html',
: '.m'));
: 3. Notice that your cdrom.html will be parsed into "cdr" with suffix
: "om.html".

Well, that's what you asked for, isn't it.

: expletive Perl and Perl slinging morons.

: Now, if you peruse the "documentat ion" of "perldoc File::Basename" ,
: you'll see that it shouldn't be so. AND, the writting as usuall is
: fantastic incompetent. To illustrate, i quote:

: --begin quote

: fileparse

: The fileparse() routine divides a file
: specification into three parts: a leading path, a
: file name, and a suffix. The path contains
: everything up to and including the last directory
: separator in the input file specification. The
: remainder of the input file specification is then
: divided into name and suffix based on the
: optional patterns you specify in
: @suffixlist. Each element of this list can be a
: qr-quoted pattern (or a string which is
: interpreted as a regular expression), and is
: matched against the end of name. If this
: succeeds, the matching portion of name is removed
: and prepended to suffix. By proper use of
: @suffixlist, you can remove file types or
: versions for examination.

: --end quote

Well it sounds to me like it says it will do what it did.

: Note the last sentence: "By proper use of @suffixlist, you can remove
: file types or versions for examination." Now, this is in sync with the
: usual verbiages of unix man pages, of mentioning irrevalent things.

How is it irrelevent to mention the purpose of the parameter?

: Why the fuck do i need to know what is version, or examination what??

If you don't need to know the version then don't ask the routine to parse
it off of the file name.

As for "or examination what", it takes some pretty obscure, poetical
parsing of english to make sense of this, so I will instead merely assume
you lacked the ability to understand what you read.


: Not every morons in this world is using unix with its morinic
: convention of appending things to file names as a versioning system,

Well that's right isn't it. Some of us morons use other moronic systems,
such as VMS sometimes. I must admit though, I rather find VMS's
"moronic", automatic, operating system supported _versioning_ of every
file is an extremely nice feature, allowing me (potentially) to examine,
recover, or reuse, any one of the versions of every file I ever touched
(since the last PURGE, anyway).

And you're right, one has no need to know the version number of a file for
any normal operation on VMS any more than a unix programmer normally needs
to know the inode number of a file, but on the other hand, when you do
certain file manipulations then you do need to know it, and since the
easiest way to access it is via the file name then it looks to me that in
that case the version number returned for my _examination_ by the above
mentioned module might be a good way to do that.

(You sure are rude by the way.)


: and not every moron in this world need to "exam" things.

"exam" is a noun, and therefore this is also sort of true, but only
because it's a bit of a tautology to say that somene doesn't need to do
something nonsensical.


: The unix
: irrevalency, inprecision, driveling are paragoned above.


: Here is a better documentation for the fileparse subroutine.

: fileparse

: fileparse divides a file name into 3 parts:
: directory string, file name, file name
: suffix. fileparse($file name, @suffixes) returns a
: array of 3 elements ($name, $dir_path,
: $suffix). The concocted result of
: "dir_path$name$ suffix" is guaranteed to equal to
: $filename. The @suffixes is a array of strings,
: for example ('\.html', '\.txt', '\.png'). These
: strings are interpreted to be regular
: expressions, and is matched against the end of
: $filename.

"concocted" ?


: But NOOO, ... morons are too enamored with driveling

well well, what do we find at the end, sure enough, this also is true.

[Gerrit Holl]

Re: perl bug File::Basename and Perl's nature

> Just bumped into another irresponsibilit y in perl.

What's this doing in the Python newsgroup?

Gerrit.

[xah lee]

Re: perl bug File::Basename and Perl's nature

think not what other messages are doing, think of what your message is
doing.

i am a known positive troll. It is people like you, who piggy back on
me, supports my constructive undoing.

Thanks.

PS if perl is demising, then it will benefit Python (because they are
competitors), and as well all other non-irresponsible programers and
languages, and consequently the programing industry, and society, and
software might stop to crash, and people might start to like computers.
Please read the following article:

---------------------------
Responsible Licenses
Xah Lee, 2003 July

http://xahlee.org/UnixResource_dir/writ/responsible_license.html

Software is a interesting invention. Software has this interesting
property, that it can be duplicated without cost, as if like copying
money. Never in history are goods duplicable without cost. But with
the invention of computer, the ephemeral non-physical programs breaks
that precept. In digital form, program and music and books all become
goods in essentially infinite quantity.

All is good except, bads in digital form can also multiply equally,
just as goods. Wellknown examples are computer viruses and email
spams. Unknown to the throng of unix morons is software bads. In a
unix moron's mind, the predominant quip among hackers is "where is
your code?", singnifying the mentality that a hacker's prestige is
judged on how much code he has contributed to the community.
Therefore, every fucking studs and happy-go-lucky morons put their
homework on the net, with a big stamp of FREE, and quite proud of
their "contributi ons" to the world. These digital bads, including
irresponsible programs, protocols, and languages, spread like viruses
until they obtained the touting right of being the STARDARD or MOST
POPULAR in industry, as if indicating superior quality. Examplary are
C, Perl, RFC, X-Windows, Apache, MySQL, Pretty Home Page (and almost
anything out of unix). The harm of a virus is direct. The harm of
irresponsible software (esp with unscrupulous promotion) is the
creation of a entire generation of bad thinking and monkey coders. The
scales can be compared as to putting a bullet in a person brain,
versus creating a creed with the Holocaust aftermath.

Distribution of software is easily like pollution. I thought of a law
that would ban the distribution of software bads, or like charging for
garbage collection in modern societies. The problem is the difficulty
of deciding what is good and what is bad. Like in so many things, i
think the ultimate help is for people to be aware; so-called
education; I believe, if people are made aware of the situation i
spoke of, then irresponsible software will decrease, regardless any
individual's opinion.

--

The most important measure to counter the tremendous harm that
irresponsible software has done to the industry is to begin with
responsible license, such that the producer of a software will be
liable for damage incurred thru their software. As we know, today's
software licenses comes with a disclaimer that essentially says the
software is sold as is and the producer is not responsible for any
damage, nor guaranteeing the functionality of the software. It is
this, that allows all sorts of sloppitudes and fucking fads and myths
to rampage and survive in the software industry. Once when software
producers are liable for their products, just as bridge or airplane or
transportation or house builders are responsible for the things they
build, then injurious fads and creeds the likes of (Perl, Programing
Patterns, eXtreme Programing, "Universal" Modeling Language...) will
automatically disappear by dint of market force without anyone's
stipulation.

In our already established infrastructure of software and industry
practices that is so already fucked up by existing shams, we can not
immediately expect a about-face in software licenses from 0 liability
to 100% liability. We should gradually make them responsible. And
this, comes not from artificial force, but gradual establishment of
awareness among software professionals and their consumers. (Producers
includes single individual to software houses, and consumers includes
not just mom & pop but from IT corps to military.)

------------

Xah
xah@xahlee.org

http://xahlee.org/PageTwo_dir/more.html

On Jan 25, 2004, at 1:10 AM, Gerrit Holl wrote:
[color=blue]
> Just bumped into another irresponsibilit y in perl.[/color]

What's this doing in the Python newsgroup?

Gerrit.

[Michele Simionato]

Re: perl bug File::Basename and Perl's nature

xah@xahlee.org (Xah Lee) wrote in message news:<7fe97cc4. 0401242131.22ac f485@posting.go ogle.com>...
<snip trollish rants against Perl>

Please, at least don't cross-post (and don't make me to cross post).

_______________ ______
/| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_____________ ________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ | ||
/ _ \\ | / `
* / \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c_______ _____

[gnari]

Re: perl bug File::Basename and Perl's nature

"Xah Lee" <xah@xahlee.org > wrote in message
news:7fe97cc4.0 401242131.22acf 485@posting.goo gle.com...[color=blue]
> Just bumped into another irresponsibilit y in perl.
>[/color]
[snipped rand about File::Basename docs]
[color=blue]
> ...
> Why the fuck do i need to know what is version, or examination what??
> Not every morons in this world is using unix with its morinic
> convention of appending things to file names as a versioning system,
> and not every moron in this world need to "exam" things.[/color]

you are right. the docs do not seem to address the
needs of morons. there sould be a shorter version of
the docs, specially for morons, with each example
if larger font, repeated 10 times.
[color=blue]
> To the rookie programers out there, i advice against learning Perl.
> (i suggest Python instead) Please see
> http://xahlee.org/UnixResource_dir/perlr.html[/color]

thank you

gnari

[Michele Dondi]

Re: perl bug File::Basename and Perl's nature

On 24 Jan 2004 21:31:36 -0800, xah@xahlee.org (Xah Lee) wrote:
[color=blue]
>Just bumped into another irresponsibilit y in perl.[/color]
[snip][color=blue]
>expletive Perl and Perl slinging morons.[/color]

Taking into account the aggressive and trollish tone of your post I'm
surprised by how polite the answers you got are. Nay, I found
interesting the OT about OSes and file versions: a proof that a bad
seed can give good fruits!

I don't know why I'm taking care of answering you seriously, but if
you don't like "Perl's nature", why are you bothering with it in the
first place? If you can't stand its real/presumed *nix-isms, why are
you using it?

Also, you may have noticed it, but this is a discussion group about
*Perl* and people here is highly likely to be fond of Perl, appreciate
its "nature" and so on... so what did you expect to receive as an
answer to your post?

What do you gain in particular by criticizing an excellently and
*clearly* written piece of documentation (of an useful package!), by
exposing your failing to understand it because of your stupidity and
ignorance about a basic concept of the language like "pattern"?
[color=blue]
>you'll see that it shouldn't be so. AND, the writting as usuall is
>fantastic incompetent. To illustrate, i quote:[/color]

Haha, thanks! I'll make that a .sig!


Michele
--
# This prints: Just another Perl hacker,
seek DATA,15,0 and print q... <DATA>;
__END__

[Joe Mason]

Re: perl bug File::Basename and Perl's nature

In article <tmqa10d6a542ma 6k1ao6tnupvj0gb tser7@4ax.com>, Michele Dondi wrote:[color=blue]
> Also, you may have noticed it, but this is a discussion group about
> *Perl* and people here is highly likely to be fond of Perl, appreciate
> its "nature" and so on... so what did you expect to receive as an
> answer to your post?[/color]

No it's not. This is a newsgroup about Ruby. And that's a newsgroup
about Python. And that over there's a newsgroup about Scheme.

Only one of these groups is actually about Perl, so I've set the
followups there. The troll is actually on-topic there. Please keep
your replies there, too.

Joe

[Michele Dondi]

Re: perl bug File::Basename and Perl's nature

On Mon, 26 Jan 2004 20:45:19 +0100, I wrote:

[OT, slightly edited]
[color=blue][color=green]
>>you'll see that it shouldn't be so. AND, the writting as usuall is
>>fantastic incompetent. To illustrate, i quote:[/color]
>
>Haha, thanks! I'll make that a .sig![/color]

I guess it is fair to point out my own errors:
[color=blue]
>Also, you may have noticed it, but this is a discussion group about[/color]
^^^^^^^^^^^^^^^ ^^^^^^^^

This should be "you may *not* have noticed it".
[color=blue]
>*Perl* and people here is highly likely to be fond of Perl, appreciate[/color]
^^

*are*


Michele

[Xah Lee]

Re: perl bug File::Basename and Perl's nature

just a few notes to wrap this thread up.

* several perl morons didn't heed my imperative of perusing the notes
in "perldoc File::Basename" . By their nature, they skimmed and scanned
and came back with "the doc said so!". They posses no attention to
detail nor knowledge of precision writing, consequently with lowered
reading comprehension. Like a man exposed to noise or shit or
malfunction, they hear nothing, smell nothing and ebythin's alright.

* when it gets one to think about design, File::Basename is one
fucking turd. The suffix list should not be regex in the first fucking
place. (it shouldn't even require a suffix list by default). The need
to feed it OS type (fileparse_set_ fstype($os)) is fucking defeating
the main point of using this module.

Fuck Perl and fuck Perl morons around the world.

Xah
xah@xahlee.org

http://xahlee.org/PageTwo_dir/more.html

--------------------------------------
Responsible Software License
By: Xah Lee, 2003 July

Software is a interesting invention. Software has this interesting
property, that it can be duplicated without cost, as if like copying
money. Never in history are goods duplicable without cost. But with
the invention of computer, the ephemeral non-physical programs breaks
that precept. In digital form, program and music and books all become
goods in essentially infinite quantity.

All is good except, bads in digital form can also multiply equally,
just as goods. Wellknown examples are computer viruses and email
spams. Unknown to the throng of unix morons is software bads. In a
unix moron's mind, the predominant quip among hackers is "where is
your code?", singnifying the mentality that a hacker's prestige is
judged on how much code he has contributed to the community.
Therefore, every fucking studs and happy-go-lucky morons put their
homework on the net, with a big stamp of FREE, and quite proud of
their "contributi ons" to the world. These digital bads, including
irresponsible programs, protocols, and languages, spread like viruses
until they obtained the touting right of being the STARDARD or MOST
POPULAR in industry, as if indicating superior quality. Examplary are
C, Perl, RFC, X-Windows, Apache, MySQL, Pretty Home Page (and almost
anything out of unix). The harm of a virus is direct. The harm of
irresponsible software (esp with unscrupulous promotion) is the
creation of a entire generation of bad thinking and monkey coders. The
scales can be compared as to putting a bullet in a person brain,
versus creating a creed with the Holocaust aftermath.

Distribution of software is easily like pollution. I thought of a law
that would ban the distribution of software bads, or like charging for
garbage collection in modern societies. The problem is the difficulty
of deciding what is good and what is bad. Like in so many things, i
think the ultimate help is for people to be aware; so-called
education; I believe, if people are made aware of the situation i
spoke of, then irresponsible software will decrease, regardless any
individual's opinion.

--

The most important measure to counter the tremendous harm that
irresponsible software has done to the industry is to begin with
responsible license, such that the producer of a software will be
liable for damage incurred thru their software. As we know, today's
software licenses comes with a disclaimer that essentially says the
software is sold as is and the producer is not responsible for any
damage, nor guaranteeing the functionality of the software. It is
this, that allows all sorts of sloppitudes and fucking fads and myths
to rampage and survive in the software industry. Once when software
producers are liable for their products, just as bridge or airplane or
transportation or house builders are responsible for the things they
build, then injurious fads and creeds the likes of (Perl, Programing
Patterns, eXtreme Programing, "Universal" Modeling Language...) will
automatically disappear by dint of market force without anyone's
stipulation.

In our already established infrastructure of software and industry
practices that is so already fucked up by existing shams, we can not
immediately expect a about-face in software licenses from 0 liability
to 100% liability. We should gradually make them responsible. And
this, comes not from artificial force, but gradual establishment of
awareness among software professionals and their consumers. (Producers
includes single individual to software houses, and consumers includes
not just mom & pop but from IT corps to military.)

archived at

http://xahlee.org/UnixResource_dir/writ/responsible_license.html

Xah
xahlee.org

http://xahlee.org/PageTwo_dir/more.html

[Walter Roberson]

Re: perl bug File::Basename and Perl's nature

In article <7fe97cc4.04012 60943.2442ba4e@ posting.google. com>,
Xah Lee <xah@xahlee.org > wrote:
:* when it gets one to think about design, File::Basename is one
:fucking turd. The suffix list should not be regex in the first fucking
:place. (it shouldn't even require a suffix list by default). The need
:to feed it OS type (fileparse_set_ fstype($os)) is fucking defeating
:the main point of using this module.

You don't -need- to feed it the OS type: it defaults to using
the information from the currently running OS ($^O). The
fileparse_set_f stype is there so that one can write routines targetted
at specific OSes. For example, one could import a VMS log file onto
a Unix system and parse it there without having to roll one's own
filename parsing routines.

:The suffix list should not be regex in the first fucking
:place.

Why not? Anyone who read the documentation would see immediately that
regexes were called for in that position. Perhaps -you- don't need
the flexibility of having regexes there, but is that any reason to
deny other people the flexibility?

:it shouldn't even require a suffix list by default

It doesn't. If you don't pass it a suffix list, then that will be
treated as the empty array, and suffixes will not be broken out.

Are you perhaps saying that on Unix systems, it should default to
using '\.[^.]*$' as the suffix list, thus breaking out from the
last period onwards?
--
Beware of bugs in the above code; I have only proved it correct,
not tried it. -- Donald Knuth

[Xah Lee]

Re: perl bug File::Basename and Perl's nature

a correction to my previous post.

In my previous post i said one of the stupidity of Perl's
File::Basename module is that it requires user to tell it OS type.
This is incorrect.

Thanks to Walter Roberson (roberson@ibd.n rc-cnrc.gc.ca) for this
correction.

Xah
xah@xahlee.org

http://xahlee.org/PageTwo_dir/more.html

[Tassilo v. Parseval]

Re: perl bug File::Basename and Perl's nature

[ F'up set ]

Also sprach Xah Lee:
[color=blue]
> a correction to my previous post.
>
> In my previous post i said one of the stupidity of Perl's
> File::Basename module is that it requires user to tell it OS type.
> This is incorrect.[/color]

You also said that the suffix list would be required.

This is also incorrect.

Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_ $;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus}) (rekcah{lrePbus })(lreP{rehtona bus})!JAPH!qq(r ehtona{tsuJbus# ;
$_=reverse,s+(? <=sub).+q#q!'"q q.\t$&."'!#+sex isexiixesixeseg ;y~\n~~dddd;eva l