Free stdout redirect software for linux

Deadmans Redirect (DMR) is designed to replace whatever it is your browser loads when you click on the Home button in your browser.
DMR is a web-surfers power tool that can be completely customized to fit the needs of the user, without being tied to a specific instance of a browser.
DMR users can create/use aliases to their favorite search engines, drop in URLs for redirection, search through the history of all URLs/commands that have been entered into DMR, make small reminders/notes, and edit the powerful template system used by DMR.
DMR templates are called Views. Views use regular HTML with some DMR-specific keywords to define how DMR looks when your browser renders it.
The View system has support for RDF headlines from your favorite site(s), seperate listings of notes, aliases, views and history, and even a fortune (UNIX fortune must be installed.)
Main features:
- Shell-like history functions
- User defined automatic history exclusion
- Shell-like aliasing with arguments
- RDF/RSS headlines
- Completely customizable interface
- Example aliases act as a front-end to various search engines

Redirection Tool is a product for Plone used for storing references to moved content to enable redirects.
The Redirection Tool can be used for storing references to moved content to enable redirects, or it can be used for giving objects multiple URLs (aliases). If a page is not found, the tool looks at its list of redirects to see if there is a match, and if so, it redirects to that page.
Future plans include a more intelligent 404 handling, where the tool would either search for alternative pages based on the components of the requested URL and automatically redirect if there is only one hit, otherwise display a limited number of hits, or alternatively chop off URL components until it finds an object that can be published to the user.
Enhancements:
- Added Plone 2.1 compatibility.

MDF audio extracter project is a tool to extract audio data from MDF/MDS audio cd images to wav or raw files. Tracks will be extracted to the current directory and named track_[num].wav or track_[num].raw. Output can also be redirected to stdout to allow the audio data to be fed to an encoder or player directly.
You need both a .mds and .mdf file to be able to extract tracks. The .mds file contains the information about the tracks, while the .mdf file contains the actual data. They usually should have the same name (except for the extension ofcourse). This is case sensitive, so for example FileName is not the same as filename.
Usage: mdfextract [options] file.mds
Options:
-i output mds info instead of extracting
-r extract raw track data
-s output to stdout instead of file
-t < num > extract single track (num > 0)
-q quiet, no output
Version restrictions:
- Probably does not work on big endian archs.

acoc is a regular-expression based colour formatter for programs that display output on the command-line. It works as a wrapper around the target program, executing it and capturing the stdout stream. Optionally, stderr can be redirected to stdout, so that it, too, can be manipulated. acoc then applies matching rules to patterns in the output and applies colours to those matches.

Ever wondered why the output of your favourite UNIX/Linux commands is still displayed in black-and-white after all these years?

Ever had to search back through your scroll-buffer in search of gcc errors and salient information to tell you what went wrong with your programs execution?

acoc is a regular expression based colour formatter for programs that display output on the command-line. It works as a wrapper around the target program, executing it and capturing the stdout stream. Optionally, stderr can be redirected to stdout, so that it, too, can be manipulated.

acoc then applies matching rules to patterns in the output and applies colour sets to those matches. A picture is worth a thousand words, so look at the sample screenshots in the next section.

Configuration

The configuration files used by the program are /usr/local/etc/acoc.conf, /etc/acoc.conf and ~/acoc.conf. One or more of these must exist. A sample /etc/acoc.conf is supplied with some example matching rules.

Blank lines and those that begin with a # are ignored.

A program configuration stanza is introduced as follows:

[program_spec]

The square brackets are mandatory literal characters. Alternatively, the @ symbol may be used, to allow [ and ] to retain their usual semantics in program specs comprising a regular expression:

@program_spec@

program_spec is defined as one or more instances of the following component, separated by a comma:

invocation[/flags]

where invocation consists of the programs name (not including its directory path component) plus any initial arguments.

