April 29, 2012
Here, have a program!
In the next few days, expect more programs to be uploaded. Today, I submit to you new_c.sh! This wonderful bash shell script in the product of a few months of forethought and one day one finally coding it. It would have been here sooner, but great programs aren't always though up overnight.
new_c.sh (or as I've put it in a directory devoted to C/C++ projects as
./new is probably the most complex of all my "new" programs. If you haven't explored the hierarchy of my site yet, I wrote "new" files for Java, Perl, PHP, and Bash about a month or so ago, but I don't think they are as nice as this file I just wrote. All of these scripts are designed to generate files with as little mental though as possible. You focus on writing the program rather than remembering how to write the program. It's ideal if you know a few programming languages, a CS student, or someone who is looking for a template to start a program.
To use this program, you type in the path of the program (even if it is not defined) and the file name. You can add another extension or a "main" to tell the script to insert code used for modules and main program files. Let's show how that works with a few visible examples in the shell.
$ ls new $ ./new test1/demo1.h # this works similarly with demo1.c or demo1.cpp $ ls new test1 $ ls test1 demo1.h $ ./new test1/demo2.h c $ ./new test1/demo3.c h $ ./new test1/demo4.h cpp $ ./new test1/demo5.cpp h $ ls test1 demo1.h demo2.c demo2.h demo3.c demo3.h demo4.cpp demo4.h demo5.cpp demo5.h # ./new test2/demo6.c main # this works similarly with demo6.cpp
OK, so what's so great about this? A program that creates another file? Consider the contents of these files. When they are created, they have their own headers (all of them), they are set up for modules (demos2 through 5), they have their own main function (demo6). I'll admit this is a start and to some programmers you may claim doing this is easy without this script. It is, but if you want to have a uniform system (which you should) to create files, wouldn't it be much better typing in a command that does this for you rather than making work for yourself?
If there is one thing that I've learned over the years, it is that documentation doesn't need to be elaborate but it is necessary. Just be sure to write the name of the file, the date, your name and email address, and a little bit of information about what the program does and do likewise with any methods, classes, or tables you define along the way.
It is also important to know that scripts like this one are works in progress. I wanted to make a version of this to write files for OpenGL source code, but it's been a few years since I did some OpenGL. Nothing going back to some old notes I have won't jog my memory on.
I'm considering uploading some of my scrap programs used to try out features of a language before using them in code. I've had these on my computer for about a couple of years, but didn't feel like they were professionally written enough to put in the files directory. The uploaded version should be cleaned up enough to impress some folks.
Tomorrow, expect to see one of my favorite shell hacks that Linux, UNIX, BSD, and probably OSX users can do, but you probably won't see it on Windows shells: COLORS in your code!