DEV Community: Scott Robinson

Fast and Consistent Deployments with Terraform

Scott Robinson — Thu, 30 May 2024 22:33:44 +0000

Most types of internet-first businesses have become incredibly competitive. You're not just competing with people in your town, but everyone around the world. Because of this, the speed at which you can launch new products and features can be the difference between success and failure. This is why it is important to have a good infrastructure in place that allows you to not only launch fast, but update fast too.

In this article, I'll be giving a brief overview of Terraform and show you how I used it to launch my new monitoring tool, Ping Bot.

What is Terraform?

Terraform is an open-source infrastructure as code software tool created by HashiCorp. It lets you define and provision data center infrastructure using a declarative configuration language. Terraform manages external resources like public cloud infrastructure, private cloud infrastructure, network appliances, software as a service, platform as a service, DNS, and a whole lot more with a code.

Let's see a simple example:

provider "aws" {
  region = "us-west-2"
}

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

This code will create an EC2 instance in the us-west-2 region with the t2.micro instance type. You could do the same thing for most other cloud providers, like Azure, Google Cloud, and Digital Ocean.

For a single instance, Terraform doesn't give you much of an advantage. But when you add in all of the other resources and configurations, it becomes a powerful tool. Not just for the time-saving, but consistency and repeatability as well. If your service only uses a small number of resources, you might not see the benefits of Terraform.

There are 3 main reasons I decided to use Terraform:

Speed: I wanted to be able to launch my products as fast as possible. Terraform allowed me to quickly create all of the resources I needed in AWS. From servers to databases to S3 buckets, I could do it all with a single command.
Consistency: I wanted to make sure that my infrastructure was consistent across all of my environments. When you have dozens of resources, manually creating and configuring them can lead to mistakes. Terraform ensures that everything is created the same way every time.
Repeatability: I wanted to be able to easily recreate my infrastructure in case of a disaster. If something were to happen to my AWS account or I needed to transfer accounts, I could easily recreate everything.

Terraform Setup

Before we get ahead of ourselves, let's talk about setup. There are a ton of resources on installing and using Terraform, so in this article I'll mostly be talking about how I used it. This kind of setup is probably best for single-person projects or small teams. For larger teams, you might want to look into more advanced configurations and tooling.

If you're like me, you have a few different AWS accounts for different projects. Because of this, I've set up my different profiles in the ~/.aws/credentials file. This allows me to easily switch between accounts.

[default]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEY

[pingbot]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEY

I can then use this in my Terraform config to switch between AWS accounts, depending on which environtment I want to deploy to:

provider "aws" {
  region = "us-west-2"
  profile = "pingbot"
}

I also took advantage of Terraform's workspace feature. This allows you to have multiple environments, like dev, staging, and production, all in the same codebase. This is great because you can easily test changes in a safe environment before deploying to production.

Once I've created my workspaces with terraform workspace new [NAME], I can switch between them with terraform workspace select [NAME]. Then in my configuration code, I use the workspace throughout to create different resources based on the environment. This can be done using locals.

locals {
  ns = {
    dev   = "-dev"
    stage = "-stage"
    prod  = ""
  }

  instance_type = {
    dev   = "t2.micro"
    stage = "t2.medium"
    prod  = "t2.large"
  }
}

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = local.instance_type[terraform.workspace]
}

resource "aws_s3_bucket" "pingbot" {
  bucket = "pingbot${local.ns[terraform.workspace]}"
}

resource "aws_route53_record" "pingbot" {
  zone_id = aws_route53_zone.pingbot.zone_id
  name    = terraform.workspace == "prod" ? "pingbot.dev" : "${terraform.workspace}.pingbot.dev"
  type    = "A"
  ttl     = "300"
  records = [aws_instance.pingbot.public_ip]
}

Here I'm changing the instance size, S3 bucket name, and Route53 record based on the workspace.

Modules

One of the most powerful features of Terraform is modules. Modules are reusable Terraform configurations that can be called multiple times. This is great for creating reusable components that can be used multiple times in a project or shared across different projects.

