This was an April Fools post.
The rich history of Unix shell scripting is often overlooked by the community of "real programmers" who work in languages like C, C++, C#, Cobol, COMTRAN, CPL, Common Lisp, CLOS, CLIPS, Clojure, and even some lesser known languages which start with other letters. But this has left decades of important infrastructure tools unavailable to the average programmer without using an external command like "system" which is often considered a security risk due to the existence of "." in everyone's path.
As a result, the Perl 6 community has announced a new suite of tools that aid in converting old shell scripts into this modern language with all of the features one might expect, and all of the other ones also. This conversion is quite difficult, which is why most languages do not provide such a tool suite. The reason for this is that shell scripts inherently rely on external programs, so the language isn't just a set of syntax, but a semantic pallet that includes the entire operating system. Perl 6 resolves this problem by providing a unique module for every existing operating system revision.
For example, if your shells script was written to run under BSD 4.2 Unix variant, Ultrix, then you would run the conversion tool like so:
shell6 --system=unix.bsd.ultrix bofh.sh
Which would produce an output script called "bofh.pl". This script maintains a close compatibility with the legacy system by providing an execution environment that mirrors the expectations of the script. It will first boot a Perl 6 version of the 4.2 BSD kernel. This kernel is actually hand-written in Parrot Byte Code (PBC) giving it the blazing speed of an interpreted byte code, far out-performing the original Ultrix VAX-based systems, when run on modern hardware.
Next, Perl attempts to simulate the expected idiosyncrasies of these legacy systems. Because the 1980s pre-dated the development of the World Wide Web, there was a far greater dependency on communications protocols like UUCP, Usenet and FTP which are not nearly as widely used today. Thus, the shell6 translator also creates a "news spool" and establishes a "bang path" connection to other users of the service over which to communicate and share observations about the latest episode of Automan, Star Trek: The Next Generation or Babylon 5 with the simulated sense of urgency that only Perl 6's hyper operators can bring.
There are, however, some problems. There are still a number of simulated environments in which scripts do not behave as expected. In most of these cases, it is believed that the legacy scripts in question may depend on the ability to compile and run code in programming languages that start with the letter "C". For those cases, the next revision of shell6 intends to have a full parser (written in Perl 6 rules) for each of the common versions of these languages, but don't expect that to be released just yet, as there may be some concerns about embedded assembly that will require a more robust approach which simulates the entire hardware platform.
As the title of this article implied, there is also a team investigating the value of moving Perl 6 from the "P" namespace (let's face it, no real language has ever had a name that started with "P") to the more prestigious "C" namespace as "Clamchowder", so you may wish to begin using that name in all of your Perl 6 communications with colleagues. Final debate has already begun, but stalled on the options of "Clamchowder," "ClamChowder," "Clam-Chowder," or "Clam_Chowder." There is a small contingent of "clmchdr" advocates who claim that Perl's name should be golfed for great justice, but nobody is taking them seriously.
Yes, today is April 1.