Sundays are my designated review days. It’s a time I set aside to revisit the material I’ve worked on throughout the week and identify any concepts, functions, or processes that still feel unclear or that I want more practice with. It gives me a chance to reinforce what I’ve learned and resolve lingering questions.
Here are my notes from my first Sunday Review.
Items that I needed clarification on:
Relative paths (directory references in particular).
The mv command (with relative path, globbing, and wildcard).
Topic 1: Relative Paths.
Issue: Although I already had a general understanding of absolute and relative paths as a concept, I found myself stumbling over how directory references like dot (.) and dot-dot (..) are expressed and interpreted in Unix-like systems such as Linux. I’ve worked in Command Prompt in Windows systems, but mostly using network utilities such as netstat, ipconfig, ping, and telent.
I haven’t had to do a lot of moving around in directories outside of the GUI. While I knew that cd meant change directory, and I have even used cd .. in Windows before as something I learned on the fly, I realized going over the Linux material that I didn’t understand the logic of it, the why of the directory reference.
When I stopped to think about it, I misunderstood what these references actually meant. I initially assumed that a single dot (.) would move me up one level in the directory hierarchy, that two dots (..) would move me up two levels, and ../.. had me scratching my head. I interpreted it as “go up two levels to root, then somehow go two levels beyond that,” which, since I knew there was nothing above root, left me confused.
Clarification: A single dot (.) represents the current working directory. Therefore, dot-dot (..) refers to the parent directory of the current working directory (not two levels up, just one. The logic is saying “start in the current directory (first dot), then go up one directory from there (second dot).”
For example, cd .. means change from the current working directory to the parent of that directory.
Furthermore, ../.. means: go up one level (..), then go up one more level from there (.. again). Each “..” moves you up exactly one level in the directory hierarchy, regardless of where you start.
In Practice (with three examples):
cd ..
The prompt is showing username@computername. For these examples, I’ve customized those sections of the prompt to use temporary values (blogdemo@thelooplog) for security reasons. It’s never a great idea to publicly display your user name and computer name, as individuals with malicious intent could potentially exploit that information and try to gain access to your machine.
As an aside, this is what I ran to customize the prompt:
PS1="blogdemo@thelooplog:\w\$ "Back to the actual example – I start in /home/blogdemo/Training/Linux (the tilde ~ indicates /home/blogdemo here, and the $ indicates this is a standard user, not root).
If I wanted to move up one directory, to the parent directory of Linux, I could type:
cd ..
Notice how the prompt changed to indicate I am now in the /Training directory
cd ../..
In this example, I start in /home/blogdemo/Training/Linux/CLI
If I run:
cd ../..this takes me to the Training directory, the logic being, given my current working directory (/home/blogdemo/Training/Linux/CLI), move me up two places in the hierarchy, first to the parent (..), then (/) to the parent of that parent (..).
ls ./Training
In this example, I start out in /home/blogdemo (the home directory of the blogdemo user), and I’ve run the “ls” command to list the contents of that directory.
You can see in this directory that there’s a subdirectory named Training. What you can’t see from here are the contents of that subdirectory.
To find that, instead of typing the full absolute path (/home/blogdemo/Training) or running the cd command to change directories, I can use a relative path directory reference combined with the ls command to list its contents, all while remaining in my current working directory:
ls ./Training
The logic is saying, from my current working directory (indicated by the dot), list the contents (the ls command) of the Training directory (/Training).
Topic 2: The mv Command with Relative Path, Globbing, and Wildcard.
Issue: I was confused about how wildcard patterns like ../*.bak behave when used in commands like mv, especially in relation to the current working directory and how the shell expands those patterns.
Clarification: The key was understanding that wildcard expansion happens before the command runs, and that ../.bak refers to files in the parent directory of the current working directory, not the parent of the files being moved. Once I visualized how the shell expands ../.bak into a list of matching files from the parent directory, it became clear how this pattern can be combined with other arguments in a single command like mv. This helped me see how relative paths and globbing can work together to move files across directory levels.
In Practice:
mv dir1 ../*.bak dir2/
In this example, I am using the mv command with a relative path and a wildcard.
Given this directory structure:
/home/blogdemo/Training
├── backup1.bak
├── backup2.bak
└── Linux/
├── dir1/
└── dir2/
If my current working directory is:/home/blogdemo/Training/Linux
and that directory has two subdirectories, named dir1 and dir2 (we can ignore the CLI subdirectory since we are not using it in this example)
and there are also two files, named backup1.bak and backup2.bak, but these are in the /Training directory (which is a parent to my working directory)
and from my current working directory I want to move:dir1, (which is a subdirectory in my current location)
AND all .bak files from the parent directory (/home/blogdemo/Training
into dir2 (another subdirectory in my current directory), no problem!
I can run
mv dir1 ../*.bak dir2/[Showing that the command ran with no complaints]
to “glob” (yes, this is a technical term) all .bak files in the parent directory (/Training), and include them alongside dir1 in the mv command , sending them into dir2 (the trailing slash on dir2/ helps clarify that it’s a destination directory).
Here I am showing the result by running the ls command to list the contents of the target dir2 directory. As you can see, it now contains both .bak files as well as the dir1 directory. Which is what I was going for. It is always a good idea to validate whatever changes you anticipated to ensure what you ran actually did the thing you wanted it to do.