For exampale, with Ping Bot I wanted to be able to monitor infrastructure for our customers from multiple locations around the world. Manually creating these resources in different AWS regions would've been tedious and error-prone. Instead, I created a module that would create the SQS queues and Lambdas in each location and installs the necessary software to run the pings.

module "ping_infra" {
  source = "./modules/ping_infra"

  locations = ["us-west-2", "us-east-1", "eu-west-1", "ap-southeast-1"]
}

Instead of taking an hour or two to set up ping infra in the Asia Pacific region, for example, I can do it in a few minutes with a single line change and terraform apply command.

A lot of teams are also pretty opinionated about how they want their infrastructure set up. By creating modules, you can create a standard way of doing things that everyone can use. This can help with onboarding new team members and make it easier to move between projects.

Cons of Terraform

While Terraform is a great tool, it's not without its downsides. Here are a few things to consider before using it:

Complexity: Terraform can be complex, especially when you start using modules and more advanced features. This can make it hard for new team members to get up to speed if your setup isn't well thought-out or you don't have someone who specifically owns the process.
State Management: Terraform uses a state file to keep track of the resources it creates. This file can get out of sync with your actual infrastructure if you're not careful. This can lead to some pretty bad situations if you're not careful. You'll often find yourself needing to migrate state as files change, which can be a huge pain.
Learning Curve: Terraform has a bit of a learning curve. While the basics are pretty easy to pick up, the more advanced features and edge cases can be confusing, especially for more junior developers. This can make it hard to get started if you're not already familiar with infrastructure as code tools.
Cost: Terraform can be expensive, especially if you're using it to manage a lot of resources. This isn't exactly Terraform's fault, but when your resources just become code, it's easy to lose track of what you're actually spending. This can lead to some pretty big bills if you're not careful. Self-funded startups, in particular, should be careful!

Conclusion

Terraform is a powerful tool that can help you launch faster and more consistently. By defining your infrastructure as code, you can easily create and manage resources across multiple environments. This can help you move faster and reduce the risk of mistakes. While it's definitely not perfect, it's a great tool to have in your toolbox if you're looking to launch fast and stay competitive.

Thoughts? Feedback? I'd love to hear from you - there are plenty of places to reach me.

Using to the Gmail API with Node.js

Scott Robinson — Wed, 16 Aug 2023 16:57:41 +0000

It's easy to think of a ton of reasons for wanting to connect to your Gmail account programmatically, whether it's to create a bot to send emails on your behalf, or maybe to create your own custom spam filter. There are also endless SaaS ideas for connecting to users' accounts and offering a service on top of Gmail.

Luckily, the Gmail API offers a nice way to manage a Gmail account. With Node.js, we can easily create applications that integrate directly with Gmail. In this article, I'll show how to set up a project, create a Gmail API client, and kickstart your journey with the Gmail API using Node.js.

Setting up the Project

Before diving into the code, let's first set up a new Node.js project. Make sure you have Node.js installed on your system, and then follow the steps below:

Create the project folder: Open your terminal and navigate to where you want your project to reside. Then create a new directory:

   $ mkdir gmail-api-project
   $ cd gmail-api-project

Create a new project: Run the following command and follow the prompts:

   $ npm init -y

The -y parameter tells npm to enter "yes" for all the questions during the init process. So basically, just use all of the defaults.

Install dependencies: We'll be using the googleapis package, so go ahead and install it:

   $ npm install googleapis

Note: Make sure your Node.js version is 10.x or higher, as the Gmail API client may not work correctly with older versions.

The project is now set up and we can move on to creating the actual Gmail API client.

Creating the Gmail API Client

The Gmail API client is the bridge between your code and Gmail. Here's how to create it:

Create credentials in Google Cloud Console: Go to the Google Cloud Console and create a project. Then navigate to "API & Services" > "Dashboard" > "Enable APIs and Services" > search for "Gmail API" and enable it. Now create credentials (OAuth client ID) and download the JSON file.
Load client libraries and credentials: In your project folder, create a new file index.js and add the following code to load the Gmail client libraries and your credentials:

   const {google} = require('googleapis');
   const credentials = require('./path/to/credentials.json');

   const auth = new google.auth.OAuth2(
     credentials.client_id,
     credentials.client_secret,
     'YOUR_REDIRECT_URL'
   );

