To kick things off, let's take a look at a typical command line to clarify some lingo so we're all on the same page about what we call the different parts of a typical command.

<div className="mt-4">
```$ rm -f filename.txt```  
</div>

<div className="mt-4">
    The `$` is the so-called prompt followed by our actual command `rf`. The command has an option or flag `-f` followed by the argument `filename.txt`.
</div>

## The basics — How to navigate the terminal

Before we move onto advanced concepts, let's take a look at the basics, so we're able to navigate, perform basic file operations and have a good understanding of the fundamentals.

Just like the finder on MacOS, the explorer on Windows or Nautilus on Linux, the CLI can be used to navigate the filesystem. To see what's inside our current directory, we can use the `ls` command and will get a list of all files in our current working directory:

<Console>
    <div>$ ls -la</div>
<div className="text-gray-400">-rw-r--r-- 1 ben staff 1.1K Nov 3 10:15 .config</div>
<div className="text-gray-400">-rw-r--r-- 1 ben staff 1.5K Nov 3 10:45 README.md</div>
<div className="text-gray-400">drwxr-xr-x 3 ben staff 196B Nov 8 07:27 cache</div>
<div className="text-gray-400">drwxr-xr-x 9 ben staff 288B Nov 9 07:03 components</div>
<div className="text-gray-400">drwxr-xr-x 5 ben staff 160B Nov 9 08:14 content</div>
<div className="text-gray-400">drwxr-xr-x 4 ben staff 128B Nov 8 07:27 scripts</div>
<div className="text-gray-400">drwxr-xr-x 6 ben staff 192B Nov 9 07:03 src</div>
<div className="text-gray-400">drwxr-xr-x 3 ben staff 296B Nov 8 07:27 store</div>
</Console>

As you can see we passed the `-la` option, which are actually two parameters and they are `-l` to show an extended list and `-a` to show all files, including hidden files (starting with a dot).
The list option shows us a lot of info, like the permissions, file size and of course the file and folder names. It is generally a little easier to see all the files this way, than just using `ls`.
The permissions block on the very left also tells us whether we're looking at a file or folder, indicated by the `d` for directory on the very left.
   
## Changing directories

Now that we know where we are and where we can go, it's time to move around. The `cd <folder>` command allows us to 'change directory' to another, specified folder.
To stay with the example above, we could change into the `scripts` folder by issuing `cd scripts`. In many shells the prompt also indicates
the current directory we're in like `~/scripts $ ...` but additionally, if we want to check where we are, we can issue the `pwd` command to **p**rint the current **w**orking **d**irectory and see where exactly we are.

<Console>
    <div>$ pwd</div>
    <div className="text-gray-400">/Users/ben/dev/example-project</div>
</Console>

Because navigating can be a little tedious with longer paths, there are some shortcuts that can be used in combination with the `cd` command:
- The `..` parameter takes us up one folder in the directory tree (if available): `cd ..`
- The `~` parameter will take us to the currently logged in user's home directory: `cd ~`
- The dash parameter `-` will take us back to the last visited directory. This can be especially handy when juggling with long paths and needing to switch back to the previous directory.

## What if I'm stuck?
While the commands above should set you up for success when navigating the filesystem from the command line, it's easy to get lost and need help.
Luckily the command line comes with its very own **man**ual, called `man`. You can call the `man` command followed by any other command, like the `cd command` and it will
display a helpful manual with all the details, available parameters and more about the command. Here's an example:

<Console>
    <div>$ man cd</div>
    <div className="text-gray-400">SYNOPSIS</div>
    <div className="ml-4 text-gray-400">builtin [-options] [args ...]</div>
    <div className="text-gray-400">DESCRIPTION</div>
    <div className="ml-4 text-gray-400">Shell builtin commands are commands that can be executed within the running shell's
                process.  Note that, in the case of csh(1) builtin commands, the command is executed
                in a subshell if it occurs as any component of a pipeline except the last.</div>
</Console>

Introduction to the command line

like the MacOS finder is also possible on the command line. Indeed if we're looking to create multiple files or observe the last lines of a certain file — like a logfile — the terminal might be the better choice!

## Creating and reading files
To create a new file we can use the `touch` command followed by the filename we want to generate. Note that we also have to specify the 
file's extension. This also works if you're not looking to create a text file or anything else that can be easily handled from within the console, like an mp4.

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command">$ touch test.txt</div>        
    </div>
</Console>

A very handy advantage over most GUIs is the ability to create multiple files at once, using `touch` combined with filenames in curly braces (globbing). On top of that, we can use loops _(more on that in another chapter)_ 
to create a lot of files with the same naming patterns and such in just one short command.
<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command">$ touch &#123;a,b&#125;.txt</div>
        <div className="command">$ ls -l</div>
        <div className="text-gray-400">-rw-r--r--  1 ben  staff     0B Nov 10 19:24 a.txt</div>
        <div className="text-gray-400">-rw-r--r--  1 ben  staff     0B Nov 10 19:24 b.txt</div>
    </div>
</Console>

If we want to read files we have a lot of options to choose from. The command line gives us very powerful editors like `vi`, `vim`, and `nano` that can all
be used to read and write files. However, if we don't want to leave our prompt there is a way to print a file's content right to our terminal and that's `cat`.

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command">$ cat test.txt</div>
        <div className="text-gray-400">Here is the content of out test file, displayed directly on the cli.</div>
    </div>
    <div></div>
</Console>

When dealing with log files that can be especially large, we often want to look at only the last few lines of a file. Luckily the CLI allows us to do just that
easy as well, by using the `tail` command and passing the `-n` flag, specifying how many lines _from the bottom of the file_ we want to look at.

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command"> $tail -n 3 test.txt</div>
        <div className="text-gray-400">Lorem ipsum dolor sit amet, consetetur sadipscing elitr</div>
        <div className="text-gray-400">Sed diam nonumy eirmod tempor invidunt ut labore et dolore</div>
        <div className="text-gray-400">This is the last line of test.txt</div>
    </div>
</Console>

