Grep By Example is also available as a PDF Minibook, and a Grep playground helps you learn quickly.

Galvanize Your Grip On Grep With This Great Grep Guide

These days, you can’t throw a USB stick without hitting something that’s running Linux. It might be a phone, an embedded device, or your TV. Either way, it’s running Linux, and somewhere along the line of the development of whatever your USB stick smacked into, somebody used the Global Regular Expression Print utility- better known as Grep. But what is Grep, and why do you need it? [Anton Zhiyanov] not only answers those questions but provides Grep by example: Interactive Guide to help you along.

Grep By Example is also available as a PDF Minibook, and a Grep playground helps you learn quickly.
Grep By Example is also available as a PDF Minibook, and a Grep playground helps you learn quickly.

To understand Linux, one must understand its commercial predecessor, Unix. One of the things that made Unix (and then Linux) unique was its philosophy: Write programs that work together, do one thing well, and handle text streams.¬† This philosophy describes a huge number of programs, and one of these programs is Grep. It’s installed everywhere there’s a *nix installed, and once one becomes familiar with it, their command-line-fu reaches an all new level.

At its core, Grep is simply a bloodhound. It’s scent? A magical incantation called Regular Expressions. Regular Expressions (aka Regex) are simply a way of describing what a stream of text should look like. So when you feed Grep a bit of Regular Expression, it Prints¬†only the text that matches that expression. Neat, right?

The trouble is that Regex can be kind of hard, and Grep has various versions and capabilities that need to be learned. And this is where the article shines- it covers both in an excellent interactive tutorial that’ll help you become a Grep Guru in no time. And if you want to do a deeper dive, check out what it takes to make your own Regex Engine from scratch!

Running UNIX On A Nintendo Entertainment System

Who wouldn’t want to run a UNIX-like operating system on their NES or Famicom? Although there’s arguably no practical reason for doing so, [decrazyo] has cobbled together a working port of Little Unix (LUnix), which was originally written for the Commodore 64 and 128 by [Daniel Dallmann]. The impetus for this project was initially curiosity, but when [decrazyo] saw that someone had already written a UNIX-like OS for the 6502 processor, it seemed apparent that the NES was too similar to the C64 to not port it.

Much of this is relatively straightforward, as the 6502 MPU in the C64 is nearly identical to the Ricoh 2A03 in the NES, with the latter missing the binary-coded decimal support, which is not a crucial feature. The only significant roadblock was the lack of RAM in the NES. The console has a mere 2 KB of RAM and 2 KB of VRAM, which made it look anemic even next to the C64. Here, a Japan-only accessory came to the rescue: the Famicom Disk System (FDS), which is a proprietary floppy disk-based system that slots into the bottom of the Famicom and was used for games as well as storing saves back in the day.

By using a Famicom with FDS, it was possible to gain an additional 32 kB provided by the FDS, making the userspace utilities available in the shell. The fruits of this labor work well enough that he could also pop it up on an EverDrive cartridge that supports FDS ROMs and boot it up on an unmodified NES. Whether this is cooler than the NES-OS, which we covered previously, is up for debate.

Incidentally, [Maciej Witkowiak] seems to have resumed development on LUnix, with a new release in 2023, so maybe UNIX-on-6502 may see a revival after a few decades of little happening.

Continue reading “Running UNIX On A Nintendo Entertainment System”

Check Out This PDP-11 Running Unix With A Teletype Terminal