Alternatively, invocation may be a regular expression, which can be used to match multiple programs and/or command-line arguments in arbitrary order. Regular expressions are automatically anchored to the beginning of the command line.

flags, if present, is separated from invocation by a slash and consists of one or more of the following characters:

a
continue to attempt to find matching patterns after the first match has been found. By default, acoc will stop processing a line and display it after the first match has been found.
e
redirect the target programs stderr to stdout, allowing it, too, to be matched by rules
p
allocate a pseudo-terminal in which to run the target program

Some programs, such as ls(1), behave differently when their stdout is not connected to a tty. Use of this option will fool the target program into believing it is outputting to a tty, rather than a pipe to acoc.

Use of this flag requires Masahiro Tomitas Ruby/TPty library to be installed. Otherwise, the flag is silently ignored.

Note that the pseudo-terminal communication enabled by this flag is one-way only, from the target program to acoc. It is thus not possible to use acoc in combination with interactive programs, such as the interactive Ruby interpreter (irb).
t
apply colour formatting even if stdout is not a tty. By default, formatting is not applied if the output stream is not attached to a terminal.

Heres an example of a line that introduces a configuration stanza:

[rpm/ae,rpmbuild/ae]

which says to apply the following rules to the rpm and rpmbuild commands, attempt to apply all matching rules, and also apply those rules to the programs stderr stream.

Another example:

[ls/p]

This says to allocate a pseudo-terminal to ls(1), fooling it into believing that its output is being sent to a regular terminal instead of a pipe to acoc.

With this flag, the effect will be this:

$ ls
file1 file2 file3 file4 file5 file6

Without it, ls will detect that its stdout is connected to a pipe and behave accordingly:

$ ls
file1
file2
file3
file4
file5
file6

A third example:

[diff/t,rcsdiff/t,cvs diff/t,p4 diff/t]

This says that the rules that follow should be applied to all invocations of diff(1) and rcsdiff(1), as well as those invocations of cvs(1) and p4 that are followed by the argument diff.

Additionally, colouring should be applied even when stdout is not connected to a tty, so that the colours still show up when the output is displayed in a pager such as more(1) or less(1).

Yet another example:

/ps -.*(e.*f|f.*e)/

In this example, the ps(1) command will be matched, as long as the e and f options are both passed in either order.

An alternative way to write the above spec is:

@ps -.*[ef].*[ef]@

There are two things to note in this alternative:

1. @ has been used to delimit the spec, because [ and ] are required for the character lists in the regular expression.
2. While this form is less specific (in that it allows matches against duplicated command line options), it makes for considerably shorter specs if one wishes to test for the inclusion of a set of more than 2 or 3 command line flags. In the original form, one must manually list all of the possible permutations, which is equal to x! (factorial). For 3 command line flags, this is 6 permutations; for 4, it is 24, etc.

Heres one more example:

[tcpdump/r]

If this were placed in ~/.acoc.conf, it would remove any matching rules that had been installed for the diff command by either /etc/acoc.conf or /usr/local/etc/acoc.conf.

After defining the program name and operational flags, matching rules can be defined. These take the following form:

/regex/[flags] colour_spec

where regex is a Ruby-compatible regular expression. The delimiting / characters can be any character, as long as that character is not present in the regular expression itself. flags, if present, consists of one or more characters from the following list:

g
find every match on the line, not just the first. When using this flag, regex should not include parentheses.

colour_spec is defined as a comma-separated list of one or more colour_groups, which are defined as a plus-separated (+) list of one or more of the following:

* black
* blink
* blue
* bold
* clear
* concealed
* cyan
* dark
* green
* italic
* magenta
* negative
* on_black
* on_blue
* on_cyan
* on_green
* on_magenta
* on_red
* on_white
* on_yellow
* rapid_blink
* red
* reset
* strikethrough
* underline
* underscore
* white
* yellow

Examples of a colour_group are white+bold, black+on_white, etc. A complete colour_spec might look like this:

red+bold,white,yellow+bold,black+on_green

