Forem: J Edwards

Va Va Vim: Get Going With the Vim Text Editor

J Edwards — Sun, 03 Jan 2021 23:47:22 +0000

Introduction
Installation
Modes
Commands
Resources

What is Vim?

Vim (Vi IMproved) is an open-source text editor. It is a clone of vi and is designed for use both from a command-line interface (CLI) and as a standalone application in a graphical user interface (GUI).

The vi editor, the first screen-oriented text editor developed by Billy Joy in 1976, was created for Unix environments and built for text manipulation.

Based on his work for Stevie (ST Editor for VI Enthusiasts), Bram Moolenaar developed and publicly released Vim (v1.14) in 1991.

Initially, the name Vim was an acronym for "Vi IMitation", but that changed to "'Vi IMproved" in 1993.

Vim supports more features than vi, is very configurable, and enables efficient text editing.

Why Use Vim?

Vim and similar text editors are incredibly powerful. By learning it, you gain the ability to navigate and modify files expertly and efficiently.

According to cmd.com, most of their users use vi/Vim as their primary file editor, with the breakdown corresponding with following statistics:

vi/Vim: 93%
nano: 5%
Emacs: 2%

In Vim, all edits are saved, and you can load past revisions easily. If you make a mistake, you can look through the list of previous versions, and select the version that works best for you.

Vim's features include:

an extensive plugin system
integration with many tools
support for hundreds of programming languages and file formats
a powerful search and replace

Install Vim

To install Vim, enter the following command:

Ubuntu / Debian

$ sudo apt install vim

CentOS

$ sudo yum install vim

Fedora

$ sudo dnf install vim

After Vim is installed, you can open the editor by typing the following command in the terminal:

vi

This command opens the default page that displays the Vim version number.

Vim Modes

Vim is a modal text editor. Based on the vi editor, Vim inherits the key bindings of vi, but also adds more functionality and extensibility that is missing from the original vi text editor.

In Vim, the mode that the editor is in determines whether the alphanumeric keys will input characters or facilitate navigation throughout the document.

Vim has several different editing modes, but its basic modes are:

Normal mode

This mode is used for editor commands. This is usually designated as the default mode.

Visual mode

Similar to Normal mode, this mode is used to highlight areas of text. Normal commands run on the highlighted area, which can be used to move or edit a selection.

Insert mode

This mode is similar to editing in most editors. In Insert mode, you can input characters and modify files.

Cmdline mode

This is the command-line mode and supports a single line input at the bottom of the Vim window. Commands beginning with : activate this mode.

Vim Commands

All Vim commands can be carried out using the keyboard - although some can be executed through the command line, while others can be used as navigation keys. This allows you to keep your fingers on the keyboard and your eyes on the screen.

To learn more about the various commands and actions that can be used in Vim, use the help.txt file. It can be accessed in Vim with the F1 key or with the :help command.

In the meantime, here are a few basic commands to get started with:

Switching Between Modes
Navigation Keys
Basic Commands for Normal Mode
Basic Commands for Insert Mode
Executing in Command Mode
Search and Replace Command

Switch Modes

By default, Vim starts in Normal mode. Normal mode can be accessed from other modes by pressing Esc.

To switch Vim to Insert mode, press i.

Press v to enter Visual mode.

Navigation Keys

There are multiple ways to move around in an open file. In addition to using the cursor keys, you can use the keys in the table below to navigate through a file in Vim.

Key	Description
h	Left by one character
j	Down by one row
k	Up by one row
l	Right by one character
w	Move one word to the right
W	Move one word to the right past punctuation
b	Move one word to the left
B	Move one word to the left past punctuation
H	Move to the top of the current screen
M	Move to the middle of the current screen
L	Move to the bottom of the current screen

Row movement can be prefixed by a number to move several lines at a time.

Basic Normal Mode Commands

Command	Description
d	Delete the text that is selected
dk	Delete the current line and the line above it. d ↑ can also be used.
x	Delete only the current character under the cursor
cc	Delete the current line and change to Insert mode
yy	Copy the selected text
p	Paste the copied content
u	Undo the last edit. Press u again for further undos
U	Undo changes on the current line
Ctrlr	Redo a change undone by u

You can combine keys to specify movement. For example, dw deletes the first word on the right side of the cursor. It also copies the content, so that you can paste it to another location.

