Linux as IDE - jmadison222/knowledge GitHub Wiki

This article is written with an organizational lens. Think of a large company with hundreds, even thousands of developers. Individuals reading this article may also benefit. But the focus is on making the case for Linux-as-IDE in front of groups like Enterprise Architecture or Software Governance.

One of the ugliest cans of worms an organization can open with developers is dictating their personal productivity tools.

However, organizations gain efficiency from developers working on a reasonably consistent tool set, so some level of standardization is justified. But do as little as possible, then stop. Or get down to a multi-suite level then leave it at that, per the next point:

As I write this (2025), I work in an environment where VSCode, Jupyter Notebook, and Linux-as-IDE are all supported. I literally code with all three open and use Git as the communication vehicle to keep it all connected. The three tools all have strengths and weaknesses. I use all three for maximum productivity—​but by far the tool delivering the most power and speed is Linux-as-IDE, so let’s explore why…​

Linux serves two purposes:

1. An operating system - A place to connect networks, mount drives, run databases, and do infrastructure work in general.

2. A productivity environment - A place to leverage the infrastructure built in Purpose #1 to deliver business solutions.

Forget Purpose #1. This topic is about Purpose #2. For Purpose #2, the best reference I’ve found is "The Linux Command Line" by William Shotts:

It’s fantastic. If you want to use Linux as a productivity environment, you MUST get this book! If you think there is a better one; that works too; as long as it focuses on Linux for productivity, not just as an operating system.

As a productivity environment, I argue that Linux is effectively an Integrated Development Environment (IDE). Not that it has-a development environment, but that it is-a development environment.

To ask if something is an IDE, we start by asking what functions an IDE provides, then see if the environment in question provides those.

Opinions will vary, but the main functions of an IDE that I believe are germane are:

• Project navigation - Create a collection of files in a structure that behaves as a cohesive unit.

• Code editing - Modify files within the project.

• Code execution - Run the code in some type of execution environment.

• Code management - Handle the many changes of the code in a source control system.

• Extension provisioning - Extend the IDE to add functionality customized to your needs.

• Environment hooks - Call out to services like databases, storage networks, schedulers, etc.

• Lifecycle awareness - Move projects across environments like development, testing, QA, production, etc.

• Personal automation - Add your own functionality based on your personal way of working.

(Fun fact, when I was in the military, I got to see one of the last flights of the SR-71 out of Okinawa as the fleet was being retired. Most amazing bird ever made. Sigh. All good things must come to an end.)

Out of the box, Linux is a confusing mess. With the proper level of configuration and automation, its power emerges. Assume we’re talking about a Linux environment configured by a development architect with Linux savvy that is about a 8 on a scale of 1 to 10. Given that, the summary answer of how Linux-as-IDE delivers IDE functionality is:

• Project navigation - Tools like Ranger and directory bookmarking navigate very quickly.

• Code editing - - The vi editor turns your entire keyboard into commands.

• Code execution - The command prompt is literally the execution of Linux itself.

• Code management - The command line integrates directly with Git.

• Extension provisioning - Installing Linux packages makes them part of the system itself.

• Environment hooks - Nearly everything in the industry has a command line interface.

• Lifecycle awareness - Environmental variables and soft links keep everything loosely coupled.

• Personal automation - Your own Bash functions and scripts let you automate everything.

Each of these is expanded as its own section below.

Out of the box: Terrible! - By default, you get dropped off at a prompt and you have to do lots of typing.

With good configuration: Excellent. - There are many tools for high-speed directory navigation. The simple ones that almost always present are:

• Tab autocomplete - If you type the first few letters of what you need, then press tab, it will complete as much as it can. If you press tab twice, it will list all things that match what you’ve typed so far.

• The 'pushd' and 'popd' commands - TODO.

• The '!$' Alias - It is very common for the last token of the last command to be needed again in the current command. If you do 'wc foobar.txt' then 'cat !$', it will know you mean foobar.txt. This is very handy for complicated file names.

• The up arrow and 'history' command - TODO.

(Note that even by default, all of the above will work on most systems, so the command prompt isn’t quite that terrible. But I’m assuming the worst, in part because many of these basics are not known by new Linux users.)

• Ranger - Allows for full-screen navigation of files and directories. You move around directories with the arrow keys. You open files by pressing Enter. You can multi-select files and perform group operations on them. It is colorized to represent lots of information.

• My 'to' Command - I wrote this myself and open-sourced it. It bookmarks directories with aliases. Go to some long path, say "to set xyz", and it remembers that alias. Then do "to xyz" from anywhere and it goes back to that place. You can set multiple aliases per location. Disk space is the only limit to the number of bookmarks you can set.

• My 'b' Command - Where 'b' just stands for 'back'. It’s very common to need to do 'cd ..'. Instead I just type 'b' and Enter in rapid succession and it backs off. You can set up an alias for this easily with your own favorite letter. I have about a half dozen one-letter commands that move around like this. Imagine your own and make them.

Out of the box: Big learning curve.

With good configuration:

With great configuration:

Out of the box: Excellent! You’re at the Linux prompt. Linux is the execution platform of industry. You can’t get a shorter connection between you and power than this.

With good configuration:

Out of the box: Good.

With good configuration: Very good.

Out of the box: Tricky.

With good configuration:

Out of the box: Elegant, but some learning curve.

With good configuration:

Out of the box: N/a.

With good configuration: Fluid.

Out of the box: None. By definition.

With good configuration: All value here is rolled into the "good configuration" items above. This item doesn’t stand alone—​it makes stronger all the points above.

With great configuration: All value here is rolled into the "great configuration" items above. This item doesn’t stand alone—​it makes stronger all the points above.

With a career’s worth of configuration: Infinite. There is simply no end to how much you can automate Linux. The main reason for this is that you can compose Bash functions and scripts of other Bash functions and scripts you’ve written, so the sky is the limit.

Just one example; one of the slickest things I’ve ever written is a command prompt for S3 on AWS (not the most important or most powerful, just an amazing time saver). AWS S3 syntax is brutal. But for me, it behaves just like a Linux prompt. It does this because I wrote an s3 function that mapped AWS S3 commands to something more POSIX-like. But I also wrote a prompt function that wraps any other command of mine and adds things like showing dynamic information in the prompt and the ability to use the up arrow to recall commands. I put the prompt function around the s3 function and thus had an S3 prompt.

But there’s a lot going on, so I needed to colorize it, so I used the clr function that I wrote. This allows for things like showing the local Linux directory in one color and the S3 location in another color.

Further, I had written a cache function that remembers things. So I built that into my S3 prompt so that when I come back, it remembers my bucket and directory.

The cache command is used by dozens of other scripts of mine, and the clr command is used by even more to colorize everything I do. I’m at a point after 30 years on Linux that I can bang out new functions with slick functionality where much of what it does is just building on functions I’ve had stable for years.