UNIX filters

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
Jun 7, 2008
121
0
#1
This is just a suggestion

UNIX/LINUX comes with filters like CUT, SPLIT SORT STRINGS TAC, TR, UNIQ, WC.

These could be built into TCC

But I would request that these are bundled with TCC as separate external utilities.
Since most of these read from stdin and write to stdout, should be a natural fit for TCC.
I am constantly using SORT, FIND, MORE to plug in a missing TCC gap (e.g. dir by owner)

I really hanker after these for an enhanced command line experience :-)

Cheers

Stephen Howe
 
Jun 7, 2008
96
3
#3
On Wed, Jul 13, 2011 at 6:28 PM, Stephen Howe <> wrote:

> This is just a suggestion
>
> UNIX/LINUX comes with filters like CUT, SPLIT SORT STRINGS TAC, TR, UNIQ, WC.
>
> These could be built into TCC
>
> But I would request that these are bundled with TCC as separate external utilities.
> Since most of these read from stdin and write to stdout, should be a natural fit for TCC.
> I am constantly using SORT, FIND, MORE to plug in a missing TCC gap *(e.g. dir by owner)
>
> I really hanker after these for an enhanced command line experience :-)
Why reinvent the wheel? A plethora of such things already exist.

If you want to go full bore, you install Cygwin, from
http://www.cygwin.com The Cygwin project is an attempt to reproduce
the Gnu toolchain under Win32. Cygwin's approach is to create a POSIX
emulation layer implemented as a DLL. A lot of *nix code builds "out
of the box" under Cygwin, because it links against the Cygwin.dll and
sees the system routines it expects to see under Unix. As an example
of how complete the emulation is, while not currently developed, a
port of X-Windows and the KDE windowing environment exist for Cygwin.
Cygwin includes the Gnu compiler suite and just about every Unix
utility you can think of, including a complete version of the Bash
shell.

If you don't want to go that far, you can look at UnxUtils and MSYS.
UnixUtils is a port of an assortment of Unix tools to Win32, but built
using the MS runtimes instead of the Cygwin POSIX layer. UnxUtils is
here: http://unxutils.sourceforge.net/

MSYS is part of the MinGW effort, which provides the Gnu compiler
suite installed to create native Win32 executables using MSVCRT.
Current versions of MSYS use an installer that will let you DL and
install specific components, so you can get just the utilities of
interest without getting the full GCC package. MSYS is here:
http://www.mingw.org/wiki/msys


> Cheers
> Stephen Howe
______
Dennis
 
#4
On Wed, Jul 13, 2011 at 15:28, Stephen Howe <>
wrote:

> I am constantly using SORT, FIND, MORE to plug in a missing TCC gap (e.g.
dir by owner)

This answer is tangentially related to your question. My timedir program
does solve the single example you gave, dir by owner:

timedir /O:O

timedir can be found at jcook.net/timedir

These sort fields are reported by timedir /??? /O:

- Prefix to reverse next R Reverse all following
C Compressed size G Group directories first
N By filename (alphabetic) O By owner
P By path displayed S By size (smallest first)
U Unsorted E By extension
D By first time printed TA By access time
TC By created time TW By write time
MC By CRC-32 checksum MM By MD5 checksum
MSHA1 By SHA1 checksum
MSHA224 By SHA224 checksum MSHA256 By SHA256 checksum
MSHA384 By SHA384 checksum MSHA512 By SHA512 checksum
B By attributes @ By links
V By version W By width of file path + name
H By hex filename I Unique ID
+ By file description L Junction target
; Color coding \ By folder+file count
_ By number of fragments A ASCII for /O:PNE
# Numeric for /O:PNE ## Only numbers for /O:PNE
X Hex for /O:PNE XX Only hex for /O:PNE

--
Jim Cook
2011 Monday: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Tuesday.
 
Jun 7, 2008
96
3
#7
On Wed, Jul 13, 2011 at 8:48 PM, vefatica <> wrote:

