Just bumped into another irresponsibility 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,$suffix) = 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 "documentation" 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($filename, @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
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
Xah Lee (···@xahlee.org) wrote:
: Just bumped into another irresponsibility 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,$suffix) = 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 "documentation" 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($filename, @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.
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
···@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 "contributions" 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
In article <····························@posting.google.com>,
Xah Lee <···@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_fstype 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
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 (········@ibd.nrc-cnrc.gc.ca) for this
correction.
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
[ F'up set ]
Also sprach Xah Lee:
> 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.
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{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
In article <····························@posting.google.com>,
Xah Lee <···@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,$suffix) = 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 "documentation" 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,$suffix) = 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.directory]filename.filetype;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.filetype;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.
From: Christopher C. Stacy
Subject: file versions [Re: perl bug File::Basename and Perl's nature]
Date:
Message-ID: <uisj0cn19.fsf_-_@news.dtpq.com>
[Removed all those other newsgroups.]
>>>>> On 25 Jan 2004 06:18:50 GMT, Walter Roberson ("Walter") writes:
Walter> There is no widespread unix convention of appending things to
Walter> file names as a versioning system. The convention of appending
Walter> a version was probably most common in VMS, which used filenames
Walter> of the form $device:[directory.directory]filename.filetype;version
Walter> such as $DISK0:[ROBERSON.SOURCE]HELLO.C;17
Walter> The use of extension information was present in CPM (1973) -- borrowed
Walter> from VMS. CPM begat QDOS which begat DOS which begat Windows.
Walter> The VMS structure of filename.filetype;version was adopted as the
Walter> ISO9660 filesystem for CDROMs.
Actually, those filesystem features predate VMS by almost 20 years.
I believe that file types originated on CTSS circa 1961.
Filenames had two seperate components (referred to as FN1 and FN2).
Then about 5 years later, this was picked up for ITS, which is where
file versions originated. On ITS, FN2 was normally the file type like
on CTSS, but if it was numeric (or if it ended in digits), the digits
were considered a version. File versioning was supported in the file
system (kernel) itself, not as some kludge convention that a program
might happen to understand. For example, the OPEN system call, in the
output direction, would normally create a new version of the specified
file with an incremented version number. For opening files in any mode,
besides an explicit version, there were designators for "newest" and
"oldest" that could be used in the pathname vesion component.
CTSS was the original Project MAC operating system on the IBM 709
(later the 7090). ITS is the PDP-10 operating system where MACLISP
came from (along with EMACS and many other things), until it was
replaced with the Lisp Machine. This is where Common Lisp file
pathnames ultimately got the idea for types and versions.
TOPS-20 picked up on the type and version idea, and made them always
be seperate components (so you could always have both). TOPS-20 also
had some other nice features that played with versions, such as the
idea of being able to always reliably un-delete a file.
VMS picked up the versioning idea from TOPS-20.
The Lisp Machine originally used ITS as its (transparent networked)
file system, but later when the LispM had its own disk file system,
it took all these ideas, plus some from Multics, plus some new stuff,
and incorporated all of them into the super-whizzy LMFS.
Examples:
ITS: CSTACY;FOO EMACS
CSTACY;FOO 42
CSTACY;FOO LSP042
TOPS-20: PS:<CSTACY>FOO.BAR.42
VMS: DRA0:[CSTACY]FOO.BAR;42
LMFS: >CStacy>foo.bar.42
DOS, NTFS, and UNIX filesystems don't have this version feature at all.
The kludge of appending some junk to the end of the filename,
and hoping that some applications will think it means something,
is by no means a substitute. Note that file versions are a different
feature than source-control difference systems or journaled file systems,
which try to solve slightly different problems.
"Xah Lee" <···@xahlee.org> wrote in message
·································@posting.google.com...
> Just bumped into another irresponsibility in perl.
>
[snipped rand about File::Basename docs]
> ...
> 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.
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.
> To the rookie programers out there, i advice against learning Perl.
> (i suggest Python instead) Please see
> http://xahlee.org/UnixResource_dir/perlr.html
thank you
gnari
On 24 Jan 2004 21:31:36 -0800, ···@xahlee.org (Xah Lee) wrote:
>Just bumped into another irresponsibility in perl.
[snip]
>expletive Perl and Perl slinging morons.
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"?
>you'll see that it shouldn't be so. AND, the writting as usuall is
>fantastic incompetent. To illustrate, i quote:
Haha, thanks! I'll make that a .sig!
Michele
--
# This prints: Just another Perl hacker,
seek DATA,15,0 and print q... <DATA>;
__END__
In article <··································@4ax.com>, Michele Dondi wrote:
> 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?
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
On Mon, 26 Jan 2004 20:45:19 +0100, I wrote:
[OT, slightly edited]
>>you'll see that it shouldn't be so. AND, the writting as usuall is
>>fantastic incompetent. To illustrate, i quote:
>
>Haha, thanks! I'll make that a .sig!
I guess it is fair to point out my own errors:
>Also, you may have noticed it, but this is a discussion group about
^^^^^^^^^^^^^^^^^^^^^^^
This should be "you may *not* have noticed it".
>*Perl* and people here is highly likely to be fond of Perl, appreciate
^^
*are*
Michele