I believe Perl was meant as a replacement for shell <i>scripts</i>, as well as sed and awk script. It wasn&#x27;t designed as a interactive shell. For example, the original perl man page says (quoting from <a href="http:&#x2F;&#x2F;history.perl.org&#x2F;PerlTimeline.html" rel="nofollow">http:&#x2F;&#x2F;history.perl.org&#x2F;PerlTimeline.html</a> ):<p><pre><code>        Perl is a interpreted language optimized for scanning  arbi-
     	trary  text  files,  extracting  information from those text
     	files, and printing reports based on that information.  It&#x27;s
     	also  a good language for many system management tasks.  The
     	language is intended to be practical  (easy  to  use,  effi-
     	cient,  complete)  rather  than  beautiful  (tiny,  elegant,
     	minimal).  It combines (in  the  author&#x27;s  opinion,  anyway)
     	some  of the best features of C, sed, awk, and sh, so people
     	familiar with those languages should have little  difficulty
     	with  it.
</code></pre>
The closest that perl had to an interactive shell was with the &quot;-d&quot; debugger. See for example this synopsis from 2007 at <a href="http:&#x2F;&#x2F;archive.oreilly.com&#x2F;pub&#x2F;post&#x2F;writing_a_modern_perl_repl.html" rel="nofollow">http:&#x2F;&#x2F;archive.oreilly.com&#x2F;pub&#x2F;post&#x2F;writing_a_modern_perl_re...</a> :<p>&gt; One area in which Perl falls behind other languages is in its lack of a usable Read-Evaluate-Print-Loop. (perl -de 0 just isn&#x27;t enough for me.) I&#x27;ve used Ruby&#x27;s irb and a handful of Python shells, and I&#x27;m starting to become a fan of ghci, but I fall back on perl -e far too often for my sanity.<p>An interactive shell should, in my opinion, support more than a REPL. It should also implement job control, like suspending a job or starting jobs in the background. Perl definitely was not invented for that purpose.