Okay, welcome back.

Today we're gonna cover a couple separate

two main topics related to the shell.

First, we're gonna do some kind of shell
scripting, mainly related to bash,

which is the shell that most of you will start

in Mac, or like in most Linux systems,
that's the default shell.

And it's also kind of backward compatible through
other shells like zsh, it's pretty nice.

And then we're gonna cover some other shell
tools that are really convenient,

so you avoid doing really repetitive tasks,

like looking for some piece of code

or for some elusive file.

And there are already really
nice built-in commands

that will really help you to do those things.

So yesterday we already kind of introduced

you to the shell and some of it's quirks,

and like how you start executing commands,

redirecting them.

Today, we're going to kind of cover more about

the syntax of the variables, the control flow,

functions of the shell.

So for example, once you drop
into a shell, say you want to

define a variable, which is
one of the first things you

learn to do in a programming language.

Here you could do something like foo equals bar.

And now we can access the value
of foo by doing "$foo".

And that's bar, perfect.

One quirk that you need to be aware of is that

spaces are really critical when
you're dealing with bash.

Mainly because spaces are reserved, and
that will be for separating arguments.

So, for example, something like foo equals bar

won't work, and the shell is gonna
tell you why it's not working.

It's because the foo command is not
working, like foo is non-existent.

And here what is actually happening,
we're not assigning foo to bar,

what is happening is we're
calling the foo program

with the first argument "=" and
the second argument "bar".

And in general, whenever you are having
some issues, like some files with spaces

you will need to be careful about that.

You need to be careful about quoting strings.

So, going into that, how you do strings in bash.
There are two ways that you can define a string:

You can define strings using double quotes
and you can define strings using single,

sorry,

using single quotes.

However, for literal strings they are equivalent,

but for the rest they are not equivalent.

So, for example, if we do value is $foo,

the $foo has been expanded like
a string, substituted to the

value of the foo variable in the shell.

Whereas if we do this with a simple quote,
we are just getting the $foo as it is

and single quotes won't be replacing. Again,

it's really easy to write a script, assume that
this is kind of like Python, that you might be

more familiar with, and not realize all that.

And this is the way you will assign variables.

Then bash also has control flow
techniques that we'll see later,

like for loops, while loops, and one main
thing is you can define functions.

We can access a function I have defined here.

Here we have the MCD function, that
has been defined, and the thing is

so far, we have just kind of seen how
to execute several commands by piping

into them, kind of saw that briefly yesterday.

But a lot of times you want to do first
one thing and then another thing.

And that's kind of like the

sequential execution that we get here.

Here, for example, we're
calling the MCD function.

We, first,

are calling the makedir command,
which is creating this directory.

Here, $1 is like a special variable.

This is the way that bash works,

whereas in other scripting languages
there will be like argv,

the first item of the array argv
will contain the argument.

In bash it's $1. And in general, a lot

of things in bash will be dollar something

and will be reserved, we will
be seeing more examples later.

And once we have created the folder,
we CD into that folder,

which is kind of a fairly common
pattern that you will see.

We will actually type this directly
into our shell, and it will work and

it will define this function. But sometimes
it's nicer to write things in a file.

What we can do is we can source
this. And that will

execute this script in our shell and load it.

So now it looks like nothing happened,
but now the MCD function has

been defined in our shell. So
we can now for example do

MCD test, and now we move from
the tools directory to the test

directory. We both created the
folder and we moved into it.

What else. So a result is...

We can access the first argument with $1.

There's a lot more reserved commands,

for example $0 will be the name of the script,

$2 through $9 will be the second
through the ninth arguments

that the bash script takes.
Some of these reserved

keywords can be directly used
in the shell, so for example

$? will get you the error code
from the previous command,

which I'll also explain briefly.

But for example, $_ will get
you the last argument of the

previous command. So another way
we could have done this is

we could have said like "mkdir test"

and instead of rewriting test, we
can access that last argument

as part of the (previous command), using $_

like, that will be replaced with
test and now we go into test.

There are a lot of them, you
should familiarize with them.

Another one I often use is called "bang
bang" ("!!"), you will run into this

whenever you, for example, are trying
to create something and you don't have

enough permissions. Then, you can do "sudo !!"

