Stories
Slash Boxes
Comments
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 ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Wednesday August 13, 2008
07:42 PM

In search of a good Perl shell (by my standards)

[ #37175 ]

In response to the release of Perl::Shell, Shawn Moore had some fairly nasty initial feedback he chose to post to cpanrantings.

So I thought I should at least explain why I created it (in a location that won't be polluting).

Like with many areas pioneered by more advanced users, my main problem is mostly with Windows support.

Lets start with Devel::REPL, and why I didn't just use it instead.

Partly, this is my fault. For some reason, I thought Devel::REPL used Coro, so when "testing" Devel::REPL I first tried to install Coro, which won't build on Windows at all.

Of course, because I was completely mistaken about Devel::REPL I missed the fact that Devel::REPL installs just fine on Win32. I really should have known better, since Matt Trout himself uses Windows.

The only problem with DeveL::REPL is that the perl shell it provides "re.pl" doesn't work on Windows as documented, because the .pl extension is associated with who knows what.

Devel::REPL also has some other minor problems, such as using vstrings in use lines (which throws a warning), allowing incomplete statements (although a few patches from me to the PPI functionality should fix that) and odd visual behaviour when you print something without a trailing newline.

Frankly, Python did the shell usability things really really well, and I would personally would just like a clone of the way they do it.

Looking at this situation, I'll probably end up ditching Perl::Shell, and moving "perlthon" to App::Perlthon instead, since it should be a fairly lightweight wrapper around Devel::REPL, once some bugs in Devel::REPL are fixed.

As for the other alternatives suggested by Shawn Moore, the field is a bit thinner.

Shell::Perl doesn't work on Windows, so is irrelevant.

App::Perl does install, and it's iperl shell does SORT of work, but all the prompts spew weird crap to the command line. It looks like maybe it's coloured ansi gone bad.

perlconsole installs on Win32, then spews some warnings that stink of Unix biases, and doesn't support implicit multi-line statements, plus is kinda noisy.

Zoidberg I have never heard of, and would never have found in a CPAN search, and also doesn't work on Windows.

Finally, Sepia's Makefile.PL starts with the particularly inspiring comment...

        To actually use this package in a useful way, you probably need to
        move the Emacs Lisp files somewhere. Where will depend on your
        installation.
... and then starts asking questions about optional features I have no idea about.

It installs, but at that point I actually looked at the search.cpan page for Sepia, to discover it isn't even a shell at all, but some kind of extension for an editor I don't even use. So the message makes a bit more sense, but the module is still useless to me.

So apart from Devel::REPL, they are all entirely useless from a cross-platform perspective (but obviously more useful if you don't mind being Unix-specific).

Apart from the initial mistake of misjudging Devel::REPL, it would seem there WAS room for a new shell.

I agree that with Devel::REPL, there's probably no need for another complete standalone shell. Instead, I'll probably just fix the various annoying bugs in Devel::REPL, and then rewrite "perlthon" around it instead.

Unless of course, Devel::REPL wanted to use it instead of the current re.pl script...

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Speaking as the author...

    First, Sepia could be used as the basis for a decent REPL, but it has been developed as part of the Emacs integration.

            rlwrap perl -Mblib -MSepia -e Sepia::repl

    works fairly well, but misses out on completion. I should really write a "repl" script that ties into readline at some point, but since I always have Emacs running, and don't really care for a language REPL outside an editor (you use vi?), I have little incentive to do so.

    Second, you seem to have

    • My problems with the Makefile.PL were only because at that point I still didn't know that Sepia was an Emacs thing, and thought it was a simple REPL-like shell.

      Now that I know, I'm completely fine with it.

      That said, if the optional deps pass tests, it might be a good idea to just make them mandatory.

      • I think the deps pass tests, but PadWalker, Lexical::Persistence, and Devel::Size are all seemingly fragile XS modules (I have an open heisenbug against Devel::Size, for example). Mainly, though, I don't like forcing people to clutter their systems with modules they don't use, so I try to minimize required dependencies.

  • Looks like you didn't try Shell::Base [cpan.org], which I wrote a few years ago for exactly the same purpose, and it's based on Python's Cmd class. Despite its low version number and large amount of "failing" tests (which are /all/ because of Term::ReadLine and Term::Size problems) it's mostly complete and usable. By default, it's a little Unix-specific, though there's nothing inherently Unix-specific in it. The readline dependency can be removed easily, and in fact the docs give an example of how to do it.
    --
    (darren)
    • I didn't find Shell::Base in my searching.

      It doesn't install on Windows, due to Term::Size failing.

  • I probably overreacted. :)

    To further explain my rating, I was completely put off by (only) this section of your documentation:

    Thanks to Ingy for suggesting that this module should exist.

    It originally seemed to fly in the face of all the hard work people have done to make usable and featureful Perl shells. I interpreted this line as "How come nobody's written a shell that evaluates Perl before?" which would of course be ludicrous. If you had included reasons why other REPL modules didn't work for you, I woul

  • On an almost but not quite completely unrelated note, Coro does at least work under cygwin. I tried it under strawberry last night and it didn't work out so well though. I'll let you know if I can get it to work.

    'Cause I want Continuity on a perl on a perl on a stick stick! And who wouldn't? :)