Authorize the client: Your app will need to obtain an access token to authenticate with Gmail. You can use these tokens by using the following code snippet:

   // Load token or redirect to auth URL
   auth.setCredentials(tokens);

   // Create Gmail client
   const gmail = google.gmail({version: 'v1', auth});

Be sure to replace 'YOUR_REDIRECT_URL' with the redirect URL you've specified in the Google Cloud Console when creating your OAuth client ID!

Note: In order to obtain the access token, you'll need to set up a way to complete the OAuth flow, which can be done using a few different methods. One possible method to is create an HTTP route that accepts the OAuth credentials and data, but that is outside the scope of this article.

Retrieving Emails

Now that you've set up the Gmail API client, retrieving emails is the next step. Here's how to fetch the emails from your Gmail account with Node.js:

Use the list method: You can use the list method of the Gmail API to fetch emails. For example, let's fetch the last 10 emails:

   const res = await gmail.users.messages.list({
     userId: 'me',
     maxResults: 10
   });

   const messages = res.data.messages;

Get the details of each message: You'll need to call the get method for each message to get the full details:

   for (const message of messages) {
     const msg = await gmail.users.messages.get({
       userId: 'me',
       id: message.id
     });
     console.log(`Subject: ${msg.data.subject}`);
   }

Here, the list method returns a summary of the messages, so calling the get method for each one is needed to get the rest of the email data.

When creating blocksender.io, I found out the hard way that you'll need a lot of error checking, retries, etc when retrieving emails. The Gmail API often returns HTTP 500 statuses and has lots of edge cases. So make sure you test your applications thoroughly and handle as many potential issues as possible in your code.

Sending an Email

Now that we know how to fetch emails, let's learn how to send an email using the Gmail API.

Create the email content: First, we need to create the email body. You'll have to convert it to a Base64-encoded string:

   const emailLines = [
     'From: sender@example.com',
     'To: receiver@example.com',
     'Content-type: text/html;charset=iso-8859-1',
     'MIME-Version: 1.0',
     'Subject: Test Subject',
     '',
     'This is a test email'
   ];

   const email = emailLines.join('\r\n').trim();
   const base64Email = Buffer.from(email).toString('base64');

Use the send method: Now, you can use the send method to actually send the email via the API:

   await gmail.users.messages.send({
     userId: 'me',
     requestBody: {
       raw: base64Email
     }
   });

And there you have it, you've just sent an email using the Gmail API 👍

Python's os and subprocess Popen Commands

Scott Robinson — Thu, 18 Jun 2020 14:24:57 +0000

This article was originally posted on StackAbuse.com. Check it out for more articles, guides, and more. 👍

Python offers several options to run external processes and interact with the operating system. However, the methods are different for Python 2 and 3. Python 2 has several methods in the os module, which are now deprecated and replaced by the subprocess module, which is the preferred option in Python 3.

Throughout this article we'll talk about the various os and subprocess methods, how to use them, how they're different from each other, on what version of Python they should be used, and even how to convert the older commands to the newer ones.

Hopefully by the end of this article you'll have a better understanding of how to call external commands from Python code and which method you should use to do it.

First up is the older os.popen* methods.

The os.popen* Methods

The os module offers four different methods that allows us to interact with the operating system (just like you would with the command line) and create a pipe to other commands. These methods I'm referring to are: popen, popen2, popen3, and popen4, all of which are described in the following sections.

The goal of each of these methods is to be able to call other programs from your Python code. This could be calling another executable, like your own compiled C++ program, or a shell command like ls or mkdir.

os.popen

The os.popen method opens a pipe from a command. This pipe allows the command to send its output to another command. The output is an open file that can be accessed by other programs.

The syntax is as follows:

os.popen(command[, mode[, bufsize]])