Except when using the g flag, each component of the regex that you wish to colour should be placed in parentheses. Text outside parentheses will be used for matching, but will not be coloured.

For example, examine the following:

/^(d+)foos*(w+)/

This will match a line that starts with more or one digits, followed by the string foo and any amount of white space, followed by one or more word characters. However, only the initial group of digits and the group of word characters will be coloured. The string foo and the white space that follows it will be used for matching, but will not be coloured.

Separated from the regex by white space is the colour_spec. Usually, you will include in this as many colours (separated by commas) as you have parenthesised expressions in the regex. However, its also permissible to have fewer. If, for example, you have three parenthesised expressions in the regex, but only two colours listed in the colour_spec, then the second colour will be used for colouring both the second and third matches.

If you have more colours listed in the colour_spec than there are parenthesised expressions in the regex, the surplus colours are ignored.

When using the g flag to perform a global match on the line, you may list as many colours as you want. The same rules apply here. If there are more matches than colours, the remaining matches will be coloured using the last colour listed. Surplus colours are ignored.

Net:IPMessenger::ToStdoutEventHandler is a Perl module for event handler for standard output.

SYNOPSIS

use Net::IPMessenger::ToStdoutEventHandler;

...

$ipmsg->add_event_handler( new Net::IPMessenger::ToStdoutEventHandler );

IP Messenger receive event handler for standard output.

METHODS

output

output($user->nickname . " joined.");

This actually converts encodings and output to STDOUT.

debug

Outputs debug receive message.

BR_ENTRY

Outputs "someone joined." message.

BR_EXIT

Outputs "someone left." message.

SENDMSG

Outputs "youve got message from someone." message.

ipsort script sorts a STDIN of IP addresses to STDOUT. It sorts by the first octet, then by the second, the third and the fourth.

Usage: Takes Standard in or a file or list of files. So ipsort < file1 > < file2 > or cat < file > | ipsort
Its quite clever and looks for an IP address on each line, rejecting if it doesnt find one

Options:

-c or --commas Separate the list by space-separated commas, rather than one IP per line.
-u or --unique Uniquely sort the list as well, to avoid duplicate IPs.
-s or --string Use this string to separate the IPs. Eg. -s :
-m or --multiple Search for multiple IP addresses per line.
-h or --help Display this usage message.

Apache::TestUtil Perl module contains utility functions for writing tests.

SYNOPSIS

use Apache::Test;
use Apache::TestUtil;

ok t_cmp("foo", "foo", "sanity check");
t_write_file("filename", @content);
my $fh = t_open_file($filename);
t_mkdir("/foo/bar");
t_rmtree("/foo/bar");
t_is_equal($a, $b);

Apache::TestUtil automatically exports a number of functions useful in writing tests.

All the files and directories created using the functions from this package will be automatically destroyed at the end of the program execution (via END block). You should not use these functions other than from within tests which should cleanup all the created directories and files at the end of the test.

FUNCTIONS

t_cmp()
t_cmp($received, $expected, $comment);
t_cmp() prints the values of $comment, $expected and $received. e.g.:
t_cmp(1, 1, "1 == 1?");
prints:
# testing : 1 == 1?
# expected: 1
# received: 1

then it returns the result of comparison of the $expected and the $received variables. Usually, the return value of this function is fed directly to the ok() function, like this:

ok t_cmp(1, 1, "1 == 1?");

the third argument ($comment) is optional, mostly useful for telling what the comparison is trying to do.

It is valid to use undef as an expected value. Therefore:

my $foo;
t_cmp(undef, $foo, "undef == undef?");

will return a true value.

You can compare any two data-structures with t_cmp(). Just make sure that if you pass non-scalars, you have to pass their references. The datastructures can be deeply nested. For example you can compare:

t_cmp({1 => [2..3,{5..8}], 4 => [5..6]},
{1 => [2..3,{5..8}], 4 => [5..6]},
"hash of array of hashes");

