A couple of hours ago the venerable hermit Xiong was opining in the monastery courtyard on the lack of a standard way of posting the output of a script on the monastery notice boards.

Some fellow monks (myself included at times) have used the <code> tags to do this, but in cases of notices containing both code and output, this leads to a lack of visual distinction between the two. Some monks may have customised their display settings for code (adding line numbers and so forth) in a manner inappropriate for displaying script output.

An ideal solution would be for the monastery to adopt HTML's <samp> element which is designed for this very purpose: marking up sample output. It could perhaps be implemented in a manner similar to <code>, so that its contents are automatically escaped, whitespace preserved, etc.

In the mean time I have taken to including output samples like this:

<code>
use Modern::Perl;
say "Hello world!";
</code>
<pre class="output">
Hello world!
</pre>

[download]

On 450961 you can add some custom CSS to display <pre class="output"> nicely. Right now I'm using:

pre.output {
  color: #006;
  background:#ddf url(http://buzzword.org.uk/2012/output) no-repeat sc
+roll top right;
  padding:0.33em;
  border:1px solid;
  font-size:90%;
  line-height:1.05;
}
pre.output em {
  font-style: italic;
  color: black;
}
pre.output strong {
  font-weight: bolder;
  color: black;
}

[download]

But you can use whatever you like.

Replies are listed 'Best First'.
Re: Standard way for displaying a script's output.
by BrowserUk (Patriarch) on Feb 11, 2012 at 09:58 UTC

    How about we mandate a standard template for a PM submissions(1). This has the advantage that it automatically captures the output for you:

    #! perl -sw
use strict;
use Inline::Files;

select OUTPUT;

print while <INPUT1>;

print while <INPUT2>;

__DATA__
__INPUT1__
1
2
3
4
5
__INPUT2__
A
B
C
D
E
__OUTPUT__
1
2
3
4
5
A
B
C
D
E

    [download]

    <smaller>(1)JK! </smaller>

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    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.

    The start of some sanity?
[reply]
[d/l]

      I'd much prefer to avoid Inline::Files , but no reason the user can't choose what kind of NEW QUESTION to ask

      Do you have code, sample input, expected output? Ask your question with NEW QUESTION VROOM template 

      <p> I'm trying to merge and edit two files with this program (short ex
+ample  files in %data )
<code>
#!/usr/bin/perl -s --
use strict; use warnings; use autodie;

Main( @ARGV );
exit( 0 );

sub Main {
    if( $help ){
        return print Usage();
    }
    open my($in1) , '<', \$data{input1};
    open my($in2) , '<', \$data{input1};
    while( not( grep eof, $in1, $in2 ) ){
        my $line1 = <$in1>;
        my $line2 = <$in1>;
        chomp $line1;
        print $line1, $line2;
    }
    close $in1;
    close $in2;
}

sub Usage {
    <<"__USAGE__";

$0    
$0    -help
$0    -foo
$0    -oof=bar
$0    -oof=bar    baz


__USAGE__
} ## end sub Usage

BEGIN {
    our %data = (
        input1 => \<<'__VROOM',
__VROOM

        input2 => \<<'__VROOM',
__VROOM

        expectedOutput => \<<'__VROOM',
__VROOM

    );
} ## end BEGIN

__END__
</code>

<p> I want the get output $data{expectedOutput} but it gives me  this 
+error message / faulty output:</p>
<code>
error message or faulty output here
</code>
<p> I'm trying to ...
<p> I also tried ...

      [download]
[reply]
[d/l]

        Geez! Talk about overkill.

        First, look at the last line of my post.

        Second, are you really suggesting that every sample posted to ask a question here has to include a Usage section? Why not require formal test suite; and a perltidy formatting; and PBB compliance enforced by a documented, full perlcritic clean pass. Not forgetting a full GPL3 notice, liability waver. And a git repository link...

        If we raise the bar high enough ...

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        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.

        The start of some sanity?
[reply]
Re: Standard way for displaying a script's output.
by Xiong (Hermit) on Feb 10, 2012 at 23:18 UTC

    This looks fine to my eyes; the only objection is the annoying amount of markup required: 

    # Write results to output file.
open my $out_fh, '>', $out_filename
    or die "Couldn't open $out_filename for writing";
say {$out_fh} $indata;
close $out_fh 
    or die "Couldn't close $out_filename";

    [download]
    Output:
    XYZ XYZ XYZ XYZ XYZ 
XYZ xyz foo ATGC atgc JAPHATGC
XYZ 
XYZXYZXYZ

    [download]

    Note that my Display Settings are as shown in Line Numbering in Code Listings.

    I'm not the guy you kill, I'm the guy you buy. —Michael Clayton
[reply]
[d/l]
[select]
Re: Standard way for displaying a script's output.
by JavaFan (Canon) on Feb 10, 2012 at 21:05 UTC
    I just separate code from output with a __END__ token. I don't see much added value in using different colours or fonts. We aren't writing vegetables in green, verbs in boldface either, do we?
[reply]
[d/l]

      A problem with that is that __DATA__ sections are often used to supply sample input for the script, and those can't really be combined in the same file.

[reply]
[d/l]

      Except that it's legitimate to store data after any __DATA__; even after __END__ in main. 

      use strict;
use warnings;
use SelfLoader;
sub daily { sleep int rand };   # work work work
print plimsoll() if shift; 
daily;
__END__
sub plimsoll { "http://en.wikipedia.org/wiki/Samuel_Plimsoll\n" };

      [download]
      I'm not the guy you kill, I'm the guy you buy. —Michael Clayton
[reply]
[d/l]
[select]
        Except that it's legitimate to store data after any __DATA__; even after __END__ in main.
        So what? Don't forget the audience isn't brainless computers, but humans. I believe that most readers of Perlmonks are smarter than the average houseplant, and don't have trouble spotting the difference between a program that tries to be Miss Smartypants by reading data after an __END__ token, and a program that has its output after an __END__.
[reply]

Back to Perl Monks Discussion