> ---Quote (Originally by Charles Dye)---
> Possibly of interest: *http://unxutils.sourceforge.net/
> ---End Quote---
> Have you used it? *Apparently it comes with ZERO documentation. *I have a partial set of
> docs from its forerunner Gnu TextUtils.
TextUtils is not a predecessor of UnxUtils. UnxUtils is an
independent effort to provide a subset of commonly used Gnu utilities
in native Win32 versions. (There was discussion of it on the Cygwin
list a few years back. It apparently took some prodding to get the
author to realize that the GPL required him to make source available,
too, and the eventual result was the Sourceforge project page.)

FileUtils, ShellUtils, and TextUtils were compined into Gnu CoreUtils,
and the first major release as a combined project took place in April,
2003.


> Do you know if UnxUtils docs are available anywhere?
They are straight Win32 ports of the corresponding Gnu utilities,
which are documented here:
http://www.gnu.org/manual/manual.html

Most also provide online usage help if invoked as <command> --help


> *- Vince
______
Dennis
 
#8
On Wed, 13 Jul 2011 21:43:04 -0400, DMcCunney <> wrote:

|FileUtils, ShellUtils, and TextUtils were compined into Gnu CoreUtils,
|and the first major release as a combined project took place in April,
|2003.

Thanks. I got the history mixed up. I looked at CoreUtils. It has 100 things
I will never use and it doesn't have grep or sed.
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,429
40
Albuquerque, NM
prospero.unm.edu
#9
Have you used it? Apparently it comes with ZERO documentation. I have a partial set of docs from its forerunner Gnu TextUtils. Do you know if UnxUtils docs are available anywhere?
I haven't used them much. I assume the options would be the same as in the regular GNU utilities for Unix. (But honestly I never find Unix documentation to be user-friendly or informative; if I really want to use Unix stuff I generally wind up shelling out for the O'Reilly books. Unix programmers could definitely learn something from Rex.)
 
Jun 7, 2008
96
3
#11
On Wed, Jul 13, 2011 at 11:11 PM, David Marcus
<> wrote:

> For Cygwin, the "man" and "info" commands provide documentation. Many commands give brief
> help if you use "--help" as a command line argument.
Versions of man and info are available for the Win32 ports as well.
_____
Dennis
 
Jun 7, 2008
96
3
#12
On Wed, Jul 13, 2011 at 10:48 PM, Charles Dye <> wrote:

> ---Quote (Originally by vefatica)---
> Have you used it? *Apparently it comes with ZERO documentation. *I have a
> partial set of docs from its forerunner Gnu TextUtils. *Do you know if
> UnxUtils docs are available anywhere?
> ---End Quote---
> I haven't used them much. *I assume the options would be the same as in the
> regular GNU utilities for Unix.
Correct. The fundamental differences will be those imposed by the
host platform, such as \ instead of / on Windows as a directory
seperator, and / instead of - as the option delimiter.

(In versions of MS-DOS up to 5.0, it was possible to specify something
other than / as the option delimiter character, whcih would let you
use either \ or / as directory seperators. The MKS Toolkit - a
comprehensive set of Unix utilities for DOS - had an install option to
do this. I believe 4DOS had a similar option. DOS 5.0 removed the
function that would let you change it, but inexplicably kept the one
that let you query what it was.)


> (But honestly I never find Unix documentation to be user-friendly or
> informative; if I really want to use Unix stuff I generally wind up
> shelling out for the O'Reilly books. *Unix programmers could definitely
> learn something from Rex.)
Unix documentation is quite informative, but it is reference material,
*not* tutorials. It assumes you already have basic knowledge of
usage, and need to check details.

There are endless sources of tutorial information available.


> Charles Dye
______
Dennis
 
#13
On Wed, 13 Jul 2011 22:48:32 -0400, Charles Dye <>
wrote:

|(But honestly I never find Unix documentation to be user-friendly or informative; if I really want to use Unix stuff I generally wind up shelling out for the O'Reilly books. Unix programmers could definitely learn something from Rex.)

You're right there. (But I do have a nice PDF for sed, with TOC and index!).
Though I have a lot of Gnu stuff, the only such utils on my path are in TTK ...
home of the Thompson Tool Kit, a collection of Unix text utilities I bought 10+
years ago ... came with a printed manual (which is now in a condition similar to
that of my ancient 4DOS manual). I do a lot with grep, sed, tr, cut ... and
I've been reluctant to learn new syntax.
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,429
40
Albuquerque, NM
prospero.unm.edu
#14
Correct. The fundamental differences will be those imposed by the host platform, such as \ instead of / on Windows as a directory seperator, and / instead of - as the option delimiter.
The ones I've messed with accept either slash as a path separator, but use only - for options. I assume wildcard expansion must be handled differently too...?
 
Jun 7, 2008
96
3
#15
On Thu, Jul 14, 2011 at 11:21 AM, Charles Dye <> wrote:

> ---Quote (Originally by DMcCunney)---
> Correct. *The fundamental differences will be those imposed by the host platform, such as \ instead of / on Windows as a directory seperator, and / instead of - as the option delimiter.
> ---End Quote---
> The ones I've messed with accept either slash as a path separator, but use only - for options. *I assume wildcard expansion must be handled differently too...?
- for options is standard for *nix, and carried through by the Gnu
utils. It pretty much has to be, or parsing becomes a nightmare
because you have to figure out whether / is being used as a path
separator or an option delimiter.

*nix tends to have a broader idea of wildcards than DOS/Windows, as
many tools accept regular expressions as wildcards, so yes, there will
be some differences there. Windows wildcards should work as
expected, since they are effectively a subset of what can be done
under *nix. But for the most part, if you know the usage under *nix,
it works the same way in Windows.

There are some tools ported from Unix, like ActiveState's
implementation of perl, that have some Windows specific extensions,
but that won't be a factor for the ones discussed here.


> Charles Dye
_____
Dennis
 
#16
Charles Dye wrote:
| Unix programmers could definitely learn something
| from Rex.)

But they won't. They think documentation is for morons, and they aren't.
Future generations? They should learn by experimentation! After all, their
time is free...
--
Steve
 
Jun 7, 2008
96
3
#17
On Mon, Jul 18, 2011 at 6:08 PM, Steve Fabian <> wrote:

> Charles Dye wrote:
> | Unix programmers could definitely learn something
> | from Rex.)
>
> But they won't. They think documentation is for morons, and they *aren't.
> Future generations? They should learn by experimentation! After all, their
> time is free...
Nope. In some respects, Unix suffers from its origins. It was
written by programmers, for programmers. Unix was originally
developed by programmers who wanted a better environment for doing
software development than the one provided by the OS of the Digital
Equipment Corp. mini-computer they used. They had a spare machine
which could be a blank slate, and they could start from scratch.

And because Unix was designed for software development, and the start
of all software was an ASCII text file containing source code, Unix
developed a lot of tools for ricing, slicing, and dicing text files.

In the early days, Unix was a multi-user system, accessed by dumb
terminals which were hard wired to a host or connected via a modem,
and you learned Unix and the tools from other users at the site where
you used Unix. The assumption was that you had a guru on site to
answer the questions and provide the background knowledge, and back
then, you did.

Unix documentation is generally good, but it's a *reference*, not a
*tutorial*. If you don't know enough to *understand* the reference,
then you *need* a tutorial, but Unix documentation is not where you go
to find it. That's not what it's for. There is a plethora of
tutorial material for Unix. It's available and easy to find.

And programmers are generally the *last* people who should write
documentation. Their skill is writing the code, not explaining how to
use it, and PC software has suffered the curse of programmer written
documentation for as long as there have been PCs. The programmers who
can write good code and good docs are few and far between. Most
programmers can write good code in their sleep, but can't write good
*prose* to save their lives.


______
Dennis