You can also compare the second argument against the first as a regex. Use the qr// function in the second argument. For example:

t_cmp("abcd", qr/^abc/, "regex compare");
will do:
"abcd" =~ /^abc/;

This function is exported by default.

t_filepath_cmp()

This function is used to compare two filepaths via t_cmp(). For non-Win32, it simply uses t_cmp() for the comparison, but for Win32, Win32::GetLongPathName() is invoked to convert the first two arguments to their DOS long pathname. This is useful when there is a possibility the two paths being compared are not both represented by their long or short pathname.

This function is exported by default.

t_debug()
t_debug("testing feature foo");
t_debug("test", [1..3], 5, {a=>[1..5]});

t_debug() prints out any datastructure while prepending # at the beginning of each line, to make the debug printouts comply with Test::Harnesss requirements. This function should be always used for debug prints, since if in the future the debug printing will change (e.g. redirected into a file) your tests wont need to be changed.

the special global variable $Apache::TestUtil::DEBUG_OUTPUT can be used to redirect the output from t_debug() and related calls such as t_write_file(). for example, from a server-side test you would probably need to redirect it to STDERR:

sub handler {
plan $r, tests => 1;

local $Apache::TestUtil::DEBUG_OUTPUT = *STDERR;

t_write_file(/tmp/foo, bar);
...
}

left to its own devices, t_debug() will collide with the standard HTTP protocol during server-side tests, resulting in a situation both confusing difficult to debug. but STDOUT is left as the default, since you probably dont want debug output under normal circumstances unless running under verbose mode.

This function is exported by default.

t_write_file()
t_write_file($filename, @lines);

t_write_file() creates a new file at $filename or overwrites the existing file with the content passed in @lines. If only the $filename is passed, an empty file will be created.

If parent directories of $filename dont exist they will be automagically created.

The generated file will be automatically deleted at the end of the programs execution.

This function is exported by default.

t_append_file()
t_append_file($filename, @lines);

t_append_file() is similar to t_write_file(), but it doesnt clobber existing files and appends @lines to the end of the file. If the file doesnt exist it will create it.

If parent directories of $filename dont exist they will be automagically created.

The generated file will be registered to be automatically deleted at the end of the programs execution, only if the file was created by t_append_file().

This function is exported by default.

t_write_shell_script()
Apache::TestUtil::t_write_shell_script($filename, @lines);

Similar to t_write_file() but creates a portable shell/batch script. The created filename is constructed from $filename and an appropriate extension automatically selected according to the platform the code is running under.

It returns the extension of the created file.

t_write_perl_script()
Apache::TestUtil::t_write_perl_script($filename, @lines);

Similar to t_write_file() but creates a executable Perl script with correctly set shebang line.

t_open_file()
my $fh = t_open_file($filename);

t_open_file() opens a file $filename for writing and returns the file handle to the opened file.

If parent directories of $filename dont exist they will be automagically created.

The generated file will be automatically deleted at the end of the programs execution.

This function is exported by default.

t_mkdir()
t_mkdir($dirname);

t_mkdir() creates a directory $dirname. The operation will fail if the parent directory doesnt exist.

If parent directories of $dirname dont exist they will be automagically created.

The generated directory will be automatically deleted at the end of the programs execution.

This function is exported by default.

t_rmtree()
t_rmtree(@dirs);
t_rmtree() deletes the whole directories trees passed in @dirs.

This function is exported by default.

t_chown()
Apache::TestUtil::t_chown($file);

Change ownership of $file to the tests User/Group. This function is noop on platforms where chown(2) is unsupported (e.g. Win32).

t_is_equal()
t_is_equal($a, $b);

t_is_equal() compares any two datastructures and returns 1 if they are exactly the same, otherwise 0. The datastructures can be nested hashes, arrays, scalars, undefs or a combination of any of these. See t_cmp() for an example.

