The sandy text editor is an open source project from the team over at suckless.org, which make painfully minimal1 alternatives for popular tools and applications for unix-ish platforms.
But perhaps the tense being used here is wrong. For quite some time, sandy, suckless’ minimal vi(m) replacement, has been unavailable. The git repository is offline; the root cgit instance returning the following “No repositories found” message:
Perhaps best described as borderline masochist in their austerity and spartanism ↩
If you haven’t heard of tac, it’s a pretty nifty command-line utility that ships with the GNU utils and it’s used to print a file backwards, line-by-line. It’s especially useful when analyzing things like log files, and judicious use of tac can speed up commands considerably.
Take the example of a 30GiB webserver access log and you want to see the last request to a certain resource or that triggered a particular HTTP status code. You could run the following to get the last such request… which would take quite awhile on anything larger than a few hundred MiB:
> egrep "GET /path/to/resource " access.log | tail -n1
Or you could be smart about it and use tac instead, and not even have time to blink before the result comes back:
> tac access.log | egrep "GET /path/to/resource " | head -n1
If you’re still stuck on .NET 2.0, 3.0, or 3.5 for any reason and don’t have access to the .CopyTo method for System.IO.Stream objects, the Stream.CopyTo extension method, available as a small NuGet package will make manually allocating buffers and other boilerplate associated with copying a buffer from one stream to another a thing of the past.
Continuing our promise to open source parts of our libraries and applications where possible, we’ve just released PrettySize, a C# and .NET library for representing file sizes in a human-readable (pretty) format. PrettySize is available for free (MIT-licensed) on GitHub and via NuGet for those that are interested, and forks, contributions, and pull-requests are actively encouraged.1
One of the best benefits of open-sourcing code is that it requires you to take a critical eye to what your code does and how it’s structured. Haphazard code interspersed throughout a dozen different files is cleaned up and re-organized in a way that can only bring benefits all around, from performance to ease-of-use, security, and future maintenance.
If anyone wants to try their hand at implementing IFormattable, consider this an open invitation. It’s not a functionality we ever needed, but some might find it useful. ↩
1Password and LastPass are probably the two best known names in the password storage business, both having been around from 2006 and 2008, respectively. Back in 2008, the internet was a very different place than it is today, especially when it comes to security. Since then, a lot has changed and the world has (hopefully) become a more security-conscious place – and security experts have come to a consensus on a lot of practices and approaches when it comes to encryption and the proper handling of sensitive data.
Both of these password managers are heavily vetted and constantly under scrutiny from security researchers, crackers, state security agencies, white hat hackers, and more with open bug bounty programs [1] [2] (though some considerably more generous than others), and are probably “safe” choices for the average computer user.. to an extent.
We are proud to present the latest addition to our open source portfolio, the Unicode.net library! We’ve extracted a number of encoding- and emoji-related namespaces and functions from a few of our projects going back many years and split them off to create Unicode.net: an open source library that can be used to aid in the safe processing and manipulation of (possibly) internationalized strings and non-ASCII characters (and then some).
Unicode.net is designed from the ground-up as a modern approach to text processing and text encoding, with only support for the most popular Unicode encodings: UTF-8, UTF-16, and UTF-32. Additionally, Unicode.net is designed to complement .NET’s existing (albeit extremely limited) Unicode support, instead of supplanting it, which primarily translates to embracing rather than shunning the System.String type wherever possible. Unlike many other text-processing libraries, Unicode.net does not want you to stop using the system types for string representation and to switch over to custom datatypes 😁.
This post is chiefly directed at .NET developers and others involved in the various stages of .NET deployment, in particular, anyone that’s been keeping tabs on the situation with the new cross-platform, open-source .NET Core initiative or .NET Standard, which came about as Microsoft’s response to the increased fragmentation of the .NET Platform as a result of the myriad of different deployment targets now available. If you’re not into that kind of stuff, feel free to skip this post, or read on and we’ll try to explain things sufficiently as we go through.
When a new Microsoft, with Satya Nadella at the helm, first open sourced the .NET Platform on November 12, 2014 it became clear that they fully intended to put everything they had into the initiative and that great things and big changes were coming to the .NET Framework and its languages. But what it also signaled was the inevitable beginning of a new level of fragmentation for the Framework, which had thus far – by and large – resisted any major fragmentation for the past 12 years of its existence.1 But taking a framework that was cobbled together from parts old and new, built atop of WIN32, GDI, and various Windows-specific anachronisms meant that porting the .NET Framework as-is to other platforms was nigh-impossible — and that major changes would have to be made to support this gargantuan effort.
There are notable exceptions to this, namely the .NET Micro Framework, the .NET Compact Framework, and Mono; however, these “members” of the .NET ecosystem – one not even by Microsoft – were never considered to be first-class .NET Targets within or without Microsoft. ↩
We’ve raved about Microsoft’s latest take on a Linux subsystem for Windows, this time in the form of the oddly-dubbed “Bash on Ubuntu on Windows” Windows Subsystem for Linux — herein and forever after referred to only as WSL for the sake of our collective sanity — but as awesome as being able to type bash in a command prompt to get access to holy posix goodiness, we think we can do better. Meet $.
$, formally known as RunInBash, is a simple command line helper utility that simply runs whatever follows it under WSL rather than in the current (Windows) terminal. Here’s a picture to illustrate (click to expand):
Let’s say you’ve got a terminal open and you want to sort the contents of a file before you email it to a friend. The file can contain anything and it could be of any length, it doesn’t matter. What do you do?
The obvious answer is to use sort. Sorting the file is as easy as sort myfile – except it doesn’t actually sort the file, it sorts the *contents* of the file and dumps them to the command line (via stdout). So how do you sort the file “in-place,” so-to-speak? Again, the obvious answer would be sort myfile > myfile,1 redirecting the output of the sort command back to the file you want to ultimately send sorted.
Don’t do this! ↩
