Fun with Cygwin's /dev/clipboard

I'd say that /dev/clipboard is surely among one of the least known handy things on Cygwin. The idea is simple -- the Windows clipboard is accessible as a file, /dev/clipboard.

I often use /dev/clipboard to bridge the gap between GUI tools and line-oriented tools. For example, if you're wondering how many words are in a section of text in a document you're looking at, you can put that text on the clipboard and then do this:

wc -w /dev/clipboard

If you want to insert the output of ls into a document you're editing, send it to the clipboard,

ls *.java > /dev/clipboard

and then paste it in. (Yes, this task is simpler with Emacs, vi, et al.!)

You can save some typing by symlinking /cb to /dev/clipboard:

ln -s /dev/clipboard /cb

Some non-Cygwin programs don't interact well with /dev/clipboard. For example, directing the output of javap to the clipboard leaves it unchanged:

% date > /cb
% javap Hello >/cb
% cat /cb
Sun Mar 30 15:23:24 USMST 2008

To compensate, I wrote a trivial script, tocb:

% cat tocb
cat >/dev/clipboard

Instead of redirecting output to /cb, I pipe into tocb:

% javap Hello | tocb
% cat /cb
Compiled from "Hello.java"
public class Hello extends java.lang.Object{
public Hello();
}

I also wrote a trivial counterpart for tocb named fromcb:

% cat fromcb
cat /dev/clipboard

Incidentally, Mac OS X has similar commands named pbcopy and pbpaste.

I got to wondering if a single script, call it "cb", could act like fromcb when on the left end of a pipeline, and act like tocb on the right end of a pipeline. Like this:

% cal | cb # puts output of cal onto the clipboard
% cb | wc # puts the clipboard contents onto standard output

Cygwin supports the isatty(file_descriptor) library function, which queries whether the specified file descriptor is connected to a terminal. (Some programs, ls to name one, change their behavior depending on whether they're writing to a terminal.) Linux has isatty(1), which simply wraps isatty(3) in a program. My Cygwin installation doesn't have isatty(1), and I was too lazy to see if it's in some package I haven't installed, but it's trivial to write:

% cat isatty.c
main(int argc, char **argv)
{
  exit(!isatty(atoi(argv[1])));
}

With that in hand it's easy to write a cb that that reads or writes the clipboard depending on which end of a pipeline it's on. Here it is:

% cat cb
if isatty 0
then
   cat /dev/clipboard
else
   cat >/dev/clipboard
fi

Usage:

% cal | cb
% cb | cat -n
     1       March 2008
     2  Su Mo Tu We Th Fr Sa
     3                     1
     4   2  3  4  5  6  7  8
     5   9 10 11 12 13 14 15
     6  16 17 18 19 20 21 22
     7  23 24 25 26 27 28 29
     8  30 31

You can put cb on both ends of a pipeline to transform the clipboard contents:

% date | cb
% cb | tr a-z A-Z | cb
% cb
SUN MAR 30 16:03:17 USMST 2008

p.s.
Maybe there is nothing new under the sun -- I just now noticed that xsel (c. 2001) apparently uses isatty to determine whether it should fetch or set clipboard contents. :)

Thoughts from a presentation on Domain Specific Languages

At the March meeting of the Tucson JUG, Warner Onstine gave a presentation on Domain Specific Languages (DSLs). I have to say that it was the most thought-provoking professional meeting that I've attended in a while.

Prior to the talk I was thinking that DSL was just a new name for an old idea. Jon Bentley wrote a CACM column on "Little Languages" in 1986 and that's what I'd pictured a DSL to be. At Warner's talk I learned that what I've thought of as a "little language" is known as an "external DSL". My understanding of the defining characteristic of an external DSL is that the syntax of the language is arbitrary and therefore a necessary component of an external DSL is a parser of some sort. Code written in an external DSL may be compiled, directly interpreted, translated to another language, etc.

I found the more interesting notion that Warner talked about to be that of an "internal DSL" (IDSL) . An IDSL has a "host language"; programs written in the internal DSL syntactically valid in the host language.

Warner put forth a "coffee example" in Java:

new Coffee("grande").type("latte").milk("soy").whip(false);

I understand that an API providing this sort of expressibility is said to be a "fluent interface". jMock uses this approach, too:

ms.expects(once()).method("receive").with(eq(message));
--jmock.org

Ruby's grammar allows more flexibility than Java. Here's an example using ActiveRecord:

  create_table :products { |t|
    t.column :pn, :string
    t.column :descrip, :text
    t.column :picture, :string
    t.column :price, :decimal, :prec => 10, :scale => 2, :default => 0
  }

It resembles DDL but it's just Ruby code.

rake, the Ruby-based build tool, takes the idea quite a bit further.

It's interesting to consider what attributes of a language facilitate internal DSLs. For example, being able to write method calls without parentheses in Ruby eliminates a lot of clutter. Ruby's notion of symbols allows for things like :decimal instead of "decimal", also reducing clutter. Ruby's blocks are considerable facilitators, too.

I believe that somebody at the meeting conjectured that it would be difficult have a very expressive IDSL in a language with static typing. Just now I found some interesting examples of IDSLs in statically typed functional languages, like Haskell. Perhaps the most interesting is Haskore, a Haskell IDSL for describing music.

It seems that ever since XML emerged there's a been growing phobia about using EDSLs. I've been dismayed by that because I hate clutter and it's hard to imagine anything more cluttered than XML. There have been tools like yacc for decades but Warner mentioned the idea of "language workbenches", which I'd describe as a next-generation tool for building EDSLs. One example is JetBrains MPS. Perhaps language workbenches will turn the tide of the industry's march toward XML-for-everything.

p.s.
Regarding XML, I love this quote from Terence Parr, the creator of ANTLR: "Being an expert in XML is like being an expert in comma-separated values."