← Back to list

Day 50 of My Cloud Engineering Journey: Go Operators, Archives, Permissions, and Learning from…

Today I started later than I wanted to, but late is still better than not showing up at all.

Kevin Windisch · 2026-07-09 23:43 · 0 claps · 3.3 min read
#devops #golang #linux #cloud-engineering #automation
Open on Medium ↗
Wiki topics: EDU · Education & Learning ☁️ · DevOps & Cloud 🔓 · Open Source

Day 50 of My Cloud Engineering Journey: Go Operators, Archives, Permissions, and Learning from Mistakes

Today I started later than I wanted to, but late is still better than not showing up at all.

I made a promise to myself that I would keep learning every day, even if some days are smaller than others. Today was one of those days where I had to push myself to keep the habit going, but I am glad I did. Consistency is becoming a priority, and the repetition is starting to matter more than the length of each session.

I continued learning Go fundamentals today, specifically around operators and control flow.

Today’s Go topics included:

• Operators

• Comparison operators

• Arithmetic operators

• Logical operators

• Assignment operators

This section felt like another building block in understanding how Go works. Operators are not the most exciting topic by themselves, but they are necessary. They help control how values are compared, calculated, assigned, and evaluated inside a program. I am still early in Go, but I can already see how these basics will matter later when I start writing larger programs with conditions, loops, and logic.

Alongside the Go lessons, I also worked through two Linux administration tasks that had some real troubleshooting involved.

The first task required me to create a compressed .tar.gz archive and move it into the /home directory, which acted as a developer repository for non-confidential data.

To complete this, I had to research how to isolate and list folders before bundling a directory’s contents into a compressed backup archive. I also had to validate the archive afterward by checking its size, internal structure, and data integrity.

At first, the commands looked correct. I created the archive. I verified the data. I moved the file, but then I realized the task was not actually complete because I moved the archive into the wrong location.

Instead of moving it into /home, I accidentally moved it into my own home directory by using the ~ shortcut. The command worked, but the destination was wrong. That was a good lesson.

The syntax can be correct, the archive can be valid, and the file can move successfully, but if it lands in the wrong place, the task is still wrong.

I had to backtrack, relocate the archive properly, and make sure it ended up where the requirement actually said it needed to go. This was a reminder that rereading the task matters. Taking a second or third look at the requirement, your work, and your next move is not wasted time.

The second Linux task required me to grant executable permissions to a Bash script used for backup automation on the correct server. The script needed to be executable by all users.

As usual, the first step was making sure I was SSH’d into the correct server under the proper user. Infrastructure details matter here. If you make the right change on the wrong server, the task is still wrong.

The issue I ran into was with permissions.

Initially, I gave the script execute permissions, but later realized the file lacked read permissions. The permissions ended up looking like execute-only access, which was not enough for the script to run properly. That made me stop and research why.

A Bash script is still a text file. For the system to execute the script, the interpreter needs to be able to read the commands inside it. Execute permission alone is not always enough if the file cannot be read.

I fixed the issue by granting both read and execute permissions to the script, changing the permissions so users could properly run it.

That was another small but important lesson. File permissions are not just about checking one box. Read, write, and execute all matter differently depending on the file type and what you need the system to do with it.

Today had two Linux tasks, and both had mistakes. The first mistake came from tricky wording and moving a file to the wrong destination. The second mistake came from missing an extra permission that was required for a Bash script to actually run.

I do not see that as a wasted day. I see it as the kind of practice that makes the lessons stick. It is one thing to learn commands in a course. It is another thing to use them, make a mistake, research the reason, correct the issue, and verify the final result. That is where the learning becomes real.

Today reinforced a simple point for me: commands matter, but context matters just as much. The right command in the wrong directory can still fail the task. The right permission without the full requirement can still prevent a script from working. The right idea still needs careful execution.

Still learning, making mistakes, correcting them and showing up.


메타데이터
post_id
cf00c5e771d2
slug
day-50-of-my-cloud-engineering-journey-go-operators-archives-permissions-and-learning-from-cf00c5e771d2
url
https://medium.com/@Kwindisch/day-50-of-my-cloud-engineering-journey-go-operators-archives-permissions-and-learning-from-cf00c5e771d2
canonical_url
https://medium.com/@Kwindisch/day-50-of-my-cloud-engineering-journey-go-operators-archives-permissions-and-learning-from-cf00c5e771d2
author_url
https://medium.com/@Kwindisch
status
ok
fetched_at
2026-07-13 06:23:13