If $b is a regex reference, the regex comparison $a =~ $b is performed. For example:

t_is_equal($server_version, qr{^Apache});

If comparing non-scalars make sure to pass the references to the datastructures.

This function is exported by default.

t_server_log_error_is_expected()

If the handlers execution results in an error or a warning logged to the error_log file which is expected, its a good idea to have a disclaimer printed before the error itself, so one can tell real problems with tests from expected errors. For example when testing how the package behaves under error conditions the error_log file might be loaded with errors, most of which are expected.

For example if a handler is about to generate a run-time error, this function can be used as:

use Apache::TestUtil;
...
sub handler {
my $r = shift;
...
t_server_log_error_is_expected();
die "failed because ...";
}

After running this handler the error_log file will include:

*** The following error entry is expected and harmless ***
[Tue Apr 01 14:00:21 2003] [error] failed because ...

When more than one entry is expected, an optional numerical argument, indicating how many entries to expect, can be passed. For example:

t_server_log_error_is_expected(2);

will generate:

*** The following 2 error entries are expected and harmless ***

If the error is generated at compile time, the logging must be done in the BEGIN block at the very beginning of the file:

BEGIN {
use Apache::TestUtil;
t_server_log_error_is_expected();
}
use DOES_NOT_exist;

After attempting to run this handler the error_log file will include:

*** The following error entry is expected and harmless ***
[Tue Apr 01 14:04:49 2003] [error] Cant locate "DOES_NOT_exist.pm"
in @INC (@INC contains: ...

Also see t_server_log_warn_is_expected() which is similar but used for warnings.

This function is exported by default.

t_server_log_warn_is_expected()
t_server_log_warn_is_expected() generates a disclaimer for expected warnings.

See the explanation for t_server_log_error_is_expected() for more details.

This function is exported by default.

t_client_log_error_is_expected()
t_client_log_error_is_expected() generates a disclaimer for expected errors. But in contrast to t_server_log_error_is_expected() called by the client side of the script.

See the explanation for t_server_log_error_is_expected() for more details.

For example the following client script fails to find the handler:

use Apache::Test;
use Apache::TestUtil;
use Apache::TestRequest qw(GET);

plan tests => 1;

t_client_log_error_is_expected();
my $url = "/error_document/cannot_be_found";
my $res = GET($url);
ok t_cmp(404, $res->code, "test 404");

After running this test the error_log file will include an entry similar to the following snippet:

*** The following error entry is expected and harmless ***
[Tue Apr 01 14:02:55 2003] [error] [client 127.0.0.1]
File does not exist: /tmp/test/t/htdocs/error

When more than one entry is expected, an optional numerical argument, indicating how many entries to expect, can be passed. For example:

t_client_log_error_is_expected(2);

will generate:

*** The following 2 error entries are expected and harmless ***

This function is exported by default.

t_client_log_warn_is_expected()
t_client_log_warn_is_expected() generates a disclaimer for expected warnings on the client side.

See the explanation for t_client_log_error_is_expected() for more details.

This function is exported by default.

t_catfile(a, b, c)

This function is essentially File::Spec->catfile, but on Win32 will use Win32::GetLongpathName() to convert the result to a long path name (if the result is an absolute file). The function is not exported by default.

t_catfile_apache(a, b, c)

This function is essentially File::Spec::Unix->catfile, but on Win32 will use Win32::GetLongpathName() to convert the result to a long path name (if the result is an absolute file). It is useful when comparing something to that returned by Apache, which uses a Unix-style specification with forward slashes for directory separators. The function is not exported by default.

t_start_error_log_watch(), t_finish_error_log_watch()

This pair of functions provides an easy interface for checking the presence or absense of any particular message or messages in the httpd error_log that were generated by the httpd daemon as part of a test suite. It is likely, that you should proceed this with a call to one of the t_*_is_expected() functions.

t_start_error_log_watch();
do_it;
ok grep {...} t_finish_error_log_watch()