Here the command parameter is what you'll be executing, and its output will be available via an open file. The argument mode defines whether or not this output file is readable ('r') or writable ('w'). Appending a 'b' to the mode will open the file in binary mode. Thus, for example "rb" will produce a readable binary file object.

In order to retrieve the exit code of the command executed, you must use the close() method of the file object.

The bufsize parameter tells popen how much data to buffer, and can assume one of the following values:

0 = unbuffered (default value)
1 = line buffered
N = approximate buffer size, when N > 0; and default value, when N < 0

This method is available for Unix and Windows platforms, and has been deprecated since Python version 2.6. If you're currently using this method and want to switch to the Python 3 version, here is the equivalent subprocess version for Python 3:

Method	Replaced by
`pipe = os.popen('cmd', 'r', bufsize)`	`pipe = Popen('cmd', shell=True, bufsize=bufsize, stdout=PIPE).stdout`
`pipe = os.popen('cmd', 'w', bufsize)`	`pipe = Popen('cmd', shell=True, bufsize=bufsize, stdin=PIPE).stdin`

The code below shows an example of how to use the os.popen method:

import os

p = os.popen('ls -la')
print(p.read())

The code above will ask the operating system to list all files in the current directory. The output of our method, which is stored in p, is an open file, which is read and printed in the last line of the code. The of this code (in the context of my current directory) result is as follows:

$ python popen_test.py 
total 32
drwxr-xr-x   7 scott  staff  238 Nov  9 09:13 .
drwxr-xr-x  29 scott  staff  986 Nov  9 09:08 ..
-rw-r--r--   1 scott  staff   52 Nov  9 09:13 popen2_test.py
-rw-r--r--   1 scott  staff   55 Nov  9 09:14 popen3_test.py
-rw-r--r--   1 scott  staff   53 Nov  9 09:14 popen4_test.py
-rw-r--r--   1 scott  staff   49 Nov  9 09:13 popen_test.py
-rw-r--r--   1 scott  staff    0 Nov  9 09:13 subprocess_popen_test.py

os.popen2

This method is very similar to the previous one. The main difference is what the method outputs. In this case it returns two file objects, one for the stdin and another file for the stdout.

The syntax is as follows:

popen2(cmd[, mode[, bufsize]])

These arguments have the same meaning as in the previous method, os.popen.

The popen2 method is available for both the Unix and Windows platforms. However, it is found only in Python 2. Again, if you want to use the subprocess version instead (shown in more detail below), use the following instead:

Method	Replaced by
`(child_stdin, child_stdout) = os.popen2('cmd', mode, bufsize)`	`p = Popen('cmd', shell=True, bufsize=bufsize, stdin=PIPE, stdout=PIPE, close_fds=True)` `(child_stdin, child_stdout) = (p.stdin, p.stdout)`

The code below shows an example on how to use this method:

import os

in, out = os.popen2('ls -la')
print(out.read())

This code will produce the same results as shown in the first code output above. The difference here is that the output of the popen2 method consists of two files. Thus, the 2nd line of code defines two variables: in and out. In the last line, we read the output file out and print it to the console.

os.popen3

This method is very similar to the previous ones. However, the difference is that the output of the command is a set of three files: stdin, stdout, and stderr.

The syntax is:

os.popen3(cmd[, mode[, bufsize]])

where the arguments cmd, mode, and bufsize have the same specifications as in the previous methods. The method is available for Unix and Windows platforms.

Note that this method has been deprecated and the Python documentation advises us to replace the popen3 method as follows:

Method	Replaced by
`(child_stdin, child_stdout, child_stderr) = os.popen3('cmd', mode, bufsize)`	`p = Popen('cmd', shell=True, bufsize=bufsize, stdin=PIPE, stdout=PIPE, stderr=PIPE, close_fds=True)` `(child_stdin, child_stdout, child_stderr) = (p.stdin, p.stdout, p.stderr)`

As in the previous examples, the code below will produce the same result as seen in our first example.

import os

in, out, err = os.popen3('ls -la')
print(out.read())