## Creating a directory
Similarly to creating a file, we can use the command line to create folders, using the `mkdir` command, followed by the new folder's name. You can also
add more folders, separated by a whitespace and they will all be created at the same time. No need to use braces here, like we needed when creating multiple files.

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command">$ mkdir my-new-folder</div>        
    </div>
</Console>

There is also a very handy option `-p` that will ensure that every other, not yet existing folder in a given _path_ is also created when issuing `mkdir`.
So in the following example the folders `parent`, `child`, and `grandchild` will be created, even if parent and / or child don't exist yet.

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command">$ mkdir -p parent/child/grandchild</div>        
    </div>
</Console>

Reading and creating files and folders

To move a file _or_ folder we can use the same command, called `mv`. It takes two arguments and it's also the command we need to issue when we want to
rename a file or folder. This sounds handy at first, but also means we have to be extra careful. Here's how you move a file or folder from the current directory into the `moved` folder

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command">$ mv ./folder ./moved/folder</div>
    </div>
    <div></div>
</Console>

Now as mentioned above, the same command is used to rename files and folders, so if we change its name in the destination (second argument) it will be moved *and* renamed, like below. This can be desired
but oftentimes it's not, so always double-check to make sure your files end up where you want them to be.

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command">$ mv ./folder ./moved/changed-folder-name</div>
    </div>
    <div></div>
</Console>

Sometimes we want to move all of the content of a folder and need to copy all sub-folders and files over as well — we want a recursive copy.
In order to achieve that with `mv`, we can provide the `-R` flag and use the wildcard operator `*` to recursively select *all files and folders* inside a directory

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command">$ mv source/* destination</div>
    </div>
    <div></div>
</Console>

## How to delete things on the command line
It's getting even more dangerous from here on out because the remove command `rm` not only lets us delete single files, but also takes arguments that let us *recursively* remove everything inside a folder.
Let's take a look at some examples, removing a single file or folder as well as removing multiple files by extension

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command">$ rm filename</div>
        <div className="command">$ rm -f foldername</div>
        <div className="command">$ rm *.txt</div>
    </div>
    <div></div>
</Console>

Notice the `-f` flag for deleting a folder? That's the _force_ option, which is required to remove folders and skip prompts 
Just like _recursively copying_ files and folders, we can also recursively remove everything inside a folder

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command">$ rm -rf foldername</div>
    </div>
    <div></div>
</Console>

## On being cautious when deleting things
A lot of developers have some kind of war story about almost or actually removing large parts of their filesystem because a `rm` command went wrong.
In order to prevent this — besides double checking your command — there is an option `-i` that makes your deletions interactive and prompts you for every file that it's going to delete.
While that's not feasible for large amounts of files, it can be very helpful when crafting more complicated patterns like below, where we're looking to delete every file that *starts* with the pattern 'trash_' and want to be extra careful to see if our command is correct.

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command">$ find . -name 'trash_*' -exec rm -i {} \;</div>
        <div className="output text-gray-400">remove ./trash_test.txt? n</div>
        <div className="output text-gray-400">remove ./trash_test2.txt? y</div>
    </div>
    <div></div>
</Console>
<small>More on how to use find and exec at a later point in this course</small>

Moving and deleting files and folders

Search is where it gets really interesting because we have so much power and things we can do *after* we've found a certain file.
Let's look at the basic operations first, finding a file by its name, a pattern or its type. Also remember, we can always use the wildcard operator, globbing, and all the other goodies the CLI allows us to use.

<Console >
    <div className="console-item-wrap">
        <div className="comment text-gray-600 ">// Finding an exact match</div>
        <div className="command">$ find ./ -name "file1.txt"</div>
        <div className="output text-gray-400">./file1.txt</div>
    </div>
    <div className="console-item-wrap mt-6">
        <div className="comment text-gray-600 ">// Finding a match by pattern</div>
        <div className="command">$ find ./ -name "*.txt"</div>
        <div className="output text-gray-400">./file1.txt</div>
        <div className="output text-gray-400">./file2.txt</div>
    </div>
    <div className="console-item-wrap mt-6">
        <div className="comment text-gray-600 ">// Finding a match by file type</div>
        <div className="command">$ find ./ -type d</div>
        <div className="output text-gray-400"><b>./files</b></div>
        <div className="output text-gray-400"><b>./src</b></div>
    </div>
</Console>

Note that the matches above are **case sensitive**, unless we pass the parameter `-iname` instead of `-name` where _i_ stands for case-insensitive.
We'll later look at `pipes` and other operators that allow us to do even more things with our results than just displaying them. For now though, let's
take a look at `grep`, one of the most powerful commands, which allows us to search the content of files and return a list of all files containing our search term or pattern.

## Searching for content inside files from the CLI

Let's say we want to find every occurrence of `weakMap` in our JavaScript files and we know there are a bunch of those occurrences in our current project.
We can utilize `grep` to look for all files containing the string `weakMap`

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="command">$ grep "weakMap" *.js</div>
        <div className="output text-gray-400">./weakMapPolyfill.js:weakMap()...</div>
        <div className="output text-gray-400">./main.js:somethgin.weakMap()</div>
    </div>
    <div></div>
</Console>

Depending on our shell, the output text-gray-400 will not be highlighted or provide otherwise helpful information, which is why it's good to know
a few flags that we can pass with grep that make our results a little easier to read and more useful, such as adding the line numbers of each match.

<Console buttons="false">
    <div className="console-item-wrap">
        <div className="comment text-gray-600 "># --color     (colorizes matches)</div>
        <div className="comment text-gray-600 "># -n          (show line numbers)</div>
        <div className="comment text-gray-600 "># -C &lt;number&gt; (show N lines above/below match for context)</div>
        <div className="command">$ grep --color -n -C 5 "weakMap" *.js</div>
    </div>
    <div></div>
</Console>

Finding files by name and content

Pipes ( `|` ) and redirections ( `>` / `>>`) are two of the most powerful features in bash and on the command line. They allow us to chain commands together, passing
data and outputs from on to the other and even into files. 
We've already covered the `ls` command, which lists the content of our current working directory. Now instead of printing the output of `ls` to the CLI,
we can use the pipe operator to put it right into a file. If the file doesn't exist yet, it will be created in the process.

