Introduction

Hello, and welcome back to CS631 Advanced Programming in the UNIX Environment. This is week 5, segment 1, and by now we've gotten around to writing a bit of code, tried to debug a few programs, and hopefully gotten the hang of this whole Unix development thing. But we want to ensure we use our systems as efficiently as possible, and software development obviously goes beyond just writing strange looking characters into a file and cursing that things don't work the way we want them to. So in this week, we'll cover a number of different tools that will make your life as a programmer infinitely easier. As so often, what we learn here can then also be applied in other contexts, and thus is not only tied to Unix- or C programming alone. What we cover here should be useful to you even if were using, say... Eclipse on Windows. Eclipse is one of the most popular Integrated Development Environments or IDEs used especially, but not only, by Java programmers. So what makes for a good IDE? It should probably offer at least an editor, which often times supports syntax highlighting of the programming language, automated indentation and other formatting tricks; an area where debugging output can be displayed; perhaps a file browser to load and organize the project's files; and maybe a place where documentation can be referenced All of this is intended to let you be more efficient when programming, and some IDEs include additional features like automated code completion, which recently GitHub has taken to the next level by providing an extension to Microsoft's Visual Studio IDE called "copilot", whereby an AI trained on the public code on GitHub can, supposedly, help you auto complete all sorts of code blocks. But of course as with so many things having to do with machine learning and AI, it doesn't quite work like magic, and all joking aside, there is at least the potential for interesting new complications and dilemmas derived from the concept of deriving code from other sources. And of course you have to think about what the input to the machine learning model was: writing code is hard, and writing _correct_ code at least doubly so, so it really shouldn't come as a surprise that code generated as a result of a large training set containing, likely, many vulnerabilities will _itself_ be vulnerable. But ok, let's leave the realm of SkyNet and the doom of humanity as a result from computers writing themselves -- where were we? Right, in the IDE. So Eclipse is an example of an IDE, but notice something? When you're writing code, what do you spend most of your time on? Thinking in code, writing code, reading code. But only roughly 30 % of your screen real estate here is available for your code, in this single large application. That is not much in line with the Unix philosophy as we discussed in our earlier videos, and I think it might be a bit nicer if your screen real estate could be used more efficiently, and give you more room for your code. In a normal Unix terminal, using a common Unix text editor, you get a lot fewer distractions. And of course, depending on what editor you use, you can also enable syntax highlighting and get code completion and all the other goodies as well, without sacrificing your concentration and screen space. But ok, you say, that's an _editor_, not an IDE, but I'm going to let you in on a little secret: The Unix Userland _is_ an IDE.

Unix as an IDE

The entire OS was designed and developed _as_ an integrated development environment. It provides all the independent component as individual tools that follow the Unix philosophy and do one thing but do that thing well. So to take advantage of this IDE, this _environment_, we combine our favorite editor -- and note: you have the choice of using any editor you like here, while in other IDEs the editor will be whatever the IDE provides; the compiler toolchain, consisting of (in our case, when writing C) the pre-processor, the compiler, the assembler, and the linker, all of which, again, can be replaced by other implementations; a debugger, to help you, well, debug and analyze your code and a code project build management tool like "make", allowing you to conditionally rebuild parts of your project tree based on what changed when you edited the different files. In addition to these, there also are software project management tools that allow you to collaborate with other developers, including the fundamental "patch" and "diff" tools as well as code revision control systems, such as CVS, SVN, or, nowadays near ubiquitously, git. All of these individual tools provide you with a rich development environment for any programming language, and since they are small and specifically scoped, they can be replaced with other tools if you so prefer, allowing for significant customization.

Demonstration

To give you just a quick taste of how these tools work together, let's look at a really simple example. Here we are opening at a single C file, a program we'll look at in more detail in a future lecture. Now while we are working on the code, we now want to compile the program, but we don't want to leave our editor or switch windows or have to click on any buttons, so instead we can use built-in commands that invoke "make" to build the project. In our case over here that's the execution of the single command invoking the compiler, but... oh no! There are errors! The compiler is being rather helpful here, indicating the file name, line and column number where the error occurred, where the function prototype in question is defined, and what else might have gone wrong. So now if we hit return, we are back in our source file, but the editor put the cursor directly on where the first error was, showing us down here the error output. Now we can use our editor's built-in shortcuts to pull up the manual page for the function under the cursor to refresh our memory of how the function should be called, and when we exit the manual page, we're right back here in the code. We can fix the first error by correcting the function argument, but remember, there were other error messages! Now instead of recompiling the code at this point, we can get a list of the errors displayed. The first error we just addressed, so now let's jump to the other error. There we are, syntax error, a missing semicolon. Once we add that, we write our file and then run 'make' again. And there we go: the compiler command is invoked and succeeds -- no errors. Now I know that this was (a) a really simple example and (b) probably still a bit quick, but don't worry: in the following video segments we'll show a few more details here. You also want to compare to what we previously showed in the tool tip video for the "ctags" command, as that complements our development environment nicely here.

Summary

Anyway, so as you can tell, your Unix system is itself a full Integrated Development Environment, and we'll cover each of the components shown here in this list in the next couple of videos. So stay tuned for the next video in this short series on tools that will absolutely make your life (well, your programming life, anyway) significantly easier -- if you invest the time to understand them. We'll start with the editor, where we'll discuss core functionality required of a decent programmer's editor by example of vi / vim, but that should translate to any other editor you might prefer. See you next time, and thanks for watching. Cheers!