and then that will replace the command in

there and now you can just try doing

that. And now it will prompt you for a password,

because you have sudo permissions.

Before, I mentioned the, kind
of the error command.

Yesterday we saw that, in general, there are

different ways a process can communicate

with other processes or commands.

We mentioned the standard
input, which also was like

getting stuff through the standard input,

putting stuff into the standard output.

There are a couple more interesting
things, there's also like a

standard error, a stream where you write errors

that happen with your program and you don't
want to pollute the standard output.

There's also the error code,
which is like a general

thing in a lot of programming languages,

some way of reporting how the
entire run of something went.

So if we do

something like echo hello and we

query for the value, it's zero. And it's zero

because everything went okay and there

weren't any issues. And a zero exit code is

the same as you will get in a language

like C, like 0 means everything
went fine, there were no errors.

However, sometimes things won't work.

Sometimes, like if we try to grep
for foobar in our MCD script,

and now we check for that
value, it's 1. And that's

because we tried to search for the foobar

string in the MCD script and it wasn't there.

So grep doesn't print anything, but

let us know that things didn't work by

giving us a 1 error code.

There are some interesting commands like

"true", for example, will always have a zero

error code, and false will always
have a one error code.

Then there are like

these logical operators that you can use

to do some sort of conditionals.
For example, one way...

you also have IF's and ELSE's, that
we will see later, but you can do

something like "false", and echo "Oops fail".

So here we have two commands connected
by this OR operator.

What bash is gonna do here, it's
gonna execute the first one

and if the first one didn't work, then it's

gonna execute the second one. So here we get it,

because it's gonna try to do a logical
OR. If the first one didn't have

a zero error code, it's gonna try to
do the second one. Similarly, if we

instead of use "false", we
use something like "true",

since true will have a zero error code, then the

second one will be short-circuited and

it won't be printed.

Similarly, we have an AND
operator which will only

execute the second part if the first one

ran without errors.

And the same thing will happen.

If the first one fails, then the second
part of this thing won't be executed.

Kind of not exactly related to that, but
another thing that you will see is

that no matter what you execute,
then you can concatenate

commands using a semicolon in the same line,

and that will always print.

Beyond that, what we haven't
seen, for example, is how

you go about getting the output
of a command into a variable.

And the way we can do that is
doing something like this.

What we're doing here is we're getting
the output of the PWD command,

which is just printing the
present working directory

where we are right now.

And then we're storing that
into the foo variable.

So we do that and then we ask
for foo, we view our string.

More generally, we can do this thing
called command substitution

by putting it into any string.

And since we're using double quotes
instead of single quotes

that thing will be expanded and

it will tell us that we are
in this working folder.

Another interesting thing is, right now,
what this is expanding to is a string

instead of

It's just expanding as a string.

Another nifty and lesser known tool
is called process substitution,

which is kind of similar. What it will do...

it will, here for example, the "<(",
some command and another parenthesis,

what that will do is: that will execute,
that will get the output to

kind of like a temporary file and it will
give the file handle to the command.

So here what we're doing is we're getting...

we're LS'ing the directory, putting
it into a temporary file,

doing the same thing for the
parent folder and then

we're concatenating both files. And this

will, may be really handy, because
some commands instead of expecting

the input coming from the stdin,
they are expecting things to

come from some file that is giving
some of the arguments.

So we get both things concatenated.

I think so far there's been a lot of
information, let's see a simple,

an example script where we
see a few of these things.

So for example here we have a string and we

have this $date. So $date is a program.

Again there's a lot of programs
in UNIX you will kind of slowly

familiarize with a lot of them.

Date just prints what the current date is
and you can specify different formats.

Then, we have these $0 here. $0 is the name

of the script that we're running.

Then we have $#, that's the number
of arguments that we are giving

to the command, and then $$ is the process
ID of this command that is running.

Again, there's a lot of these dollar
things, they're not intuitive

because they don't have like a mnemonic

way of remembering, maybe, $#. But

it can be... you will just be

seeing them and getting familiar with them.

Here we have this $@, and that will
expand to all the arguments.

So, instead of having to assume that,

maybe say, we have three arguments
and writing $1, $2, $3,

if we don't know how many arguments we
can put all those arguments there.

