1Term::Shell(3) User Contributed Perl Documentation Term::Shell(3)
2
3
4
6 Term::Shell - A simple command-line shell framework.
7
9 version 0.13
10
12 package MyShell;
13 use base qw(Term::Shell);
14
15 sub run_command1 { print "command 1!\n"; }
16 sub smry_command1 { "what does command1 do?" }
17 sub help_command1 {
18 <<'END';
19 Help on 'command1', whatever that may be...
20 END
21 }
22
23 sub run_command2 { print "command 2!\n"; }
24
25 package main;
26 my $shell = MyShell->new;
27 $shell->cmdloop;
28
30 Term::Shell lets you write simple command-line shells. All the boring
31 details like command-line parsing, terminal handling, and tab
32 completion are handled for you.
33
34 The base class comes with two commands pre-defined: exit and help.
35
36 To write a shell with an "exec" command, do something like this:
37
38 package MyShell;
39 use base qw(Term::Shell); # or manually edit @MyShell::ISA.
40
41 sub run_exec {
42 my ($o, $cmd, @args) = @_;
43 if ($cmd ne $0) {
44 print "I'm sorry you're leaving us...\n";
45 }
46 exec $cmd, @args;
47 exit 1;
48 }
49
50 When Term::Shell needs to handle the "exec" command, it will invoke
51 this method. That's all there is to it! You write handlers, and
52 Term::Shell handles the gory details.
53
55 How do you bring your shell to life? Assuming the package "MyShell"
56 contains your actions, just do this:
57
58 use MyShell;
59 my $shell = MyShell->new;
60
61 # Setup code here (if you wish)
62
63 # Invoke the shell
64 $shell->cmdloop;
65
66 # Cleanup code here (if you wish)
67
68 Most people put the setup code in the shell itself, so you can usually
69 get away with this:
70
71 use MyShell;
72 MyShell->new->cmdloop;
73
74 It's that simple! All the actions and command handlers go in
75 "MyShell.pm", and your main program is simple. In fact, it's so simple
76 that some people like to write both the actions and the invocation in
77 the same file:
78
79 package main;
80 MyShell->new->cmdloop;
81
82 package MyShell;
83 use base qw(Term::Shell);
84
85 # Actions here
86
87 Adding commands to your shell is just as easy, if not easier.
88
90 For every command "foo", Term::Shell needs a method called "run_foo()",
91 where 'foo' is what the user will type in. The method will be called
92 with the Term::Shell object as the first parameter, followed by any
93 arguments the user typed after the command.
94
95 Several prefixes other than "run_" are supported; each prefix tells
96 Term::Shell to call that handler under different circumstances. The
97 following list enumerates all the "special" prefixes. Term::Shell will
98 ignore any method that doesn't start with a prefix listed here.
99
100 1. run_foo()
101
102 Adds the command "foo" to the list of supported commands. The
103 method's return value is saved by Term::Shell, but is not used.
104
105 The method is called with the Term::Shell object as its first
106 argument, followed by any arguments the user typed in.
107
108 Special case: if you provide a method "run_()", Term::Shell will
109 call it whenever the user enters a blank line. A blank line is
110 anything which matches the regular expression "/^\s*$/".
111
112 2. help_foo()
113
114 Adds the command "foo" to the list of help topics. This means the
115 user may enter 'help foo' and get a help screen. It should return a
116 single string to be displayed to the user.
117
118 The method is called with the Term::Shell object as its first
119 argument, followed by any arguments the user typed in after 'help
120 foo'. You can implement hierarchical help documents by using the
121 arguments.
122
123 If you do not provide a "help_foo()" method, typing 'help foo'
124 produces an error message.
125
126 3. smry_foo()
127
128 Should return a one-line summary of "foo", to be displayed in the
129 help screen.
130
131 This method is called with the Term::Shell object as its first
132 argument, and no other arguments.
133
134 If you do not provide a "smry_foo()" method, then the string
135 'undocumented' is used instead.
136
137 4. comp_foo()
138
139 Provides custom tab-completion for "foo". That means if the user
140 types 'foo ' and then hits <TAB>, this method will be called. It
141 should return an array reference containing a list of possible
142 completions.
143
144 This method is called with the Term::Shell object as its first
145 argument, followed by the three arguments:
146
147 1. $word
148
149 The word the user is trying to complete.
150
151 2. $line
152
153 The line as typed by the user so far.
154
155 3. $start
156
157 The offset into $line where $word starts.
158
159 If you do not provide "comp_foo()", Term::Shell will always return
160 no completions for "foo".
161
162 Special case: if you provide "comp_()", Term::Shell will call it
163 when the user is trying to complete the name of a command.
164 Term::Shell provides a default "comp_()" method, which completes
165 the actions that you have written handlers for. If you want to
166 provide tab-completion for commands that do not have handlers,
167 override "comp_()".
168
169 5. alias_foo()
170
171 Returns a list of aliases for "foo". When one of the aliases is
172 used instead of "foo", the corresponding handler for "foo" is
173 called.
174
175 6. catch_run()
176
177 catch_help()
178
179 catch_comp()
180
181 catch_smry()
182
183 Called when an undefined action is entered by the user. Normally
184 when the user enters an unrecognized command, Term::Shell will
185 print an error message and continue.
186
187 This method is called with the Term::Shell object, the command
188 typed by the user, and then the arguments which would normally be
189 passed to the real handler.
190
191 The "catch_" methods may do anything the original function would
192 have done. If you want, you can implement all the commands in it,
193 but that means you're doing more work than you have to. Be lazy.
194
195 When you want something done right...
196 You sometimes have to do it yourself. Introducing add_handlers().
197 Naturally, it adds a handler to the list of defined handlers in the
198 shell.
199
200 Term::Shell can't always find the commands you want to implement by
201 searching the inheritance tree. Having an AUTOLOAD() method, for
202 instance, will break this system. In that situation, you may wish to
203 tell Term::Shell about the extra commands available using
204 add_handlers():
205
206 package MyShell;
207 use base qw(Term::Shell);
208
209 sub AUTOLOAD {
210 if ($AUTOLOAD =~ /::run_fuzz$/) {
211 # code for 'fuzz' command
212 }
213 elsif ($AUTOLOAD =~ /::run_foozle$/) {
214 # code for 'foozle' command
215 }
216 }
217
218 sub init {
219 my $o = shift;
220 $o->add_handlers("run_fuzz", "run_foozle");
221 }
222
223 There are other ways to do this. You could write a "catch_run" routine
224 and do the same thing from there. You'd have to override "comp_" so
225 that it would complete on "foozle" and "fuzz". The advantage to this
226 method is that it adds the methods to the list of commands, so they
227 show up in the help menu and you get completion for free.
228
230 You're probably thinking "just don't write them". But remember, you can
231 inherit from another shell class, and that parent may define commands
232 you want to disable. Term::Shell provides a simple method to make
233 itself forget about commands it already knows about:
234
235 1. remove_commands()
236
237 Removes all handlers associated with the given command (or list of
238 commands).
239
240 For example, Term::Shell comes with two commands ("exit" and
241 "help") implemented with seven handlers:
242
243 1. smry_exit()
244
245 2. help_exit()
246
247 3. run_exit()
248
249 4. smry_help()
250
251 5. help_help()
252
253 6. comp_help()
254
255 7. run_help()
256
257 If you want to create a shell that doesn't implement the "help"
258 command, your code might look something like this example:
259
260 package MyShell;
261 use base qw(Term::Shell);
262
263 sub init {
264 my $o = shift;
265 $o->remove_commands("help");
266 }
267
268 # ... define more handlers here ...
269
270 2. remove_handlers()
271
272 Removes the given handler (or handlers) from the list of defined
273 commands. You have to specify a full handler name, including the
274 'run_' prefix. You can obviously specify any of the other prefixes
275 too.
276
277 If you wanted to remove the help for the "exit" command, but
278 preserve the command itself, your code might look something like
279 this:
280
281 package MyShell;
282 use base qw(Term::Shell);
283
284 sub init {
285 my $o = shift;
286 $o->remove_handlers("help_exit");
287 }
288
289 # ... define more handlers here ...
290
291 Cover Your Tracks
292 If you do remove built in commands, you should be careful not to let
293 Term::Shell print references to them. Messages like this are guaranteed
294 to confuse people who use your shell:
295
296 shell> help
297 Unknown command 'help'; type 'help' for a list of commands.
298
299 Here's the innocuous looking code:
300
301 package MyShell;
302 use base qw(Term::Shell);
303
304 sub init {
305 my $o = shift;
306 $o->remove_commands("help");
307 }
308
309 MyShell->new->cmdloop;
310
311 The problem is that Term::Shell has to print an error message, and by
312 default it tells the user to use the "help" command to see what's
313 available. If you remove the "help" command, you still have to clean up
314 after yourself and tell Term::Shell to change its error messages:
315
316 1. msg_unknown_cmd()
317
318 Called when the user has entered an unrecognized command, and no
319 action was available to satisfy it. It receives the object and the
320 command typed by the user as its arguments. It should return an
321 error message; by default, it is defined thusly:
322
323 sub msg_unknown_cmd {
324 my ($o, $cmd) = @_;
325 <<END;
326 Unknown command '$cmd'; type 'help' for a list of commands.
327 END
328 }
329
330 2. msg_ambiguous_cmd()
331
332 Called when the user has entered a command for which more than
333 handler exists. (For example, if both "quit" and "query" are
334 commands, then "qu" is an ambiguous command, because it could be
335 either.) It receives the object, the command, and the possible
336 commands which could complete it. It should return an error
337 message; by default it is defined thusly:
338
339 sub msg_ambiguous_cmd {
340 my ($o, $cmd, @c) = @_;
341 local $" = "\n\t";
342 <<END;
343 Ambiguous command '$cmd': possible commands:
344 @c
345 END
346 }
347
349 Shell classes can use any of the methods in this list. Any other
350 methods in Term::Shell may change.
351
352 1. new()
353
354 Creates a new Term::Shell object. It currently does not use its
355 arguments. The arguments are saved in '$o->{API}{args}', in case
356 you want to use them later.
357
358 my $sh = Term::Shell->new(@arbitrary_args);
359
360 2. cmd()
361
362 cmd($txt);
363
364 Invokes $txt as if it had been typed in at the prompt.
365
366 $sh->cmd("echo 1 2 3");
367
368 3. cmdloop()
369
370 mainloop()
371
372 Repeatedly prompts the user, reads a line, parses it, and invokes a
373 handler. Uses "cmd()" internally.
374
375 MyShell->new->cmdloop;
376
377 mainloop() is a synonym for cmdloop(), provided for backwards
378 compatibility. Earlier (unreleased) versions of Term::Shell have
379 only provided mainloop(). All documentation and examples use
380 cmdloop() instead.
381
382 4. init()
383
384 fini()
385
386 Do any initialization or cleanup you need at shell creation
387 (init()) and destruction (fini()) by defining these methods.
388
389 No parameters are passed.
390
391 5. preloop()
392
393 postloop()
394
395 Do any initialization or cleanup you need at shell startup
396 (preloop()) and shutdown (postloop()) by defining these methods.
397
398 No parameters are passed.
399
400 6. precmd()
401
402 postcmd()
403
404 Do any initialization or cleanup before and after calling each
405 handler.
406
407 The parameters are:
408
409 1. $handler
410
411 A reference to the name of the handler that is about to be
412 executed.
413
414 Passed by reference so you can control which handler will be
415 called.
416
417 2. $cmd
418
419 A reference to the command as the user typed it.
420
421 Passed by reference so you can set the command. (If the handler
422 is a "catch_" command, it can be fooled into thinking the user
423 typed some other command, for example.)
424
425 3. $args
426
427 The arguments as typed by the user. This is passed as an array
428 reference so that you can manipulate the arguments received by
429 the handler.
430
431 sub precmd {
432 my $o = shift;
433 my ($handler, $cmd, @args) = @_;
434 # ...
435 }
436
437 7. stoploop()
438
439 Sets a flag in the Term::Shell object that breaks out of cmdloop().
440 Note that cmdloop() resets this flag each time you call it, so code
441 like this will work:
442
443 my $sh = MyShell->new;
444 $sh->cmdloop; # an interactive session
445 $sh->cmdloop; # prompts the user again
446
447 Term::Shell's built-in run_exit() command just calls stoploop().
448
449 8. idle()
450
451 If you set "check_idle" to a non-zero number (see "The Term::Shell
452 Object") then this method is called every "check_idle" seconds. The
453 idle() method defined in Term::Shell does nothing -- it exists only
454 to be redefined in subclasses.
455
456 package MyShell;
457 use base qw(Term::Shell);
458
459 sub init {
460 my $o = shift;
461 $o->{API}{check_idle} = 0.1; # 10/s
462 }
463
464 sub idle {
465 print "Idle!\n";
466 }
467
468 9. prompt_str()
469
470 Returns a string to be used as the prompt. prompt_str() is called
471 just before calling the readline() method of Term::ReadLine. If you
472 do not override this method, the string `shell> ' is used.
473
474 package MyShell;
475 use base qw(Term::Shell);
476
477 sub prompt_str { "search> " }
478
479 10. prompt()
480
481 Term::Shell provides this method for convenience. It's common for a
482 handler to ask the user for more information. This method makes it
483 easy to provide the user with a different prompt and custom
484 completions provided by you.
485
486 The prompt() method takes the following parameters:
487
488 1. $prompt
489
490 The prompt to display to the user. This can be any string you
491 want.
492
493 2. $default
494
495 The default value to provide. If the user enters a blank line
496 (all whitespace characters) then the this value will be
497 returned.
498
499 Note: unlike ExtUtils::MakeMaker's prompt(), Term::Shell's
500 prompt() does not modify $prompt to indicate the $default
501 response. You have to do that yourself.
502
503 3. $completions
504
505 An optional list of completion values. When the user hits
506 <TAB>, Term::Shell prints the completions which match what
507 they've typed so far. Term::Shell does not enforce that the
508 user's response is one of these values.
509
510 4. $casei
511
512 An optional boolean value which indicates whether the
513 completions should be matched case-insensitively or not. A true
514 value indicates that "FoO" and "foo" should be considered the
515 same.
516
517 prompt() returns the unparsed line to give you maximum flexibility.
518 If you need the line parsed, use the line_parsed() method on the
519 return value.
520
521 11. cmd_prefix()
522
523 cmd_suffix()
524
525 These methods should return a prefix and suffix for commands,
526 respectively. For instance, an IRC client will have a prefix of
527 "/". Most shells have an empty prefix and suffix.
528
529 12. page()
530
531 page($txt)
532
533 Prints $txt through a pager, prompting the user to press a key for
534 the next screen full of text.
535
536 13. line()
537
538 line_parsed()
539
540 Although "run_foo()" is called with the parsed arguments from the
541 command-line, you may wish to see the raw command-line. This is
542 available through the line() method. If you want to retrieve the
543 parsed line again, use line_parsed().
544
545 line_parsed() accepts an optional string parameter: the line to
546 parse. If you have your own line to parse, you can pass it to
547 line_parsed() and get back a list of arguments. This is useful
548 inside completion methods, since you don't get a parsed list there.
549
550 14. run()
551
552 If you want to run another handler from within a handler, and you
553 have pre-parsed arguments, use run() instead of cmd(). cmd() parses
554 its parameter, whereas run() takes each element as a separate
555 parameter.
556
557 It needs the name of the action to run and any arguments to pass to
558 the handler.
559
560 Term::Shell uses this method internally to invoke command handlers.
561
562 15. help()
563
564 If you want to get the raw text of a help message, use help(). It
565 needs the name of the help topic and any arguments to pass to the
566 handler.
567
568 Term::Shell uses this method internally to invoke help handlers.
569
570 16. summary()
571
572 If you want to get the summary text of an action, use summary(). It
573 needs the name of the action.
574
575 Term::Shell uses this method internally to display the help page.
576
577 17. possible_actions()
578
579 You will probably want this method in comp_foo().
580 possible_actions() takes a word and a list, and returns a list of
581 possible matches. Term::Shell uses this method internally to decide
582 which handler to run when the user enters a command.
583
584 There are several arguments, but you probably won't use them all in
585 the simple cases:
586
587 1. $needle
588
589 The (possible incomplete) word to try to match against the list
590 of actions (the haystack).
591
592 2. $type
593
594 The type with which to prefix $action. This is useful when
595 completing a real action -- you have to specify whether you
596 want it to look for "run_" or "help_" or something else. If you
597 leave it blank, it will use $action without prefixing it.
598
599 3. $strip
600
601 If you pass in a true value here, possible_actions() will
602 remove an initial $type from the beginning of each result
603 before returning the results. This is useful if you want to
604 know what the possible "run_" commands are, but you don't want
605 to have the "run_" in the final result.
606
607 If you do not specify this argument, it uses '0' (the default
608 is not to strip the results).
609
610 4. $haystack
611
612 You can pass in a reference to a list of strings here. Each
613 string will be compared with $needle.
614
615 If you do not specify this argument, it uses the list of
616 handlers. This is how Term::Shell matches commands typed in by
617 the user with command handlers written by you.
618
619 18. print_pairs()
620
621 This overloaded beast is used whenever Term::Shell wants to print a
622 set of keys and values. It handles wrapping long values, indenting
623 the whole thing, inserting the separator between the key and value,
624 and all the rest.
625
626 There are lots of parameters, but most of them are optional:
627
628 1. $keys
629
630 A reference to a list of keys to print.
631
632 2. $values
633
634 A reference to a list of values to print.
635
636 3. $sep
637
638 The string used to separate the keys and values. If omitted, ':
639 ' is used.
640
641 4. $left
642
643 The justification to be used to line up the keys. If true, the
644 keys will be left-justified. If false or omitted, the keys will
645 be right-justified.
646
647 5. $ind
648
649 A string used to indent the whole paragraph. Internally,
650 print_pairs() uses length(), so you shouldn't use tabs in the
651 indent string. If omitted, the empty string is used (no
652 indent).
653
654 6. $len
655
656 An integer which describes the minimum length of the keys.
657 Normally, print_pairs() calculates the longest key and assigns
658 the column width to be as wide as the longest key plus the
659 separator. You can force the column width to be larger using
660 $len. If omitted, 0 is used.
661
662 7. $wrap
663
664 A boolean which indicates whether the value should be text-
665 wrapped using Text::Autoformat. Text is only ever wrapped if it
666 contains at least one space. If omitted, 0 is used.
667
668 8. $cols
669
670 An integer describing the number of columns available on the
671 current terminal. Normally 78 is used, or the environment
672 variable COLUMNS, but you can override the number here to
673 simulate a right-indent.
674
675 19. term()
676
677 Returns the underlying "Term::ReadLine" object used to interact
678 with the user. You can do powerful things with this object; in
679 particular, you will cripple Term::Shell's completion scheme if you
680 change the completion callback function.
681
682 20. process_esc()
683
684 This method may be overridden to provide shell-like escaping of
685 backslashes inside quoted strings. It accepts two parameters:
686
687 1. $c
688
689 The character which was escaped by a backslash.
690
691 2. $quote
692
693 The quote character used to delimit this string. Either """ or
694 "'".
695
696 This method should return the string which should replace the
697 backslash and the escaped character.
698
699 By default, process_esc() uses escaping rules similar to Perl's
700 single-quoted string:
701
702 1. Escaped backslashes return backslashes. The string "123\\456"
703 returns "123\456".
704
705 2. Escaped quote characters return the quote character (to allow
706 quote characters in strings). The string "abc\"def" returns
707 "abc"def".
708
709 3. All other backslashes are returned verbatim. The string
710 "123\456" returns "123\456".
711
712 Term::Shell's quote characters cannot be overridden, unless you
713 override line_parsed(): they are """ or "'". This may change in a
714 future version of Term::Shell.
715
716 21. add_handlers()
717
718 See "Adding Commands to Your Shell" for information on
719 add_handlers().
720
721 22. remove_commands()
722
723 remove_handlers()
724
725 See "Removing Commands from Your Shell" for information on
726 remove_handlers().
727
729 Term::Shell creates a hash based Perl object. The object contains
730 information like what handlers it found, the underlying Term::ReadLine
731 object, and any arguments passed to the constructor.
732
733 This hash is broken into several subhashes. The only two subhashes that
734 a Shell should ever use are $o->{API} and $o->{SHELL}. The first one
735 contains all the information that Term::Shell has gathered for you. The
736 second one is a private area where your Shell can freely store data
737 that it might need later on.
738
739 This section will describe all the Term::Shell object "API" attributes:
740
741 The args Attribute
742 This an array reference containing any arguments passed to the
743 Term::Shell constructor.
744
745 The case_ignore Attribute
746 This boolean controls whether commands should be matched without regard
747 to case. If this is true, then typing "FoO" will have the same effect
748 as typing "foo".
749
750 Defaults to true on MSWin32, and false on other platforms.
751
752 The class Attribute
753 The class of the object. This is probably the package containing the
754 definition of your shell, but if someone subclasses your shell, it's
755 their class.
756
757 The command Attribute
758 Whenever Term::Shell invokes an action, it stores information about the
759 action in the "command" attribute. Information about the last "run"
760 action to be invoked is stored in $o->{API}{command}{run}. The
761 information itself is stored in a subhash containing these fields:
762
763 name
764 The name of the command, as typed by the user.
765
766 found
767 The a boolean value indicating whether a handler could be found.
768
769 handler
770 The full name of the handler, if found.
771
772 Note that this facility only stores information about the last action
773 to be executed. It's good enough for retrieving the information about
774 the last handler which ran, but not for much else.
775
776 The following example shows a case where "run_foo()" calls "run_add()",
777 and prints its return value (in this case, 42).
778
779 sub run_foo {
780 my $o = shift;
781 my $sum = $o->run("add", 21, 21);
782 print "21 + 21 = ", $sum, "\n";
783 }
784
785 sub run_add {
786 my $o = shift;
787 my $sum = 0;
788 $sum += $_ for @_;
789 print "add(): sum = $sum\n";
790 return $sum;
791 }
792
793 At the end of run_foo(), $o->{API}{command}{run}{handler} contains the
794 string "run_add".
795
796 The match_uniq Attribute
797 This boolean controls whether the user can type in only enough of the
798 command to make it unambiguous. If true, then if the shell has the
799 commands "foo" and "bar" defined, the user can type "f" to run "foo",
800 and "b" to run "bar".
801
802 Defaults to true.
803
804 The readline Attribute
805 Which Term::ReadLine module is being used. Currently, this is always
806 one of "Term::ReadLine::Stub", "Term::ReadLine::Perl", or
807 "Term::ReadLine::Gnu".
808
809 The script Attribute
810 The name of the script that invoked your shell.
811
812 The version Attribute
813 The version of Term::Shell you are running under.
814
816 For more information about the underlying ReadLine module, see
817 Term::ReadLine. You may also want to look at Term::ReadLine::Gnu and
818 Term::ReadLine::Perl.
819
820 For more information about the underlying formatter used by
821 print_pairs(), see Text::Autoformat.
822
823 The API for Term::Shell was inspired by (gasp!) a Python package called
824 "cmd". For more information about this package, please look in the
825 Python Library Reference, either in your Python distribution or at
826 <https://docs.python.org/3/library/cmd.html> .
827
829 Neil Watkiss (NEILW@cpan.org)
830
832 Copyright (c) 2001, Neil Watkiss. All Rights Reserved.
833
834 All Rights Reserved. This module is free software. It may be used,
835 redistributed and/or modified under the same terms as Perl itself.
836
837 See http://www.perl.com/perl/misc/Artistic.html
838
840 Websites
841 The following websites have more information about this module, and may
842 be of help to you. As always, in addition to those websites please use
843 your favorite search engine to discover more resources.
844
845 • MetaCPAN
846
847 A modern, open-source CPAN search engine, useful to view POD in
848 HTML format.
849
850 <https://metacpan.org/release/Term-Shell>
851
852 • RT: CPAN's Bug Tracker
853
854 The RT ( Request Tracker ) website is the default bug/issue
855 tracking system for CPAN.
856
857 <https://rt.cpan.org/Public/Dist/Display.html?Name=Term-Shell>
858
859 • CPANTS
860
861 The CPANTS is a website that analyzes the Kwalitee ( code metrics )
862 of a distribution.
863
864 <http://cpants.cpanauthors.org/dist/Term-Shell>
865
866 • CPAN Testers
867
868 The CPAN Testers is a network of smoke testers who run automated
869 tests on uploaded CPAN distributions.
870
871 <http://www.cpantesters.org/distro/T/Term-Shell>
872
873 • CPAN Testers Matrix
874
875 The CPAN Testers Matrix is a website that provides a visual
876 overview of the test results for a distribution on various
877 Perls/platforms.
878
879 <http://matrix.cpantesters.org/?dist=Term-Shell>
880
881 • CPAN Testers Dependencies
882
883 The CPAN Testers Dependencies is a website that shows a chart of
884 the test results of all dependencies for a distribution.
885
886 <http://deps.cpantesters.org/?module=Term::Shell>
887
888 Bugs / Feature Requests
889 Please report any bugs or feature requests by email to "bug-term-shell
890 at rt.cpan.org", or through the web interface at
891 <https://rt.cpan.org/Public/Bug/Report.html?Queue=Term-Shell>. You will
892 be automatically notified of any progress on the request by the system.
893
894 Source Code
895 The code is open to the world, and available for you to hack on. Please
896 feel free to browse it and play with it, or whatever. If you want to
897 contribute patches, please send me a diff or prod me to pull from your
898 repository :)
899
900 <https://github.com/shlomif/Term-Shell>
901
902 git clone git://git@github.com:shlomif/Term-Shell.git
903
905 Shlomi Fish <shlomif@cpan.org>
906
908 Please report any bugs or feature requests on the bugtracker website
909 <http://rt.cpan.org/NoAuth/Bugs.html?Dist=Term-Shell> or by email to
910 bug-term-shell@rt.cpan.org <mailto:bug-term-shell@rt.cpan.org>.
911
912 When submitting a bug or request, please include a test-file or a patch
913 to an existing test-file that illustrates the bug or desired feature.
914
916 This software is copyright (c) 2001 by Neil Watkiss.
917
918 This is free software; you can redistribute it and/or modify it under
919 the same terms as the Perl 5 programming language system itself.
920
921
922
923perl v5.34.0 2022-01-21 Term::Shell(3)