Basic Insert Mode Commands

Command	Description
`a`	Insert characters to the right of the cursor
`A`	Append characters to the current line
`i`	Insert characters to the left of cursor
`I`	Insert characters at the beginning of the current line
`o`	Add a new line after the current line
`O`	Insert a new line above the current line

Basic Command Mode Commands

Command	Description
`:q!`	Quit but do not save changes
`:w!`	Force save the file
`:wq`	Save the file and exit Vim
`:w`	Write out the file to save changes
`:w <file_name>`	Write the file to the specified file
`:r <file_name>`	Import a file into the current file

You can prefix commands with a number to couple navigation. For instance, :10 r <file_name> imports a file into the current file after line 10.

Search and Replace Command

To perform a basic search and replace function, use the following format in an editable mode:

%s/<search_term>/<replace_term>/g

This command replaces all instances of the search_term with the replace_term.

To breakdown the command:

: enters command mode
% means across all lines
s means to substitute

Optionally, you can use:

/foo is the regex (regular expression) to find things to replace
/bar/ is the regex to replace things with
/g means global, otherwise, the command will only execute once per line
c to confirm each replacement

Vim has a number of other methods that you can read about in the help documentation, by entering the command :h or :help.

For instance, if given the text file:

Hello world
You are my sunshine
In the world

When the command :%s/world/planet/g/c is executed, all instances of world are changed to planet. The new file will look like this:

Hello planet
You are my sunshine
In the planet

The c at the end of the command, prompts a confirmation message, and you will be asked if you want to proceed with the replacement.

Resources

Vim is a great, powerful, and very learnable tool. Becoming comfortable with the basics of Vim (or similar text editors) helps in becoming a more confident developer.

The are several amazing resources that can help you get better-acquainted and familiar with Vim. Check out the following links to learn more about using Vim as a text editor, as well as some of the available plugins that can be used with it.

Git Gremlin: Squash Commits (to Make Your Git History Cleaner)

J Edwards — Fri, 01 Jan 2021 23:50:46 +0000

Git is a free and open-source distributed version control system, designed to help developers handle small to large code changes with efficiency. But, with great ease comes great opportunity for screw-ups. It is quite easy (especially for beginners) to make a small mistake with Git that can have a seemingly catastrophic effect on overall work. Some Git mistakes are more intimidating and difficult to correct than others, but fear not! There is no need to panic — you can roll back a Git disaster with some help. For the infinite number of ways one can make an error with Git, Git Gremlin provides useful tips for what to do when things don't go as planned.

User Story
Scenario
Issue
Resolution
Prerequisites
Procedure

User Story

As an open-source contributor, I want to group the content of a pull request, so that the commit history is neater

Scenario

When working with Git, you may want to revise your local commit history and decide what files go into which commits.
You can rewrite commits so they appear as if they occurred in a different manner. This can involve changing the order of the commits, changing messages, modifying files in a commit, or removing commits entirely , before you share your work with other contributors who have access to the repository.

For example, after using git log to view the commit history, you notice some embarrassing commits on a feature branch, similar to this:

* ed88dab Correct configuration details
* dca37d5 typo
* 46e83b5 test
* e30e77d undo mistake
* 9409777 Add configuration details

You want to rework the history so that the output from git log looks more like this:

* ed88dab Add Test and correct configuration details
* 9409777 Add configuration details

What is the Issue?

How can you augment the commit history so that a series of N commits are presented in a single commit?

How to Resolve the Issue?

Squashing can be used to condense a large number of commits into a smaller number of more meaningful commits, in an effort to make the git history clearer.

Squashing in Git is a technique that employs rebasing to help consolidate a series of commits. You can use git rebase to combine a sequence of commits into a new base commit. When you use rebasing to rewrite history, you are automatically applying commits in your current working branch to the passed branch head.

By making the rebase interactive (adding the -i option to git rebase) you have the opportunity to alter individual commits.

git rebase --interactive (-i for short), opens an editor with a list of the commits which can be changed as well as a list of acceptable commands - allowing the user to edit the list before initiating the rebase action. In addition to squashing a commit, the user is also presented with the following options:

p, pick = use commit
r, reword = use commit, but edit the commit message
e, edit = use commit, but stop for amending
s, squash = use commit, but meld into previous commit
f, fixup = like “squash”, but discard this commit’s log message
x, exec = run command (the rest of the line) using shell
d, drop = remove commit

