test report - embedding bzipped tar in a bash script (with uuencode)

Just a quick note on the cunning technique used in the making of tag_test.sh.

The utility's both data store and main interface is file system - which makes it easy to think of diff'ing directory trees (actual to golden) as a means to test the former.

Now, I would generate a golden test directory tree, test it manually all I want, tar-bzip2 it, and uuencode the data for pasting as an in-place redirection block (<<EOF) - which is fed to uudecode and untar in the script, of course.
And I'd also repeat this operation for every test I wanted to perform.

The resulting bash code is rather fatty, but it is totally self-contained.

tag: the bash utility's major update

Although I have properly realised the truly versatile filesystem-based tagging-enabled environment is much further away than I originally thought, I've updated my simple bash mini-utility, and it is now as useful as ever. I've even creatively wrote some tests for it.
Dowload/Clone Here

p.s. Some thoughts on the ideal filesystem interface left out for a while.

>>.bashrc

bash contexts

in your ~/.bashrc and any .bashrc's in your working directories
— for context-(cwd)-specific bash sessions!

simple (bash) file tagging utility

444 lines of pure bash tagging goodness!

Usage:  tag OPTIONS FILENAME [TAG ...]
       - tag FILENAME with the TAGs (if none, list current tags on FILENAME)
       untag OPTIONS FILENAME [TAG ...]
       - remove TAGs (or ALL if none specified) from FILENAME and list removed

(currently, you need some aliases to make this work)

This is a very raw (alpha, hehe) version of my new invention, but it works: I can tag and I can untag, and I can browse tags in my (unix) filesystem.

It has plenty of info inside, so please take your time and look at it.

Comments are much more than welcome.

p.s. In no particular order:

• blueslugs.com » Blog Archive » tag(1): del.icio.us-style file tagging
• CiteSeerX — Semantic File Systems
• tagsistant
• oyepa - Linux tagging file system (Manuel Arriaga)
• Punakea | nudge:nudge
  

p.p.s. UPD!

in-cwd web serving

I've come across a simple need to serve some (static) files temporarily, for the development. I didn't find anything on the surface for this purpose, though the need may be quite common, hence the note.
The obvious choice for the server is lighttpd, and the scripting goes along the lines of lighthere.sh.

If anyone is aware of another known-good solution, please share.

now this is something important I want to share

Note that it is TED.COM!

programming as an evolutionary advantage

It might just happen that the ability to program – spanning informational pattern recognition through behaviour formalisation – is the next woman's skill along the line of the commonly accepted ones, in our information-driven civilisation.
The human brain processing capacity – acknowledged evolutionary advantage of our species – will most probably not increase any time soon, but rather re-utilised by outsourcing particular activities to individually programmable computer systems.
What this might do to our culture – I can only guess. Let's not live in denial then, my hopes are for good.

Some related, but practical stuff of mine coming soon.

A Guiding Tagline

I find it reasonable to label content (speaking of British of course) with a word or two in the plural — for common objects, and use the singulars just for proper names (while appropriate casing is in order). The use of 'ing'ed verbs is also welcome since it reduces the confusion from noun homonyms.
Semantic systems of the future are nowhere but in a reach.

Sinatra is really good just for one-filers.

p.s. But merb's flat app is pretty much in its diapers, and they're not fresh clean.

bash LAP: project shell history

Once chosen the way of True Laziness, your best friends are Locality and Persistence (gonna write a lot on those guys later). And there's surely no point missing opportunities of making things more local or persistent right here, right now, in your current environment. Yes, yes, the prophecy says that I'm going to unleash the power of mmTerm to save the world from the GUI hell, but why wait doing nothing?

So you may help yourself by defining a sort of bash command:

function hist() {
    echo "`fc -ln -1` # `date`" >> .history
}

which allows (and encourages) you to record any significant (previous) command line to a local history log. You may also edit that ./.history yourself, of course, it's your file.

I am using this trick to keep a track of a project's command line activity of mine, and I must say, it's pretty useful while working in the project's directory (executing code generators, linking files, and stuff).

Historical Reasons vs history reasoning

I wonder, if we coding folk (just like any other sane people) don't like "Historical Reasons" mentioned anywhere in documentation, why should we put any trust in such historical reasons just anywhere else?

nested gits

I see no problem at all in nesting git repositories within a file system. Moreover, I would encourage using this technique (plus symlinks for strength) with an optional auto-commit hook (or rather agent) for parent git repositories. This will make your work more visible and persistent.

git for life, what?

I have high hopes about git, and I think it may be a workhorse for the new generation of "human output" repositories. Yes, it is still highly filesystem-based (with its regular handling), but it is clearly a step in a good direction.
What I (and quite a few people I've discovered on the net) miss in git is a command to create an "independent" commit, or rather the ability of free and convenient selection of parent commits to a forthcoming repo commit.
Probably some scripting should be in order after some additional research. Later.

p.s. I would take an extra step towards current git technology which will not adopt the above improvement as is. And that is making an additional commit after an "independent first one" with the previous (before the first commit) HEAD commit as a parent (plus the first commit as the other parent) so the working directory and git's HEAD will live in peace and harmony. Amen.

fink vs MacPorts

MacPorts! ('nuf said, fink is dead)