And that has been given to a
for loop. And the for loop

will, in time, get the file variable

and it will be giving each one of the arguments.

So what we're doing is, for every
one of the arguments we're giving.

Then, in the next line we're running the

grep command which is just search for
a substring in some file and we're

searching for the string foobar in the file.

Here, we have put the variable
that the file took, to expand.

And yesterday we saw that if we care
about the output of a program, we can

redirect it to somewhere, to save it
or to connect it to some other file.

But sometimes you want the opposite.

Sometimes, here for example, we care...

we're gonna care about the error code. About
this script, we're gonna care whether the

grep ran successfully or it didn't.

So we can actually discard
entirely what the output...

like both the standard output and the
standard error of the grep command.

And what we're doing is we're

redirecting the output to /dev/null which

is kind of like a special device in UNIX

systems where you can like write and

it will be discarded. Like you can

write no matter how much you want,

there, and it will be discarded.
And here's the ">" symbol

that we saw yesterday for redirecting
output. Here you have a "2>"

and, as some of you might have

guessed by now, this is for redirecting the

standard error, because those those two

streams are separate, and you kind of have to

tell bash what to do with each one of them.

So here, we run, we check if the file has

foobar, and if the file has foobar then it's

going to have a zero code. If it

doesn't have foobar, it's gonna have a

nonzero error code. So that's exactly what we

check. In this if part of the command we

say "get me the error code". Again, this $?

And then we have a comparison operator

which is "-ne", for "non equal". And some

other programming languages
will have "==", "!=", these

symbols. In bash there's

like a reserved set of comparisons and

it's mainly because there's a lot of

things you might want to test for when

you're in the shell. Here for example

we're just checking for two values, two
integer values, being the same. Or for

example here, the "-F" check will let

us know if a file exists, which is

something that you will run into very,

very commonly. I'm going back to the

example. Then, what happens when we

if the file did not have
foobar, like there was a

nonzero error code, then we print

"this file doesn't have any foobar,

we're going to add one". And what we do is

we echo this "# foobar", hoping this

is a comment to the file and then we're

using the operator ">>" to append at the end of

the file. Here since the file has

been fed through the script, and we don't
know it beforehand, we have to substitute

the variable of the filename. We can
actually run this. We already have

correct permissions in this script and

we can give a few examples. We have a
few files in this folder, "mcd" is the

one we saw at the beginning for the MCD

function, some other "script" function and

we can even feed the own script to itself
to check if it has foobar in it.

And we run it and first we can
see that there's different

variables that we saw, that have been

successfully expanded. We have the date, that has

been replaced to the current time, then

we're running this program, with three

arguments, this randomized PID, and then

it's telling us MCD doesn't have any

foobar, so we are adding a new one,

and this script file doesn't

have one. So now for example let's look at MCD

and it has the comment that we were looking for.

One other thing to know when you're
executing scripts is that

here we have like three completely

different arguments but very commonly

you will be giving arguments that

can be more succinctly given in some way.

So for example here if we wanted to

refer to all the ".sh" scripts we

could just do something like "ls *.sh"

and this is a way of filename expansion
that most shells have

that's called "globbing". Here, as you

might expect, this is gonna say

anything that has any kind of sort of

characters and ends up with "sh".

Unsurprisingly, we get "example.sh"
and "mcd.sh". We also have these

"project1" and "project2", and if there

were like a... we can do a
"project42", for example

And now if we just want to refer
to the projects that have

a single character, but not two characters

afterwards, like any other characters,

we can use the question mark. So "?"
will expand to only a single one.

And we get, LS'ing, first

"project1" and then "project2".

In general, globbing can be very powerful.
You can also combine it.

A common pattern is to use what
is called curly braces.

So let's say we have an image,
that we have in this folder

and we want to convert this image from PNG to JPG

or we could maybe copy it, or...

it's a really common pattern, to have
two or more arguments that are

fairly similar and you want to do something
with them as arguments to some command.

You could do it this way, or more
succinctly, you can just do

"image.{png,jpg}"

And here, I'm getting some color feedback,
but what this will do, is

it'll expand into the line above.

Actually, I can ask zsh to do that for
me. And that what's happening here.