Prerequisites

A branch with a commit history.
You will need to use the terminal to execute commands.

Procedure

Use the following command to get the commit history:

git log

The output will reflect the commits on that branch, similar to the following:

* 617c65c Fix CRD group and minor updates
* 46e95a5 WIP additional work in progress
* e30e77d WIP work in progress
* 9409666 Adding the build script

There are WIP (Work in Progress) commits in the history that we can squash to make the Git history more concise. To interactively rebase the commits, we can use the following command:

git rebase -i HEAD~<n>

Alternatively, you can use the command
git rebase -i <after-this-commit-sha1>.

The -i flag in the command indicates that is an interactive rebase and the <n> represents the number of commits you want to go back in your history to rewrite.

In our example, we would like to rebase all commits proceeding the initial commit, and can use the following command:

git rebase -i HEAD~3

An interactive editor opens when the rebase process commences. The rebase command brings up an interface that presents the following options:

pick 617c65c Fix CRD group and minor updates
pick 46e95a5 WIP additional work in progress
pick e30e77d WIP work in progress

# Rebase 617c65c..e30e77d onto e30e77d (3 command(s))
# 
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.

#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

The editor displays the commits in reverse order starting from 3 commits back, which is defined by HEAD~3.

In the editor, replace pick (on all commit lines except the top line) with squash.

pick 617c65c Fix CRD group and minor updates
squash 46e95a5 WIP additional work in progress
squash e30e77d WIP work in progress

The squash command consolidates the three commits into the top commit.

Alternatively, you can use the fixup command and amend the commit message.

To save changes and exit the interactive editor, press Esc, enter : followed by x, and press Enter.

If you view the output of git log again, a single commit is displayed.

That's it! If you'd like to dive deeper, please check out more of the Git Gremlin posts. Also, the following resources are helpful for getting more comfortable with Git:

Git-SCM - Git reference documentation
Git Training - Official Git cheat sheets
Visual Git - A tool for exploring Git visually.
Git Game - A desktop application that helps you learn Git through fun challenges.

Thank you for checking out this post, and please git going!

Git Gremlin: Pull Request Fake Out (to Clean Up A Messy Pull Request)

J Edwards — Tue, 29 Dec 2020 18:00:00 +0000

User Story
Scenario
Issue
Resolution
Prerequisites
Procedure

User Story

As a developer who has created a flawed pull request, I want to seamlessly change the content of a pull request and augment its history, so that my initial mistake is not visible in the commit history

Scenario

You are a new contributor to a repository and have just submitted a pull request (PR) that must be reviewed and approved by a maintainer to be merged. You created the initial pull request, it was reviewed, comments were left, and you added some additional commits.

For whatever reason (maybe you accidentally pulled in additional commits during a rebase, or found an error in a commit you pushed to the PR) you want to completely change the content of the pull request, but do not want to close the pull request. You want to keep the history of the comments the maintainer left when reviewing your initial pull request, but also want to essentially rewrite the commit history and add entirely brand new content to the same pull request.

What is the Issue?

How do you completely change the history and content of a single pull request, without closing it? Let's look at the example below.

If the pull request looks like the following image:

How can you clean up the pull request, so it looks more like this?

How to Resolve the Issue?

There are actually a number of ways you can approach this issue, but the following solution will employ a branch renaming strategy to solve the problem.

For the solution, you are essentially faking the branching strategy. You will rename the original branch the pull request is on, create a new branch to add content to, and then rename the new branch with the original branch name. A bit confusing, but it's clarified in the steps below.

Prerequisites

To get started you should have the following:

A pull request you want to change/work on.
You should know which branch the pull request is being pushed into.
You will need to use the terminal and your text editor. This is solution does not use the GitHub UI.

For the procedure, the following is assumed:

You have forked and cloned the repository you plan to work on.
The remote branch is named origin.
The name of the branch the pull request is on is docs_restructure
The pull request is being pushed to the main branch (default branch).

Procedure

To start, check which branch you are on by using git status. You should see an output similar to the following after you enter the command:

$ git status
On branch docs_restructure

Rename the original (current) branch

$ git branch -M <ORIGINAL_BRANCH_NAME> <NEW_NAME>

