No, you use the more modern chomp() which removes EOL's from lines as defined by the $/ variable.
I imagine that $/ defaults to CRLF on Windoze.
Um, no. That's not the way it works. It's just a \n. Here's an excerpt from The Perl Cookbook:
Not everyone agrees what a line in a text file is, because one person's textual character set is another's binary gibberish. Even when all parties involved are using ASCII instead of EBCDIC, Rad50, or Unicode, discrepancies arise. There is no such thing as a newline character. It is purely virtual, a figment of the operating system, standard libraries, device drivers, and Perl.
Under Unix or Plan9, a "\n" represents the physical sequence "\cJ", a linefeed. However, on a terminal that's not in raw mode, an key generates an incoming "\cM" (a carriage return), which turns into "\cJ", while an outgoing "\cJ" magically turns into "\cM\cJ". This strangeness doesn't happen with normal files, just terminal devices, and is handled strictly by the device driver.
On a Mac, a "\n" is usually represented by "\cM"; just to make life interesting, a "\r" represents a "\cJ". You will note that this is exactly the opposite of the way that Unix, Plan9, VMS, CP/M, or nearly anyone else does it. This means that Mac programmers writing files for other systems, or talking over a network, have to be careful. If you just send out "\n", you'll deliver a "\cM" and no "\cJ" will ever be seen. Most network services prefer to receive and send "\cM\cJ" as a line terminator, but most are also content to receive merely a "\cJ". The old adage ``be liberal in what you accept, and conservative in what you send'' is still true today.
Under VMS, DOS, or derivatives thereof, a "\n" represents "\cJ", in a similar fashion to Unix and Plan9. From the perspective of a tty, Unix and DOS behave identically: a user who hits ENTER generates a "\cM", but this arrives at the program as a "\n", which is "\cJ". And a "\n" (that's a "\cJ", remember) sent to a terminal shows up as a "\cM\cJ".
But these strange conversions happen to Windows files as well. A ``text file'' in DOS actually contains two characters at the end of every line, "\cM\cJ". And the last block in the file has a "\cZ" in it to indicate where the text stops. When you write a line like "bad news\n" on those systems, the file ends up containing "bad news\cM\cJ", just as if it were a terminal.
When you read a line on such systems, it's even stranger. The file itself contains "bad news\cM\cJ", a ten-byte string. When you read it in, your program gets nothing but "bad news\n", where that "\n" is the virtual newline character, that is, a linefeed ("\cJ"). That means to get rid of it, a single chop or chomp will do it. But your poor program has been tricked into thinking it's only read nine bytes from the file. If you were to read ten such lines, you would appear to have read 90 just bytes into the file, but in fact would be at position 100. That's why the tell function must always be used to figure out where you are. You can't infer your position just by counting what you've read.
This legacy of the old CP/M file system, in which their equivalent of an inode stored only block counts and not file sizes, has been a source of frustration and despair to programmers for decades now. And there's no end in sight. Because DOS is compatible with CP/M file formats, Windows with DOS, and NT with Windows, the transgressions of the fathers have truly been visited unto the children of the fourth generation.
The Unix column assumes that you are not accessing a serial line (like a tty) in canonical mode. If you are, then CR on input becomes "\n", and "\n" on output becomes CRLF.
These are just the most common definitions of \n and \r in Perl. There may well be others.
There is a chip, the picoJava chip, that runs bytecode native (that's bytecode compiled from Java source). There no picoPerl chip. You cannot run a Perl program unless you either have a Perl interpreter or you compile the Perl source to a native binary.
Oh, good. I see now that what you've so generously explained is how the mere current existence of this chip that interprets Java bytecodes means that the Java thingie-that-might-be-a-compiler that produces bytecode really is a real, honest-to-Dennis compiler, but that the current albeit potentially ephemeral lack of an equivalent chip for Perl bytecode interpretation similarly indicates that the Perl thingie-that-might-be-a-compiler isn't really a compiler at all.
Let's see now. That means that all I'll have to do to make the Perl thingie-that-wishes-it-were-a-compiler into a true compiler, is, without touching a single little bit within the aforementioned pseudocompiler's tender little binary image, wave my magic wand and create a chip that happens to directly use the Perl bytecodes as its native instructions. Voila! The old thingie-that-wished-it-were-a-compiler has had its heartfelt desire granted, all without altering it at all.
Because I can already convert the Perl bytecodes into something to feed a C compiler and thence an assembler using one of our various code generators, it would to appear that the existence of such a process has magically elevated the hitherto humdrum role of the whilom pseudocompiler into that of a proper compiler, but that before such code generators for Perl existed, no such appellation was merited. In short, the presence of an external, unrelated entity alters the very nature of a particular process, yet miraculously does so by changing neither the input nor the output of that same process.
You have demonstrated how the principle of strange action at a distance is one limited not merely to quantum physics, but that its reach in fact extends even to compiler theory. Your peccable perspicacity, sir, has so completely overwhelmed me, that I can but stand in humble awe--nay, call it shock--before you. Doubtless this is but the tip of the iceberg, and wholly new fields of figmentation await your inventive elaboration. You must definitely write a thorough treatise on your fascinating findings of Heisencompilers. Do be sure to please include some of that tasty postmodern deconstructionism while you're at it.
...compiled code is fed via electrical signals into the processeor (whether that processor is one a chip, or a board). If the processor never performs an actual instruction fetch cycle on whatever is considered the program's "executable form" (such as bytecode for Java), then it's interpreted.
So, that thingie that turns Java source code into Java bytecode is not really a compiler the way everyone says it is, but rather merely a thingie-that-turns-Java-source-code-into-Java-byte code?
The current degree of concern and confusion about the relationship between the intertwinglelingly aforementioned businesses may be out of proportion with the reality of the matter. In response to your concerns and those of others, the parties involved (of which I am not one) have updated the relevant FAQ with more concrete details. I believe that these clarifications stand a chance of allaying a few of your more conspiratorial fears.
No, he was sly. This way, many companies get to use and even ship Perl who otherwise would be restricted from doing so. Do you think Apple would touch anything GPL'd after what the Fascist Software Foundation did to them? Notice how Mac OS X is BSD-based, not Linux-based. Think about that for a while, please.
There are plenty of other cases, some of which are not obviously public, of companies shipping products with Perl bundled in, companies whose lawyers absolutely would not have permitted their product to require a GPV'd program. Whether the contamination were really there or not, the lawyers would only know how to say no.
And that helps no one. This way, more people can use Perl, and on their own terms, and without fear of reprisal from any rabid lawyers. Perl is more useful, more widespread, and more free than it would be were it saddled with nothing but the GPV. If you want freedom, don't tie people up with duct tape.
The Artistic Licence does just exactly what it was intended to do, and consequently is unlikely to disappear just because you want to remove people's freedom with a more restrictive, binding licence. Perhaps you might please reread it seen in this light.
I'm sorry to be a stickler for correctness and honesty here, but someone has to fight against the confusion. All Perl is compiled! I keep telling you that. Every little bit of it. There are no exceptions. Go read/usr/src/perl/toke.c and perhaps/usr/src/perl/perly.y if you don't believe me.
Likewise, all programs are interpreted! Those PCs and SPs are there for nothing, you know. And that's just the start of it. I can compile into a VAX-11 polynomial expansion expression, and this still has to play patsy-cake with the firmware interpreter before it hits silicon.
You probably really meant `Perl that has only been compiled into parsetrees or bytecode for the PP interpreter to interpret, but which has not been compiled into C code and thence compiled into assembly language and thence compiled into machine language for the current or target firmware to interpret'.
But if so, I'm afraid that you'd still be wrong. One simply links in the whole image of the compiler as needed by things like do and eval. There's a good reason to keep a libperl.so lying about, and this is one of them. Of course, now that this is merely a shared library, of course there's no interpreter involved.:-)
Sigh. Where do they teach these mistaken notions of what a compiler really does? Doesn't anybody write a slew of diverse mini-compilers in school anymore? If you compile into P-code, who's to say you won't some day run on a chip with P-code-enabled hardware? Or it could be dynamically generated machine language, the way ML works, or the way Java's JIT stuff works.
We have one generic front-end compiler, three different optional code generators (bytecode, unrolled interpreter style C code, or optimized C code), a bytecode-to-PP rebuilder, and a PP-interpreter. That's the story, and I'm sticking to it.
The fact that it needs perl... the program perl to load it and interpret it is what i see as a interpreted language.
And the fact that you need some shared library (that's DLL in the Black Speech of Mordor) to interpret certain kinds of function calls would by that criterion make any such program an interpreted one. After all, the shared-library/DLL/run-time-system is fielding the calls for you. You're not doing it yourself.
Do you write Lisp scripts? Do you write BASIC scripts? Do you write Java scripts? Do you write Pascal scripts? Do you write C scripts? You can, of course. You can set those all up so they are run by a different virtual machine than the one that's doing firmware interpretation. And just who is doing the interpretation and how much preprocessing is done on the very same source code can vary from run to run.
Face it, this is an altogether silly idea borne of marketroids and other atechnical jargonizers with no legitimate foundation in the computing sciences.
For a long time, the only tolerable way to address this paralysing lack of tools was to use MKS, but that's a poor solution because you have to buy it (strike one), you can't hack it (strike two), and it doesn't have everything you want/need (strike three).
The advent of freely available, plug-and-play substitutes for our standard Unix tools has been a great relief to victims of Big Bad Bill. These include the vi (vim, actually, but that's fine), Perl, the entire UWIN environment, the Cygwin suite, and of course, Perl Power Tools, which also work on non-{Microsoft,Unix} systems.
Some folks feel that we shouldn't port our tools to the evil one lest it thereby become easier to exist under his yoke, and thus perhaps decrease the chance of someone upgrading to Unix. But hold on there. Imagine that you're living in a fertile oasis of plenty, and on a dayhike, come across your friend toiling for his business in the searing desert that surrounds you. He is parched and crying out for aid. You invite him back to your oasis to refresh him, but he says that his job is there in the infernal sands. What do you do? Do you just walk away and abandon him? Of course not! You give him a sip or seven of that cool water you've brought with you from your safe haven.
Some of you know what the Perl slogan on Windows is, and you can say it with me: ``It's a good thing there's more than one way to do it, because most of them don't work.''
There will now be one fewer way for Perl not to work under Microsoft: forking is good for you. This helps everyone because we can all fork off at will without the grinch that stole Redmond barking at us.
I'm curious how it will avoid the insanely inefficient process start-up penalties one incurs under Microsoft, as well as how the non-shared data pages will be fast without being copy-on-write. The multiple-interpreters-in-one-process work will also help everyone.
I'd say to reserve one's fears until there's something to fear. ActiveState can't after all be all bad: they even list the Perl Power Tools on their pages to help people sentenced to tool-deprived systems.:-)
As for the definition of `interpreted', I will say that I would define Perl, along with the Bourne, C and Korn shells, and TCL as interpreted scripting languages, as opposed to Ada, C, C++ and Java, which I would define as compiled programming languages.
I'm afraid it's nothing so simple as that. Both Perl and Java compile into what we always used to refer to as P-code. Does anybody else but me remember UCSD Pascal on the LSI-11's? Sometimes this turns into machine code, sometimes it doesn't. The only honest thing you can say is that all programming languages are by definition interpreted. You cannot a priori look at a program and say what is going on. In fact, nothing is going on at all.:-)
Nostagically relevant, consider pi, pix, px, and pc on old BSD systems for a Pascal environment. I can present you with Pascal source, and ask what it is. You cannot tell me. It could be run under a pure interpreter, a bytecode compiler-and-interpreter, or further translated into some machine's assembly language. All are still interpreted.
As an aside - don't Microsoft claim that NT is POSIX compliant? If it is, then why do they have to make custom changes to things like Java and Perl?
Oh, they claim, they claim. But see the old article by Heinz Lycklama. Everyone else who did POSIX compliance did so to create something genuinely useful for their customers. Why use persnickety technicians when you get to hoodwink the courts to ordain you POSIX in a bait-and-switch game? I leave it to the readership to judge Microsoft on their own.
Perl isn't like Java - for the most part, it's a server-side scripting language, not a half-compiled binary which is meant to run on the client
I'm afraid that your statement is disingenuous at best, deceptive at worst. Perl is hardly a `server-side scripting language' as you portray it.
First, to relegate Perl to nothing more than CGI is a tremendous disservice. Perl is a general-purpose programming language whose process, file, and text manipulation facilities have made it the programming language of choice for tasks involving quick prototyping, system utilities, software tools, system management tasks, database access, graphical programming, and world wide web programming--just to name a few. Systems administrators, network administrators, and web administrators on all platforms flavors especially love it because of its potential to automate virtually everything they need to do.
The second misconception to disabuse oneself of is this whole `scripting' notion as being somehow different from `programming'. It's not. They're quite the same thing, at least as used in the vernacular now that JCL scripts and uucp chat scripts are largely (and thankfully) gone. And before you mumble something about `interpreted', you should think about how, contrary to popular misconception, not merely Perl but all programming languages are interpreted. The only question is, at what level?
In the normal case, the Perl compiler compiles source code into parsetrees of Perl Pseudocode (PP), and hands those off to the PP interpreter to execute (one could say `interpret') these trees.
In other cases, the Perl compiler compiles source code into parsetrees of Perl Pseudocode (PP), and hands those off to a code generator, which generates bytecodes. These bytecodes are then later loaded by a special module that converts them back into PP trees, which are then handed off to the PP interpreter to execute (one could say `interpret').
In still other cases, the Perl compiler compiles source code into parsetrees of Perl Pseudocode (PP), and hands those off to a code generator, which generates C source code, which is handed off to the C compiler, which generates assembly source code, which is handed off to the assembler to produce object code, which is handed off to the linker to create a linked binary image, which is then handed off to the kernel to execute (one could say `interpret') at some later date, whose instructions are then often handed off to the firmware to execute (one could say `interpret').
In all cases, the Perl compiler runs an optimization pass, just like any other compiler. For example, the expression $x = 2 ** 31 - 1 would be computed at compile-time, since it's a constant expression. But the Perl compiler is rather more clever than just that, sometimes inlining certain subroutines, ignoring unreachable code, doing loop hoisting, etc.
I hope that's all clear now.:-)
The main thing is, don't panic.
That part is certainly true!
This will probably turn out to be good for Perl in the long run.
[PHP] was easier and faster than Perl for CGI stuff.
If you haven't used the standard CGI.pm, you're missing out on some of the easy part, and if you haven't used mod_perl, then you're missing out on some of the fast part.:-)
Lucky is a monadic parser. Monads are a very powerful way to resolve the contradictions between functional and object oriented programming philosophies. A monadic parser has all the elegance, flexibility, and raw power of a functional parser without the grammer constrains normaly imposd on a functional parser.
Keep in mind that monadic has other meanings as well. The OED definition 1b for `monadic' is:
of a proposition, fact, function, etc., or the predicate contained therein, when the predicate is non-relational and applies to only one subject term. [emphasis mine --tchrist]
For example, Monadic Classes are a fancier term for Highlander Classes (`There can be only one!'). And lest you think this an irrelevant tangent, the link above actually has Perl content. [Someone actually posted a Haskell-inspired Functional.pm today, too. Funny how things show up together in more than one place all at once.]
Even though it's just fine, instead of "cracker", try using "attacker" instead. Or perhaps "criminal". There's a lot less ambiguity there.
--tom
Paucity of Documentation Plagues Free Software
on
Unix in a Nutshell
·
· Score: 5
An anonymous coward scribbled:
Man pages are too-kitchen sink for the clueful-newbie.
Apparently you have a different definition of `clueful' than I have.
... manpages aren't required in SysV (they're a BSD-ism)...
I must take issue with this notion that `manpages are a BSDism'. You are demonstrably wrong: they were included with Version 7, as this manpage clearly indicates. And your statement about SysV is also wrong: manpages are required on any system that purports POSIX compliance, as AIX learned the hard way.
Unfortunately, technically speaking, only catpages not manpages are required. Perhaps that's what you meant. But even catpages are better than nothing.
...even GNU disses manpages...
This hardly constitutes a fine selling point in your favor. Sometimes the FSF pertains more to the problem set than they do the solution set; this is certainly one of those places. Not only do they ignore the POSIX requirements, they appear to disavow the need for a unified, indexable, searchable, printable, formalized set of technical documentation. This is hardly what most of us would call `progress'.
It's bad enough when you summon up a manpage only to be infuriatingly chidden by the FSF that `This documentation is no longer being maintained and may be inaccurate or incomplete.' Worse still is the situation with programs like diff or gnomecal, which are completely bereft of any manpage whatsoever. The FSF should be ashamed of themselves! This is one of the root causes of the notorious Daemon Linux project.
This lackadaisical attitude toward complete, on-line documentation is hardly confined to the FSF, although I hold them ultimately responsible for one area: Linux distributors. The Linux rebundlers inherit the problem from the FSF, and do nothing about it. Take SuSE for example. In virtually all other aspects a robust and coherent Linux distribution, SuSE confesses in their printed book that accompanies their CD that not all commands and functions have documentation. What a punt! They're just being irresponsible.
I suppose that one could in desperation invent some sort of rarefied alibi for the FSF's negligence here. They are, after all, more dedicated to principle than they are to mundane matters of quotidian utility. But for those who repackage and sell Linux distributions, no excuse can exist. These businesses are selling what they purport to be an integrated system, yet then have the audacity to confess that it is not. If the FSF won't fix this, then the resellers must. But the FSF really is the right place to fix it, because that way the fix helps everyone, rather than just one reseller trying to create a market advantage for themselves.
But this already depressing situation gets worse, far worse, before it gets better. You see, as programmers try to create something flashy enough to attract non-programmers, something critical has been lost. I'm thinking of those programs whose GUIs are the Way, the Truth, and the Light, whereby no man cometh unto the documentation for a given program save through its lauded GUI. If the information is not found under an About button or a Help button, it simply isn't available. Even if it were to be found there, how would you know it? Once you figure out each program's new set of hieroglyphics, these miserable shinyhappy icons and their cascading shinyhappy menus just aren't greppable. How do you in a non-manual fashion search through these myriad menus? How do you print them out? How do you create an index?
This situation in completely unacceptable.
Having recently tried out the whole Eterm, Enlightenment, and Gnome set-up, as duly impressed as I was with Eterm's manpage, I was severely underwhelmed by the attention toward detailed -- strike that, make it any -- documentation manifest in the other two. Miguel has assured me that what I had looked at was a mistake, that the released snuck out without the libraries' docs included. But I want more than only the programming libraries having manpages. If it's a command or a file format, it needs to be documented! Otherwise we're back to the mushroom school of systems management (keep us in the dark and feed us shit). Every little gnomic panel application and associated happycon needs a manpage, one that apropos and whatis can access, as well. Don't make me click with a mouse to find help and directions. I didn't spend thirty years mastering the keyboard and learning to read and write lengthy treatises merely to be reduced to a one-bit input device and a two-line output device.
Having to randomly hunt through manpages, HOWTOs, info pages, various programs' home pages out on the Web, per-program help pages, and stringsing the infernal binaries is shear madness As Henry Spencer observed, `Those who do not understand Unix are condemned to reinvent it, poorly.' Unified Unix manpages solved the insane situation in which you had shelves upon shelves of printed documentation that came with an IBM mainframe; these docs weren't online, so were unnavigable. Apparently we are doomed to repeat that unhappy history.
While it's true that I write all my books in troff, along with the traditional helpmates of eqn, pic, and tbl, please don't assume by this that I am particularly enamoured of that system. I'm certainly not. What I do expect in proper online documentation is the properties that manpages provide:
All documentation must be contained and accessible from within the same on-line system.
Available for independent on-line viewing, apart from the application.
Format easy to read and write by humans, parse and generate by programs.
Conveniently structured.
Printable as a high-quality book using a typesetter.
Searchable and indexable using standard tools.
The language used to encode this information is far less important than is having these basic features. Without a coherent, comprehensive, and unified documentation system, we might as well all be running some expert-hostile and user-obsequious toybox suitable for the point-and-drool atechnical public all too typical in these post-literate Dark Ages, where WYSIWYG means that what you see is all you get.
Our attempts to take back the word ``hacker'' by getting the ignorant, consumerist mass-media to adopt ``cracker'' instead has met with very little success to date.
Perhaps we should s/hacker/attacker/ or more simply s/hacker/criminal/ instead. While there are no guarantees that this will work any better, at least it will stand out better and so be less readily confusable.
:what are you talking about i went to the site :and there are no question marks anywhere and i :do not see ms anywhere please check your facts :before posting
Doubtless that's because you're a Prisoner of Bill. For the rest of us, it's garbeldy gook, because it's not legal HTML. If you fetch the raw page, and get a nice octal dump, you'll see what I mean.
My point was simply that I felt that when Slashdot points us at a site that requires a special setup to view (for example: you must register; or you must have a valid referring page; or you need Flash installed; or you must have tithed Lord Bill) that this merits special notification of this unpleasantry.
I assure you that I certainly did "check my facts" before posting. Did you?
I tried to read the article linked to, but that's hard to do when the article isn't even in HTML, but rather was written using MS-HTML. This is that annoying thing that makes "?" show up all over your screen as illegal characters are encountered.
Perhaps in much the same way as/. warns about registration required when pointing at the New York Times, it might also be useful if you would include a warning when Microsoft is required for proper viewing of a page you link to.
Slashdot Mirror
--tom
Let's see now. That means that all I'll have to do to make the Perl thingie-that-wishes-it-were-a-compiler into a true compiler, is, without touching a single little bit within the aforementioned pseudocompiler's tender little binary image, wave my magic wand and create a chip that happens to directly use the Perl bytecodes as its native instructions. Voila! The old thingie-that-wished-it-were-a-compiler has had its heartfelt desire granted, all without altering it at all.
Because I can already convert the Perl bytecodes into something to feed a C compiler and thence an assembler using one of our various code generators, it would to appear that the existence of such a process has magically elevated the hitherto humdrum role of the whilom pseudocompiler into that of a proper compiler, but that before such code generators for Perl existed, no such appellation was merited. In short, the presence of an external, unrelated entity alters the very nature of a particular process, yet miraculously does so by changing neither the input nor the output of that same process.
You have demonstrated how the principle of strange action at a distance is one limited not merely to quantum physics, but that its reach in fact extends even to compiler theory. Your peccable perspicacity, sir, has so completely overwhelmed me, that I can but stand in humble awe--nay, call it shock--before you. Doubtless this is but the tip of the iceberg, and wholly new fields of figmentation await your inventive elaboration. You must definitely write a thorough treatise on your fascinating findings of Heisencompilers. Do be sure to please include some of that tasty postmodern deconstructionism while you're at it.
--tom
--tom
--tom
Gotcha.
--tom
--tom
--tom
There are plenty of other cases, some of which are not obviously public, of companies shipping products with Perl bundled in, companies whose lawyers absolutely would not have permitted their product to require a GPV'd program. Whether the contamination were really there or not, the lawyers would only know how to say no.
And that helps no one. This way, more people can use Perl, and on their own terms, and without fear of reprisal from any rabid lawyers. Perl is more useful, more widespread, and more free than it would be were it saddled with nothing but the GPV. If you want freedom, don't tie people up with duct tape.
The Artistic Licence does just exactly what it was intended to do, and consequently is unlikely to disappear just because you want to remove people's freedom with a more restrictive, binding licence. Perhaps you might please reread it seen in this light.
--tom
Likewise, all programs are interpreted! Those PCs and SPs are there for nothing, you know. And that's just the start of it. I can compile into a VAX-11 polynomial expansion expression, and this still has to play patsy-cake with the firmware interpreter before it hits silicon.
You probably really meant `Perl that has only been compiled into parsetrees or bytecode for the PP interpreter to interpret, but which has not been compiled into C code and thence compiled into assembly language and thence compiled into machine language for the current or target firmware to interpret'.
But if so, I'm afraid that you'd still be wrong. One simply links in the whole image of the compiler as needed by things like do and eval. There's a good reason to keep a libperl.so lying about, and this is one of them. Of course, now that this is merely a shared library, of course there's no interpreter involved. :-)
Sigh. Where do they teach these mistaken notions of what a compiler really does? Doesn't anybody write a slew of diverse mini-compilers in school anymore? If you compile into P-code, who's to say you won't some day run on a chip with P-code-enabled hardware? Or it could be dynamically generated machine language, the way ML works, or the way Java's JIT stuff works.
We have one generic front-end compiler, three different optional code generators (bytecode, unrolled interpreter style C code, or optimized C code), a bytecode-to-PP rebuilder, and a PP-interpreter. That's the story, and I'm sticking to it.
--tom
Do you write Lisp scripts? Do you write BASIC scripts? Do you write Java scripts? Do you write Pascal scripts? Do you write C scripts? You can, of course. You can set those all up so they are run by a different virtual machine than the one that's doing firmware interpretation. And just who is doing the interpretation and how much preprocessing is done on the very same source code can vary from run to run.
Face it, this is an altogether silly idea borne of marketroids and other atechnical jargonizers with no legitimate foundation in the computing sciences.
--tom
The advent of freely available, plug-and-play substitutes for our standard Unix tools has been a great relief to victims of Big Bad Bill. These include the vi (vim, actually, but that's fine), Perl, the entire UWIN environment, the Cygwin suite, and of course, Perl Power Tools, which also work on non-{Microsoft,Unix} systems.
Some folks feel that we shouldn't port our tools to the evil one lest it thereby become easier to exist under his yoke, and thus perhaps decrease the chance of someone upgrading to Unix. But hold on there. Imagine that you're living in a fertile oasis of plenty, and on a dayhike, come across your friend toiling for his business in the searing desert that surrounds you. He is parched and crying out for aid. You invite him back to your oasis to refresh him, but he says that his job is there in the infernal sands. What do you do? Do you just walk away and abandon him? Of course not! You give him a sip or seven of that cool water you've brought with you from your safe haven.
So too should it be with our tools.
--tom
I'm curious how it will avoid the insanely inefficient process start-up penalties one incurs under Microsoft, as well as how the non-shared data pages will be fast without being copy-on-write. The multiple-interpreters-in-one-process work will also help everyone.
I'd say to reserve one's fears until there's something to fear. ActiveState can't after all be all bad: they even list the Perl Power Tools on their pages to help people sentenced to tool-deprived systems. :-)
--tom
Nostagically relevant, consider pi, pix, px, and pc on old BSD systems for a Pascal environment. I can present you with Pascal source, and ask what it is. You cannot tell me. It could be run under a pure interpreter, a bytecode compiler-and-interpreter, or further translated into some machine's assembly language. All are still interpreted.
Oh, they claim, they claim. But see the old article by Heinz Lycklama. Everyone else who did POSIX compliance did so to create something genuinely useful for their customers. Why use persnickety technicians when you get to hoodwink the courts to ordain you POSIX in a bait-and-switch game? I leave it to the readership to judge Microsoft on their own.--tom
First, to relegate Perl to nothing more than CGI is a tremendous disservice. Perl is a general-purpose programming language whose process, file, and text manipulation facilities have made it the programming language of choice for tasks involving quick prototyping, system utilities, software tools, system management tasks, database access, graphical programming, and world wide web programming--just to name a few. Systems administrators, network administrators, and web administrators on all platforms flavors especially love it because of its potential to automate virtually everything they need to do.
The second misconception to disabuse oneself of is this whole `scripting' notion as being somehow different from `programming'. It's not. They're quite the same thing, at least as used in the vernacular now that JCL scripts and uucp chat scripts are largely (and thankfully) gone. And before you mumble something about `interpreted', you should think about how, contrary to popular misconception, not merely Perl but all programming languages are interpreted. The only question is, at what level?
In the normal case, the Perl compiler compiles source code into parsetrees of Perl Pseudocode (PP), and hands those off to the PP interpreter to execute (one could say `interpret') these trees.
In other cases, the Perl compiler compiles source code into parsetrees of Perl Pseudocode (PP), and hands those off to a code generator, which generates bytecodes. These bytecodes are then later loaded by a special module that converts them back into PP trees, which are then handed off to the PP interpreter to execute (one could say `interpret').
In still other cases, the Perl compiler compiles source code into parsetrees of Perl Pseudocode (PP), and hands those off to a code generator, which generates C source code, which is handed off to the C compiler, which generates assembly source code, which is handed off to the assembler to produce object code, which is handed off to the linker to create a linked binary image, which is then handed off to the kernel to execute (one could say `interpret') at some later date, whose instructions are then often handed off to the firmware to execute (one could say `interpret').
In all cases, the Perl compiler runs an optimization pass, just like any other compiler. For example, the expression $x = 2 ** 31 - 1 would be computed at compile-time, since it's a constant expression. But the Perl compiler is rather more clever than just that, sometimes inlining certain subroutines, ignoring unreachable code, doing loop hoisting, etc.
I hope that's all clear now. :-)
That part is certainly true! And I hope that part is, too.--tom
--tom
--tom
--tom
Unfortunately, technically speaking, only catpages not manpages are required. Perhaps that's what you meant. But even catpages are better than nothing.
This hardly constitutes a fine selling point in your favor. Sometimes the FSF pertains more to the problem set than they do the solution set; this is certainly one of those places. Not only do they ignore the POSIX requirements, they appear to disavow the need for a unified, indexable, searchable, printable, formalized set of technical documentation. This is hardly what most of us would call `progress'.It's bad enough when you summon up a manpage only to be infuriatingly chidden by the FSF that `This documentation is no longer being maintained and may be inaccurate or incomplete.' Worse still is the situation with programs like diff or gnomecal, which are completely bereft of any manpage whatsoever. The FSF should be ashamed of themselves! This is one of the root causes of the notorious Daemon Linux project.
This lackadaisical attitude toward complete, on-line documentation is hardly confined to the FSF, although I hold them ultimately responsible for one area: Linux distributors. The Linux rebundlers inherit the problem from the FSF, and do nothing about it. Take SuSE for example. In virtually all other aspects a robust and coherent Linux distribution, SuSE confesses in their printed book that accompanies their CD that not all commands and functions have documentation. What a punt! They're just being irresponsible.
I suppose that one could in desperation invent some sort of rarefied alibi for the FSF's negligence here. They are, after all, more dedicated to principle than they are to mundane matters of quotidian utility. But for those who repackage and sell Linux distributions, no excuse can exist. These businesses are selling what they purport to be an integrated system, yet then have the audacity to confess that it is not. If the FSF won't fix this, then the resellers must. But the FSF really is the right place to fix it, because that way the fix helps everyone, rather than just one reseller trying to create a market advantage for themselves.
But this already depressing situation gets worse, far worse, before it gets better. You see, as programmers try to create something flashy enough to attract non-programmers, something critical has been lost. I'm thinking of those programs whose GUIs are the Way, the Truth, and the Light, whereby no man cometh unto the documentation for a given program save through its lauded GUI. If the information is not found under an About button or a Help button, it simply isn't available. Even if it were to be found there, how would you know it? Once you figure out each program's new set of hieroglyphics, these miserable shinyhappy icons and their cascading shinyhappy menus just aren't greppable. How do you in a non-manual fashion search through these myriad menus? How do you print them out? How do you create an index?
This situation in completely unacceptable.
Having recently tried out the whole Eterm, Enlightenment, and Gnome set-up, as duly impressed as I was with Eterm's manpage, I was severely underwhelmed by the attention toward detailed -- strike that, make it any -- documentation manifest in the other two. Miguel has assured me that what I had looked at was a mistake, that the released snuck out without the libraries' docs included. But I want more than only the programming libraries having manpages. If it's a command or a file format, it needs to be documented! Otherwise we're back to the mushroom school of systems management (keep us in the dark and feed us shit). Every little gnomic panel application and associated happycon needs a manpage, one that apropos and whatis can access, as well. Don't make me click with a mouse to find help and directions. I didn't spend thirty years mastering the keyboard and learning to read and write lengthy treatises merely to be reduced to a one-bit input device and a two-line output device.
Having to randomly hunt through manpages, HOWTOs, info pages, various programs' home pages out on the Web, per-program help pages, and stringsing the infernal binaries is shear madness As Henry Spencer observed, `Those who do not understand Unix are condemned to reinvent it, poorly.' Unified Unix manpages solved the insane situation in which you had shelves upon shelves of printed documentation that came with an IBM mainframe; these docs weren't online, so were unnavigable. Apparently we are doomed to repeat that unhappy history.
While it's true that I write all my books in troff, along with the traditional helpmates of eqn, pic, and tbl, please don't assume by this that I am particularly enamoured of that system. I'm certainly not. What I do expect in proper online documentation is the properties that manpages provide:
- All documentation must be contained and accessible from within the same on-line system.
- Available for independent on-line viewing, apart from the application.
- Format easy to read and write by humans, parse and generate by programs.
- Conveniently structured.
- Printable as a high-quality book using a typesetter.
- Searchable and indexable using standard tools.
The language used to encode this information is far less important than is having these basic features. Without a coherent, comprehensive, and unified documentation system, we might as well all be running some expert-hostile and user-obsequious toybox suitable for the point-and-drool atechnical public all too typical in these post-literate Dark Ages, where WYSIWYG means that what you see is all you get.--tom
Perhaps we should s/hacker/attacker/ or more simply s/hacker/criminal/ instead. While there are no guarantees that this will work any better, at least it will stand out better and so be less readily confusable.
--tom
Doubtless that's because you're a Prisoner of Bill. For the rest of us, it's garbeldy gook, because it's not legal HTML. If you fetch the raw page, and get a nice octal dump, you'll see what I mean.
My point was simply that I felt that when Slashdot points us at a site that requires a special setup to view (for example: you must register; or you must have a valid referring page; or you need Flash installed; or you must have tithed Lord Bill) that this merits special notification of this unpleasantry.
I assure you that I certainly did "check my facts" before posting. Did you?
--tom
Perhaps in much the same way as /. warns about registration required when pointing at the New York Times, it might also be useful if you would include a warning when Microsoft is required for proper viewing of a page you link to.