This is really powerful. So for example

you can do something like... we could do...

"touch" on a bunch of foo's, and
all of this will be expanded.

You can also do it at several levels
and you will do the Cartesian...

if we have something like this,
we have one group here, "{1,2}"

and then here there's "{1,2,3}",
and this is going to do

the Cartesian product of these

two expansions and it will expand
into all these things,

that we can quickly "touch".

You can also combine the asterisk
glob with the curly braces glob.

You can even use kind of ranges.
Like, we can do "mkdir"

and we create the "foo" and the
"bar" directories, and then we

can do something along these lines. This

is going to expand to "fooa", "foob"...

like all these combinations, through "j", and

then the same for "bar". I haven't

really tested it... but yeah, we're getting
all these combinations that we

can "touch". And now, if we touch something

that is different between these
two [directories], we

can again showcase the process
substitution that we saw

earlier. Say we want to check what
files are different between these

two folders. For us it's obvious,
we just saw it, it's X and Y,

but we can ask the shell to do
this "diff" for us between the

output of one LS and the other LS.

Unsurprisingly we're getting: X is

only in the first folder and Y is

only in the second folder. What is more

is, right now, we have only seen
bash scripts. If you like other

scripts, like for some tasks bash
is probably not the best,

it can be tricky. You can actually
write scripts that

interact with the shell implemented in a lot

of different languages. So for
example, let's see here a

Python script that has a magic line at the

beginning that I'm not explaining for now.

Then we have "import sys",

it's kind of like... Python is not,
by default, trying to interact

with the shell so you will have to import

some library. And then we're doing a

really silly thing of just iterating

over "sys.argv[1:]".

"sys.argv" is kind of similar to what
in bash we're getting as $0, $1, &c.

Like the vector of the arguments, we're
printing it in the reversed order.

And the magic line at the beginning is

called a shebang and is the way that the

shell will know how to run this program.

You can always do something like

"python script.py", and then "a b c" and that

will work, always, like that. But

what if we want to make this to be

executable from the shell? The way the

shell knows that it has to use python as the

interpreter to run this file is using

that first line. And that first line is

giving it the path to where that thing lives.

However, you might not know.

Like, different machines will have probably

different places where they put python

and you might not want to assume where

python is installed, or any other interpreter.

So one thing that you can do is use the

"env" command.

You can also give arguments in the shebang, so

what we're doing here is specifying

run the "env" command, that is for pretty much every
system, there are some exceptions, but like for

pretty much every system it's is in

"usr/bin", where a lot of binaries live,

and then we're calling it with the

argument "python". And then that will make

use of the path environment variable

that we saw in the first lecture. It's

gonna search in that path for the Python

binary and then it's gonna use that to

interpret this file. And that will make

this more portable so it can be run in

my machine, and your machine
and some other machine.

Another thing is that the bash is not

really like modern, it was

developed a while ago. And sometimes

it can be tricky to debug. By

default, and the ways it will fail

sometimes are intuitive like the way we

saw before of like foo command not

existing, sometimes it's not. So there's

like a really nifty tool that we have

linked in the lecture notes, which is called

"shellcheck", that will kind of give you

both warnings and syntactic errors

and other things that you might
not have quoted properly,

or you might have misplaced spaces in

your files. So for example for
extremely simple "mcd.sh"

file we're getting a couple

of errors saying hey, surprisingly,

we're missing a shebang, like this

might not interpret it correctly if you're

it at a different system. Also, this

CD is taking a command and it might not

expand properly so instead of using CD

you might want to use something like CD

and then an OR and then an "exit". We go

back to what we explained earlier, what

this will do is like if the

CD doesn't end correctly, you cannot CD

into the folder because either you

don't have permissions, it doesn't exist...

That will give a nonzero error

command, so you will execute exit

and that will stop the script

instead of continue executing as if

you were in a place that you are

actually not in. And actually
I haven't tested, but I

think we can check for "example.sh"

and here we're getting that we should be

checking the exit code in a
different way, because it's

probably not the best way, doing it this

way. One last remark I want to make

is that when you're writing bash scripts

or functions for that matter,

there's kind of a difference between

writing bash scripts in isolation like a

thing that you're gonna run, and a thing