For example, you should enter a command similar to the
following, if you're using docs_restructure as the original branch name:

$ git branch -M docs_restructure docs_change

After the branch has been renamed, you can verify the change has been applied by using git status.

$ git status

You should see an output similar to the following:

On branch docs_change

Switch to the default branch.

In most repositories, this branch is labeled either master, main, developer, or development. In any case, it should be the branch that the pull request is being pushed to.

$ git checkout main

You should see an output similar to the following:

Switched to branch 'main'
Your branch is up to date with 'origin/main'.

Now, create an entirely new branch. This new branch is where you can add the content you want to appear in the pull request.

$ git checkout -b <NEW_BRANCH>

Switched to a new branch 'improvement_branch'

Rename the new branch, so it has the original name of the branch the initial pull request was on.

$ git branch -M <NEW_BRANCH> <ORIGINAL_BRANCH_NAME>

For example, you can use the following command:

git branch -M improvement_branch docs_restructure

The branch is now named docs_restructure - the same as what you started with!

In the text editor of your choice, make the changes that you would like to see in the pull request and save the content.

Add the new content to the branch you are currently on.

$ git add .

Commit the changes. Be sure to leave a commit message that reflects the changes made.

$ git commit -m "restructure docs"

Push the changes to the branch.

$ git push <REMOTE_NAME> <ORIGINAL_BRANCH_NAME> --force

Following the examples used in this post, the command will look similar to the following:

$ git push origin docs_restructure --force

That's it! If you'd like to dive deeper, please check out more of the Git Gremlin posts. Also, the following resources are helpful for getting more comfortable with Git:

Git-SCM - Git reference documentation
Git Training - Official Git cheat sheets
Visual Git - A tool for exploring Git visually.
Git Game - A desktop application that helps you learn Git through fun challenges.

Thank you for checking out this post, and please git going!

Getting Started with Kubernetes: A Brief Introduction to Kubernetes Pod Security Policies

J Edwards — Sat, 05 Dec 2020 04:23:29 +0000

As a new user of Kubernetes, I want to understand how to create a pod security policy, so I can secure a Kubernetes cluster.

Kubernetes is a powerful container management and orchestration platform that automates many of the manual processes involved in deploying, managing, and scaling containerized applications. When using Kubernetes (or really any container-centric management platform), security must take a central role in the deployment of your applications and services.

Container security is the process of implementing security tools and policies that help you protect the infrastructure of your container and add the needed assurance that everything in your container is running as you intend.

Because containers encapsulate all their dependencies and automation has shifted security across the software development lifecycle, securing containers has become a prominent issue in container management. Manually creating and maintaining security rules for each entity is impractical, so integrating security into CI/CD workflows and implementing DevSecOps best practices provides incredible security advantages in the world of containers.

Kubernetes pod security policies provide an efficient way to enforce security settings across a cluster. You can use Pod Security Policies to keep Kubernetes and the containers running in it, secured.

Read on to find out more about Kubernetes pod security policies and the following:

What is a Pod?
Creating a Kubernetes Pod Security Policy
Understanding the structure of a Kubernetes Pod Security Policy
Example: Create a Kubernetes Pod Security Policy that Prevents the Creation of Privileged Pods
Verification
Delete the policy
The Takeaway

What is a Pod?

A pod is the basic (and smallest) building block of Kubernetes Objects. Within a cluster, a pod represents a process that is running. The inside of a pod can have one container or can have a co-located group of containers with shared resources, and specifications. Containers within a single pod share the following:

A unique network IP
Network credentials
Storage resources
Specifications applied to the pod that govern how the container should run

You can scale your application by adding or removing pods.

Now that we have introduced the concept of pods in Kubernetes, let's review how to craft a security policy.

Creating a Kubernetes Pod Security Policy

Pod security policies (PSP) are specified in YAML files. Note that YAML files are based on indentation with spaces, not with tabs.

NOTE: You can use .yml or .yaml extension for YAML files. Although the .yaml extension is recommended, many code bases and documentation use .yml.

The following is an example of a pod security policy YAML file:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  privileged: false
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - 'nfs'

The above PodSecurityPolicy implements the following security rules:

Disallows containers running in privileged mode.
Disallows containers that require root privileges
Disallows containers that access volumes apart from NFS volumes

Let’s take a closer look at the fields in a pod security policy.