However, in this case, we have to define three files: stdin, stdout, and stderr. The list of files from our ls -la command is saved in the out file.

os.popen4

As you probably guessed, the os.popen4 method is similar to the previous methods. However, in this case, it returns only two files, one for the stdin, and another one for the stdout and the stderr.

This method is available for the Unix and Windows platforms and (surprise!) has also been deprecated since version 2.6. To replace it with the corresponding subprocess Popen call, do the following:

Method	Replaced by
`(child_stdin, child_stdout_and_stderr) = os.popen4('cmd', mode, bufsize)`	`p = Popen('cmd', shell=True, bufsize=bufsize, stdin=PIPE, stdout=PIPE, stderr=STDOUT, close_fds=True)` `(child_stdin, child_stdout_and_stderr) = (p.stdin, p.stdout)`

The following code will produce the same result as in the previous examples, which is shown in the first code output above.

import os

in, out = os.popen4('ls -la')
print(we.read())

As we can see from the code above, the method looks very similar to popen2. However, the out file in the program will show the combined results of both the stdout and the stderr streams.

Summary of differences

The differences between the different popen* commands all have to do with their output, which is summarized in the table below:

Method	Arguments
popen	stdout
popen2	stdin, stdout
popen3	stdin, stdout, stderr
popen4	stdin, stdout and stderr

In addition the popen2, popen3, and popen4 are only available in Python 2 but not in Python 3. Python 3 has available the popen method, but it is recommended to use the subprocess module instead, which we'll describe in more detail in the following section.

The susbprocess.Popen Method

The subprocess module was created with the intention of replacing several methods available in the os module, which were not considered to be very efficient. Within this module, we find the new Popen class.

The Python documentation recommends the use of Popen in advanced cases, when other methods such like subprocess.call cannot fulfill our needs. This method allows for the execution of a program as a child process. Because this is executed by the operating system as a separate process, the results are platform dependent.

The available parameters are as follows:

subprocess.Popen(args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0)

One main difference of Popen is that it is a class and not just a method. Thus, when we call subprocess.Popen, we're actually calling the constructor of the class Popen.

There are quite a few arguments in the constructor. The most important to understand is args, which contains the command for the process we want to run. It can be specified as a sequence of parameters (via an array) or as a single command string.

The second argument that is important to understand is shell, which is defaults to False. On Unix, when we need to run a command that belongs to the shell, like ls -la, we need to set shell=True.

For example, the following code will call the Unix command ls -la via a shell.

import subprocess
subprocess.Popen('ls -la', shell=True)

The results can be seen in the output below:

$ python subprocess_popen_test.py 
total 40
drwxr-xr-x   7 scott  staff  238 Nov  9 09:13 .
drwxr-xr-x  29 scott  staff  986 Nov  9 09:08 ..
-rw-r--r--   1 scott  staff   52 Nov  9 09:13 popen2_test.py
-rw-r--r--   1 scott  staff   55 Nov  9 09:14 popen3_test.py
-rw-r--r--   1 scott  staff   53 Nov  9 09:14 popen4_test.py
-rw-r--r--   1 scott  staff   49 Nov  9 09:13 popen_test.py
-rw-r--r--   1 scott  staff   56 Nov  9 09:16 subprocess_popen_test.py

Using the following example from a Windows machine, we can see the differences of using the shell parameter more easily. Here we're opening Microsoft Excel from the shell, or as an executable program. From the shell, it is just like if we were opening Excel from a command window.

The following code will open Excel from the shell (note that we have to specify shell=True):

import subprocess
subprocess.Popen("start excel", shell=True)

However, we can get the same results by calling the Excel executable. In this case we are not using the shell, so we leave it with its default value (False); but we have to specify the full path to the executable.

import subprocess
subprocess.Popen("C:\Program Files (x86)\Microsoft Office\Office15\excel.exe")

In addition, when we instantiate the Popen class, we have access to several useful methods:

Method	Description
`Popen.poll()`	Checks if the child process has terminated.
`Popen.wait()`	Wait for the child process to terminate.
`Popen.communicate()`	Allows to interact with the process.
`Popen.send_signal()`	Sends a signal to the child process.
`Popen.terminate()`	Stops the child process.
`Popen.kill()`	Kills a child process.