that you're gonna load into your shell.

We will see some of this in the command

line environment lecture, where we will kind of

be tooling with the bashrc and the
sshrc. But in general, if you make

changes to for example where you are,

like if you CD into a bash script and you

just execute that bash script, it won't CD

into the shell are right now. But if you

have loaded the code directly into

your shell, for example you load...

you source the function and then you execute

the function then you will get those

side effects. And the same goes for

defining variables into the shell.

Now I'm going to talk about some
tools that I think are nifty when

working with the shell. The first was

also briefly introduced yesterday.

How do you know what flags, or like

what exact commands are. Like how I am

supposed to know that LS minus L will list
the files in a list format, or that

if I do "move - i", it's gonna like prom me

for stuff. For that what you have is the "man"

command. And the man command will kind of

have like a lot of information of how

will you go about... so for example here it

will explain for the "-i" flag, there are

all these options you can do. That's

actually pretty useful and it will work

not only for really simple commands
that come packaged with your OS

but will also work with some tools
that you install from the internet

for example, if the person that did the

installation made it so that the man

package were also installed. So for example

a tool that we're gonna cover in a bit

which is called "ripgrep" and
is called with RG, this didn't

come with my system but it has installed

its own man page and I have it here and

I can access it. For some commands the

man page is useful but sometimes it can be

tricky to decipher because it's more

kind of a documentation and a

description of all the things the tool

can do. Sometimes it will have

examples but sometimes not, and sometimes

the tool can do a lot of things so a

couple of good tools that I use commonly

are "convert" or "ffmpeg", which deal
with images and video respectively and

the man pages are like enormous. So there's

one neat tool called "tldr" that

you can install and you will have like

some nice kind of explanatory examples

of how you want to use this command. And you

can always Google for this, but I find

myself saving going into the

browser, looking about some examples and

coming back, whereas "tldr" are

community contributed and

they're fairly useful. Then,

the one for "ffmpeg" has a lot of

useful examples that are more nicely

formatted (if you don't have a huge

font size for recording). Or even

simple commands like "tar", that have a lot

of options that you are combining. So for

example, here you can be combining 2, 3...

different flags and it can not be

obvious, when you want to combine

different ones. That's how you

would go about finding more about these tools.
On the topic of finding, let's try

learning how to find files. You can

always go "ls", and like you can go like

"ls project1", and

keep LS'ing all the way through. But

maybe, if we already know that we want

to look for all the folders called

"src", then there's probably a better command

for doing that. And that's "find".

Find is the tool that, pretty much comes
with every UNIX system. And find,

we're gonna give it... here we're
saying we want to call find in the

current folder, remember that "." stands

for the current folder, and we want the

name to be "src" and we want the type to
be a directory. And by typing that it's

gonna recursively go through the current

directory and look for all these files,

or folders in this case, that match this
pattern. Find has a lot of useful

flags. So for example, you can even test

for the path to be in a way. Here we're

saying we want some number of folders,

we don't really care how many folders,

and then we care about all the Python

scripts, all the things with the extension
".py", that are within a

test folder. And we're also checking, just in

cases really but we're checking just

that it's also a type F, which stands for

file. We're getting all these files.

You can also use different flags for things

that are not the path or the name.

You could check things that have been

modified ("-mtime" is for the modification
time), things that have been

modified in the last day, which is gonna

be pretty much everything. So this is gonna print

a lot of the files we created and files

that were already there. You can even

use other things like size, the owner,

permissions, you name it. What is even more

powerful is, "find" can find stuff

but it also can do stuff when you

find those files. So we could look for all

the files that have a TMP

extension, which is a temporary extension, and

then, we can tell "find" that
for every one of those files,

just execute the "rm" command for them. And

that will just be calling "rm" with all

these files. So let's first execute it

without, and then we execute it with it.

Again, as with the command line

philosophy, it looks like nothing

happened. But since we have
a zero error code, something

happened - just that everything went

correct and everything is fine. And now,

if we look for these files,
they aren't there anymore.

Another nice thing about the shell
in general is that there are

these tools, but people will keep

finding new ways, so alternative

ways of writing these tools. It's
nice to know about it. So, for

example find if you just want to match
the things that end in "tmp"