<Console>
    <div className="console-item-wrap">
        <div className="command">$ ls > directory-listing.txt</div>
    </div>
    <div></div>
</Console>

Now all the output from `ls` is actually put inside `directory-listing.txt` and not displayed explicitly in the CLI. If we want to append to a file instead of overwriting its content (if it exists already),
we can use the appending redirect syntax `>>` like below

<Console>
    <div className="console-item-wrap">
        <div className="comment text-gray-600">// echo is simply printing a string to the cli</div>
        <div className="command">$ echo "appending this..." >> directory-listing.txt</div>
    </div>
    <div></div>
</Console>

## Redirecting a command's output with pipes
The pipe operator ( `|` ) allows us to use the output of one command as the input for another. A great example of that is combining any output
with the `sed` command, which allows many simple and complex text-based operations, such as replacing strings that match a regular expression.
In the following example, we're using the output of `ls -l` and pipe it into `sed`, which replaces all occurrences of the letters `a,e,i,o,u` with the letter `X`.

<Console>
    <div className="console-item-wrap">
        <div className="comment text-gray-600">// Usually, without sed's replace we'd get: </div>
        <div className="comment text-gray-600">// -rw-r--r--@ 1 ben  staff   7 Nov 11 20:13 test.txt</div>
        <div className="command">$ ls -l | sed -e "s/[aeiou]/X/g"</div>
        <div className="output text-gray-400">-rw-r--r--@ 1 bXn  stXff   7 NXv 11 20:13 tXst.txt</div>        
    </div>
    <div></div>
</Console>

It is worth noting that we can chain as many commands as we want or need to, so we could take the examples above and combine them into
one big chain that lists our current directory's files, replaces all letters `a,e,i,o,u` with `X` and immediately writes them to a file called `output.txt`.

<Console>
    <div className="console-item-wrap">
        <div className="command">$ ls -l | sed -e "s/[aeiou]/X/g" >> output.txt</div>
    </div>
    <div></div>
</Console>

The more shell commands we know, the more possibilities those operators open up to us.

Here's a great resource, covering those opertators in more depth: https://tldp.org/LDP/abs/html/io-redirection.html

Chaining commands with pipes and redirecting outputs

Itermediate cli usage

Similar to other languages, we can use conditions, loops, and other constructs when writing our scripts that help us solve more complex problems.
Every command that can be executed on the CLI, like `grep` and `ls`  we already learned about and even pipes and chaining, can also be used in bash scripts.

Declaring variables in bash is very straightforward, as we can simply assign a value to every not-reserved word like below.
To use our variable, we can prepend a `$` to the variable name.

<Console>
    <div className="console-item-wrap">
        <div className="command">$ number=10</div>
        <div className="command">$ number2=2</div>
        <div className="command">$ echo $number2<span className="comment text-gray-600"> # prints '2'</span></div>
    </div>
    <div></div>
</Console>

## If statements
To compare the just declared variable in a condition, we can use it like above and evaluate its value in an if statement like this:

<Console buttons={true}>
    <div className="console-item-wrap">
        <div className="output">if [[ $number == 10 ]]; then</div>
        <div className="output pl-4">echo expression evaluated as true</div>
        <div className="output">else</div>
        <div className="output pl-4">echo expression evaluated as false</div>
        <div className="output">fi</div>
    </div>
    <div className="console-iten-wrap">
        <div className="comment text-gray-600"># Example of an else if statement</div>
        <div className="output mb-3">number=11</div>
        <div className="output">if [[ $number -gt 10 ]];</div>
        <div className="output">then</div>
            <div className="output pl-4">echo "The number is greater than 10"</div>
        <div className="output">elif [[ $number -lt 10 ]];</div>
        <div className="output">then</div>
            <div className="output pl-4">echo "The number is less than 10"</div>
        <div className="output">else</div>
            <div className="output pl-4">echo "default condition"</div>
        <div className="output">fi</div>
    </div>
</Console>

## Basic loops

Whenever we want to run operations on multiple files, or just need multiple executions, we can make use of loops. Here are the three most commonly
used loops in Bash.

<Console buttons={true}>
    <div className="console-item-wrap">
        <div className="output">while [ condition ]</div>
        <div className="output">do</div>
        <div className="output pl-4">commands</div>
        <div className="output">done</div>
    </div>
    <div className="console-item-wrap">
        <div className="output">for (( i=i; i >= 5; i++))</div>
        <div className="output">do</div>
        <div className="output pl-4">echo -n "$i "</div>
        <div className="output">done</div>
    </div>
</Console>

Just like in other languages (and on the CLI) we can make use of conditional operators `||` as OR and `&&` as AND to evaluate
and chain conditions. 

## Functions and parameters
To structure our scripts a little more, let's take a look at bash functions. They help us with putting different
parts and tasks of our script into coherent blocks that can be invoked multiple times and with different arguments. Here's how a basic function looks like in bash

<Console>
    <div className="console-item-wrap">
        <span className="output">function say() &#123;</span><span className="comment text-gray-600"> # '<i>function</i>' is optional here</span><br/>
        <span className="output pl-4">echo "$1 world"</span><span className="comment text-gray-600"> # $1 is the first passed argument</span>
        <div className="output">&#125;</div>
        <span className="output mt-4 d-inline-block">output=$(say "hello")</span> <span className="comment text-gray-600"> # Assigning the output of say() to $output</span>
        <div className="output">echo "the greeting is $output"</div>
        <div className="comment mt-4"><i>>> Outputs 'hello world'</i></div>
    </div>
    <div></div>
</Console>

The example above shows us that we can execute functions or statements by calling /evaluating them like this `$(<function name>)` and we'll be able to receive the returned value.
Unlike other programming languages, bash doesn't have a real `return` statement, but functions instead return the status of the last executed statement inside the function.

If we don't need a return value however it is enough to simply call the function by its name. In the example above, simply calling `say` without any braces would output `' world'` because
we're not passing a parameter.

