Free command and conquer red alert 3 software for linux

Command Line WRAPper is a tool that provides an easy way to build and run commands from input lines, avoiding the use of shell script. It is similar to xargs.

clwrap can make great things with the locate command, and is low resource intensive. It can also do some not-quite-fun works like multiple configure/make/make install after a fresh system installation. In practice, you have to generate a list of files/directories you want to manage, clwrap takes it in standard input and apply the command you want to apply for each files (lines) in input.

But you can do much more, in fact, its up to you to find how to use it ;).

examples:

- copying several files into one specific directory:

locate myfiles | clwrap -e cp {} mydir/

- renaming several files:

ls -1 ultra*
| clwrap -e "echo -n mv -v {}" -e "echo {} | sed s/ultra/ /"
| clwrap -e {}

- running a specific line in the shell history:

history | grep "482" | head -n 1 | sed s/ *[0-9]* *// | clwrap -v -e {}


- try all tv norms and frequency tables possible combinations with scantv:

cat norm
| clwrap -e "cat freq | clwrap -e echo scantv -n {} -f {}"
| clwrap -e {} > file 2>&1

- reformat source code, after a backup of course:

ls -1 | clwrap -e "cp {} {}.orig && flip -u {} && cat {}
| sed s/^[ t]*$//;/^$/d
| indent -kr -bad -bap -bbb -sob -i8 -l100 {} -o {}.tmp
&& mv {} tmp && mv {}.tmp {}"

Blob Wars : Blob and Conquer is a 3rd person action shooter. With the apparent defeat of Galdov and the reclaiming of the Fire, Space, Time and Reality Crystals, the Blobs battle was only just beginning.
Bob had rescued many Blobs and fought many battles, but now he had an ever bigger task ahead of him. The Blobs homeworld is still littered with the alien forces and Bob once again makes it his task to lead the counter attack.
But even without Galdov the aliens are still extremely well organised.
Main features:
- Explore and battle in full 3D environments
- Use and aquire mutliple weapons (uzis, shotguns, grenades)
- Fight familiar enemies - Assimilated Blobs, Eye Droids.
- Auto targetting enables you to maintain a lock on enemies whilst dodging around
- Blob allies - Fight alongside buddies such as Teeka the Scout

Astaro Command Center (ACC) is an application for centralized management of Astaro Security Gateways. With ACC, network administrators can easily manage and control multiple Astaro devices.
The intuitive Web-based user interface provides an effective overview that details the actual health of each device, swiftly allowing administrators to see which gateways require immediate action.
Astaro Command Center offers monitoring, inventory management, central update management, WebAdmin single-sign-on, and a world map view.
Enhancements:
- This version changes the GUI to the new look and feel of the ASG V7 style and it adds V7 support.
- It also handles the new daylight saving time dates from the Energy Savings Act in the US and Canada.
- Cluster monitoring global pattern version and UPS battery charge monitoring are now supported, and ACC can be used as an Up2Date Cache for all V7 packages.
- Besides these new features, some minor bugs were fixed.

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.

Konqueror Userscript is a KDE improvement script for Konqueror browser.
So far, the only feature available is autoexecuting every file under ~/.kde/share/apps/konqueror/userscripts as js, within current document context. TODO, of course, a lil bit compatibility with GreaseMonkey. Include, exclude url definitely will be mandatory needed feature. So far, you got to filtered it yourself within your JS :D. Im sure somebody will post a handy js script for this. Also, needed feature would be: enable disable userscript of course.
Screenshot shows an effect of the following code:
var elms = document.getElementsByTagName("a");
//alert(elms.length);
for(var i=0;i
elms[i].style.color="red";
elms[i].style.border="1px solid";
}
Enhancements:
- Supports userscript metadata (//== UserScript== tag).
- include/exclude works (I assume greasemonkey using wildcard matching)

C++ Command Line Library provides a framework for handling command line options and arguments. Either variables (of any type) are set to values given at the command line. Or user defined functions are called with arguments (of any type) read from the command line.
It was developed and tested using kdevelop 2.1 and gcc 2.95.3 on SuSE Linux 7.3.x
Main features:
- Easy extraction of command line arguments
- Automatic conversion of command line arguments to any type (even user defined classes)
- Convenient handling of command line usage errors by exceptions
- Complete documentation
- And all this is absolutely free

Snoopy vs. the Red Baron is an open-source one/two player combat game, available for Mac OS X, Linux, BeOS, QNX and Windows.
The original Snoopy was a tiny game for the Apple Macintosh, with black and white graphics, but already almost all the levels of the new Snoopy/SDL were implemented.
Snoopy could be played by two opponents, sharing a single screen and keyboard, and although it had poor graphics and tough controls, we very much liked to play it.
While we learned programming, we constantly sought for simple, yet interesting projects. If you have ever tried to learn a new language or API, you will have recognized that the simplest way in mastering the stuff is simply reprogramming an existing application, without losing much thought on design and originality.
So my friend reprogrammed Snoopy, in Object Pascal, using SAT, the Sprite Animation Toolkit, on his Classic II. That version of Snoopy features a fully functional AI, network play, but only the first level ( weapons drop).
While he was at it, he also implemented a "missing feature", the bombs, for which there where graphics and sounds in the game, but which could not be thrown.
When I discovered SDL, I recognized that it would be ideal for the job. Running on Windows, Linux, MacOS, BeOS and many other platforms, it is my new toolkit of choice for multimedia programming. It took us several weeks to port Snoopy (besides going to school, but now the work is almost done, with only the finishing touches to be made.
I can only encourage everyone to try SDL; it is really easy and portable (if worked right).