Opening a cmd window in the current working directory from cygwin

With the newer version of cygwin I am running, there are a few flaws. These mainly have to do with how it interacts with printing and user input from windows executables.


  • The windows python prompt doesn’t display. See here for more details.
  • Using mercurial, it can’t prompt me for a password. It comes up as abort: http authorization required

There are a few little niggly things like this which makes it handy to have the windows console available at your fingertips. You can launch cmd.exe from within cygwin, but that doesn’t solve the problem as you are still using the same input/output from the terminal. So I wrote a very simple script which will launch cmd in the current working directory.

Here it is:

# Written by: DGC

usage() {
  cat <<EOF
Usage: $(basename $0) <options>;

Opens a windows command window in the current working directory.

-h                 Display this message.

# Main
while getopts ":h?" option
  case $option in
      echo -e "Invalid option: -$OPTARG \n"

cygstart 'C:\Windows\System32\cmd.exe'

This is slightly overkill for essentially just cygstart 'C:\Windows\System32\cmd.exe', but I like to include a help with all my scripts.

It was helpful to me, so I thought I’d share it.


Interactive menus for UnitC++

UnitC++ has gone to version 1.1.0. The new feature is the addition of an interactive menu system. You run your tests declared using the TEST macro with the following code.

int main(int argc, char** argv)
  return UnitCpp::TestRegister::test_register().run_tests_interactive(

This will produce a menu which looks something like this;

0) All tests.

1) Maths
  2) "Maths:sqrt_results"
  3) "Maths:is_square"
  4) "Maths:sqrt_precondition"

5) MyString
  6) "MyString:length_test"
  7) "MyString:validity_test"

The numbers which you run the tests with can be input on the command line also, so utest.exe 0 will always run all of the tests.

See more at my sourceforge page


UnitC++ on SourceForge

My latest project, UnitC++ , is now live on SourceForge. Check it out here


Humour in the C++ standard

It’s nice to see that the C++ standard, while mostly dry, has a little humour in it. There is a limerick in section 14.7.3, 7. It goes like this;

When writing a specialization,
be careful about its location;
or to make it compile will be such a trial
as to kindle its self-immolation.

And according to Mostly Buggy in version C++0x FCD there was an amusing footnote in Section 29 Atomic operations library

29.1 General [atomics.general]
1 This Clause describes components for fine-grained atomic access. This access is provided via operations on atomic objects.341
341) Atomic objects are neither active nor radioactive.

But sadly in my copy (ISO IEC 14882) this was not included. It must have been taken out before the official standard was released.

There are according to Michael Wong two limericks in the standard, but I couldn’t find the second one (in the document, or on the internet).



This post is an introduction to a library I have written, UnitC++.

UnitC++ is a modern, light weight, header-only c++ library for making unit testing easy. The intention of this library is to make it really easy to test c++ code in a portable way.


Continue reading ‘UnitC++’


Functional Data Structures in C++: Lists

Great article by Bartosz Milewski. I’m always interested in applying different paradigms to C++. Here is my attempt at this.

  Bartosz Milewski's Programming Cafe

“Data structures in functional languages are immutable.”

What?! How can you write programs if you can’t mutate data? To an imperative programmer this sounds like anathema. “Are you telling me that I can’t change a value stored in a vector, delete a node in a tree, or push an element on a stack?” Well, yes and no. It’s all a matter of interpretation. When you give me a list and I give you back the same list with one more element, have I modified it or have I constructed a brand new list with the same elements plus one more?

Why would you care? Actually, you might care if you are still holding on to your original list. Has that list changed? In a functional language, the original data structure will remain unmodified! The version from before the modification persists — hence such data structures are called persistent (it has…

View original post 4,199 more words


Using ediff with Version Control

This is just a quick note about a nice emacs feature.

If you develop with emacs, you may have heard of/used ediff. This is a very handy diff program which runs inside emacs. We use this with a custom hook at work to work with our version control system. I found out that it works nicely with more standard version control systems as well.

The main way to use ediff is the command


This lets you choose two buffers to diff. To do this for different revisions of a file you can use the command


This will ask for which file you want to view revisions of (default, the current buffer), and the two revisions to compare (default latest revision and the current state). The you will have the file you asked for loaded in the two revisions you asked for.

Using mercurial personally I find this more informative than the output from hg diff in complicated cases. I believe this works for any version control system recognised by emacs, e.g. mercurial git and subversion.


Get every new post delivered to your Inbox.

Join 166 other followers