Dec 122017
UNIX filters ported to dos.
File FILTERS.ZIP from The Programmer’s Corner in
Category C Source Code
UNIX filters ported to dos.
File Name File Size Zip Size Zip Type
FECHO.ASM 1792 706 deflated
FECHO.COM 128 44 deflated
FEED.ASM 3200 1257 deflated
FEED.COM 384 100 deflated
FILTERS.DOC 9420 3185 deflated
FORCLEAN.ASM 3072 1189 deflated
FORCLEAN.COM 256 129 deflated
LOWER.ASM 3328 1270 deflated
LOWER.COM 384 101 deflated
SNGLSPC.ASM 3200 1216 deflated
SNGLSPC.COM 768 137 deflated
TRANSLAT.ASM 3328 1134 deflated
TRANSLAT.COM 256 134 deflated
TRUNC.ASM 2688 991 deflated
TRUNC.COM 128 79 deflated
UNIQUE.ASM 3072 1199 deflated
UNIQUE.COM 640 111 deflated
UPPER.ASM 3328 1270 deflated
UPPER.COM 384 101 deflated

Download File FILTERS.ZIP Here

Contents of the FILTERS.DOC file

Documentation for the DOS 2.1 (and probably 2.0) filters

Upper | translate all lowercase characters to uppercase
Lower | translate all uppercase characters to lowercase
Snglspc | removes extra blank lines from a file
Unique | deletes multiple occurances from a sorted list
Trunc | truncates a line at first matching char (or space)
Fecho | echoes standard input to screen (great for debugging)
Translat| puts each word of a file onto a separate line.
Feed | reads a filespec and sends files to standard output
Forclean| takes a fortran source and deletes comments and labels


Filters in general:

In case you have never played with MORE, FIND, or SORT in
DOS 2.0 and DOS 2.1, here is a brief explanation of what they
are and what they do.

Filters are special programs that always read their data from
something called "standard input" and send their output to
"standard output". Standard input is usually the keyboard, and
standard output is usually the screen. However, both of these
can be "redirected" wherever you want them to go using the
"<" and ">" symbols. For example,


causes the SORT filter to read its input from INPUT.DAT, sort
that data, and place the sorted output into OUTPUT.DAT.
If you tried

SORT would get its input from INPUT.DAT and send the sorted
data to the screen.

Can you guess what the next line will do?


That's right, it will read its data from the keyboard and
send the sorted output to the file OUTPUT.DAT! This means
that sort will wait for you to type data, and will continue
to read your data until you either stop the input with a
Control-Z (or F6), run out of memory, or turn off the machine!
After you enter F6, the sorted data will appear on the screen.

For a useful example of this, try


(There is a neater way to this, which I'll get into soon.)

MORE is a filter, too, with (I presume) some forced reads
from the keyboard at each pause.

FIND is also a filter, but it can read parms from the command
line (like MORE should, but doesn't.) The first parm it
wants is a search string in double quotes. The second parm
is an optional file name. If you don't supply a filename, FIND
will read standard input.

Now for pipes:

PIPES and FILTERS originally appeared in UNIX. PIPES are
much more powerful in UNIX than DOS 2.0, but even ours can
be very useful.

PIPES, simply put, are several FILTERS strung out with each
FILTER's output becoming the input to the next. For example,
the sorted directory listing in the last example could have
been produced with


This would result in the same thing but doesn't leave extra
files hanging around (like DIR.LST in the previous example.)

The "|" (located above the backslash "\" and next to "z") is the
symbol for a PIPE and is best used with spaces before and
after. Sometimes DOS has problems separating the "|" from
filenames in the parameters and get confused if the "|" is
not preceeded by a space.


Now for the new FILTERS:

UNIX has a large number of very useful FILTERS available, which
inspired several of the FILTERS here. What follows is a short
description of each filter and usage examples for the weirder



These two filters work very much alike - they read from
standard input and translate every character to either
uppercase (UPPER) or lowercase (LOWER). Non-alphabetic
characters are not affected.

Both of these filters will also accept a filename on the
command line, which means you don't have to use the redirection
symbol "<" to supply the input data. Note that output data must
still be redirected.





This filter reads a SORTED list and removes multiple occurances
of IDENTICAL lines.



WORDS.TXT new contains a sorted list of all the different words
contained in BOOK.TXT.



This filter reads from standard input and removes blank lines.
(Blank lines are defined as more than one cr/lf together.)



This filters accepts a filespec (which can include wildcards!)
from the command line. All files which match the filespec
are opened and the contents are sent to standard output.
This allows you to redirect the standard input from more than
one file. Possible uses are searching a large group of
files for the occurance of some string, like with FIND.



This will find all subroutine calls within a series of programs,
but, unfortunately, won't necessarily supply the name of each
file containing the "CALL".



This filter reads a file and truncates it starting at the first
space or any single character you specify on the command line.
If the character is not found in the line the entire line is
passed intact.



This line will give you a sorted list of fortran programs that
does not include extensions.


This line fill search all fortran files for the word "CALL",
truncate each line at the "(" following the subroutine name
(if any), sort the list, and delete multiple occurances. This
gives me a list of all the subroutines called by my programs.
Note that any numeric labels in the Fortran code are still
there and result in extra listings at the bottom of the list.
The next filter takes care of that.



This filter reads Fortran files, deletes all comment lines,
and deletes numeric labels. Inserting this before the sort
in th\Yious TRUNC example eliminates the extra lines
at the end of the list, as well as comments that happened to
contain the word "CALL". I wrote this one to fill a specific
need, so it will probably not solve any of your problems.



This filter is VERY handy when you are designing a filter
string of your own. Placing it in your command allows you to
see what is going on without disrupting the command itself.
Specificaly, it reads standard input and sends the data to both
standard output AND error output (the screen.)



This line contains two FECHO commands, one after the TRUNC and
the other after the SORT. This shows you the results of the
TRUNC command before SORT sees it, and again afterwards.



This filter reads a file of text and sends it out one word to a
line. Non-alphabetic characters are deleted. If you were to
send this file through TRANSLAT what you would see would start



These filters were written by Joi Ellis of Santa Barbara, CA. If
you have any problems or some ideas you would like to see become 'real'
contact me or leave a message on the Programmer's Shack RBBS 805/968-7871.

I hope you find some of these as useful as I have.

 December 12, 2017  Add comments

Leave a Reply