If you’ve spent a few years around Hackaday, you’ve probably seen or heard of the DEC PDP-11 before. It was one of the great machines of the minicomputer era, back when machines like the Apple ][ and the Commodore 64 weren’t even a gleam in their creator’s eyes. You’ve also probably heard of Unix, given that so many of us use Linux on the regular. Well, now you can see them both in action, as [HappyComputerGuy] fires up real Unix on a real PDP-11/73… with a real Teletype Model 33 to boot!

It’s a fascinating dive into the tech of yesteryear, with a rich dose of history to boot. It’s mindboggling to think that video terminals were once prohibitively expensive and that teletype printers were the norm for interacting with computers. The idea of interacting with a live machine via a printed page is alien, but it’s how things were done! We’re also treated to a lesson on how to boot the PDP-11 with 2.11BSD which is a hilariously manual process. It also takes a very long time. [HappyComputerGuy] then shows off the Teletype Model 33 rocking the banner command to great effect.

It’s awesome to see this hardware as it would really have been used back in its heyday. Computing really was different before the microcomputer format became mainstream. It’s not the only PDP-11 we’ve seen lately, either! Video after the break.

Continue reading “Check Out This PDP-11 Running Unix With A Teletype Terminal”

Apple System 7… On Solaris?

While the Unix operating systems Solaris and HP-UX are still in active development, they’re not particularly popular anymore and are mostly relegated to some enterprise and data center environments They did enjoy a peak of popularity in the 90s during the “wild west” era of windowed operating systems, though. This was a time when there were more than two mass-market operating systems commercially available, with many companies fighting for market share. This led to a number of efforts to get software written for one operating system to run on others, whether that was simply porting software directly or using some compatibility layer. Surprisingly enough it was possible in this era to run an entire instance of Mac System 7 within either of these two Unix operating systems, and this was an officially supported piece of Apple software.

The software was called the Macintosh Application Environment (MAE), and was an effort by Apple to bring Macintosh System 7 applications to various Unix-based operating systems, including Solaris and HP-UX. This was a time before Apple’s OS was Unix-compliant, and MAE provided a compatibility layer that translated Macintosh system calls and application programming interfaces (APIs) into the equivalent Unix calls, allowing Mac software to function within the Unix environments. [Lunduke] outlines a lot of the features of this in his post, including some of the details the “scaffolding” allowing the 68k processor to be emulated efficiently on the hardware of the time, the contents of the user manual, and even the memory management and layout.

What’s really jarring to anyone only familiar with Apple’s modern “walled garden” approach is that this is an Apple-supported compatibility layer for another system. At the time, though, they weren’t the technology giant they are today and had to play by a different set of rules to stay viable. Quite the opposite, in fact: they almost went out of business in the mid-90s, so having their software run on as many machines as possible would have been a perk at the time. While this era did have major issues with cross-platform compatibility, there was some software that attempted to solve these problems that are still in active development today.

Thanks to [Stephen] for the tip!

Illumos Gets A New C Compiler

Illumos is an OpenSolaris-derived Unix system, and no Unix is complete without a C compiler or two. And with a name like Portable C Compiler (PCC), you would think that would be a great bet to get up and running on Illumos. That’s probably what [Brian Callahan] thought, too, but found out otherwise.

PCC already generates x86 code, so that wasn’t the problem. It was a matter of reconfiguring the compiler for the environment, ironic since PCC probably started on true Unix but now won’t work with 64-bit Solaris-like operating system. According to the post:

It looks like some time ago someone added configuration for 32-bit x86 and SPARC64 support for the Solaris family. But no one ever tried to support 64-bit x86. So first we had to teach the configure script for both pcc and pcc-libs that 64-bit x86 Solaris

Continue reading “Illumos Gets A New C Compiler”

Suc Aims To Replace Slack In Five Lines Of Bash

The design philosophy of Unix is fairly straightforward. Software should do one thing as simply as possible, and do that one thing only. As a design principle this is sound advice even well outside of the realm of Unix, and indeed software in general, but that doesn’t stop modern software packages from being too large for their own good. So, if you’re tired of bloated chat programs like Slack or Mattermost with their millions of lines of code, you might instead favor something like Simple Unix Chat (suc).

The idea is that suc can perform almost all modern chat functions in only five lines of Bash, supporting rich-text chat, file sharing, access control, and encryption. These five lines, though, only perform the core function of suc — which is to write text to a file on the system. Indeed, suc makes liberal use of plenty of other Unix services which do not add to the line counts, such as the use of SSH to handle authentication. It also relies on some other common Unix system features to handle things like ownership and access for the text files that host the text for the chat.

As channels are simply text files, it makes writing bots or other tools exceptionally simple. You can also easily pipe the output of commands directly into suc with one-liners that can do things like dump the output of make into a specific channel if compilation fails.

While it’s not likely that everyone will ditch tools like Slack to switch to something like this, it’s still an impressive demonstration of what can be done when designing around the Unix philosophy and taking advantage of system tools that already exist rather than reinventing the wheel and re-programming all of those tools into the application. Practices like this might decrease development time and increase the ease of developing cross-platform applications but they often also produce a less than desirable user experience.

Is MINIX Dead? And Does It Matter?

Is MINIX dead? OSnews is sounding its death-knell, citing evidence from the operating system’s git log that its last updates happened as long ago as 2018. Given that the last news story on the MINIX website is from 2016 and the last release version, 3.3, came out in 2014, it appears they they may have a point. But perhaps it’s more appropriate to ask not whether or not MINIX is dead, but whether indeed it matters that the venerable OS appears no longer in development. It started as an example to teach OS theory before becoming popular in an era when there were no other inexpensive UNIX-like operating systems for 16-bit microcomputers, but given that its successors such as Linux-based operating systems have taken its torch and raced ahead, perhaps its day has passed.

No doubt many of you will now be about to point out that MINIX lives on unexpectedly baked into the management engine core on Intel microprocessors, and while there’s some debate as to whether that’s still the case, you may have a point. But the more important thing for us isn’t whether MINIX is still with us or even whether it’s a contender, but what it influenced and thus what it was responsible for. This is being written on a GNU/Linux operating system, which has its roots in [Linus Torvalds]’ desire to improve on… MINIX.

Read more about the tangled web of UNIX-like operating systems here.