## Function arguments
As shown above, every argument we pass into a function can automatically be accessed by `$1`, `$2` ... `$n`, corresponding to the position of the parameter
in the function's invocation. There are a few extra variables that are automatically defined for us
- The variable `$0` is automatically assigned (reserved) the function’s name
- The variable `$#` automatically holds the number of passed parameters
- The variables `$*` and `$@` hold *all* passed parameters and can be iterated over

## Return statuses
As mentioned above there is no real `return` statement for functions, like we know from other languages. Instead, bash reserves the `return` keyword for what's commonly referred to as status codes or a function's exit status.
The return value of any function execution is automatically assigned to the variable `$?`, right after running the function or command.

<Console>
    <div className="console-item-wrap">
        <div className="output">say () &#123;</div>
        <div className="output pl-4">echo "random return text"</div>
        <div className="output pl-4">return 42</div>
        <div className="output">&#125;</div>
        <div className="output"></div>
        <div className="output d-inline-block mt-4">say</div><span className="comment text-gray-600"> # outputs 'random return text'</span><br/>
        <div className="output d-inline-block">echo $?</div><span className="comment text-gray-600"> # outputs 42</span>
    </div>
    <div></div>
</Console>

This  behavior is the same for any command we run, as they all have status/exit codes. So running a successful `ls` command would 
therefore assign `$?` the value `0` — It is defined that `0` is a successful execution and 1 - 255 are reserved for errors.

Bash scripting fundamentals

Just like all the commands we've used so far, we can create our own bash scripts that we can store and execute, without having to type all
the commands again. This is especially useful when moving into automation and repetitive tasks or to store commands that are very long and tedious to type or remember.
There are only three steps needed to create our first bash script:
- Create a file and make sure it's executable
- Tell the CLI the file is a bash script and should be interpreted as such
- The actual content of our script that will be executed

Let's start with the first two steps, so all that's left to do, is write our actual script. The first line simply puts the three-word `echo hello world` in our
file called `script.sh`, just like we've done before. The second line sets *user permissions* to allow the user `+u` to execute `+x` the file as a script.

<Console>
    <div className="console-item-wrap">
        <div className="command">$ echo "echo hello world" > script.sh</div>
        <div className="command">$ chmod u+x script.sh</div>
    </div>
    <div></div>
</Console>

Now the above would in most cases already be enough and we just wrote our first tiny bash script that we can execute by calling `./script.sh`. However, to tell the CLI that
it should be interpreted as a bash script, it's common practice (read necessary) to add a so-called <i>shebang</i> to the top of the file. Depending on the shebang, we
can even tell the terminal to interpret the file in a different language, such as JavaScript or PHP, and write our executable in that language!

<Console>
    <div className="console-item-wrap">
        <div className="command">$ #!/usr/bin/env bash <span className="comment text-gray-600"># bash</span></div>
        <div className="command">$ #!/usr/bin/env node <span className="comment text-gray-600"># node</span></div>
        <div className="command">$ #!/usr/bin/env php <span className="comment text-gray-600"># php</span></div>
    </div>
    <div></div>
</Console>

Now what's left to do is write the actual content of our script. Just like other languages, bash (and therefore the CLI) has
various primitives, loops, and conditions that we'll take a closer look at in the following chapter.

Creating and running bash scripts

Now that we know how to write and execute our own scripts, it's time to move into building out a little arsenal of tools that
we can re-use in different web projects. Most useful are scripts that can be universally applied, regardless of the frameworks
we use in our projects or that help us automate tasks that would otherwise be repetitive or time-consuming.

One great tool that doesn't come pre-installed is `jq` — it allows us to interact with JSON data by parsing it into
a bash array which we can then iterate over like we've done before when we looked at <Link href="/courses/command-line-for-web-developers/bash-scripting-fundamentals">basic loops</Link>.
In order to use `jq` on the command line or in our scripts, we first need to <a href="https://stedolan.github.io/jq/" target="_blank">install it from the official site</a>.

Once you have it installed, we can immediately use it in our scripts. Let's look at a basic example, where we provide the JSON data in form of a simple string.
We're piping the JSON string to `jq`, which filters out and returns the according value to the `name` property that we are looking for.
<Console>
    <div className="console-item-wrap">
        <div className="command">$ echo '&#123; "name": "Loki" &#125;' | jq '.name'</div>
        <div className="output text-gray-400">Loki</div>
    </div>
    <div></div>
</Console>

## Reading dependencies from a package.json file
Now that we have a basic understanding of how `jq` works, let's combine it with pipes and loops, like previously learned, so we're
able to loop over every single dependency in the `package.json`.

<Console>
    <div className="console-item-wrap">
        <div className="output">for dep in $(jq -r '.dependencies | keys | .[]' package.json); do</div>
        <div className="output ml-4">echo $dep</div>
        <div className="output">done</div>
    </div>
    <div></div>
</Console>

The `-r` flag tells `jq` to return raw output, which helps us deal with quotes in the JSON data and is especially useful when piping the output to other commands.
The built-in `keys` function returns all dependencies keys as an array, ordered alphabetically.

Now demonstrate how useful this little script can really become, let's try finding all dependencies that are not `import`ed in 
a modern JavaScript codebase, but installed according to our `package.json`. 

<Console>
    <div className="console-item-wrap">
        <div className="output">for dep in $(jq -r '.dependencies | keys | .[]' package.json); do</div>
        <div className="output mt-4 ml-2">if ! grep "from .*$dep.*" -Rq --exclude-dir="node_modules" ./src; then</div>
            <div className="output ml-4">echo "Likely unused: $dep"</div>
        <div className="output mb-4 ml-2">fi</div>
        <div className="output">done</div>
    </div>
    <div></div>
</Console>

We're using the simple loop we already used above but instead of just listing all dependencies, we're now utilizing `grep` to
search through all files in our `./src` directory. The pattern we're searching for in this case is `"from '<dependency>'"` like it's commonly used to import scripts in JS.

We're replacing `<dependency>` with the actual values (packages) from our `package.json` and can use the flags `-Rq` to make the command recursive and *quiet*,
so it only prints something to the console if the condition is met. the last flag allows us to exclude the `node_modules` folder
from our grep command, so we don't get any false positives by looking in there.

