We’ll start with basic message transmission. Then you'll progress to creating a file transfer system, and you’ll ultimately develop a secure chat application with encryption.

Here’s what we’ll cover:

• Prerequisites

• Install Netcat

• Your First Network Connection

• How to Build a Simple File Transfer Tool

• How to Create a Secure Chat System

• Conclusion

• Practice Your Skills

Prerequisites

Before we start, you'll need:

• A Linux-based system: I recommend Ubuntu. Alternatively, you can use the Online Linux Terminal if you don't have Linux installed.

• Basic terminal knowledge (how to use cd and ls)

Don't worry if you're new to networking - I’ll explain everything as we go!

Install Netcat

Netcat is like a digital "pipe" between computers – anything you put in one end comes out the other. Before we start using it, let's get it installed on your system.

Open your terminal and run these commands:

# Update your system's package list
sudo apt update

# Install Netcat
sudo apt install netcat -y

To check if the installation worked, run:

nc -h

You should see a message starting with "OpenBSD netcat". If you do, great! If not, try running the installation commands again.

Your First Network Connection

Before we dive into building tools, let's understand what a network connection actually is. Think of it like a phone call: one person needs to wait for the call (the listener), and another person needs to make the call (the connector).

In networking, we use "ports" to make these connections. You can think of ports like different phone lines – they let multiple conversations happen at the same time.

Let's try making our first connection:

1. Open a terminal window and create a listener:

nc -l 12345

What did we just do? The -l tells Netcat to "listen" for a connection, and 12345 is the port number we chose. Your terminal will look like it's frozen – that's normal! It's waiting for someone to connect.

2. Open another terminal window and connect to your listener:

nc localhost 12345

Here, localhost means "this computer" – we're connecting to ourselves for practice. If you want to connect to another computer, you can replace localhost with its IP address.

Now try typing a message (like "hi") in either window and press Enter. Cool, right? The message appears in the other window! This is exactly how basic network communication works.

To stop the connection, press Ctrl+C in both windows.

What Just Happened?

You just created your first network connection! The first terminal was like someone waiting by a phone, and the second terminal was like someone calling that phone. When they connected, they could send messages back and forth.

How to Build a Simple File Transfer Tool

Now that we understand basic connections, let's build something more useful: a tool to transfer files between computers.

First, let's create a test file to send:

# Create a file with some content
echo "This is my secret message" > secret.txt

To transfer this file, we'll need two terminals again, but this time we'll use them differently:

1. In the first terminal, set up the receiver:

nc -l 12345 > received_file.txt

This tells Netcat to:

• Listen for a connection (-l)

• Save whatever it receives to a file called received_file.txt (>)

2. In the second terminal, send the file:

nc localhost 12345 < secret.txt

The < tells Netcat to send the contents of our file.

3. Press Ctrl+C in both terminals to stop the transfer. Then check if it worked:

cat received_file.txt

You should see your message!

This is similar to our chat system, but instead of typing messages, we're:

1. Taking content from a file

2. Sending it through our network connection

3. Saving it to a new file on the other end

Think of it like sending a document through a fax machine!

How to Create a Secure Chat System

Our previous examples sent everything as plain text – anyone could read it if they intercepted the connection. Let's make something more secure by adding encryption.

First, let's understand what encryption does:

• It's like putting your message in a locked box

• Only someone with the right key can open it

• Even if someone sees the box, they can't read your message

We'll create two scripts: one for sending messages and one for receiving them.

1. Create the sender script:

nano secure_sender.sh

Copy this code into the file:

#!/bin/bash

echo "Secure Chat - Type your messages below"
echo "Press Ctrl+C to exit"

while true; do
  # Get the message
  read message

  # Encrypt and send it
  echo "$message" | openssl enc -aes-256-cbc -salt -base64 \
    -pbkdf2 -pass pass:chatpassword 2>/dev/null | \
    nc -N localhost 12345
done

This script will:

1. Read messages from user input.

2. Encrypt them using OpenSSL's AES-256-CBC encryption (a strong encryption standard).

