Free kn filters software for linux

IOLib-Filters is a filter package for IOLib. IOLib-Filters is mainly an example of how to write filters for IOLib.

IOLib is a portable universal data IO library. Implementations exist in C, C++ and Objective C and for many different platforms (including Linux, Win32, MacOS X and .NET).

IOLib provides a unified interface for accessing different types of data streams. It currently supports file IO, BSD sockets, memory buffers and SOCKS4/5 connections and can be extended with drivers easily.

It has support for different binary formats (Intel, Motorola, PDP) and it supports filters. You can write your own filters (e.g. for encryption or compression) and use them with IOLib.

Doxygen Filter project is an input filter for Doxygen enabling support for Perl code documentation.
Of course, Perl developers are used to use POD rather than some other code documentation tools.
However, most developers actually are not restricted to using one single language. Instead of using multiple code documentation systems one tends to use one tool for all - Doxygen is quite a powerful code documentation system that already has built-in support for multiple programming languages.
Unfortunately, Doxygen does not directly support Perl. Thus, Doxygen Filter has been written in order to be able to use Doxygen for generating code documentation for Perl projects, too.
Enhancements:
- This release makes huge efforts for automatically extracting namespace/class/method/function information and function argument lists of not explicitly documented entities.
- Non-Perl files are now passed as is to doxygen, or are run through appropriate filters like js2doxy or pas2dox.
- The release includes a Windows executable.

squid-filter project was designed to build filtering capabilities comparable to those of Muffin into Squid. It consists of
a patch to Squid, containing a module loader and filtering hooks, and a set of filter modules.
Currently available filters:
- Redirection of URIs.
- Rejection of certain (configurable) MIME content types.
- Suppression of cookies.
- Removal of Javascript and ActiveX.
- Breaking of GIF animation loops.
- Detection of 1x1 images.
Main features:
- Modular, easily extensible by writing new filters.
- Flexible configuration. Filters are independent from each other.
- Each filter can take a list of URIs which should not be filtered (allow list). URIs are specified as full regular expressions.
- Client can choose to bypass filters case-by-case.
- Filtering keeps Content-Length where possible.
Purpose
A filtering proxy allows users to remove unwanted stuff from Web pages as they browse them. What "unwanted stuff" is obviously depends on the individual user, but things which are commonly regarded as annoyances include
banner ads, user behaviour tracking via cookies,
animated pictures, JavaScript, VBScript, ActiveX (dangerous as well as annoying).
Some of those things can be avoided by filtering URIs, which Squid can already do via an external redirect program. Others require a content filter.
Usually, a filtering proxy runs standalone and does nothing but filtering. Users have to configure this proxy in their browsers, and if they use a caching proxy too, chain them after the filter. In situations where the user runs Squid anyway (mostly because of caching for different browsers or a small LAN), it is convenient to build this capability into Squid.

mod_filter allows you to filter output from other modules inside of Apache. This allows you to implement filters (think Swedish Chef, jive, etc.).

You can also use it to retailer output for your locale. This works with HTML documents, mod_perl, PHP, JServ, CGIs, and for that matter just about any sort of custom handler you might have.

IM-Filter is a daemon for GNU/Linux firewall hosts written in C which is able to analyze and filter the ICQ protocol. The daemon runs in userspace and fetches packets of the ICQ protocol by using the libnetfilter_queue mechanism.
IM-Filters main purpose is to run at a gateway, so all ICQ-related traffic of users in the LAN runs over IM-Filter. Nevertheless the daemon could also be used directly on end users computers. The following diagram shows, how the daemon is integrated in a GNU/Linux system.
One of the design goals of IM-Filter was modularity. So plugins for other protocols like MSN or IRC could be written easily. The source code already contains skeleton code for an IRC module.
Together with the source code, adequate iptables scripts are provided so that only packets which belong to ICQ traffic get in the netfilter queue of IM-Filter.
Main features:
Logging of messages sent via ICQ
IM-Filter is able to identify and log messages which have been sent via the ICQ protocol. These messages contain a timestamp, an IP-address, the appropriate UIN and - of course - the message itself. A logged message could look like this:
[2007-07-27 11:24:21] IP "10.0.0.1" sent following message to #123456789: "hello, this is a test"
Blacklists for messages and UINs
IM-Filter handles two different blacklists: for messages and for UINs. The message blacklist holds strings which must not occur in text messages. When such a string is detected in a message, it gets censored in the logfiles.
The UIN blacklist contains UINs of users which are not allowed to connect to the ICQ network. Those blacklists can be re-read by the daemon during runtime by sending signals.
Detection and blocking of file transfers
Since file transfers are not always welcome, they can be blocked by invoking the daemon with a specific command line argument. Then, users in the LAN can not send files to other users anymore. Beside blocking, the daemon logs file transfers. Such a log entry can look like this:
[2007-07-06 17:01:26] FILTRANSFER detected (outgoing): receiver uin: #123456789 || filename: test.txt || size: 143360B
List with currently logged in users
To be able to know which users are currently logged in, IM-Filter manages a text file which holds all necessary information. By default, the file is placed in /var/log/imfilter.users and contains IP-address and UIN of the users which are currently logged in. The file could look like this:
UIN=123456789, IP=10.0.0.1
UIN=234567890, IP=10.0.0.22
UIN=345678901, IP=10.0.0.4