And just like that, we have a re-usable script that can tell us when a package was installed by not used anywhere in our codebase, so we can likely remove it,
which might lead to improved build times 🎉

Interacting with JSON data and package.json files

Similar to reducing build times by <Link href="/courses/command-line-for-web-developers/interacting-with-json-data">finding and removing unused packages</Link> from our `package.json`,
we can use bash to find other assets that are not used anywhere in our codebase and unnecessarily increase the repo size.

We're going to use the `find` command to create a list of all the assets we want to iterate over and check if they are used in our codebase.
Of course, this can be done for multiple formats and files, either separately or in the same list and iteration. To keep it simple here,
we're going to create a temporary file with all images (png and jpg) and use the `grep` command to check for any occurrences in our code.

<Console>
        <div className="output">#!/bin/bash</div>
        <div className="output mt-4">mkdir ./tmp</div>
        <div className="output">directory="./src"</div>
        <div className="output mt-4">find "$directory" -name *.jpg -exec basename {} \; > ./tmp/patterns.txt</div>
        <div className="output">find "$directory" -name *.png -exec basename {} \; > ./tmp/patterns.txt</div>
        <div className="output mt-4">for pattern in $(cat ./tmp/patterns.txt); do</div>
            <div className="output ml-4">grep -Rq $pattern "$directory" || echo $pattern;</div>
        <div className="output">done</div>
        <div className="output mt-4 d-inline-block">rm -rf ./tmp</div><span className="comment"> # optional</span>
</Console>

The real lookup happens inside our loop, which iterates over all the images we collected with `find`. We're giving
`grep` the `-Rq` flags to make it recursive and quiet, so it doesn't return any errors to the console and then pipe the outcome to `echo`.
The `||` pipe will only ever output the results of `grep` to `echo` when the left-hand statement throws an error, which in our case means `grep`
didn't find the pattern in any of the files it was looking through. Which also means, the image wasn't used anywhere in our code.

## Finding unused CSS selectors
Just like using a script to optimize our assets, it can be very beneficial to have a re-usable bash script that can help us find 
unused CSS in our projects and works the same across all projects. Let's take a look at how we can achieve this with the tools we've already learned about.

First, we need to get a list of *all* CSS selectors that have been declared across our codebase. We can use `grep` to go through
all `*.css` and `*.scss` files, looking for the pattern `^\s*\.`, which equals CSS classes — strings starting with a dot. We'll first write them into a temporary file,
before using a few `sed` operations to clean out the string, eg. remove curly braces, pseudo-selectors, dots, etc.


<Console>
<div className="output">#!/bin/bash</div>

<div className="output">grep -hr --include "*.css" --include "*.scss" "^\s*\." ./src > ./tmp/tmp.txt;</div>

<div className="comment text-gray-600 mt-4"># We're doing all kinds of operations with sed to clean our</div>

<div className="comment text-gray-600"># newly created list with all found class names</div>

<div className="output d-inline-block">sed -i -e 's/\/\/.*$&#47;&#47;' ./tmp/tmp.txt >/dev/null         <span className="comment text-gray-600"># remove comments</span></div>

<div className="output d-inline-block">sed -i -e 's/&#123;.*&#125;&#47;&#47;' ./tmp/tmp.txt >/dev/null            <span className="comment text-gray-600"># remove inline declarations</span></div>

<div className="output d-inline-block">sed -i -e 's/&#123;&#47;&#47;g' ./tmp/tmp.txt >/dev/null              <span className="comment text-gray-600"># remove open brackets</span></div>

<div className="output d-inline-block">sed -i -e 's/[,>+]\s*/\n/g' ./tmp/tmp.txt >/dev/null     <span className="comment text-gray-600"># split class names separated by , > +</span></div>

<div className="output d-inline-block">sed -i -e 's/ /\n/g' ./tmp/tmp.txt >/dev/null            <span className="comment text-gray-600"># split any children classes e.g. .class .children</span></div>

<div className="output d-inline-block">sed -i -e 's/\./\n./g' ./tmp/tmp.txt >/dev/null          <span className="comment text-gray-600"># split multiple selectors e.g. .aclass.active</span></div>

<div className="output d-inline-block">sed -i -e 's/^[^.].*$&#47;&#47;' ./tmp/tmp.txt >/dev/null        <span className="comment text-gray-600"># remove html tag selectors</span></div>

<div className="output d-inline-block">sed -i -e 's/[:]\&#123;1,2\&#125;.*$&#47;&#47;' ./tmp/tmp.txt >/dev/null   <span className="comment text-gray-600"># remove pseudo selectors e.g. :hover</span></div>

<div className="output d-inline-block">sed -i -e 's/[#].*$&#47;&#47;' ./tmp/tmp.txt >/dev/null          <span className="comment text-gray-600"># remove ids after classes e.g. .someclass#someid</span></div>

<div className="output d-inline-block">sed -i -e '/^$/d' ./tmp/tmp.txt >/dev/null                  <span className="comment text-gray-600"># remove empty lines</span></div>

<div className="output d-inline-block">sed -i -e 's/^\.&#47;&#47;' ./tmp/tmp.txt >/dev/null             <span className="comment text-gray-600"># remove starting dot</span></div>

<div className="output d-inline-block">sed -i -e 's/^[ \t]*&#47;&#47;;s/[ \t]*$&#47;&#47;' ./tmp/tmp.txt >/dev/null   <span className="comment text-gray-600"># remove whitespace from each line</span></div>

<div className="output d-inline-block mt-4">sort -u ./tmp/tmp.txt > all-classes.txt</div>

<div className="output">rm ./tmp/tmp.txt</div>

<div className="output mt-4">for pattern in $(cat ./all-classes.txt); do</div>

    <div className="output ml-4">grep -hrq --include \*.html  --include \*.jsx --include \*.js $pattern ./src || echo $pattern;</div>
    
<div className="output">done</div>
</Console>