3. Send the encrypted message to the specified port.

Press Ctrl+X, then Y, then Enter to save.

2. Create the receiver script:

nano secure_receiver.sh

Copy this code:

#!/bin/bash

echo "Waiting for messages..."

while true; do
  # Receive and decrypt messages
  nc -l 12345 | openssl enc -aes-256-cbc -d -salt -base64 \
    -pbkdf2 -pass pass:chatpassword 2>/dev/null
done

This script will:

1. Listen for incoming encrypted messages.

2. Decrypt them using the same encryption key.

3. Display the decrypted messages.

Save this file too.

3. Make both scripts executable:

chmod +x secure_sender.sh secure_receiver.sh

4. Try it out:

• In one terminal: ./secure_receiver.sh

• In another terminal: ./secure_sender.sh

Type a message in the sender terminal. The receiver will show your decrypted message!

Enhancing Our Chat System

Now that we have a working basic chat system, let's make it more user-friendly and informative. We'll add features like timestamps, color-coded messages, and encryption status updates. This enhanced version will help you better understand what's happening during the encryption and transmission process.

If you're comfortable with the basic version, try this improved version:

1. Create an enhanced sender script (save it as secure_sender_v2.sh):

#!/bin/bash

# Set up color codes for better visibility
GREEN='\033[0;32m'
BLUE='\033[0;34m'
NC='\033[0m' # No Color

echo -e "${GREEN}Secure Chat Sender - Started at $(date)${NC}"
echo -e "${BLUE}Type your messages below. Press Ctrl+C to exit${NC}"
echo "----------------------------------------"

while true; do
    # Show prompt with timestamp
    echo -ne "${GREEN}[$(date +%H:%M:%S)]${NC} Your message: "

    # Get the message
    read message

    # Skip if message is empty
    if [ -z "$message" ]; then
        continue
    fi

    # Add timestamp to message
    timestamped_message="[$(date +%H:%M:%S)] $message"

    # Show encryption status
    echo -e "${BLUE}Encrypting and sending message...${NC}"

    # Encrypt and send it, showing the encrypted form
    encrypted=$(echo "$timestamped_message" | openssl enc -aes-256-cbc -salt -base64 \
        -pbkdf2 -iter 10000 -pass pass:chatpassword 2>/dev/null)

    echo -e "${BLUE}Encrypted form:${NC} ${encrypted:0:50}..." # Show first 50 chars
    echo "$encrypted" | nc -N localhost 12345

    echo -e "${GREEN}Message sent successfully!${NC}"
    echo "----------------------------------------"
done

2. Create an enhanced receiver script (save as secure_receiver_v2.sh):

#!/bin/bash

# Set up color codes for better visibility
GREEN='\033[0;32m'
BLUE='\033[0;34m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

echo -e "${GREEN}Secure Chat Receiver - Started at $(date)${NC}"
echo -e "${BLUE}Waiting for messages... Press Ctrl+C to exit${NC}"
echo "----------------------------------------"

while true; do
    # Receive and show the encrypted message
    echo -e "${BLUE}Waiting for next message...${NC}"

    encrypted=$(nc -l 12345)

    # Skip if received nothing
    if [ -z "$encrypted" ]; then
        continue
    fi

    echo -e "${YELLOW}Received encrypted message:${NC} ${encrypted:0:50}..." # Show first 50 chars
    echo -e "${BLUE}Decrypting...${NC}"

    # Decrypt and display the message
    decrypted=$(echo "$encrypted" | openssl enc -aes-256-cbc -d -salt -base64 \
        -pbkdf2 -iter 10000 -pass pass:chatpassword 2>/dev/null)

    # Check if decryption was successful
    if [ $? -eq 0 ]; then
        echo -e "${GREEN}Decrypted message:${NC} $decrypted"
    else
        echo -e "\033[0;31mError: Failed to decrypt message${NC}"
    fi

    echo "----------------------------------------"
done

3. Make the enhanced scripts executable:

chmod +x secure_sender_v2.sh secure_receiver_v2.sh

Try running both versions to see how the additional feedback helps you better understand the encryption and communication process.

The enhanced version (v2) adds several improvements:

• Colorized output for better readability.

• Timestamps for each message.

• Status updates showing the encryption/decryption process.

• Error handling for failed decryption attempts.

• Preview of encrypted messages before sending/after receiving.

Conclusion

This tutorial taught you how to use Netcat as a versatile networking tool. We started with basic message sending, progressed to building a simple file transfer system, and then created a secure chat system with encryption.

You've gained hands-on experience with:

• Setting up network listeners and connections

• Transferring files securely between systems

• Implementing basic encryption for secure communication

• Adding user-friendly features like timestamps and status updates

The skills you've learned here form a solid foundation for understanding network communication and can be applied to more complex networking projects. To practice the operations from this tutorial, try the interactive hands-on lab.

Practice Your Skills

Now that you've learned the basics of Netcat and built a secure chat system, let's put your skills to the test with a real-world scenario. Try the "Receive Messages Using Netcat" lab challenge where you'll play the role of a junior interstellar communications analyst. Your mission: intercept and log signals from an alien civilization using your newfound Netcat knowledge.

Zsh shell offers four configuration files with no discernible differences. Particularly, ~/.zshrc and ~/.zprofile appear to be identical, leaving us wondering which one to use.

In this article, you'll learn the difference and a simple guideline for your shell configuration.

Why Do you Need Configuration?

For programming on a Mac, the Terminal application is an essential tool in your development environment. The Terminal is a command-line interface (CLI) that allows you to interact with the operating system and run commands.

The Terminal or console gives you access to the Unix command line, or shell.

Zsh, also known as Z shell, is a program that runs in the Terminal, interprets Unix commands, and interacts with the operating system. Zsh is the default shell program on MacOS.

Before you get started with programming on the Mac, you'll need to configure the shell. There are optional and convenient settings, such as aliases for hard-to-remember commands and a custom prompt that can display the directory you're in, among other things.

There are also some critical environment variables that make programs available or alter shell behavior. The EDITOR environment variable, for example, can set your preferred text editor. Oftentimes, when installing a programming language or software utilities, you need to set the PATH environment variable..

Where to Start

Zsh configuration files are kept in the user's home directory and are named with a dot as the first character to keep them hidden by default.

Zsh recognizes four different configuration files in the user's home directory: ~/.zshenv, ~/.zprofile, ~/.zshrc, and ~/.zlogin.

This is where Zsh configuration becomes puzzling, even for experienced developers. Tutorials rarely explain the differences, especially between the zprofile and zshrc files, leaving curious developers scratching their heads and blindly following instructions.

How is the Shell Used?

To understand the differences among Zsh configuration files, consider various shell uses, which can be classified as interactive or non-interactive, login or non-login sessions.

1. On macOS, each new terminal session is treated as a login shell, so opening any terminal window starts an interactive login session. Also, a system administrator who connects to a remote server via SSH initiates an interactive login session.
2. If a terminal window is already open and you run the command zsh to start a subshell, it will be interactive and non-login. Beginners rarely use subshells.
3. Automated shell scripts run without login or any user prompting. These are non-interactive and non-login.
4. Few people ever encounter a non-interactive login shell session. It requires starting a script with a special flag or piping output of a command into an SSH connection.

How do the Configuration Files Work?

These use cases necessitate different shell configurations, which explains why Zsh supports four different configuration files. Here's how the configuration files are used:

• ~/.zshenv: This is loaded universally for all types of shell sessions (interactive or non-interactive, login or non-login). It is the only configuration file that gets loaded for non-interactive and non-login scripts like cron jobs. However, macOS overrides this for PATH settings for interactive shells.
• ~/.zprofile: Loaded for login shells (both interactive and the rare non-interactive sessions). MacOS uses this to set up the shell for any new terminal window. Subshells that start within the terminal window inherit settings but don't load ~/.zprofile again.
• ~/.zshrc: Loaded only for interactive shell sessions. It is loaded whenever you open a new terminal window or launch a subshell from a terminal window.
• ~/.zlogin: Only used for login shell configurations, loaded after .zprofile. This is loaded whenever you open a new terminal window.