it can be sometimes weird to do this
thing, it has a long command.

There's things like "fd",

for example, that is a shorter command
that by default will use regex

and will ignore your gitfiles, so you

don't even search for them. It

will color-code, it will have better
Unicode support... It's nice to

know about some of these tools. But, again,

the main idea is that if you are aware
that these tools exist, you can

save yourself a lot of time from doing

kind of menial and repetitive tasks.

Another command to bear in mind is like

"find". Some of you may be

wondering, "find" is probably just

actually going through a directory

structure and looking for things but

what if I'm doing a lot of "finds" a day?

Wouldn't it be better, doing kind of

a database approach and build an index
first, and then use that index

and update it in some way. Well, actually

most Unix systems already do it and

this is through the "locate" command and

the way that the locate will

be used... it will just look for paths in

your file system that have the substring

that you want. I actually don't know if it
will work... Okay, it worked. Let me try to

do something like "missing-semester".

You're gonna take a while but

it found all these files that are somewhere

in my file system and since it has

built an index already on them, it's much

faster. And then, to keep it updated,

using the "updatedb" command
that is running through cron,

to update this database. Finding files, again, is

really useful. Sometimes you're actually concerned
about, not the files themselves,

but the content of the files. For that

you can use the grep command that we

have seen so far. So you could do

something like grep foobar in MCD, it's there.

What if you want to, again, recursively
search through the current

structure and look for more files, right?

We don't want to do this manually.

We could use "find", and the "-exec", but

actually "grep" has the "-R" flag
that will go through the entire

directory, here. And it's telling us

that oh we have the foobar line in example.sh

at these three places and in

this other two places in foobar. This can be

really convenient. Mainly, the

use case for this is you know you have

written some code in some programming

language, and you know it's somewhere in

your file system but you actually don't

know. But you can actually quickly search.

So for example, I can quickly search

for all the Python files that I have in my

scratch folder where I used the request library.

And if I run this, it's giving me

through all these files, exactly in

what line it has been found. And here

instead of using grep, which is fine,

you could also do this, I'm using "ripgrep",

which is kind of the same idea but
again trying to bring some more

niceties like color coding or file

processing and other things. It think it has,
also, unicode support. It's also pretty

fast so you are not paying like a
trade-off on this being slower and

there's a lot of useful flags. You

can say, oh, I actually want to get some

context around those results.

So I want to get like five
lines of context around

that, so you can see where that import
lives and see code around it.

Here in the import it's not really useful

but like if you're looking for where you

use the function, for example, it will

be very handy. We can also do things like

we can search, for example here,.

A more advanced use, we can say,

"-u" is for don't ignore hidden files, sometimes

you want to be ignoring hidden
files, except if you want to

search config files, that are by default
hidden. Then, instead of printing

the matches, we're asking to do something
that would be kind of hard, I think,

to do with grep, out of my head, which is

"I want you to print all the files that

don't match the pattern I'm giving you", which

may be a weird thing to ask here but

then we keep going... And this pattern here

is a small regex which is saying

at the beginning of the line I have a

"#" and a "!", and that's a shebang.

Like that, we're searching here for all

the files that don't have a shebang

and then we're giving it, here,

a "-t sh" to only look for "sh"

files, because maybe all your
Python or text files are fine

without a shebang. And here it's telling us

"oh, MCD is obviously missing a shebang"

We can even... It has like some

nice flags, so for example if we

include the "stats" flag

it will get all these results but it will
also tell us information about all

the things that it searched. For example,

the number of matches that it found,
the lines, the file searched,

the bytes that it printed, &c.

Similar as with "fd", sometimes
it's not as useful

using one specific tool or another and

in fact, as ripgrep, there are several
other tools. Like "ack",

is the original grep alternative that was

written. Then the silver searcher,

"ag", was another one... and they're all

pretty much interchangeable so

maybe you're at a system that has one and

not the other, just knowing that you can

use these things with these tools can be

fairly useful. Lastly, I want to cover

how you go about, not finding files
or code, but how you go about

finding commands that you already

some time figured out. The first, obvious
way is just using the up arrow,

and slowly going through all your history,
looking for these matches.

This is actually not very efficient, as

you probably guessed. So the bash
has ways to do this more easily.