We're passing the flags `-hr` to our initial `grep` and `-hrq` to the second `grep` to prevent it from printing out filenames or errors and
to make sure it's recursively looking through all sub-folders inside `./src`. Inside our loop, we include all `html`, `jsx` and `js` files to check 
for occurrences of the selectors in our list. Just like with finding images and assets above, we only print those CSS selectors that
grep can't find in our codebase, leading us to a list of all unused selectors.

*Keep in mind that this is a very naive and simple approach that might not find all nested or complex selectors, especially when dealing with SASS
and other preprocessors.*form

Finding unused assets and CSS

Bash scripting basics

While GUIs can take away a lot of complexity in our everyday tasks, they sometimes also hinder us from accomplishing tasks as efficient as possible. The command line interface (CLI) has been around since the very early days of computers and so have a lot of tools thaht run on it, which we can utilize to improve our development workflow.

In this course we'll go over the basics, such as navigating on the CLI, reading and creating files as well as using pipes and loops to create re-usable bash scripts.

The course is tailored for modern Unix / MacOS systems and syntax on Windows might vary. More lessons will be added as over time to cover more common CLI tools and advanced scripts.

Modern resources for well-rounded web developers.

allround

Fathom tracking

The Command Line for Web Developers

Besides the obvious utility of selecting elements with an exactly matching data attribute, there are a lot more things we can achieve with CSS attribute selectors.
In general, the attribute selector can target *any* attribute that's attached to an HTML element. By default, the selector is case sensitive and has a lower specificity than id's and classes.

Here's an attribute selector in its simplest form, selecting every anchor element that has an `href` attribute — regardless of the actual href URL:   

```css
a[href] {
    /* ... */
}
```

If we want it to be more specific about which `href` to target, we can explicitly pass the URL to the attribute selector like this

```css
a[href="https://specific-url.com"] {
    /* ... */
}
```

One of the latest <a href="https://www.w3.org/TR/selectors-4/#attribute-case" target="_blank">specs changes</a> introduced a new flag for attribute selectors, which allows us to make the matching case insensitive, by adding an `i` after our selector.
This is <a href="https://caniuse.com/?search=attribute%20case" target="_blank">fairly well supported</a> and works across all modern browsers, except IE11.
```css
a[href="https://specific-url.com" i] {
    /* matches <a href="https://SpEciFic-url.com"></a> ... */
}
```


## Special types of attribute selectors
Besides matching an attribute with an existing attribute or a specific value, we can use other types of attribute selectors to achieve partial matching on the
value of an attribute. These selectors can also be combined to match very specific elements.

### CSS attribute contains
Using the wildcard operator `*` we can match any element that has an attribute containing the given string in any form.
That means the example below would match the exact string `value` but also `something value something` as well as `somethingvaluesomething`.
```css
[data-attribute*="value"] {
  /* ... */
}
```


### CSS attribute starts with
If we want to look for an attribute whose value **starts** with a given string, we can use the `^` operator lie below.
In that case, we'd only match `value something` and `valuesomething` but not `something value`.
```css
[data-attribute^="value"] {
  /* ... */
}
```

### CSS attribute ends with
Conversely to looking for matched at the start, we can also look at the very end of an attribute's value by useing the `$` operator.
We'd match `something value` but not `value something`. This is especially interesting because we know that files always have a certain extension and by passing
the full name into a data-attribute, we'd be able to match elemenets that represent PDF documents like this `a[href$="pdf"]`.
```css
[data-attribute$="value"] {
  /* ... */
}
```

### CSS attribute is in space-separated or dash-separated lists
There are two selectors that allow us to specifically look for matches inside lists, where one is only matching when the value is dash-separated `|` and the other operator
matches everything inside a space-separated list `~`. Especially the space separation can also be achieved with other operators mentioned above.

```css

[data-attribute~="value"] {
  /* matches eg. <li data-years="thor value loki">...</li> */
}

[data-attribute|="value"] {
  /* matches eg. <li data-years="value-2021">...</li> */
}
```

## Combining attribute selectors
Of course, we can also use multiple attribute selectors simultaneously to select specific elements. This can be especially handy when the HTML
provides us with enough info to create different styles only through our attributes. Let's say we want to give icons to every file download link
on a site and a special icon to PDFs. We can combine the contains and ends with selectors to select all files and then specifically find all PDFs.

```css
a[href*="/downloads"] {
    /* file is in /downloads directory */
}

a[href*="/downloads"][href$="pdf"] {
    /* file is in /downloads directory */
    /* AND ends with pdf */
}
```

## Negating the attribute selector with :not
All the attribute selectors above can also be combined with the CSS `:not` selector, so we could also take our example above and find all files
that are inside the downloads directory but are specifically *not* PDF files.
```css
a[href*="/downloads"]:not([href$="pdf"]) {
    /* file is in /downloads directory */
    /* AND ends NOT with pdf */
}
```

## Using attribute selectors in Javascript
Just like using regular class and id selectors, we can also utilize all of the above selectors when writing JavaScript to select DOM elements.
```javascript
let team = document.querySelector('img[src*="team"]');
```


Advanced CSS attribute selectors

As developers, we often use a lot of libraries and packages and know very well how to use them.. We're used to it, because packages and libraries are a huge part of the ecosystem and a great way to speed up development and free us from rather complicated, repetitive tasks.

When it comes to writing libraries or reusable modules from scratch, however, it's not always so clear where to start and how to make sure our libraries are not breaking anything else in an application. Making sure we're using our own scope, function names and such are only part of what makes a good module. Let's take a close look at how to write our own libraries that can be plugged into different projects without worrying about breaking any existing code.

When we're  the developer who's using a library, we care about simplicity and ideally want to understand what's going on by the name of the function we're calling alone. We're also very used to a certain kind of syntax, which probably looks something like this:

```javascript
Library.init({
	option: "option"
})

Library.doThing(arg1, arg2);

```
   
We can initialize our library with some options and then just call pre-defined and hopefully well-documented functions on the library, possibly passing in some arguments. Sometimes we'll get a return value or promise out of that function call, other times there might be a change in the DOM as a result of calling the function. Either way, we're very used to that kind of syntax when using libraries and so when writing our own we should try to imitate that.

