Fry::Shell - Flexible shell framework which encourages using loadable libraries of functions.
From the commandline: perl -MFry::Shell -eshell OR In a script: package MyShell; use Fry::Shell; #subs sub evalIt { my $cls = shift; my $code = ($cls->Flag('strict')) ? 'use strict;' : ''; $code .= "@_"; eval "$code"; } sub listStations { my $cls = shift; my @stations = ( {name=>'high energy trance/techno',ip=>'http://64.236.34.196:80/stream/1003'}, {name=>'macondo salsa',ip=>'http://165.132.105.108:8000'}, {name=>'new age',ip=>'http://64.236.34.67:80/stream/2004'}, ); $cls->saveArray(map{$_->{ip}} @stations); return map {$_->{name}} @stations; } #set shell prompt my $prompt = "Clever prompt: "; #initialize shell and load a command and an option my $sh = Fry::Shell->new(prompt=>$prompt, load_obj=>{ cmds=>{listStations=>{a=>'lS'}}, opts=>{strict=>{type=>'flag',a=>'n',default=>0}} } ); #begin shell loop $sh->shell(@ARGV); ####end of example, start of other possible methods #run shell once $sh->once(@ARGV); #loads libraries and runs each library's &_initLib $sh->initLibs(@modules); $sh->loadFile($file); $sh->loadPlugins($myplugin); $sh->runCmd($cmd);
This document describes version 0.15.
Fry::Shell is a simple and flexible way to create a shell. Unlike most other light-weight shells, this module facilitates (un)loading libraries of functions and thus encourages creating shells tailored to several modules. Although the shell is currently only viewable at the commandline, the framework is flexible enough to support other views (especially a web one :). This module is mainly serving(will serve) as the model in an MVC framework.
From a user perspective it helps to know that a shell session consists of mainly four shell components (whose classes are known as core classes) : libraries (lib), commands (cmd), options (opt) and variables(var). Commands and options are the same as in any shell environment: a command mapping to a function and an option changing the behavior of a command ie changing variables within it or calling functions before the command. Variables store all the configurable data, including data relating to these commands and options. Libraries are containers for a related group of these components.
Here's a quick rundown of Fry::Shell's features:
- Loading/unloading shell components at runtime. - Flexible framework for using shell features via plugins. You can even set up a bare minimum shell needing no external modules! Currently plugins exist for dumping data,readline support,reading shell configurations and viewing shell output. - Commands and options can be aliased for minimal typing at the commandline. - Commands can have help and usage defined. - Commands can have user-defined argument types. One defines argument types by subroutines or tests that they should pass. These tests are then applied to a command's defined argument(s). With defined argument types, one can also define autocompletion routines for a command's arguments. - Options can modify variables. Since variables exist for almost every aspect of the shell, options can change many core shell functions. A handy example is 'parsecmd' which names the current parse subroutine for the current line. Changing this var would change how the input after the options is parsed. - Options can have different behaviors defined including the ability to invoke subroutines when called or to maintain a value for a specified amount of iterations. - Default options include 'menu' which numbers output and allows the next command to reference them by number. - Page output with preferred pager. - Multiline mode. - Comes with a decent default library,Fry::Lib::Default, to dump,list or unload any shell component, run system commands,evaluate perl statements and execute methods of autoloaded libraries.
Although this code is decently tested and is apparently unbuggy, I consider it alpha until a few design issues have been solved.
Oh yeah, some abbreviations I use often in these modules, especially in naming subroutines: cmd- command, lib- library,opt- option,var-variable, gen- general, attr- attribute .
The two main ways to start a shell are via &shell and &once. &once only runs once and useful for a noninteractive environment ie a shell script. To set up &once :
my $sh = Fry::Shell->new(prompt=>$prompt); $sh->once(@ARGV);
To set up &shell:
my $sh = Fry::Shell->new(prompt=>$prompt); $sh->shell(@ARGV);
What can you do in your shell? Run any subroutines which you define as commands (or even better commands defined by libraries). Even if your subroutines are not defined they can still be executed by typing the subroutine's name. In SYNOPSIS above, &evalIt is such a subroutine.
Looking at &evalIt's innards, you see that the first argument is $cls which is the class that calls commands. You also see ' $cls->Flag("strict") ' which is a boolean flag to prepend a 'use strict' to the evaluated code. Since we defined an option as type flag when initializing the shell, we change the flag's value when we flip the option from the commandline (ie '-n evalIt $ref = "woah"; $foo = "ref"; print $$foo').
&listStations is a cool example of the menu option. You'll need to have a music player that can be executed via a system call, most likely a *nix environment, and that can play shoutcast radio stations (ie xmms). Without any options, this command simply prints a list of stations. If you use the menu option (ie '-m lS'), the next input line is parsed differently with numbers being substituted with corresponding positions from the variable lines. For example,'! xmms 2', would call xmms with the 2nd radio station in the variable lines. The &saveArray call is what passed the list of ip's to the variable lines.
By default, options come before commands. You can change this behavior by redefining &parseLine. An option begins with a '-'. You can specify an option's alias or full name. To set an option's value put a '=' and the option value after it ie '-menu=1'. If no '=' comes after an option name then the option is treated as a flag and set to 1 (ie the previous example can be written '-menu').
The SYNOPSIS section contains a good example of a shell with a couple of functions. But what happens if you expand on this and develop several more radio-playing commands and other eval-based commands? You would probably break them up into separate shells as the shell gets crowded with too many commands you don't need for a given session. It's at this point that a library comes in handy.
A library is simply a group of related subroutines. At its simplest you can place your functions in a library, load the library and execute any of its functions. You can load library(ies) when initializing a shell via the libs attribute :
Fry::Shell->new(libs=>[qw/:Lib1 Fry::Lib::Lib2/]);
or after initialization via &initLibs:
$sh->initLibs([qw/:Lib1 Fry::Lib::Lib2/]);
Notice the shorthand ':Lib1' in both examples. This abbrevations is equal to 'Fry::Lib::Lib1' as 'Fry::Lib::' is implied by ':' . This shorthand should work for any public method that takes libraries.
Even if no libraries are specified, a shell loads the lib Fry::Lib::Default. Its functions enable you to view and change the core shell components.
Libraries are usually placed under Fry::Lib. Other namespaces will work for now but are only recommended if you can't get under the Fry::Lib namespace . To use most shell features, you need to define shell components in your library. Currently this is only done via &_default_data. However, since it only returns a hashref, there are many possible ways of storing configuration data ie databases,xml,dbm, FreezeThaw ...
A good library example is Fry::Lib::Default.
&_default_data returns a hashref that can set library attributes and create any shell component. It consists of any of the following keys:
depend(\@): lists other libraries that this library depends on. Dependent modules and their configurations are required and read before the current library. This parameter accepts the library abbreviation. cmds(\%): Defines commands with each id pointing to a defined object. A command object's attributes are explained in Fry::Cmd. cmds=>{cmd1=>\%obj1,cmd2=>\%obj2} opts(\%): Defines options with each id pointing to a defined object. An option object's attributes are explained in Fry::Opt. subs(\%): Defines subroutines with each id pointing to a defined object. A subroutine object's attributes are explained in Fry::Sub. objs(\%): Defines objects (of library classes) with each id pointing to a defined object. An object object's attributes are explained in Fry::Obj. vars(\%): Defines variables with each id pointing to its value. A variable object's attributes are explained in Fry::Var. Note: Since object and variable definitions only set one attribute of the object, it isn't possible to define any of their other attributes using &default_data. You could call &set in &_initLib.
This is an optional subroutine that initializes anything within the library after loading its configuration data. Its explicitly run via &Fry::Lib::runLibInits.
See Fry::ShellI for the complete list of public shell methods you can use when writing a library's commands.
A dilemma you mave come across when developing more complex libraries is portability. Perhaps you want to reuse a library's functions in other applications. Your library will fail in other applications that don't use shell methods. The obvious solution is minimizing the use of shell methods throughout your code. To work around the variable and flag-related methods, define global hashes for Fry::Shell flags and variables. Then write a wrapper around the command setting the needed variables and flags:
my (%flag,%var); sub commandMammoth { my $o = shift; #set variables for my $v (qw/Pi fodder goatcheese/) { $var{$v} = $o->Var($v) } #set flags for my $f (qw/complex simple fakeit/) { $flag{$f} = $o->Flag($f) } #original command #use %flag and %var in mammothAlgorithm $o->mammothAlgorithm(@_); }
Fry::Shell plugins provide flexibility for often used shell features both in functionality and in module dependency. In making Fry::Shell as portable as possible, the default plugins do not require any external modules. If Data::Dumper and Term::ReadLine::Gnu are detected,their plugins are used. When a plugin is loaded, it is required and then initialized via &setup. Plugins do not currently have their own shell components like libraries. There are currently five plugins: View, ReadLine,Dump,Error and Config.
View handles the view of the shell. Currently only a commandline view (Fry::View::CLI) exists. A view outputs to the filehandle specified by the var 'fh'. A view's methods can be accessed via the accessor View ie $o->View->list(@output).
Expected methods:
view(@): General view method called by all other view methods. Outputs to filehandle specified by variable fh. list(@): Displays an array one value per line. hash(\%arg\%options): Displays a hashref, a key-value pair per line. Also takes an options hash which can be passed a quote flag to quote values. arrayOfArrays(@): Displays an array of arrays with an array per line separated by the variable field_delimiter.
ReadLine plugins are usually interfaces to Term::ReadLine::* modules. These plugins are still in a state of flux and will delve into run-time configurable autocompletions, assigning keys and configurable commandline history. Fry::Shell comes with two of these plugins, Fry::ReadLine::Default and Fry::ReadLine::Gnu.
stdin($prompt): Reads input and returns it. prompt($prompt): Same as &stdin but also adds input to history.
Dump renders complicated data structures viewable. A dump's methods can be accessed via the accessor Dump ie $o->Dump->dump(@stuff). Fry::Shell comes with three of these plugins, Fry::Dump::Default, Fry::Dump::DataDumper, and Fry::Dump::TreeDumper.
dump($data_structure): Dumps given data structure Note that dumping doesn't output the data structure but returns a string dump. To print out a dump you could do this: $o->view($o->dumper($gargantuanDataStructure)).
Config plugins read configuration data (as if you didn't know). Currently only file configurations exist. Fry::Shell comes with two of these plugins, Fry::Config::Default and Fry::Config::YAML.
read($file): Reads given configuration file and returns a hashref.
Configurations are a quick way to define/redefine shell components such as variables and options. There are two configurations read when initializing the shell ,a core one and a global one. The core one is read after loading default data. Since the core config is read before you can specify your preferred config plugin, it will always be read by Fry::Config::Default. See the section Configuring Core Variables for more detail. The global config is the place to redefine any shell components from loaded libraries.
Configurations can also be loaded at the script level via &loadFile.
$sh->loadFile('/home/dope/.mylovelyconfig');
If you're unable to set an object's attribute through the config then you can always use a script method defined by the Fry::ShellI interface. For an example with a shell object $sh:
$sh->call(lib=>'set',':MyLib',class=>'MyLib');
See the t/testlib/ directory for sample configurations.
A configuration defines a hashref similar to a library's &_default_data, no suprise since they're both defining shell components. It can have any of the same keys as &_default_data except for depend.
When configuring core shell components (defined in this module's &_default data), you'll usually modify variable values. Here's a quick overview of core variables and what they do (note,variables take a scalar value unless indicated otherwise):
defaultlib: default library loaded instead of Fry::Lib::Default cmd_class: name of class which inherits loaded libraries plugin_config: config plugin plugin_readline: readline plugin plugin_dump: dump plugin plugin_view: view plugin plugin_error: error plugin defaultlibs(\@): default libraries to load parsecmd: current subroutine for parsing commands cmdlist: current subroutine for autocompleting commands viewsub: current subroutine for viewing subs, is used when it has a nonzero value fh: current filehandle for output view_options(\%): contains options to be passed at eval_splitter: used by &parseEval to delimit where normal parsing ends and where eval parsing begins field_delimiter: delimits fields used in view subroutines fh_file: used with fh_file option to specify filename pager: name of preferred pager mline_char: regular expression indicating end of a multiline command pipe_char: regular expression used to delimit piping between command names on commandline prompt: shell prompt core_config: name of core config file global_config:name of global config file lines: used by the menu option closefh: used by options to keep track of open filehandles quit: flag which indicates to &shell to quit when true skipcmd: flag which skips executing a command when true autoview: option variable, see section Useful Options skiparg: " " menu: " " method_caller: " " multiline: " " cmdlist: " " page: " " loaded_libs(\@): currently loaded libraries
See Fry::Error for details.
When considering where and how to create/recreate shell component values, you should know how and in what order they are loaded. For now, the creation of shell component objects at any of these stages is ultimately done by &Fry::List::setOrMake. This method creates an object if it doesn't exist. If it does exist, it sets the object with its value. The shell components are loaded in the following order: config of Fry::Shell library, core config, config of all other libraries, global config,load_obj option of &new and options setting variable values.
Fry::Shell comes with a few handy options (defined in &_default_data):
parsecmd: sets the current parsing subroutine, handy when needing to pass a command a complex data structure and want to use your own parsing syntax cmdlist: sets the current subroutine for autocompleting commands menu: sets parsecmd to parseMenu thus putting the user in a menu mode where each output line is aliased to a number for the following command, explained in SYNOPSIS Explained section fh_file: sends command's output to specified file name page: sends command's output to preferred pager autoview: flag which turns on/off autoview and a command's subroutine outputs for itself skiparg: flag which turns on/off skipping command argument checking multiline: begins multiline mode method_caller: Controls class or object that calls a method when calling a command. Value of 1, calls method with CmdClass. See &Fry::Cmd::runCmd for details.
Subroutine hooks allows runtime choosing of which subroutine to call at its location. Every choice is a Fry::Sub object defined in a library's config. You can choose your subroutine by setting the variable containg the hook's subroutine id, which is only done for now by its option.
A parser sub hook parses the input after options. It receives the input as a string and returns the command and its arguments in an array.
sub parseMyWay { my ($o,$input) = @_; return (split(/ |/,$input)) }
Available parse subroutines are parse* methods in Fry::Sub. This hook's variable and option is parsecmd.
This sub hook returns the list of commands when autocompleting commands. This hook's variable and option is cmdlist.
This sub hook displays output in &autoView when set to a nonzero value. This hook's variable and option is viewsub.
To start a multiline session you flip the multiline option (ie '-M'). The multiline mode lasts as long as it doesn't encounter the variable mline_char, default being ';'. Multiple lines of input are joined by a whitespace.
This is a sweeet feature implented via &classAct and &objectAct that allow you to load a normal module and act on its object and/or class methods. See Fry::Lib::Default for details.
By default, any command with an arg attribute has its arguments checked. See <Fry::Cmd> for details.
Shell scripting methods that are recommended for scripting Fry::Shell while methods that are encouraged to be subclassed.
A method's arguments are described via data structure symbols @,$,% and a descriptive name. Optional arguments are described in perl regular expression format.
Shell scripting methods new(%options): Creates a shell object and creates its shell components ie load libraries and initialize core data. It can take any variable name and value pairs as well as the following keys: libs(\@): Loads libraries after having loaded all libraries specified in configs. core_config($): core config file load_obj(\%): Creates shell components via &setAllObj,see it for data structure format global_config($): global config file Note: For further description of core variables look at the above section Configure Core Variables. You can pass a core variable as an option just like any other variable. shell(@input?): Starts the shell's main loop. Optional argument is input to first loop iteration. once(@input?): One iteration of loop. If optional argument isn't given, prompts for input. runCmd(@args): Executes given command and arguments. initLibs(@libs): Loads libraries and calls library initialization subroutines. loadFile($file): Reads config file via config plugin. loadPlugins(@vars): Loads plugins by their variable name ie plugin_config. Subclassable methods preLoop(): This subroutine executes at the beginning of every shell loop. postLoop(): This subroutine executes at the end of every shell loop. loopDefault($cmd,@arg): This subroutine executes if no valid command is given. By default this sub returns an error message of an invalid entry. It is passed an array containg the command and its arguments. setPrompt(): Returns shell prompt to be displayed parseLine($input): Parses input into option and command sections and carries out actions associated with these shell components. Returns an array containg the command first and the arguments afterwards. autoView($cmd,@cmd_output): Handles displaying a command's output when the autoview flag is set. This subroutine handles cases first by the variable viewsub, then by number of arguments and then by type of data. This subroutine may move over soon to Fry::View::CLI. getInput(): Returns input from one shell iteration. The default way to get input is via a ReadLine plugin's &prompt. Should be subclassed if a Readline plugin for &prompt can't be made. postQuit(): Called after user has quit the shell via &shell. Useful for saving state of shell ie command history.
An outline of all modules that come with Fry::Shell Core classes Fry::Var Fry::Cmd Fry::Opt Fry::Obj Fry::Lib Fry::Type Fry::Sub Libraries Fry::Lib::Default Fry::Lib::DBI Fry::Lib::Inspector Plugins Fry::Config::YAML Fry::Config::Default Fry::Error Fry::Error::Carp Fry::Dump::DataDumper Fry::Dump::TreeDumper Fry::Dump::Default Fry::ReadLine::Default Fry::ReadLine::Gnu Fry::View::CLI Other modules Fry::List Fry::Base Fry::Shell Fry::ShellI
See Fry::Lib::* for available libraries.
For similar light shells, see Term::Shell,Shell::Base and Term::GDBUI.
For big-mama shells look at Zoidberg and psh.
I use Devel::Cover to test code coverage. All modules have a total code coverage of at least 70%. I aim to cover more as the API stabilizes.
There are a jazillion things I would like to do with this module. Here are the high priority items:
priority 1 autoload modules develop framework around &objectAct be able to load: OO methods ie List::Compare class methods ie Class::DBI functions ie Date::Manip view plugin: cgi view develop configuration format for autoloaded modules and plugins menu or option-based choosing of a class's global settings menu or option-based choosing of a module's functions error framework logging error tracking with Fry::List readline and Fry::Type autocomplete arguments of commands chain commands: autocomplete cmds based on output type of last command map commands to keys priority 2 move &autoView and convert it to a for loop of Fry::Sub objects clean tests
Me. Gabriel that is. I welcome feedback and bug reports to cldwalker AT chwhat DOT com . If you like using perl,linux,vim and databases to make your life easier (not lazier ;) check out my website at www.chwhat.com.
Although I've written up decent tests there are some combinations of configurations I have not tried. If you see any bugs tell me so I can make this module rock solid.
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
To install Fry::Shell, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Fry::Shell
CPAN shell
perl -MCPAN -e shell install Fry::Shell
For more information on module installation, please visit the detailed CPAN module installation guide.