There is the "history" command, that will

print your history. Here I'm in zsh and
it only prints some of my history, but

if I say, I want you to print everything
from the beginning of time, it will print

everything from the beginning
of whatever this history is.

And since this is a lot of results,

maybe we care about the ones where we

use the "convert" command to go from some
type of file to some other type of file.

Some image, sorry. Then, we're getting all

these results here, about all the ones

that match this substring.

Even more, pretty much all shells by default will

link "Ctrl+R", the keybinding,

to do backward search. Here we

have backward search, where we can

type "convert" and it's finding the

command that we just typed. And if we just

keep hitting "Ctrl+R", it will

kind of go through these matches and

it will let re-execute it

in place. Another thing that you can do,

related to that, is you can use this

really nifty tool called "fzf", which is

like a fuzzy finder, like it will...

It will let you do kind of

like an interactive grep. We could do

for example this, where we can cat our

example.sh command, that will print

print to the standard output, and then we

can pipe it through fzf. It's just getting

all the lines and then we can
interactively look for the

string that we care about. And the nice

thing about fzf is that, if you enable
the default bindings, it will bind to

your "Ctrl+R" shell execution and now

you can quickly and dynamically like

look for all the times you try to
convert a favicon in your history.

And it's also like fuzzy matching,
whereas like by default in grep

or these things you have to write a regex or some

expression that will match within here.

Here I'm just typing "convert" and "favicon" and

it's just trying to do the best scan,

doing the match in the lines it has.

Lastly, a tool that probably you have
already seen, that I've been using

for not retyping these extremely long

commands is this "history
substring search", where

as I type in my shell,

and both F fail to mention but both face

which I think was originally introduced,
this concept, and then

zsh has a really nice implementation)

what it'll let you do is

as you type the command, it will
dynamically search back in your

history to the same command
that has a common prefix,

and then, if you...

it will change as the match list stops

working and then as you do the

right arrow you can select that
command and then re-execute it.

We've seen a bunch of stuff... I think I have

a few minutes left so I'm going
to cover a couple of tools to do

really quick directory listing
and directory navigation.

So you can always use the "-R" to recursively
list some directory structure,

but that can be suboptimal, I cannot
really make sense of this easily.

There's tool called "tree" that will
be the much more friendly form of

printing all the stuff, it will
also color code based on...

here for example "foo" is blue
because it's a directory and

this is red because it has execute permissions.

But we can go even further than
that. There's really nice tools

like a recent one called "broot" that
will do the same thing but here

for example instead of doing
this thing of listing

every single file, for example in bar

we have these "a" through "j" files,

it will say "oh there are more, unlisted here".

I can actually start typing and it will again

again facily match to the files that are there

and I can quickly select them
and navigate through them.

So, again, it's good to know that

these things exist so you don't
lose a large amount of time

going for these files.

There are also, I think I have it installed

also something more similar to what
you would expect your OS to have,

like Nautilus or one of the Mac
finders that have like an

interactive input where you can just use your
navigation arrows and quickly explore.

It might be overkill but you'll
be surprised how quickly you can

make sense of some directory structure
by just navigating through it.

And pretty much all of these tools
will let you edit, copy files...

if you just look for the options for them.

The last addendum is kind of going places.

We have "cd", and "cd" is nice, it will get you

to a lot of places. But it's pretty handy if

you can like quickly go places,

either you have been to recently or that

you go frequently. And you can do this in

many ways there's probably... you can start

thinking, oh I can make bookmarks, I can

make... I can make aliases in the shell,

that we will cover at some point,

symlinks... But at this point,

programmers have like built all these

tools, so programmers have already figured

out a really nice way of doing this.

One way of doing this is using what is

called "auto jump", which I
think is not loaded here...

Okay, don't worry. I will cover it
in the command line environment.

I think it's because I disabled
the "Ctrl+R" and that also

affected other parts of the script.
I think at this point if anyone has

any questions that are related to this,
I'll be more than happy to answer

them, if anything was left unclear.

Otherwise, a there's a bunch of
exercises that we wrote, kind of

touching on these topics and we
encourage you to try them and

come to office hours, where we can help

you figure out how to do them, or some
bash quirks that are not clear.