The object literal notation in JavaScript lets us do just that. It also has the added benefit of keeping everything inside our object and therefore we're not putting anything related to our module on the global scope, except the object itself.

```javascript
var Module = {
	// Our Object literal can hold simple variables
  someProperty: "someValue",
	
	// We can also declare further objects inside our object
  config: {
    reload: true,
    language: "en"
  },

	// And of course declare regular, named functions
  saySomething: function (word) {
    console.log(word);
  }
};

Module.say("hi");
```

## The module pattern

We can take the object literal approach one step further with the module pattern, which allows us to declare public and private functions and variables, using closures. We're basically defining a public API that our library/module exposes while keeping other internal states, variables, and functions private and thereby inaccessible from the outside.

```css
var Module = (function() {

  let secret = 0;
	let publicNumber = 2;

  function privateFunc(a) {
    console.log(a);
  }

	function addOne(b) {
		return b + 1;
	}

  return {
		addOne: addOne,
		publicNumber: publicNumber
  }

})()

Module.addOne(Module.publicNumber);
```

As shown above we can now explicitly define what functions and variables should be accessible from the outside by returning an object with only those things that we want the outside to know about. This is great because we can hide away a lot of the heavy lifting or things we don't want to expose because calling them directly would break things. We're basically exposing a little API that is consistent and well structured.

While this pattern is great for frontend libraries and modules, it is also super convenient when writing modules in node. In fact most modules naturally follow this pattern in a way, because they have a (default) export statement. Here's how we can utilize the same structure in node

```javascript
import db from '../models/index.js'

const MessageController = {
    sendMessage: async function(message) {
				// ...
		}
        
    receiveMessage: async function(message) {
        // ...
    },
}

export default MessageController
```

That way we get to keep the clean structure of our object literal / module pattern while being able to just import our module like we would with other modules. We also get to chosse what to export explicitly while we can keep other functions private. Here's how we'd import the above module in node:

```javascript
import MessageController from './controllers/message-controller.js';
```   

Overall we get a lot of benefits when writing our modules that way, such as high reusability, a clear structure, no naming collision with the outside, control over private/public parts of our module and even a shared but encapsulated state for things inside our object literal.

Writing reusable modules and libraries in JavaScript

Most folks know about the `box-shadow` property and use it a lot already in their CSS, however there are certain scenarios where a box-shadow doesn't give us ideal results. There is however also a CSS filter called `drop-shadow` that let's us do some cool things we cannot achieve with box-shadows. It's currently supported in all modern browsers and definitely worth a look. Here's how a drop-shadow looks like in CSS:

```css
.selector {
  filter: drop-shadow(0 10px 12px rgba(0, 0, 0, 0.4));
}
```

## What's the use case?

While box-shadows are sufficient in most scenarios, they can only give us a shadow around the exact shape of an element, which is usually angular or round due to a `border-radius`. With drop-shadows however, we can cast a shadow around elements and even images that stays in direct proximity to the non-transparent parts of the image or element.

So in essence this works on regular HTML elements, SVGs and also transparent PNGs. Here's an example:

```css
.triangle {
	width: 180px;
	height: 180px;
	background: linear-gradient(45deg, yellow 50%, transparent 50%);
	filter: drop-shadow(0.2rem 0.2rem 1rem rgba(0,0,0, 0.8));
}
```

<img src="https://storage.codestruct.io/upload/6377f6e114fda2c6a460bf14/triangle.png" />


One downside we can spot in the syntax here is that we're not able to set a spread parameter the shadow should have. Other than that, the parameters match what we're used to with box-shadows (x-offset, y-offset, blur, color).

The real magic however becomes more obvious when we apply a drop-shadow to a transparent PNG, which gives us the same effect as seen above, instead of just putting a shadow on the whole image or container, we see the shadow aligned to the filled lines and shapes.

```css
<style>
    img {
        filter: drop-shadow(0.5rem 0.5rem 0.5rem rgba(0, 100, 200, 0.7));
    }
</style>
<img src="./waves.png">
```

<img src="https://storage.codestruct.io/upload/6377f6e114fda2c6a460bf14/waves.png" />

A nifty alternative to box-shadows

If you haven't checked out Tailwind CSS yet or don't know what all the buzz regarding utility classes is all about, this article is for you. We'll take a first look at the advantages and get our hands just dirty enough to know what makes Tailwind a great CSS framework and what alternatives there are.

In general when talking about utility classes, you can think of primitive utilities that don't do much individually. In fact they shouldn't do much by themselves but work well when combined with other utility classes. The goal is to have a set of pre-existing classes that we can use to style HTML without writing a lot of custom CSS, which allows us to move faster and re-use those classes as much as possible.

## Keeping it simple

We'll keep it simple and skip all the build-steps and setting up our tooling for now, even though it's an important and powerful part of Tailwind's magic. For now we'll just look at the concept of utility classes and see how they can help us reduce the required amount of custom CSS and allow us to style our content faster overall.

So instead of setting up a build step, we'll start by simply requiring the Tailwind stylesheet into a blank HTML file. That's all we really need to get going.

```css
<link href="https://unpkg.com/tailwindcss@^2/dist/tailwind.min.css" />
```

