Easy Ansi Escape Code in C♯ and Javascript

I've been really rather ill over the weekend, so I wasn't able to write a post when I wanted to. I'm starting to recover now though, so I thought I'd write a quick post about a class I've written in C♯ (and later ported to Javascript via an ES6 Module) that makes using VT100 Ansi escape codes easy.

Such codes are really useful for changing the text colour & background in a terminal or console, and for moving the cursor around to draw fancy UI elements with just text.

I initially wrote it a few months ago as part of an ACW (Assessed CourseWork), but out of an abundance of caution I've held back on open-sourcing this particular code fragment that drove the code I submitted for that assessment.

Now that the assessment is done & marked though (and I've used this class in a few projects since), I feel comfortable with publishing the code I've written publically. Here it is in C♯:

(Can't see the above? Try this direct link instead)

In short, it's a static class that contains a bunch of Ansi escape codes that you can include in strings that you send out via Console.WriteLine() - no special fiddling required! Though, if you're on Windows, don't forget you need to enable escape sequences first. Here's an example that uses the C♯ class:

// ....
catch(Exception error) {
    Console.WriteLine($"{Ansi.FRed}Error: Oops! Something went wrong.");
    Console.WriteLine($"    {error.Message}{Ansi.Reset}");
    return;
}
// ....

Of course, you can get as elaborate as you like. In addition, if you need to disable all escape sequence output for some reason (e.g. you know you're writing to a log file), simply set Ansi.Enabled to false.

Some time later, I found myself needing this class in Javascript (for a Node.js application I'm pretty sure) quite badly (reason - I might blog about it soon :P). To that end, I wound up porting it from C♯ to Javascript. The process wasn't actually that painful - probably because it's a fairly small and simple class.

With porting complete, I intend to keep both versions in sync with each other as I add more features - but no promises :P

Here's the Javascript version:

(Can't see the above? Try this direct link instead)

The Javascript version isn't actually a static class as like the C♯ version, due to the way ES6 modules work. In the future, I'd like to do some science and properly figure out the ins and outs of ES6 modules and refactor this into the JS equivalent of a globally static class (or a Singleton, though in JS we don't have to worry about thread safety 'cause the only way to communicate between threads (also) in JS is through messaging).

Still, it works well enough for my purposes for now.

Found this interesting? Got an improvement? Just want to say hi? Comment below!

Pepperminty Wiki CLI

I've got a plan. Since I'm taking the Mobile Development module next semester, I'd like to create an Android app for Pepperminty Wiki that will let me edit one or more instances of Pepperminty Wiki while I'm, say, on a bus.

To this end, I'll need to make sure that Pepperminty Wiki itself is all ready to go - which primarily entail making sure that its REST API is suitably machine-friendly, so that I can pull down all the information I need in the app I build.

Testing this, however, is a bit of a challenge - since I haven't actually started the module yet. My solution, as you might have guessed by the title of this blog post, is to build a command-line interface (CLI) instead. I've been writing a few bash scripts recently, to I tried my hand at creating something that's slightly more polished. Here's a list of the features supported at the time of posting:

• Listing all pages
• Viewing a specific page
• Listing all revisions of a page
• Viewing a specific revision of a page

Support for searching is on the cards, but it's currently waiting on support for grabbing search results as json / plain text from Pepperminty Wiki itself.

I'll be updating it with other things too as I think of them, but if you'd like to give it a try now, then here's the source:

It should update dynamically as I update the script. Simply save it to a file called peppermint - and then you can run ./peppermint to get an overview of the commands it supports. To get detailed help on a specific command, simply run ./peppermint {command_name} to get additional help about that specific command - and additional help for that command will be displayed if it supports any further arguments (it will be executed directly if not).

Sound interesting? Any particular aspect of this script you'd like explaining in more detail? Want to help out? Leave a comment below!

Learn your terminal (or command line)

Enter stage left: the terminal (or command line, on windows). That window with strange white text on a black background. You might not see it, but every operating system has one - humming away in the background, just waiting to be used, but epic arcane skills are needed to navigate this bizarre and perhaps dated window into your computer.... or so it seems.

When you think of your computer, you will probably think of a GUI (a.k.a. goo-ey), with windows, a cursor, and perhaps a few buttons. GUIs make it easy for newcomers to easily find their way around a computer by referencing things that exist in the real world (e.g. folders and files, a floppy disk on the save button, etc.), but they can be inherently slower to use - especially for long series of perhaps repetitive tasks that stay essentially the same.

A terminal (linux and friends) or a command line (windows) is another view into your computer. It's a way of controlling your computer with text. Text that follows particular set of rules, that can be saved and repeated at will through the use of scripts. It's built on commands, each of which does one thing and one thing well. On their own they're mildly useful, but together they form a powerful framework that can perform almost any task. It's certainly different (and there's a little bit of learning curve, to be sure), but not as hard or arcane as you might think it currently.

A knowledge of the terminal or command line on your computer can be rather useful - especially so for those involved in computer science or technical support. How long would it take you to flatten a large set of deeply nested folders with a GUI? Or convert and recompress few folders worth of videos? Or even renew all your ssl certificates on your web server? All of these things can be automated through the use of a terminal or command line.

Even if you're just a casual computer user who's not into programming, it's still worth at least looking into. Perhaps it'll save you some time! Perhaps it'll save you from asking your friend where something is on their computer when you can't find it. Maybe it'll even save you if your computer suddenly decides it doesn't want to boot up properly. And you'll look cool doing it too :P (What better reason is there?)

If I've somehow managed to convince you to dive in and take up the challenge learning, then I'll end this somewhat different post with a collection of places you can go to get started.

• Linux
  • Linux Tutorial - Learn the Bash Command Line by Ryan's Tutorials - An excellent 13 part tutorial on the basics of bash and the terminal (Still useful if you use zsh for the basics at least).
  • Computer Literacy 101 on linuxcommand.org - A linux terminal tutorial. Uses bash. Your prompt might differ, but the concept is the same.
  • Using the terminal in the Ubuntu Documentation. Ubuntu specific, but again, the concept is the same. Read Computer Literacy 101 first.
  • An Introduction to the Linux Terminal by Mitchell Anicas in the Digital Ocean Community - mainly aimed at servers, but still useful.
  • Computer Freely - A guide to different Linux Distributions, how to choose one, and how to switch to using it full-time.
  • explainshell.com - Enter a linux command on this website, and it'll tell you what each part of it does. Really useful for dissecting those long and complex one-liners.
  • Explain a command - if explainshell won't do it, then this one will :P
  • Linux Commands - A practical reference on pixelbeat.org
  • Linux Terminal Command Reference by Alexio on community.linuxmint.com
  • Linux Shell - Getting Started - A good whistle-stop tour and reference.
  • Linux/BSD command line wizardry: Learn to think in sed, awk, and grep on Ars Technica
  • Command line wizardry, part two: Variables and loops in Bash on Ars Technica
  • Get started with the Linux command line and the Shell - Training | Microsoft Learn on Microsoft Learn
  • Introduction to Bash - Training | Microsoft Learn on Microsoft Learn
• Windows
  • Introduction to the Windows Command Prompt by Lawrence Abrams on BleepingComputer.com
  • A getting started guide on dosprompt.info
  • Command-line reference A-Z on the Microsoft TechNet - A list of core windows commands and links to their help pages

Pushing Git Commits to an SVN Repository

Yesterday I found myself in the awkward position in which I needed to push some commits in a git repository to an existing SVN repository. This came about because as soon as my 3D module was finished at University, I copied my code over to a private git repository and started working from there instead. As luck would have it, I ended up running into a few nasty issues and needed to push my extra commits to the original SVN repository.

Since it took me a while to work out how to accomplish this, I thought I'd write a blog post on it. Credit for this method goes to Pete Goodliffe for figuring out how to do it.

The first thing you need to do is to install git svn, if you haven't already. If you're on Windows, then you probably already have it if you've got git (which you'll need too). If you're not sure, simply type git svn into a command line (or terminal), and if you don't get a 'svn' is not a git command message, you've got it installed.

Next, you need to use git svn to clone your SVN repository. Even if you've got a clone sitting somewhere already, you should create a fresh one, just in case. This process may take a long time, depending on how many commits you've made to the SVN repository. Use the following command:

git svn clone {svnRepositoryUrl}

Replace {svnRepositoryUrl} with the URL of your remote SVN repository. Now that you've done that, cd into the created directory.

Next, we need to add the git repository as a new remote. To do this, type something like this:

git remote add -f remote-repo {gitRepoUrl}

Replace {gitRepoUrl}with the url of your remote git URL. Now we've set everything up, we can replay the remote git repository's commits overtop the commits in the SVN repository:

git rebase --onto remotes/git-svn --root remote-repo/master

Again, this may take a while. Once this command has completed, all you have to do is a quick git svn dcommit to push the new commits up to the SVN repository.

Alternatively you can push the SVN commits to the remote git repository by entering the following commands instead of the rebase command above:

git pull remote-repo master # Make sure that the local workspace is in sync with the remote git repo
git push remote-repo # Push the SVN commits to the remote git repo

That's about all I wanted to include in this post. If you found this post useful (and even if you didn't!), please leave a comment down below.

3D Worley Noise with noisebox

Recently, I've been writing a command line noise generation tool in C♯, and I've called it noisebox. Initially I found a few noise generation algorithms that other people had already implemented, so all I had to do was write an extensible interfacde on top of the code I'd found. When I came to Worley noise, I couldn't find an implementation that I could understand (I haven't taken a look at delegates properly yet), so I decided to write my own. It's still got some bugs in it, but I've decided to relase the Worley noise implementation on it's own first, and then I will tidy up a few loose ends and release the full code on GitHub (loko out for a blog post soon!).

Here's a link to a gist of the Worley noise generator: Worley.cs

The imbuilt documentation comments (what do you call them?) should give you enough information to use it, but if you get stuck post a comment below and I will try and help you out.

The code will be released under the Mozilla Public License 2.0.

This post's title include the word "3D" - but the image at the top is very much in 2D. To demonstrate the 3D-ness of the algorithm, I added the --frames and --offset options to noisebox and rendered 1000 frames of noise, and then stitched the together with ffmpeg. I've uploaded the result to youtube.

Splitting your C♯ Code into Multiple Files 2: DLLs

I have found out about compiling and linking to DLLs. I think this is called Dynamic Linking but again, I could be wrong.

We will be using the example files from last time:

filea.cs:

using System;

class ClassA
{
    public static void Main()
    {
        Console.WriteLine("This is a test from file A");
        Someplace.ClassB.PrintHello();
    }
}

fileb.cs:

using System;

namespace Someplace
{
    public class ClassB
    {
        public static void PrintHello()
        {
            Console.WriteLine("Another hello from file B!");
        }
    }
}

This is a 2 step process. First we need to compile the DLL, then we need to compile the main exe and link to the DLL.

To compile the DLL, you type something like this:

csc /target:library fileb.cs

The important bit here is /target:library. This tells the C♯ compiler to compile your code to a DLL and not and exe.

To compile the main exe, you need to type something like this:

csc /reference:fileb.dll filea.cs

This tells the C♯ compiler to compile the code in filea.cs into an exe, and link it to fileb.dll.

Taken from this MSDN page.

Splitting your C♯ Code into Multiple Files

I have just started to work out how to split my C♯ code into multiple files, and thought that I would share it with you. This post will be about what I believe to be static linking, but I could be wrong. Anyway, it is actually quite simple:

Here is the contents of filea.cs:

using System;

class ClassA
{
    public static void Main()
    {
        Console.WriteLine("This is a test from file A");
        Someplace.ClassB.PrintHello();
    }
}

and here is the contents of fileb.cs:

using System;

namespace Someplace
{
    class ClassB
    {
        public static void PrintHello()
        {
            Console.WriteLine("Another hello from file B!");
        }
    }
}

Then when you compile, you should do something like this:

csc filea.cs fileb.cs

This will tell the C Sharp compiler to grab both filea.cs and fileb.cs, and to output a single filea.exe.

Next I will try to figure out how to create a .dll file and include that - then I can build my own libraries.

Sending POST Requests with curl

This is a quick post about sending POST requests via the command line. I have been using curl for a while now - and I find it to be a good alternative to wget. I have just found out how to use it to send a POST request from the command line, and I thought that I would share my findings here.

Sending a POST request is really quite simple:

curl -X POST --data-binary "@$input_filename" -o $output_filename $url

• $input_filename is the name of the filename that contains the data that you want to send.
  • @- can be used to specify stdin, allowing you to pipe the output of the previous command into curl.
  • You can also drop at @ symbol and hard-wire the data you want to send into the command itself.
• $output_filename is the name of the file you want to save the response to. You can drop -o $output_filename if you want curl to output he result to he standard output for further processing.

If you find that you get some king of error message from the above, you may need to add --header "Expect: 100-continue" just before the $url - some servers require this.

The --data-binary is rather important, as if you use --data on it's own, line breaks are not preserved for some bizarre reason.

I am finding that curl is much more powerful that I first expected, as it understands just about any protocol you care to name....I need to experiment with it further.

Curl also has a modular structure to it's command line arguments, so you can tack and extra setting on the end and it will work exactly as you would expect it to (most of the time!).