Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ChrisDolan (2855)

  (email not shown publicly)

Journal of ChrisDolan (2855)

Wednesday January 30, 2008
12:04 AM

[Idea Bin] Port bash to Parrot

[ #35518 ]

I'm going to use the "[Idea Bin]" flag to indicate ideas or projects that I would love to develop if I had more time, but realistically admit that I'll never finish. If you choose to use one of these ideas, you have my permission and best wishes.

An implementation of bash on Parrot would be a great test of Parrot's I/O capabilities. The source code for bash is fairly readable considering how arcane are some of its supported operations. Bash has a rather healthy test suite that could be reused during development.

I spent many commutes pondering possible names for such a port, but never came up with a great one. I wanted "posh" to work, but never came up with the right words for the acronym. "bashup" = bash-under-parrot felt too forced.

If such a parrot implementation would enable you to call out to other languages via namespace prefixes on functions, this could let shell be a better glue language than ever. You could incrementally port hairy shell scripts to more expressive programming languages.

Then you could switch all of your /etc/rc scripts to run under parrot by just changing the sharp-bang.

Furthermore, I've been a csh/tcsh user for 15 years and have always envied the power of bash, but never bothered learning more than the rudiments. This would be an excuse to learn it deeply.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I saw that comment on perlbuzz! :)

    As one of the only people with solid Java/Eclipse experience, who as also hacked PPI and Perl::Critic and has some idea of what things are actually possible, when do we get to see the journal entry that contracts the toolsets and suggests the bits that could be done for Perl reasonably.
    • I wrote up [] my Java tooling ideas last week on the Perl::Critic mailing list, but it was Warnocked.

      I summary, I think perlcritic6 should split into two tools: one that analyzes byte code (and is thus language-agnostic) and one that analyzes source code. The former is easier, because the compiler has to do all of the worrying about optional grammars and BEGIN blocks.
      • I certainly agree that they are two different classes of tools...

        If you look at something like the linting backend of Komodo, it does the whole "perl -c code" thing repeatedly.

        Perhaps the problem with that sort of proposal is that it's easy for humans to understand what sorts of policies you can write for PPI-based stuff, because it "parses" the same way that humans do.

        It's trickier to mentally understand how you do the same thing for bytecode, because many less people understand the code at that level.