|
Re: PIPE less
by choroba (Cardinal) on Apr 16, 2010 at 09:19 UTC
|
| [reply] |
Re: PIPE less
by cdarke (Prior) on Apr 16, 2010 at 10:14 UTC
|
With the minimum of changes to existing code:
open (my $less, "|less") or die "No less: $!\n";
my $OldHandle = select $less;
print "help text\n"; # will go to less
close ($less); # Don't forget this!
select $OldHandle;
| [reply]
[d/l] |
Re: PIPE less
by jethro (Monsignor) on Apr 16, 2010 at 09:37 UTC
|
open($f,'|-','less') or die "Error: Could not help";
print $f "hi";
close $f;
More information about this you can find with "perldoc -f open"
| [reply]
[d/l] |
Re: PIPE less
by ungalnanban (Pilgrim) on Apr 16, 2010 at 10:15 UTC
|
using system function we can achieve this.
See the following example code.
use strict;
use warnings;
use Getopt::Std;
.
.
.
my %option=();
getopts("hwmyc:",\%option);
.
.
.
if(defined $option{h})
{
system("less help_file");
#system("cat help_file | less");
#system("echo "this is help file"|less");
}
.
.
.
| [reply]
[d/l] |
Re: PIPE less
by BrowserUk (Patriarch) on Apr 16, 2010 at 16:36 UTC
|
My take on this is that if your "usage" info is more than fits on a single screen, then it is too much and should be documented separately.
Usage text should be an on-screen prompt of the syntax of the command that the user can put on the screen to remind him while he is typing the command.
If the text scrolls off the top of his screen, he can't do that. In which case he's better off loading the help info--man; info; html; whatever--in a separate screen from where he is typing the command, so that he can refer between them.
My real bottom line is that if the command syntax is so complicated that it cannot be outlined in less than one screenful of text, it would be much better to allow the user to supply the command parameters and switches through a file. Eg:
command -p job.parms
And perhaps supply a separate interactive utility or gui to construct those parameters files.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
Re: PIPE less
by ambrus (Abbot) on Apr 16, 2010 at 16:52 UTC
|
Also, for customizability, I recommend running "${PAGER-pager} || less" instead of just plain "less".
| [reply]
[d/l]
[select] |
Re: PIPE less
by Crackers2 (Parson) on Apr 16, 2010 at 14:14 UTC
|
I'd say don't do this.
If your user wants to view the help in less, it's easy enough for them to pipe your script to less themselves. With an implicit less you also make it harder to just dump out the whole help.
| [reply] |
|
|
My less (version 436 by Mark Nudelman) doesn't page unless its STDOUT is connected to a terminal
| [reply] |
|
|
For the reason outlined by BrowserUK below, I often like to just dump the help to stdout so I can use (in most terminals) Shift-PgUp and Shift-PgDown to look through it while actually typing the command.
Of course that's still possible either way. Doing something like "program --help | cat" could probably trick less into thinking it's not connected to a terminal.
| [reply] |
|
|
Which leads back to my answer, Re: PIPE less, giving the user more options (usually usage, help and man).
| [reply] |