How to Use Each File

With that in mind, let's consider which configuration files you should use.

• ~/.zshenv: It is universally loaded, so you could use it to configure the shell for automated processes like cron jobs. However, it is best to explicitly set up environmental variables for automated processes in scripts and leave nothing to chance. As a beginner, you will not use this configuration file. In fact, few experienced macOS developers use it.
• ~/.zprofile: Homebrew recommends setting the PATH variable here. There's a reason PATH should be set in ~/.zprofile and not the universal ~/.zshenvfile: the macOS runs a utility path_helper (from /etc/zprofile) that sets the PATH order before ~/.zprofile is loaded.
• ~/.zshrc: This is the configuration file that most developers use. Use it to set aliases and a custom prompt for the terminal window. You can also use it to set the PATH (which many people do) but ~/.zprofile is preferred.
• ~/.zlogin: This is rarely used. Only important in managing the order of initialization tasks for login shells in complex environments. It can be used to display messages or system data.

How to Avoid Complications

These configurations may appear complicated. It made sense in the early days of computing to start time-consuming processes at login and not have them repeat when a new terminal was launched.

MacOS now launches any new terminal window as a login shell, loading both ~/.zprofile and ~/.zshrc files without concern for the shell startup time. So why not use one Zsh configuration file? A bow to history, plus configuration customization for the experts.

The key advantage of the ~/.zprofile file (versus ~/.zshenv) is that it sets environment variables such as PATH without override from macOS. The ~/.zshrc file could be used for the same but, by convention and design, is intended for customizing the look and feel of the interactive terminal.

Keep It Simple

If you're looking for simple guidelines, here's the current best practice.

• Use ~/.zprofile to set the PATH and EDITOR environment variables.
• Use ~/.zshrc for aliases and a custom prompt, tweaking the appearance and behavior of the terminal.
• If you write automated shell scripts, check and set environment variables in the script.

More Information

I've written other guides that go into detail about the following:

• Mac Terminal
• Shell Configuration
• Mac PATH.

If you're just getting started, you'll need to know How to Open Mac Terminal and Install Xcode Command Line Tools.

Configuring the Zsh shell is a critical step in preparing your Mac development environment. With your development environment set up, you'll be prepared for any tutorial you'll find on freeCodeCamp.

A computer is basically a piece of electronic circuitry that performs tasks as instructed by its users.

But for a human to interact with this hardware, they must really know and understand how it works. The person must also know the order in which to give the computer various tasks to produce a meaningful result.

But most of us don't know these things. What happened?

In this article, we're going to look at:

• The history of early computing

• How operating systems were developed

• Modern operating systems

• The development of kernels and shells

• The history of shells

• Why CLI tools are still important

The Early Days of Computers

In the 1800's, computers were mostly used to work on large amounts of numerical data. They were basically programmable calculators the size of small factories.

The data they worked on were also very physical. They were manually fed as punched cards into the machine's card readers. The computers were then programmed by physically rewiring cables, plugboards, and switches to determine what operations would be carried out on the input data. Some of the computers even processed logic through partially mechanical means.

Plugboards allowed you write (or wire) a program and store it so when you needed that program, you'd remove the current plugboard and install a new one. The output of the programs were printed out by line printers, saved on tapes, or punched on cards.

These programming and memory technologies were used in many forms of technological designs.

For example, the Enigma machine which was used to scramble letters and encipher top secret military and diplomatic communication had a plugboard you would rewire to change settings.

The IBM International Daily Dial Attendance Recorder also counted and recorded staff attendance on punched cards. These were more special-purpose equipment.

Early Operating Systems

The first-ever speech synthesis was done in 1962 on an IBM 704, a computer without an operating system.

