awk VS busybox-w32

Yep, functions! I used to write a fair amount of Awk code back in the late '80s and early '90s. I treated Awk as a "real" programming language and tried to make the code nice and readable. This of course involved a lot of use of functions.

I only have a couple of surviving examples of the code from back then, but here they are for the curious:

https://github.com/geary/awk

LJPII.AWK is probably the best example. It made a nicely formatted printout of source code on my HP LaserJet II printer. I wish I had one of the printouts it generated, but they are long gone.

Hmm... I wonder if my Brother printer supports the old LaserJet II control codes? Or maybe there is an emulator online?

The code was written for Thompson Awk (TAWK), so some bits would need to be adapted to modern Awks.

I used to love Awk! I still do, even if I don't use it much any more.

Awk has a reputation for being hard to read (as noted in stevebmark's comment), but when I was using it actively, I tried to treat it as a serious programming language and write readable programs in it.

Several years ago I tracked down a couple of my old Awk programs from around 1990 and posted them here:

https://github.com/geary/awk

SHANEY.AWK is an implementation of the infamous Mark V. Shaney:

https://www.clear.rice.edu/comp200/09fall/textriff/sci_am_pa...

This was probably the first program that made me really impressed with Awk. People were writing rather complicated Shaney implementations in C, and I thought, "this could be really simple in Awk." And it was!

LJPII.AWK is the Awk program I'm most proud of. This was in the days when we had tiny screens and no multiple monitors and you always printed out your code to read it. In my circles we also fond of inserting "separator lines" between functions, in various formats such as this one:

  // - - - - - - - - - - - - - - - - - -

Even in environments such as win32, we have https://frippery.org/busybox/ that is just fucking awesome. Staying the size below an 1mb while being extremely fast. Unlike the shitty python package which has 40mb archive size and leave breadcrumbs for me to cleanup all over my filesystem.

Win32 port is here: https://frippery.org/busybox/

Look into busybox for windows https://frippery.org/busybox/. Pretty bad ass even with it’s downsides of missing applets and such

Vim by itself means no supporting unix environment. It's useful to call out to powerful external tools not present by default on Windows. I fill that gap with busybox-w32. It's not a big deal once solved.

Sure, it's not necessary, but a few simple, nice tools (<600kiB for an entire suite of extended unix utilities) makes thing a whole lot simpler on a platform devoid of nice tools.

To operate on many files you'll need better tools than what Windows gives you. One option is busybox-w32 (important caveat: doesn't support unicode paths), which will get you some basic command line tools. For example, to gzip compress every file under the current directory, including subdirectories (leaving the originals behind with -k):

busybox-w32 includes a cal applet. If that's all you care about, you can just rename busybox.exe to cal.exe.

busybox-w32: standard unix utilities for Windows. It's a BusyBox port.

IHMO, even better is to just use POSIX sh in your Makefile and simply make it a build requirement. It's easy to obtain a reasonable sh even on Windows (Cygwin, MSYS2, busybox-w32), and to further support exactly this I include sh alongside make in my development kit distribution. This uniformity lets me hit all operating systems with the same Makefile. I use EXE from the environment to determine the binary file extension, if any.