Free redirect stdout software for linux

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.

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

Egg::Plugin::Redirect::Body is a Perl module created to output of redirect screen etc.

SYNOPSIS

use Egg qw/ Redirect::Body /;

__PACKAGE__->egg_startup(

plugin_redirect => {
default_url => /,
default_wait => 0,
default_msg => Processing was completed.,
style => {
body => ..... ,
h1 => ..... ,
div => ..... ,
},
},

);

# redirect screen is output and processing is ended.
$e->redirect_body(/hoge_page, complete ok., alert => 1 );

# The HTML source of redirect screen is acquired.
my $html= $e->redirect_body_source(/hoge_page, complete ok., alert => 1 );

RIR to DNS converter is a tool to convert Regional Internet Registry data to a DNS country lookup zone. You can use it to build your own DNS zone for looking up country codes from IP addresses.

It uses data directly from RIPE, ARIN, APNIC, LACNIC, and AFRINIC. The data can be updated on a schedule of your choosing.

The input data comes from:

ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest
ftp://ftp.apnic.net/pub/stats/apnic/delegated-apnic-latest
ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest
ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest
ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest

The input data format is described in:

http://www.apnic.net/db/rir-stats-format.html

The output is a BIND 9 zone file that can be used to look up country codes
in a similar fashion to in-addr.arpa. For example, to find out what country
203.30.47.58 is:

host 58.47.30.203.rir.example.com
58.47.30.203.rir.example.com has address 127.0.65.86

where 65 and 85 are ASCII for A and U, which means 203.30.47.58 is
in Australia (AU).

HOW TO USE IT

Just feed it the above delegated- -latest files into stdin and it will
spit out the zone file to stdout. The zone file will only have the IP addresses,
so you could $INCLUDE it into a zone file that contains NS records, SOA, $ORIGIN,
etc.

WHY USE IT

You dont need the resolution of MaxMinds GeoIP database, but you do want
something that is free and you want it kept up to date on a schedule that
you decide.

You could use this to block or tag email based on countries, block or redirect
visitors to your website based on end-user country, and so on. Be very
careful about blocking mail this way, though, as you may block legitimate
email. Instead of blocking outright, use it in a SpamAssassin rule to add
something to the spam level, based on where the email comes from.

HOW IT WORKS

The RIR files contain ranges of IP addresses, and indicate what CC each range is allocated to. At the simplest level, rir2dns just sorts the ranges then iterates
through the IPs in each range and generates a reverse-dns-style A record that
represents the country code.

HOW IT WORKS - IN DETAIL

Rather than iterate through each IP address, the program tries to skip through
entire classes at a time (256 IPs, 65536 IPs, etc). Rather than iterate
through each IP, the loop iterates through classes or IP ranges (whichever are
smaller at the loop control), using control-breaks to accummulate neighbouring
ranges where possible so that entire classes that are in the same country dont
generate huge numbers of records.

Firstly, IPs are considered to be 4-digit numbers, but in base-256. In other
words, each octet is dealt with as if it were a single base-256 digit. This
turns out to be convenient because optimisations of large chunks of IP space can be done by looking for places where least-significant base-256 digits are zero.

Next, IP ranges are broken down into the following sub-ranges:

Optional individual IP addresses (ie: 4 octets)
Optional A-class ranges (ie: 3 octets)
Optional B-class ranges (ie: 2 octets)
Optional C-class ranges (ie: 1 octet)
Optional B-class ranges (ie: 2 octets)
Optional A-class ranges (ie: 3 octets)
Optional individual IP addresses (ie: 4 octets)

Considering that there is a pattern here, Im sure theres an elegant way to
handle breaking this down into two loops (one reducing the octets and one
increasing the octets), but I cant be bothered, so Ill break it down into
seven loops. Kind of hard-coded, but at least its simple.

For ease of processing, the IP addresses are actually converted to 32-bit numbers, then back again. This simplifies mathematics and looping through ranges.

Thats pretty much it, really...

Note that currently there are about 80,000 RIR records between all five
registries. This takes about 35 seconds on a 2.4GHz P4 to process, and
generates a 26MB file with around 3/4 million lines (RRs). This causes BIND
to use about 100MB or so of memory, and on a slow machine will probably cause it to take too long to reply, while it searches the zone. That size zone can
take a minute or two to load, which is quite a while.

Basic algorithm:

Read & process RIR data:

Read RIR ranges
Sort RIR ranges by start IP address
Glue together contiguous ranges of the same country

For each range

Generate the IPs at the start of the range

Generate the A-classes at the start of the range

Generate the B-classes at the start of the range

Generate the C-classes in the middle of the range

Generate the B-classes at the end of the range

Generate the A-classes at the end of the range

Generate the IPs at the end of the range

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()

RCUNIT is a robust C unit testing framework. Requiring only an ANSI compliant C compiler, It is a highly portable testing tool.
Main features:
- Uniform interfaces for managing test cases
- Optional setup and tear down functions for each test case (test function) to isolate a particular test.
- Optional setup and tear down functions for each test suite (test module).
- Multiple test registries and test suites for structuring test cases. Also provides a default test suite and default test registry.
- Output redirection mechanism to redirect log and test run report when a file I/O facility is not available in the test platform.
- Log handler mechanism for redirecting logs.
- Allows optional test run callback function (test run hook).
- Alternative mechanism to ANSI Cs assert() function (non-test run assertions). Also allows assertion callback function (assertion hook)
- A runtime memory leak check facility
- An extensible exception handling mechanism
Enhancements:
- This is is the pre-release version of 1.0.
- There were no major changes from version 0.1, and it is fairly stable.

wsgi_intercept 0.4 is yet another excellent utility for programmers. It is actually a library which lets you intercept calls to any specific host/port combination and redirect them into a WSGI application importable by your test program instead of normally starting a server at a local host and port, then pointing your test code to that address. Thus, you can avoid spawning multiple processes or threads to test your Web app. Installs a WSGI application in place of a real URI for testing.

This package works by replacing httplib. HTTPConnection with a subclass, wsgi_intercept. WSGI_HTTPConnection. This class then redirects specific server/port combination into a WSGI application by emulating a socket. If no intercept is registered for the host and port requested, those requests are passed on to the standard handler.

The functions add_wsgi_intercept (host, port, app_create_fn, script_name=) and remove_wsgi_intercept (host, port) specify which URLs should be redirect into what applications. Note especially that app_create_fn is a function object returning a WSGI application; script_name becomes SCRIPT_NAME in the WSGI apps environment, if it is set.

Requirements:

• Python

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.