At the time of the first computers, nobody ever thought of operating systems. People wrote their programs in machine language (or wired them on plugboards) and ran them. There was no way to run two programs at the same time or perform error detection/correction. Your program ran until it either crashed or completed.

IBM 704 computer with two operators in 1957

Initially, computers didn't ship with any software. Later on, IBM included FORTRAN and COBOL compilers in their mainframes. Then came 'resident monitors,' the precursor to operating systems. They literally got the name because they were software that resided in the company's memory and monitored tasks. They basically performed tasks like cleaning up after programs and helping to sequence jobs on the computers.

The first operating systems were made by computer owners who were tired of under-utilizing their computers. They didn't want to have to wait for a program to complete before they manually loaded in another set of data and programs.

One of these early operating systems was the Input/Output System of General Motors and North American Aviation (GM-NAA I/O). Its main aim was to execute the next program automatically after the current one was finished (batch processing). It was created in 1956, and is known as the first-ever working operating system.

IBM later modified one of its customer's operating systems and distributed it as IBSYS. Then, IBM thought that it wasn't good for different computers to have different (machine language) instruction sets, so they stopped all production and started a new line called System/360.

With this, they aimed to build just one operating system for all their computers. It didn't quite go as planned, so they ended up with a family of operating systems, OS/360.

OS/360 included features like time-sharing, error detection/correction, and device management, which are all features implemented in modern operating systems. The OS/360 was introduced in 1964 and was in use until 1977.

Early time-sharing technologies enabled multiple people to access the same mainframe from their different terminals at once. The first computer terminals were teletypewriters (or teletypes). Teletypes were developed around the 1830's but weren't used as computer terminals until the 1970's.

Modern Operating Systems

The MULTiplexed Information and Computing Service (MULTICS) operating system was initially developed for General Electric's 645 mainframe, and later Honeywell's mainframes when they bought over GE's computer division.

It was jointly developed in 1964 by GE, MIT, and Bell Labs, mainly as a successor to the Compatible Time-Sharing System (CTSS).

It came with a lot of new ideas to the computing world like access control, dynamic linking, support for ASCII, and dynamic reconfiguration.

Dynamic reconfiguration allowed the operators to remove and add memories and CPUs without logging out or disrupting users. With the advent of the Compatible Time-Sharing System (CTSS), computers were looked at as a utility.

The idea was that computers were too big and expensive and could be used by only one person at a time. But what if that expensive hardware could be used more efficiently by allowing more than one person to use them at the same time? That way, the computer could become a public utility, accessed from home with terminals.

With a public utility, you need to be able to carry out maintenance on different components without disrupting the service. That was the usefulness of dynamic reconfiguration.

That idea of computers becoming a public utility seems to have lived on with the use of servers, and now, cloud computing.

At a point, MULTICS didn't work out and the companies went their separate ways. Ken Thompson, one of the programmers, later described MULTICS as 'over-designed,' 'overbuilt,' and close to unusable. In an interview with Peter Seibel, he said that the things he liked enough to take from it were the hierarchical filesystem and the shell.

He later went on to create the UNIX operating system with Dennis Ritchie.

The Development of Kernels and Shells

One of the major features of the UNIX operating system was the splitting of the operating system into shell and kernel. The OS kernel was then meant to handle all the system calls, while the shell was used to access the system's services without exposing the inner workings of the operating system.

This concept was first introduced by French computer scientist Louis Pouzin in 1965. He also coined the term shell. This is how he described it in a document titled, The SHELL: A Global Tool for Calling and Chaining Procedures in the System.

We may envision a common procedure called automatically by the supervisor whenever a user types in some message at his console . . . we shall refer to that procedure as the "SHELL".

Louis Pouzin's Document on Shells

According to the document, when the user types in a command, the supervisor initiates a new stack to save the command, then calls the shell with the command as an argument.

He also envisioned a future where people created their own shells and used them without having to meddle with the underlying structure of the shell.

