pushd/popd vs. cd

My shell of choice and circumstance for most of my Linux life was Bash.  So, naturally, in my head, shell pretty much equals Bash, and I rarely think or get into situations when this is not true.  Recently, I was surprised by a script failure, which left me scratching my head.  The command that failed in the script was pushd.

pushd and popd, it turns out, are built into Bash, but they are not standard POSIX commands, so not all the shells have them.  My script wasn’t setting the shell explicitly, and end up executing with Dash, which I haven’t even heard of until this day.  The homepage of Dash says the following:

DASH is not Bash compatible, it’s the other way around.

Mkay… So, I’ve done two things:

  1. Set /bin/bash explicitly as my shell in the script.
  2. Switch to “cd folder && do something && cd –“, instead of pushd/popd combination, where possible.

I knew about “cd –” before, but it was interesting to learn if there are any particular differences (hint: there are) between the this approach and the pushd/popd one that I was using until now.  This StackOverflow thread (ok, ok, Unix StackExchange) was very helpful.

Things Every Hacker Once Knew

Eric Raymond goes over a few things every hacker once knew.

One fine day in January 2017 I was reminded of something I had half-noticed a few times over the previous decade. That is, younger hackers don’t know the bit structure of ASCII and the meaning of the odder control characters in it.

This is knowledge every fledgling hacker used to absorb through their pores. It’s nobody’s fault this changed; the obsolescence of hardware terminals and the near-obsolescence of the RS-232 protocol is what did it. Tools generate culture; sometimes, when a tool becomes obsolete, a bit of cultural commonality quietly evaporates. It can be difficult to notice that this has happened.

This document is a collection of facts about ASCII and related technologies, notably hardware terminals and RS-232 and modems. This is lore that was at one time near-universal and is no longer. It’s not likely to be directly useful today – until you trip over some piece of still-functioning technology where it’s relevant (like a GPS puck), or it makes sense of some old-fart war story. Even so, it’s good to know anyway, for cultural-literacy reasons.

The article goes over:

  • Hardware context
  • The strange afterlife of the outboard modem
  • 36-bit machines and the persistence of octal
  • RS232 and its discontents
  • UUCP, the forgotten pre-Internet
  • Terminal confusion
  • Key dates

Found via a couple of other interesting bits –
What we still use ASCII CR for today (on Unix) and
How Unix erases things when you type a backspace while entering text.

100 Favorite Programming, Computer and Science Books

Peteris Krumins, of the Browserling fame, has a series of blog posts on his top favorite programming, computer and science books.  It’s an excellent selection of titles, from which I’ve read only a fraction.  Good timing for the Christmas shopping too.  Here are the blog posts in the series so far (5 books per post):

Even with the 30 books mentioned so far, there are new things to read and learn.  I wonder how many of the notes to self I’ll have by the time the whole 100 are listed.

Things to learn about Linux

Julia Evans has this amazing list of things to learn about Linux.  I think, it doesn’t matter how new or experienced you are with the operating system, you’ll find a few points in this list that you either know nothing about or know very little.

Personally, I’ve been using and administrating Linux systems for almost two decades now, and my own knowledge of the things on that list is either very limited or not existing.  Sure, I know about pipes and signals, but even with basic things like permissions there are some tricky questions that I’m not sure I can get right on the first go.

Some of the topics mentioned are simple and straight-forward and will only need a few minutes or a couple of hours to get up to speed with.  Others – are huge areas which might take years, if not decades (like networking, for example).

I look forward to Julia’s drawings covering some of these.


Julia’s Drawings on Programming

Julia Evans, who blogs about her programming endeavors, now also draws simple, note-like sketches on a variety of the computer and programming related subjects.  Those are great as kick memory refreshers or reminders for “I wanted to learn more about that” kind of things.  Here’s her take on pipes, for example:


Worth an RSS subscription!

Vim 8.0 Released!

The team behind the greatest text editor of all times has release the new major version – Vim 8.0.  It’s the first major release in 10 years!  Brief overview of the changes:

  • Asynchronous I/O support, channels, JSON
  • Jobs
  • Timers
  • Partials, Lambdas and Closures
  • Packages
  • New style testing
  • Viminfo merged by timestamp
  • GTK+ 3 support
  • MS-Windows DirectX support

For a more complete list and details, have a look here.

The TL;DR summary: Vim provides a lot more power now to plugin developers, so we’ll be seeing a boost in both new functionality and old ways getting better.

Here is a mandatory Slashdot discussion with your usual Vim vs. Emacs flame.

P.S.: Emacs has recently released a major update too …

What is the shortest and most effective code ever written?

Quora runs the question, that by now has plenty of awesome answers.  But this one is my favorite so far:

The ‘true’ program in Unix from the 1970s was an empty file. The shell interpreted that as a shell script which ran and resulted in no error status, so the result was zero. Zero is the shell exit code value that represents ‘success’ or ‘true’ within if and while clauses.

So, no program can be shorter than that. And it was entirely effective at meeting its specification.

False was much longer, being

exit 1

Once lawers got in, both programs were sullied with plenty of copyrights. BSD also eventually established a format for identifying shell scripts explicitly, and those codes got added to the file too. Eventually, ‘true’ stretched to hundreds of bytes of copyrights on top of the shell script format intro code. Now, annoyingly, Linux and Mac OS have made it a compiled binary program. In Ubuntu, it is a 22K binary with an 18K code size. Ugh.

At least writing a correct C program for true can be very short. It is one of the few C programs that should require no #include files, and can be simply:

int main(void){return 0;}

Of course make sure to add lots of copyright notices.