Understanding the structure of a Kubernetes Pod Security Policy

The metadata section of the policy specifies the name and basic information.
The spec section of the policy outlines the key criteria a pod must fulfill in order to be allowed to run.

Required Fields

In the YAML file for the Kubernetes object you want to create, you'll need to set values for the following fields:

apiVersion - version of the Kubernetes API you're using to create this object
kind - kind of object you want to create
metadata - data that helps uniquely identify the object
spec - the state you desire for the object

Definitions of fields that you should understand to get started

privileged - indicates whether to allow containers that use privileged mode.
runAsUser - defines which users a container can run as. Most commonly, it is used to prevent pods from running as the root user.
seLinux- defines the Security-Enhanced Linux (SELinux) security context for containers and only allows containers that match that context.
supplementalGroups- defines which group IDs containers add.
fsGroup - defines the user groups or fsGroup-owned volumes that a container may access.
volumes - defines the type(s) of volumes a container may access.
hostPorts - together with related fields like hostNetwork, hostPID, and hostIPC, restrict the ports (and other networking capabilities) that a container may access on the host system.

To learn more about configuring these fields, please read the Kubernetes documentation.

Assumptions for Creating a Pod Security Policy

When a Kubernetes cluster is started with pod security policy support, Kubernetes follows a default-deny approach. This means that, by default, pods are not allowed to run unless they match the criteria outlined in a pod security policy. This also means that if your cluster does not have at least one pod security policy in place, not a single pod will run and Kubernetes will let you know that you should activate a pod security policy. You should see an error message that reads the following:

no providers available to validate pod request.

The Kubernetes API is intent-based. Each API call allows you to specify the desired-state for one of Kubernetes’ many objects. To send this desired state to Kubernetes, use kubectl, the CLI for running commands against Kubernetes clusters. Use kubectl to apply the YAML file to your Kubernetes' cluster.
You can use the following command to activate the newly created YAML file.

kubectl create -f <policy-name>.yaml

NOTE: <policy-name>.yaml denotes the policy file you created and plan to implement.

Prerequisites

You have a Kubernetes cluster running.

You have kubectl command-line tool installed.

You have enabled support for pod security policies. You can only use pod security policies if they are enabled in your Kubernetes cluster's admission controller.

You should have some knowledge of Kubernetes and how things work in your cluster. Use the Getting Started documentation as a resource.

To better explain how pod security policies work in practice, the following example walks you through creating a security policy.

Example: Create a Kubernetes Pod Security Policy that Prevents the Creation of Privileged Pods

In a Kubernetes pod, containers can optionally run in privileged mode, which means that the processes inside the container have almost unrestricted access to resources on the host system. Although there are some use cases where this level of access is necessary, in general, it’s a security risk to let your containers do this.

You can create a Kubernetes pod security policy that prevents the creation of privileged pods and controls access to volumes. To do this, create the YAML file that defines the specifications of your policy.

You can prevent privileged containers from running by including the following in your Kubernetes pod security policy:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name:no-privileged-containers
spec:
  privileged: false
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny  
  volumes:
  - '*'

In the file, you are preventing privileged pods with the line:

privileged: false

The following is also allowed in this pod security policy:

Allows any user to control SELinux within pods
Allows users to run container entry points only as a non-root user
Volumes support ownership management

Next, activate the policy by executing the following command, which creates the new policy from the file:

kubectl create -f no-privileged-containers.yaml

Check that the policy has been installed with the following command, which lists all active policies in the cluster:

kubectl get psp

You should see the policy listed, along with its specifications.

Verification

After you activate the policy, you should test it. Try running a container that contradicts the rules established in the policy. This provides a way to check that your specifications are in place and working.

In the no-privileged-containers.yaml, since the pod security policy explicitly disallows pods or containers with root privileges, a request to do the opposite should be rejected. You should see an error output similar to the following example when you check the pod's status.

If you enter the command:
kubectl get pods

The output, if unsuccessful, should be similar to:

 container has runAsNonRoot and image will run as root

Delete the Policy

You can delete the no-privileged-containers pod security policy with the following command:

kubectl delete psp no-privileged-containers

The Takeaway

In this article, we've looked at creating a pod security policy and addressed the various fields included in the YAML file of the policy. You should now be able to create, check the status, verify and delete a Kubernetes pod security policy.

