Standard way for displaying a script's output.

[tobyink]

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>

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;
}

But you can use whatever you like.

[BrowserUk]

How about we mandate a standard template for a PM submissions(¹). 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

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

[Anonymous Monk]

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 ...

[BrowserUk]

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 ...

[Xiong]

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";

Output:

XYZ XYZ XYZ XYZ XYZ XYZ xyz foo ATGC atgc JAPHATGC XYZ XYZXYZXYZ

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

[JavaFan]

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?

[tobyink]

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.

[Xiong]

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" };

[JavaFan]

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__.