|
Re: Perl as interactive Shell?
by tobyink (Canon) on May 12, 2017 at 22:05 UTC
|
Okay, here's a very basic shell implementation…
It only really implements cd and ls. So you can start the shell and type:
> cd('bin')
> ls()
> cd('..')
And things work as you might expect. The eval which evaluates each line has strict and warnings switched off, so you can use things like barewords. Thus the following also works fine and feels slightly more shell-like:
> cd bin
> ls
> cd '..'
| [reply]
[d/l]
[select] |
|
|
Thanks, but i hope you know that there already exist a wild variety of "solutions"
especially perldebug comes with a variety of unknown goodies, like tab completion, introspection and doc lookup and is backwards compatible.
I once spend time adding patching the debugger to Data::Dump of the evaled line and allowing multiline commands ( talk ... sorry slides are offline ATM)
> It only really implements cd and ls. So you can start the shell and type:
yep, OS independence is nice ... though I'm thinking about reusing Brian's powertools
> The eval which evaluates each line has strict and warnings switched off, so you can use things like barewords. Thus the following also works fine and feels slightly more shell-like:
> cd bin
two problems
- the Shell code should be production ready, thus allowing cut&paste
- as soon as you use a path separator like / barewords would fail (parser sees regex)
my idea is to allow a DWIM typing with barewords and path, but to visually translate to correct syntax
i.e. one types
> cd /home/user
but display and history would automatically shows
> cd '/home/user'
(tab completion needs syntax awareness anyway and it'll be a service for people coming from sh)
| [reply]
[d/l]
[select] |
|
|
Ha, I love it! Need a modular Perl Shell? Why not Zoidberg?
(V) (;,,;) (V)
Whoop! Whoop! Whoop! Whoop! Whoop! Whoop! Whoop!
Just another Perl hooker - Working on the corner... corner conditions that is.
| [reply] |
Re: Perl as interactive shell?
by haukex (Archbishop) on May 12, 2017 at 15:11 UTC
|
run \@cat, '<', "in.txt", '>>', "out.txt", '2>>', "err.txt";
run \@cat, '|', \@gzip;
with less and ls implemented as subs (see also Shell)
Excuse the plug, but I wrote a module that presents a similar interface, but it has more error handling, less problems with shell quoting, and additional capabilities: IPC::Run3::Shell.
There are also several modules I've found very useful in writing shorter code, such as Path::Class and File::Find::Rule.
what are the fundamental obstacles hindering Perl to be used instead of Bash and or PowerShell?
I imagine one issue that might come up is variable scoping, i.e. how long do variables last once they're created - I imagine in a long-running shell, this might end up being a bit of a memory leak. | [reply]
[d/l] |
|
|
Thanks that's nice! :)
IPC::Run is certainly interesting, but it'd need a nicer syntax to be usable in a CLI.
IPC::Run3::Shell already looks much better, but I'd opt to use it primarily for non-standard executables which can't be implemented in Perl. (like with powertools )
| [reply] |
|
|
IPC::Run3::Shell already looks much better, but I'd opt to use it primarily for non-standard executables which can't be implemented in Perl.
Agreed, and I wouldn't normally shell out to things that Perl can do natively either. Sometimes, if I'm writing a one-off script that's not meant for production, I might call find, but then again I've started using File::Find::Rule more often (even though I've measured it and it's not nearly as fast as File::Find or find). Anyway, I grepped my code and here are two examples of how I've actually used the module, in the first one I remember that in that particular case, simply calling the convert program was much faster to implement than getting Image::Magick set up. Especially if the scripts are not meant for a production environment, speed of development is often what it's about; depending on what one has the most experience with, remembering or looking up the command-line arguments can be faster than finding the appropriate Perl module.
use IPC::Run3::Shell { fail_on_stderr=>1 }, qw/convert/;
convert $img, '-auto-orient', '-resize', '300x300', $thumb;
use IPC::Run3::Shell qw/gs/;
gs({fail_on_stderr=>1,show_cmd=>1},
'-o',$OUTPUT, '-sDEVICE=pdfwrite', ..., '-f',$INPUT);
Update: Minor re-wording. | [reply]
[d/l]
[select] |
Re: Perl as interactive Shell?
by marto (Cardinal) on May 12, 2017 at 14:59 UTC
|
| [reply] |
|
|
yes, IIRC zoidberg had a good handling of Term::Readline (I don't like the underlying documentation of Gnu-Readline )
And there was also another attempt ("perlshell" ? "psh"?) where pipe was overloaded.
But I'm asking about technical limitations, because I'm thinking about patching the perldebugger in a REPL/Shell way.
update
see also using perldebugger as REPL?
| [reply] |
|
|
Technically, seems like it should work fine. It would probably be convenient for at least some one-off tasks, or for working out the logic of a script-able procedure. And a lot of what can be done in *sh can be done in Perl with out using external executables. (Not that I see anything intrinsically wrong with using external executables - especially when *sh issues can be avoided by bypassing *sh.)
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
Re: Perl as interactive Shell?
by GotToBTru (Prior) on May 12, 2017 at 18:26 UTC
|
I suppose I'm showing my ignorance, but how would you execute Perl without the shell?
But God demonstrates His own love toward us, in that while we were yet sinners, Christ died for us. Romans 5:8 (NASB)
| [reply] |
|
|
xterm -e perl -MReply -e'Reply->new->run'
| [reply]
[d/l] |
|
|
I said interactive shell.
"Shell" is an ambiguous term
Bash can be
- the shell process parenting Perl
- the interactive CLI
- the language of shell scripts.sh
we mainly use Perl for the last part and full scale applications.
Taking into consideration that a big part of Perl's gene pool comes from sed, awk AND Bourne shell ( plus lisp), it's paradoxical not to use Perl as CLI.
| [reply] |
|
|
Paradoxical not to use as a CLI? I don't see how. Certainly that's not what Perl was developed to be. 3 out of 4 parents in your list aren't CLI's either.
I suppose the motivation is to put its features more at your fingertips, moreso than perl -e already does. I often use the debugger for that purpose. Do you have a simple example of something you'd like to be able to do that you can't at present?
But God demonstrates His own love toward us, in that while we were yet sinners, Christ died for us. Romans 5:8 (NASB)
| [reply]
[d/l] |
|
|
|
|
Actually, you called the troll's bluff. xD
| [reply] |
Re: Perl as interactive Shell?
by Anonymous Monk on May 12, 2017 at 17:37 UTC
|
The only reason Perl can be a replacement at all for the shell is because it can fork and exec. What it cannot replace is the shell's natural ability to communicate with itself. Rather than trying to solve all your problems with one tool, use the right tool for the task at hand.
Another way of looking at it is shell programming works on one level, and dynamic languages work on completely different level. | [reply] |
|
|
> What it cannot replace is the shell's natural ability to communicate with itself.
Please elaborate "ability to communicate with itself" (?)
Best with examples.°
... the rest sounds buzzwordy (and sorry also "sundial'ish" )
°) I have the impression you don't know much about Perl's possibilities to communicate.
| [reply] |
|
|
Means you are trying to use shell in Perl when you should be using shell to use Perl:
curl -o - 'http://perlmonks.org/?node_id=1190142' | \
perl -Mojo -e'a("/"=>{text=>do{local$/;<STDIN>}})->start' daemon
| [reply]
[d/l] |
|
|
Re: Perl as interactive Shell?
by Anonymous Monk on May 12, 2017 at 18:39 UTC
|
Don't try to outsource your research. Roll up the sleeves and get right to it. Experiment. Restrict yourself to using perl shell and perl shell alone for two weeks. Then share the new-found experience.
| [reply] |
|
|
My use of CLIs doesn't necessarily reflect the use pattern of others i.e. common requirements
And I already rolled up my sleeves long ago and patched the debugger for my needs.
update
Besides restricting myself to the new shell is easy if you are forced to use windows like I am. My alternatives are limited.
| [reply] |
|
|
Oh, I see... You're basically asking why other people are unlike you: what could they possibly lack in a perl CLI when it serves your purposes perfectly.
Try turning the argument around. Why would someone pick perl over bash. Consider various possibilities, different job descriptions, etc. Also remember, introspection is good for you, 'slong as you don't succumb to infinite recursion. ;)
Oh, and for heavens sake, stop slapping everyone with the -1. PEB(y)KAC.
| [reply] |
|
|
|
|
|
|
I understand this is an old thread, but the concept is interesting.
It would definitely be nice to have a shell with perl capabilities.
Handling arrays and hashes from the shell would be super fantastic.
Handling regex matches like perl can do would be extremely awesome.
Yes, this is a good idea indeed, would help with perl revival IMHO.
| [reply] |