File::FilterFuncs is a Perl module that specify filter functions for files.

SYNOPSIS

use File::FilterFuncs qw(filters);

filters(source.txt,
sub { $_ = uc $_; 1 },
dest.txt
);

INTRODUCTION

File::FilterFuncs makes it easy to perform transformations on files. When you use this module, you specify a group of filter functions that perform transformations on the lines in a source file. Those transformed lines are written to the destination file that you specify. For example, this code converts an entire file to upper-case, line-by-line:
use File::FilterFuncs qw(filters);

filters(source.txt,
sub { $_ = uc $_; 1 },
dest.txt
);

The "1" at the end of the filter subroutine tells filters to keep all the lines. The filter subroutine should return 1 for any lines that should be kept, and it should return 0 for any lines that should be ignored. This program copies only lines that contain something besides just whitespace:

use File::FilterFuncs qw(filters);

filters(source.txt,
sub { /S/ },
dest.txt
);

The entire source file is not read into memory. Instead it is read one line at a time, and the destination file is written one line at a time.

Just as Perls concept of a line can be changed by setting $/, so the filters functions idea of a line can also be changed by specifying a value for $/ in the call to filters:

my $pad = " " x 2;
filters(source.dat,
$/ => 1022,
sub { $_ .= $pad; 1 },
dest.dat
);

Filter functions are invoked in the order in which they are seen. This code upper-cases then puts inside parenthses every line in source.txt and copies the output to dest.txt:

filters (source.txt,
sub { $_ = uc $_; 1 },
sub { chomp $_; $_ = "($_)n"; 1 },
dest.txt
);

Obviously, the current line that is being worked on is in $_.

The filters subroutine expects its first argument to be the name of the source file, and the last argument should be the name of the destination file. The function filters will die if either one of the file names is missing or if they are inaccessible.

OPTIONS

A few options determine how the filters subroutine works.

binmode

Binmode lets you specify a layer to be used for the input data. For example, this will read a utf-8 file and write the data using the default output layer:

filters (
source.txt,
binmode => :utf8,
dest.txt,
);

boutmode

Boutmode lets the programmer specify a layer to be used for writing the output data. For example, this code on a Linux platform should read text data using the Linux end-of-line format and write it using the DOS (CRLF) end-of-line format:

filters (
source.txt,
boutmode => :crlf,
dest.txt,
);
$/

Setting $/ lets you determine how an end-of-line is recognized. Set this option to the same value that you would set the $/ variable to in a program. For example, suppose a file contains this:

ABCDEFGHIJKL

The following program should write three letters at a time to the output file:
filters (

source.txt,
$/ => 3,
sub { $_ = "$_n"; 1 },
dest.txt,
);

NOTES

Alternate function name

If you consider the function name filters to be too generic, you can import the name filter_funcs instead.

Convenience return values

For the programmers convenience and to facilitate self-documenting code, the values $KEEP_LINE and $IGNORE_LINE can be exported. As an example, this is another program to filter out lines containing only whitespace:

use File::FilterFuncs qw(filters $IGNORE_LINE);

filters(source.txt,
sub { return $IGNORE_LINE unless /S/ },
dest.txt
);