"An important facility is that the SHELL being itself a common procedure may be replaced by a private one supplied by the user. On that way, not only a particular procedure can be replaced on user's choice, but all conventions about typing commands may be tailor-made to user's wishes just by providing his own SHELL."

This idea was first implemented in MULTICS, and is one of the only things Ken Thompson admitted to liking enough to take from the project.

Now, in modern operating systems, the shell is the software that lets you communicate with the operating system, and access the OS services which are things like program execution, file management, and I/O management. It could be a command-line shell (CLI) or it could be a graphical user interface (GUI).

The kernel is the part that handles all the system calls, manages computer resources like memory, CPU, and storage, and handles timesharing between processes.

History of CLI Shells

Shells as we know them now really began with UNIX, and one of the first was the Thompson shell.

Thompson Shell (1971)

Ken Thompson, of course, went on to create his own shell. It was a simple command interpreter, not designed for scripting. It introduced the < > symbols for redirecting the input or output of a command, and the | symbol for piping.

C Shell (1978)

The C Shell (or csh) was created by Bill Joy and enabled scripting. The objective was to create a command language that looked more like the C programming language.

Bourne Shell (1979)

Stephen Bourne started work on the Bourne Shell in 1976 as a replacement for the Thompson Shell. It was intended as a scripting language. One of the major goals was to enable using scripts as filters.

Korn Shell (1983)

Developed by David Korn, the Korn Shell was based on source code from the Bourne Shell, and attempted to integrate the features of C Shell and Bourne Shell. It is POSIX.2 compliant.

Bourne Again SHell aka BASH (1989)

BASH was written by Brian Fox in 1989 and released under the GNU license as a free and open-source version of the Bourne Shell.

It was one of the first programs Linus Torvalds ported to Linux and is the default shell for most Linux distributions. It was built for scripting and is POSIX compliant.

Z Shell (1990)

The Z Shell (or Zsh) was created by Paul Falstad as an extended and improved Bourne Shell. The name was derived from the name of a teaching assistant at Paul's university named Zhong Shao.

It also enables scripting and is aesthetically superior to Bash. It supports plugins and extensions, auto-completion, and some other globing capabilities that are unavailable in Bash.

There are many other popular shells used today, but I'm not going to talk about them.

All these shells mentioned did not apply to Windows (until recently). Windows had two command-line shells: Command Prompt (cmd) and PowerShell. The PowerShell was created as an extension to Command Prompt. It supports cmdlets, scripting, piping, and many more features.

Then in 2019, that changed with Windows Terminal, a new terminal emulator for Windows that can run Bash on what is called Windows Subsystem for Linux (WSL). It also supports Command Prompt, PowerShell, and Azure Cloud shell out-of-the-box.

Why Are These CLI Tools Important When We Have Graphical User Interfaces (GUIs)?

You may wonder why we would take the pains to go through this whole evolution and yet still love to use CLI tools and shells. What's so interesting about typing commands into terminals?

The first and most compelling reason is that CLI tools are lightweight because they're text-based. In cases where you have servers and other devices where you need to optimize the use of resources, it's not very wise to use up most of the resources to run GUI interfaces.

Using the CLI can also provide you with a great deal of flexibility and speed that you won't get with a GUI. For example, you may want to search for all the images in a folder with 1000 files and rename them in a certain order. Doing that with your GUI will be time-consuming and maybe frustrating. With the CLI, you can just type a few commands.

Scripts are another important feature. Sometimes, there are tasks you want to carry out multiple times and you don't want to have to navigate through menus all the time or even type commands multiple times. You can write scripts that you run to automatically carry out the tasks repetitively.

In cases where you have to access devices remotely, like web servers or network devices, the CLI is also the most favoured method. Also, for some tasks, it's just easier to do them with a few commands than using your GUI—updating your apps on Linux for example.

Wrapping Up

We've really come a long way from purely mechanical computers to purely electronic computers. The way we interact with computers has changed over the decades, but command-line interfaces aren't going anywhere soon.

Thanks for reading. I hope you enjoyed this article. You can connect with me on LinkedIn.