The full list can be found at the subprocess documentation. The most commonly used method here is communicate.

The communicate method allows us to read data from the standard input, and it also allows us to send data to the standard output. It returns a tuple defined as (stdoutdata, stderrdata).

For example, the following code will combine the Windows dir and sort commands.

import subprocess

p1 = subprocess.Popen('dir', shell=True, stdin=None, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
p2 = subprocess.Popen('sort /R', shell=True, stdin=p1.stdout)

p1.stdout.close()
out, err = p2.communicate()

In order to combine both commands, we create two subprocesses, one for the dir command and another for the sort command. Since we want to sort in reverse order, we add /R option to the sort call.

We define the stdout of process 1 as PIPE, which allows us to use the output of process 1 as the input for process 2. Then we need to close the stdout of process 1, so it can be used as input by process 2. The communication between process is achieved via the communicate method.

Running this from a Windows command shell produces the following:

> python subprocess_pipe_test.py
11/09/2019  08:52 PM                  234 subprocess_pipe_test.py
11/09/2019  07:13 PM                   99 subprocess_pipe_test2.py
11/09/2019  07:08 PM                   66 subprocess_pipe_test3.py
11/09/2019  07:01 PM                   56 subprocess_pipe_test4.py
11/09/2019  06:48 PM     <DIR>            ..
11/09/2019  06:48 PM     <DIR>            .
 Volume Serial Number is 2E4E-56A3
 Volume in drive D is ECA
 Directory of D:\MyPopen
               4 File(s)            455 bytes
               2 Dir(s)  18,634,326,016 bytes free

Wrapping up

The os methods presented a good option in the past, however, at present the subprocess module has several methods which are more powerful and efficient to use. Among the tools available is the Popen class, which can be used in more complex cases. This class also contains the communicate method, which helps us pipe together different commands for more complex functionality.

Thanks for reading! Check us out over at StackAbuse.com for more articles, guides, and other resources. You can also follow us @StackAbuse for new articles daily.

Zsh vs Bash

Scott Robinson — Tue, 09 Jun 2020 15:03:07 +0000

This article was originally posted on StackAbuse.com. Check it out for more articles, guides, and more. 👍

When we talk about Unix-based programming, it's usually about the shells, terminals, and the command line interfaces. The most prevalent shell in this regard is Bash but there are other variants available and used widely as well, like Zsh, or the Z shell.

In this article, we'll attempt to draw the line between the two shells and show the differences so you can get a sense of why you might use one or the other. But first, in the following sections we'll introduce both shells before we compare them together.

Z Shell

Zsh, or Z shell, was first released by Paul Falstad back in 1990 when he was still a student at Princeton University. Z shell is included in many operating systems, including Mac OS (although it isn't the default that's actually used).

Much like Bash, Z shell can basically be seen as an extended version of the Bourne shell, and does contain a lot of the same features as Bash, which you'll probably notice in the sections below. You may also notice that it pretty closely resembles the Korn shell as well. Some of the features that are worth mentioning include (but are not limited to):

File globbing
Spelling correction
Directory aliases (much like ~ or ..)
Loadable modules, like socket controls or an FTP client
Compatibility modes: e.g. You can use /bin/bash as a drop-in replacement for Bash
Startup/shutdown scripts via zshenv, zprofile, zshrc, zlogin, and zlogout
git command completion
Path expansion: e.g. Enter cd /u/lo/b, press tab, and it will be completed to cd /usr/local/bin since it is the only matching pattern

There are a lot more features than what we've shown here, but at least this gives you an idea as to how shells can be different.

Bash

The Bash shell (also known as the "Bourne-again shell") was also released around the same period as the Z shell (in 1989) and Brian Fox is regarded as the creator behind it. It was initially written as a replacement for the Bourne shell. For many years it has shipped as the default shell for GNU, most Linux distributions, and Mac OS X (version 10.3+). Like a true replacement should, Bash is capable of executing all of the Bourne shell commands without a problem.

There are quite a few features that the Bash shell has and some of the lesser-known ones include:

Insert the last parameter(s) of the preceding command in your current command using Alt + .
You can keep a process running even after logging out. To do so, use the command disown -h <pid> where you will have to place the process ID (PID) of the program instead of <pid>
Execute the previous command again, but this time running with sudo using the command sudo !! (!! is shorthand for 'the previous command')
Perform a reverse incremental search using the Ctrl + R keys
Press tab twice and you will see the list of completions for the word that you have just typed or are typing
When executing a script with bash, use the -x option to output the script contents as it's being executed

If you want to learn more, you can see a much larger list of Bash-specific features here.

Comparing Z shell and Bash

Now that we've give you a brief introduction to both of the shells, let's see how they hold up when actually compared and contrasted together.

The first thing to look at (and one of the more significant aspects, in my opinion) is prevalence and popularity of the shell. While the Z shell has its fair share of users throughout the developer community, it's usually safer to write your scripts for Bash since there is a much larger group of people that will be able to run those scripts.

The importance of adoption holds true for the public resources and documentation as well. Thanks to its large community, Bash has quite a few more resources out there to help you learn how to use it.

So, if you are planning on writing a script that you want many developers to easily be able to run then I'd recommend that you go with Bash. However, this shouldn't stop you from using Z shell if your end goal is more suited to Z shell. Finding the right solution to a problem is much more important than just using what's popular, so keep that in mind as well.

Although Bash is much more popular, that doesn't mean Z shell is without any useful features of its own. It's actually heavily praised for its interactive use, because it's more customizable than Bash. For example, the prompts are more flexible. It can display a prompt on the left and another on the right side of the screen, much like vim's split screen. The auto-completion is also more customizable and is actually faster than Bash's.

To give you a better sense of what kind of features Z shell has, here is a list of things that you will have access to when using Z shell over Bash:

The built-in zmv command can help you do massive file/directory renames. e.g. to append '.txt' to every file name run zmv –C '(*)(#q.)' '$1.txt'
The zcalc utility is a great command-line calculator which is a convenient way to do a quick calculation without leaving the terminal. Load it with autoload -Uz zcalc and run with zcalc
The zparseopts command is a one-liner that lets you to parse complex options that are provided to your script
The autopushd command helps you do popd after you use cd to go back to your previous directory
Floating point support (which Bash suprisingly does not have)
Support for hash data structures

There are also a bunch of features that are present in the Bash terminal but are absent from almost all of the other shells. Here are a few of them as well:

The –norc command-line option, which allows the user to proceed with the shell initialization without reading the bash.rc file
Using the option –rcfile <filename> with bash allows you to execute commands from the specified file
Excellent invocation features
Can be invoked with the sh command
Bash can be run in a specific POSIX mode. Use set –o posix to invoke the mode or --posix on startup
You can control the look of the prompt in Bash. Setting the PROMPT_COMMAND variable to one or more of the special characters will customize it for you
Bash can also be invoked as a restricted shell (with rbash or --restricted), which means certain commands/actions are no longer allowed, such as:
- Setting or unsetting the values of the SHELL, PATH, ENV, or BASH_ENV variables
- Redirecting output using the >, >|, <>, >&, &>, and >> redirection operators
- Parsing the value of SHELLOPTS from the shell environment at startup
- Using the exec builtin to replace the shell with another command.
- And many more...

It's difficult to say which shell is actually better. It all really depends on your own preferences and what you actually want to do with the shell. In the case of Bash vs Z shell, neither is really better than the other.

There are quite a few fans of the Z shell throughout the developer community who advocate for it quite heavily thanks to the many useful features it provides. On the other side, there are even more fans of Bash who know that their biggest advantage is their far larger user base. It's easy to see why it is so difficult to get developers to switch from Z shell to Bash and vice versa.

Thanks for reading! Check us out over at StackAbuse.com for more articles, guides, and other resources. You can also follow us @StackAbuse for new articles daily.