Remember:

Pod security policy is a cluster-level resource that controls security sensitive aspects of the pod specification.
YAML files are pretty specific, but also quite easy to create.
If ever in doubt, check out the official Kubernetes documentation for helpful tips and examples.

So now...go forth and start securing your cluster.

Tackling the Terminal: Introduction to the Command Line

J Edwards — Tue, 20 Oct 2020 00:42:24 +0000

If you're new to Linux... start here.

Beginning your journey into the exciting world of Linux can be daunting (and at times a bit overwhelming). To get a good foothold on Linux and to start on your way towards being an active contributor, it is essential you understand the basics of the operating system. To become familiar with what's under the hood in your Linux OS, it is crucial you understand how to navigate its filesystem.

A computer’s filesystem organizes the data stored on a computer so that it can be easily retrieved by a user. Files are typically represented by a tree-like structure, in which any parent directory can have any number of children. The root directory is then found at the base of the tree.

The command line allows a user to navigate the Linux filesystem and run programs or custom scripts. In Linux, the command line interface is called Bash, and the shell prompt is usually $.

This article goes over the absolute basics of traversing the Linux filesystem.

Bash Background
Getting around the File Directory
- Print the Working Directory
- List Files
- Make a Directory
- Change the Directory
Manipulating the File Directory
- Remove Files
- Move Files
- Copy Files

Bash Background

The Bourne-Again Shell (Bash) was developed by the Free Software Foundation (FSF) under the GNU Project. Although Bash is the default user shell on most Linux installations, it is just one of several well-known UNIX shells. Still, its wide distribution with Linux makes it an important tool to learn.

The UNIX shell allows users to interact effectively with the system through the command-line interface (CLI). A shell action can invoke an executable that causes the kernel to create a new running process. The shell can send the output of one program as the input into another and facilitate interaction with the filesystem - so users can move around and make changes to files by using the command line.

Getting around the File Directory

Print Working Directory

pwd - The shell command pwd displays the file path from the root directory to the current working directory.

$ pwd
/Users/Downloads

List

ls - The shell command ls is used to list the contents of directories. If no arguments are given, it will list the contents of the current working directory.

$ ls Desktop
assignment.pdf
photo.png

Options can be used to modify the behavior of shell commands. Shell command options are commonly represented by a single letter preceded by a -.

List Command Options

-a: lists all contents, including hidden files and directories.
-l: lists all contents, in long format.
-t: lists all contents, by the time they were last modified.
-r: lists and the contents of the directory in reverse sorting order.
-R: lists the contents of all directories below the current directory recursively.
-S: sorts files by sizes.
Additionally, multiple options can be used together.

$ ls -a
$ ls -l
$ ls -t
$ ls -alt

Make Directory

mkdir - The shell command mkdir can be used to make a new directory in the filesystem according to its argument. If a file path is given, the new directory will be placed at the end. Otherwise, it will create a new directory in the current working directory with the name given.

$ mkdir new-directory
$ ls 
old-directory    new-directory

Change Directory

cd - The shell command cd can be used to navigate through the filesystem of a computer. You can use:
- Full file paths.
- Names of the children of the current directory.
- It's important to understand the characters that have special functionality in the Linux filesystem:
- The dot (.) represents the current directory in the filesystem.
- The dot-dot (..) represents one level above the current directory. It is the parent of the current directory.
- The forward-slash (/) represents the "root" of the filesystem. Every directory/file in the Linux filesystem is nested under the root/directory.
- The tilde (~) represents the home directory of the currently logged-in user.
- So, you can move to the filesystem’s root (/) with this command:

$ cd /

To navigate back to your home directory:

$ cd ~

Manipulating the File Directory

Remove

rm - The shell command rm is used to delete files and directories. The -r flag deletes a directory and all of its files and directories.

$ rm -r outdated_files

Move

mv - The shell command mv is used to move a file into a directory or to rename a file. Use mv with the source file as the first argument and the destination directory as the second argument.

$ mv index.html website/

You can use the mv command to rename a file or directory

mv old_name new_name
# The above command renames the file `old_name` to `new_name`.

mv ../old_name new_name
# The above command moves the file `old_name` from one directory up to the current directory and renames it `new_name`.

Copy

cp - The shell command cp is used to copy files or directories.

$ cp file1 file1_copy