Let's start by looking at a `<button>` element and make it pretty! First, let's make sure it has a `background-color` —> In Tailwind we get a lot of predefined [background colors](https://tailwindcss.com/docs/background-color), all created with rgba values, which allows our utility classes to change the colors based on the alpha, which we can set with a simple number in our class names like this:
  
```html
<button class="bg-blue-700">I'm a button</button>
```
  
In this case, 700 sets the alpha and we can go lighter and darker from 50 to 900, where 50 is the only smaller step and the basic rule is that we can increase or decrease the alpha in hundreds. So if we wanted a lighter blue, we could set it to `bg-blue-500`. This is great, because it already gives us a clue how we can make use of this for our hover effect! Let's check that out.

In order to give our button a lighter blue on hover, we'll use one of Tailwind's prefixes: `hover:` and combine it with the background, we've just used above: `hover:bg-blue-500` 

Sweet! We have a button that changes its background color on hover! Let's improve it further, by adding a font-color that is easier to read on our blue background. Just like we set the background-color, we can use the class `text-<color>` to set a color on our element. Again like the color palette for backgrounds, Tailwind comes with a set of [predefined text-colors](https://tailwindcss.com/docs/text-color) which can be adjusted by changing the alpha of the base color.

```css
<button class="bg-blue-700 hover:bg-blue-500 text-white">I'm a button</button>
```

*Side note: When using build tools we can also define our own colors, so we are not limited to the predefined palette.*

That's a pretty rad button already and we were pretty fast to get there. This simple button element already illustrates how utility classes can save us  a lot of time, as we have written exactly zero CSS so far, even though we changed the background color, text color and added a hover effect. And we're barely scratching the surface – let's dig a little deeper.

## Digging a little deeper

I'm a sucker for details when it comes to user interactions, so I'm already having a hard time looking at the button we just created. It needs a transition! Luckily Tailwind has our back and we can make use of multiple transition properties, or go with the `transition-all` property, which defaults to the following.

```css
transition-property: all;
transition-timing-function: cubic-bezier(0.4, 0, 0.2, 1);
transition-duration: 150ms;
```

Making sure we adhere to best practices around the `reduced-motion` property, we can even use a prefix called `motion-reduce:` to only show the transition when reduced-motion is not activated. Let's put that together real quick:

```html
<button class="bg-blue-700 hover:bg-blue-500 text-white transition-all motion-reduce:transition-none">I'm a button</button>
```

At this point you probably got the underlying idea of utility classes, utilizing a standardized way of naming with prefixes, the actual class and predefined and adaptable modifiers: `{prefix}:{class}-{modifier}`. One downside people complain about a lot with this expressive approach is that we're overloading our HTML that way and it actually becomes pretty unreadable. It's definitely a good idea to start formatting your HTML a little more according to that and let lines not run too long. The alternative however is probably a rather lengthy stylesheet, so there are always trade offs 🤷‍♂️

```html
<div class="..."
   id="...">
  Heya!
</div>
```

Before wrapping up, let's take a look at the bigger picture of building sites with Tailwind: Layout, spacing and responsiveness. Tailwind comes with a ton of handy classes to support us in all those areas like floats, flexbox and positioning classes, allowing us to build more complex components and layouts quickly. Let's take a look at a classic horizontal navigation bar using flexbox and centering things inside.

```html
<nav class="flex justify-between items-center px-16 bg-blue-700 text-white h-14">
  <h1>Navigation</h1>
  <ul class="flex justify-between w-56">
    <a href="#">
      <li>Link</li>
    </a>
    <a href="#">
      <li>Link</li>
    </a>
    <a href="#">
      <li>Link</li>
    </a>
  </ul>
</nav>
```

*There's a demo below the article.*

Now that wasn't too much to write and we got a pretty solid navigation bar! If we wanted to change things on smaller or bigger devices, we can make use of prefixes again. Tailwind, much like Bootstrap, comes with predefined breakpoints (media queries) that are named as follows:

- `sm` 640px
- `md` 768px
- `lg` 1024px
- `xl` 1280px

Those can be seen as replacements for media queries in your CSS and when introducing them, the unprefixed version we have used so far will only be applied **above** the prefixed version. So if we were to use a class with the prefix `md:bg-blue` and also have a class `bg-yellow` applied to the same element, the background would only be blue for everything above 768px (md) and yellow below that breakpoint.

Just like predefined breakpoints, Tailwind comes with a set of spacings for paddings and margins that can be applied to either one or multiple sides of an element, basically making it a great alternative to `margin-top: x;` and similar declarations. All spacing adhere to the following syntax `m{t|r|b|l}-{size}` which translates to a class like `mt-8` for a margin top of "8", where 8 translates to `2rem`. Those values are as mentioned predefined but can be adapted when using a real build step. It's definitely worth checking out the [Tailwind documentation](https://tailwindcss.com/docs) for exact values and in general a good idea to get a more in depth understanding of everything described in this article.

## Next steps and alternatives

A lot of the advantages of Tailwind actually come from using a build step and creating our own [configurations](https://tailwindcss.com/docs/configuration). This step allows us to define new colors, spacings, fonts, and much more! It's like keeping all the benefits of the utility-first approach but making it your own and adjusting it to your design and requirements. A lot of people seem to skip this step, which is why we see a lot of sites out there these days that use the default Tailwind styles. Don't get me wrong – that's not a bad thing! But you are missing out when not making use of those customizations. In fact, I think it is so important, I want to dedicate another full article to customizing Tailwind.

In the meantime, there are also other utility-first frameworks that came before Tailwind and there will probably be a bunch more to come. Here are some really interesting ones I recommend checking out.

[https://basscss.com/](https://basscss.com/)

[https://tachyons.io/](https://tachyons.io/)

[https://yogurtcss.netlify.app/](https://yogurtcss.netlify.app/)

[https://tedconf.github.io/shed-css/index.html](https://tedconf.github.io/shed-css/index.html)

[https://turretcss.com/](https://turretcss.com/)


*And lastly, here's a working demo to play around with, which contains the basic examples shown in the article.*
<iframe height="500" style={{width: '100%'}} scrolling="no" title="Tailwind CSS introduction" src="https://codepen.io/allroundio/embed/VwPWaJa?height=265&theme-id=dark&default-tab=html,result" frameBorder="no" loading="lazy" allowtransparency="true" allowFullScreen={true}>
  See the Pen <a href='https://codepen.io/allroundio/pen/VwPWaJa'>Tailwind CSS introduction</a> by Allround
  (<a href='https://codepen.io/allroundio'>@allroundio</a>) on <a href='https://codepen.io'>CodePen</a>.
</iframe>

The complete publishing platform for developers.

Advanced CSS attribute selectors

Writing reusable modules and libraries in JavaScript

A nifty alternative to box-shadows

Code your content into existence.

Start your tech blog for free.

Monetize your courses.

Why create with Codestruct?

Contribute on GitHub

Join us on Slack

All the building blocks you need.