Coder Legion - Recent posts tagged chaicode

Beyond the Terminal: My Hunt Through the Linux File System

Sat, 25 Apr 2026 05:07:24 +0000

At first, Linux felt like magic. You open the terminal, type a command… and things just work. No questions asked. But after a while, that “magic” started bothering me.

Because I kept thinking:

Where is all of this actually happening?
How does the system know what to do?

Like… when I connect to the internet, where is that configuration stored?
When a user logs in, where is that data coming from?
When something breaks, where does Linux keep track of it?

These weren’t just random questions anymore. They were pulling me deeper.

So instead of just using Linux… I decided to explore it. Not like a normal user.
But like someone trying to understand what’s going on behind the scenes.

Digging into folders.
Opening system files.
Trying to connect the dots.

And what I discovered?

It completely changed how I look at Linux. Because behind every command…
there’s a system quietly doing a lot more than we realize.

`/etc` - The Place Where System Behavior Lives

The first place I explored was /etc, because I kept hearing that it’s important.

So I went inside:

cd /etc
ls

At first, it just looked like a collection of random files. But the more I opened them, the more I realized something important.

/etc is not just a folder.

It is where Linux stores all configuration that controls system behavior.

When I opened files like:

cat /etc/hosts
cat /etc/passwd

I could literally see how my system is configured.

This made me realize why this folder exists. Instead of hardcoding system behavior deep inside programs, Linux stores configurations as editable files. This means the system becomes flexible you can change behavior without touching the core system.

The problem this solves is huge. Imagine if you had to recompile the OS just to change a setting. That would be impossible for daily use.

But with /etc, Linux separates configuration from execution.

And the insight that hit me was this:
My system is not controlled by hidden magic. It’s controlled by plain text files that I can read and understand.

`/etc/resolv.conf` - How My System Finds Websites

One thing I never really questioned was typing something like:

ping google.com

It just works. But then I stopped and thought:

How does my system even understand what “google.com” is?
Because at the end of the day, computers don’t understand names, they understand IP addresses.

So I decided to dig into it.

I ran:

cat /etc/resolv.conf

And I saw this:

nameserver 10.0.2.3

At first, this confused me.

I was expecting something like 8.8.8.8 (Google DNS).
But this… looked different.

So what is this `10.0.2.3`

It turns out, this is not a public DNS server. It’s a local DNS resolver provided by my virtual machine environment

Since I’m running Linux inside a VM, my system is not directly talking to the internet.

Instead, it works like this:

My Linux system → asks 10.0.2.3 → which then forwards the request to actual DNS servers

So basically, 10.0.2.3 is acting like a middleman.

Why does this file exist?

This file tells the system: “If you don’t understand a domain name, ask this nameserver.”

Without this, the system wouldn’t know where to send DNS queries.

What problem does it solve?

Humans use names like:

But systems use IP addresses. So DNS acts as a translator between human-friendly names and machine-friendly IPs.

And /etc/resolv.conf tells Linux where that translator lives.

What I found interesting

The biggest realization for me was this: My system isn’t always directly using public DNS.
In my case, it’s using a local resolver (10.0.2.3), which then handles everything behind the scenes.

That means even something as simple as opening a website involves:

local system configuration
virtual networking layers
DNS forwarding

Small but powerful insight

Just by changing this file, I can control how my system resolves domains.

Which means I can switch to a faster DNS, block certain domains, & control network behavior.

And honestly… Something as simple as opening a website suddenly felt way deeper than I thought.

Routing Table - How Linux Decides Where Data Goes

Next, I wanted to understand how my system sends data.

So I ran:

ip route

What I saw was something like:

This is the routing table.

At a basic level, this tells the system: “If you don’t know where to send data, send it to this gateway.”

In my case, that gateway is 10.0.2.2.

This exists because your system doesn’t just randomly send data. It needs a structured way to decide where packets go.

The problem it solves is routing confusion. Without this, your system wouldn’t know whether to send data locally or over the internet.

The second line (10.0.2.0/24) tells the system that anything in this local network range can be accessed directly, without going through the gateway.

The insight here was surprising: My system is not just sending data it’s making routing decisions like a mini network controller.

And since I’m using a virtual machine, 10.0.2.2 is actually a virtual gateway, not a physical router.

I always thought networking happens “somewhere outside”. But Linux is actively involved in deciding paths. And in this case, it’s even routing traffic through a virtual layer before it reaches the real network.

`/var/log` - The Silent Observer of Everything

Then I explored logs:

cd /var/log
ls

And opened files like:

cat messages
cat secure

This folder is basically the memory of the system.

Everything that happens:

logins
errors
services
system events

…it all gets recorded here. This exists because systems need a way to track what’s happening internally.
The problem it solves is debugging and monitoring. Without logs, if something breaks, you’re blind.

But what really stood out to me was this:

Linux doesn’t interrupt you with errors all the time.
It quietly writes everything down.

It’s like the system is constantly saying:
“I’ll tell you everything… but only if you come and look.”

`/etc/passwd` & `/etc/shadow` - How Linux Handles Users Securely

To understand users, I ran:

cat /etc/passwd
sudo cat /etc/shadow

What I saw was interesting.

/etc/passwd contains user details.

But passwords are not there.

They’re stored in /etc/shadow, which requires special permissions.

This exists for security reasons. If everything was stored in one place, anyone could read sensitive data.

The problem it solves is protecting user credentials.

But the insight here was deeper:

Linux separates identity from authentication.

/etc/passwd → who you are
/etc/shadow → how you prove it

That separation makes the system more secure by design.

Permissions - Built-In Security, Not an Add-On

When I ran:

ls -l

I saw things like:

-rwxr-xr--

At first, it looked confusing. But then i understood: this is how Linux controls access to every file.

Permissions exist because not every user should have full control over everything.

The problem it solves is unauthorized access and system damage.

But what really stood out was:

Security in Linux is not something extra.
It is built directly into the file system itself.

Every file carries its own rules.

`/proc` - Where I Saw the System Live

This was the most surprising part

I explored:

cd /proc
ls

And then:

cat /proc/cpuinfo
cat /proc/meminfo

What I realized is: These are not real files stored on disk. They are generated in real time by the kernel. This exists so users and programs can access live system data.
The problem it solves is system monitoring.

But the insight here blew my mind:

When I read these files, I’m not reading stored data.
I’m interacting with the system live.

It felt like I was directly talking to Linux.

`/dev` - Where Hardware Becomes Files

Then I explored:

ls /dev

I saw entries for disks, terminals, and devices.

This exists because Linux treats hardware as files.

The problem it solves is complexity. Instead of learning different ways to interact with devices, everything becomes file operations.

And the insight here was simple but powerful: In Linux, everything is unified under one idea: files.

That consistency makes the system elegant.

`/boot` - The Starting Point of Everything

Finally, I checked:

ls /boot

This folder contains the kernel and bootloader files.

This exists because the system needs instructions to start itself. The problem it solves is system initialization.
And the insight: Without /boot, Linux cannot even begin to run.

It’s literally where everything starts.

`/var/log/secure` - Who Tried to Enter My System?

While exploring logs, I went deeper:

So I ran:

sudo tail -f /var/log/secure

And what I saw was honestly eye-opening.

This file logs things like:

login attempts
sudo usage
authentication failures

Basically… anything related to who is trying to access the system.

This exists because systems need to keep track of access.

Who logged in
Who tried and failed
Who used admin privileges

Without something like this, there would be no way to monitor system security.

The problem it solves is pretty serious. If something suspicious happens, like:

repeated failed login attempts
unauthorized access
misuse of sudo

you need a way to trace it. And that’s exactly what this file does. The insight here really changed how I see system logs.

Linux doesn’t constantly warn you about everything.
Instead, it quietly records everything in the background.

And this file becomes like a security audit trail. If someone tries to break into your system… the evidence is already there.

`/dev/null` - The Black Hole of Linux

This one was honestly one of the coolest discoveries.

I started with something simple:

ls /dev/null

Then I tried this:

echo "hello" > /dev/null

And… it disappeared.

No output. Nothing showed up anywhere. That’s when I realized what was happening.

/dev/null is a special file that discards anything written to it. This exists because sometimes, you don’t care about output. Maybe a command is producing too much noise, or you just want to run something silently.

The problem it solves is simple but important. Without /dev/null:

your terminal would get cluttered
scripts would print unnecessary output
things would become harder to manage

The insight here was actually pretty cool.

/dev/null is like a black hole. Anything goes in… and nothing comes out. And suddenly, this made sense:

command > /dev/null 2>&1

This basically tells the system:

Run the command, but don’t show me anything.

And now I finally understood why developers use it so often.

`systemd` - The Hidden Manager Running Everything

Then I got curious about what’s running behind the scenes.

So I explored:

cd /etc/systemd/system
ls

At first, it just looked like a bunch of configuration files.

But then it clicked. This is where system services are defined and managed.

systemd is basically the component that handles:

services
startup processes
background tasks

It’s the reason your system feels “alive” even when you’re not doing anything.

This exists because modern systems need automation. You don’t manually start things like:

networking
logging
system monitoring

Every time you boot your system.

The problem it solves is huge. Without something like systemd you would have to manually start every service after boot . Which is clearly not practical. The insight here was interesting. Even when I’m doing nothing…
Linux is still running multiple services silently in the background. Things just work because systemd is managing everything for me.

`/boot/grub2/grub.cfg` - The First Instructions Linux Follows

This one felt powerful.

I ran:

cat /boot/grub2/grub.cfg

And I was looking at the configuration used by GRUB the bootloader.

This file tells the system:

which kernel to load
how to start Linux

This exists because before Linux even starts, something needs to:

initialize the system
load the kernel
hand over control to the OS

And that’s exactly what the bootloader does.

The problem it solves is fundamental. Without this configuration:
the system wouldn’t even know how to boot. No startup. No OS. Nothing.

The insight here made me realize how critical this file is. This is literally where the system’s startup behavior is defined. If this file gets corrupted Linux won’t even start
And that’s when it hit me… This isn’t just another config file. This is the starting point of everything.

After exploring all these parts, one thing became very clear to me:

Linux is not just an operating system
It is a collection of well-structured systems connected through files

From booting → to users → to networking → to logs

Everything is transparent, accessible, & understandable.
And once you start exploring it like this… you stop guessing and start understanding.

Linux is not hiding anything from you.
Everything is there in files, waiting to be explored.

The moment you stop just using Linux… and start reading it… that’s when things finally start clicking.

Understanding Variables and Data Types in JavaScript

Sat, 25 Apr 2026 04:08:11 +0000

I remember when i first started learning JavaScript everything was so confusing, i felt completely overwhelmed.
Variables, Data Types, let, const, Scope, Hoisting, Temporal Dead Zone (TDZ)... ahh so many things.

It felt like everyone else understand it and i was just trying to memorize these things without actually understanding what was going on under the hood.

So in this blog i’m going to cover and explain slowly, clearly & practically everything the way i wish someone had explained it to me when i started learning JavaScript.

By the end of this blog you won’t just know the definitions but you will understand how JavaScript behaves actually.

So let’s start from the very beginning.

What are JavaScript Variables?

Let’s forget the technical definition for now and think of a variable like a box
So start with this Imagine you have a box

You put something inside it
Write a lable on it
Open it later to see what’s inside the box
Later replace what’s inside if needed

That box is exactly what a variable is

In JavaScript a variable is simply a named container that stores data so we can use it later.

for example:

let name = "Nausheen";

How I see it in my head:

name => the label on the box
"Nausheen" => what's inside the box

But the question is: Why do we need variables?
The reason is simple because programs need memory

When you log into a website, it needs to remember:

Your username
Your password
Whether you’re logged in or not
What’s in your cart

Without variables, JavaScript wouldn’t be able to remember anything not even for a second.

Variables are the foundation of everthing

How I Declare Variables (var, let, const)

Here we go In JavaScript, we have three ways to create variables:

var
let
const

But the thing is they are not the same. And this is where beginners usually get confused.
So, let me break it down the way I personally understand it and where to use them.

1. var (old way)

var age = 20;

yup simple, this is how it works.

And yes, you can also change it:

age = 21;

But here’s what I’ve learned over time:
var has some strange behaviors that can create confusion in larger programs.

For example:

var city = "Delhi";
var city = "Mumbai"; // No error

It allows redeclaration in the same scope.

That might not seem dangerous now, but in a big project, this can silently overwrite values & cause bugs that are hard to track.

That’s why in morder JavaScript, we mostly avoid var

Not because it’s bad, but because there are safer alternatives.

2. let (Flexible and Modern)

let score = 50;

I use let when I know that value might change later.

score = 60; // Perfectly fine

But here’s something important:

let score = 70; // Error

You cannot redeclare a let variable in the same scope.

And honestly, I like this.
Because it prevents accidental mistakes.

3. const (Fixed and Safe)

const birthYear = 2004;

Ok so, when I write const I'm basically saying:

I don’t want this value to change

And JavaScript respects that.

birthYear = 2005; // Error

This is why I personally follow this rule:

I use const by default
I switch to let only when I need to change the value

This makes code safer and more predictable.

Difference Between var, let, and const

If you’re just starting out, here’s what I’d suggest you:

Use const most of the time
Use let when necessary
Forget var for now

What Are Data Types?

What’s Inside the Box?

Now let’s talk about what we actually store inside variables.

When I say "data type" I'm simply asking:
What kind of value is inside this variable?

If variables are boxes, data type describes what kind of thing is inside the box.

In JavaScript, there are many types. But as beginners, we focus on primitive data types.

Basically, there are two categories of data types:

Primitive Data Types
Non-Primitive Data Types

But in this blog, we will only focus on primitive data types.

The main primitive types in JavaScript are:

String
Number
Boolean
Null
Undefined

Let’s understand them properly

1. String - Text Data

Whenever I want to store some text data, I use a string.

let name = "Nausheen";
let message = "Hello World";

String are always written inside quotes.
Without quotes, JavaScript thinks it’s a variable name.

Strings are used for:

Name
Emails
Messages
Addresses

Basically, anything that’s text.

2. Number - Numeric Values

let age = 21;
let price = 99.99;

In JavaScript, there is only one number type.

It doesn’t seperate integers and decimals unlike many other programming languages

Whether it’s 21 or 99.99 , both are simply number.

Numbers are used for:

Age
Score
Prices
Calculations

3. Boolean - True or False

Booleans are very simple but very powerful.

They only have two values:

true
false

let isLoggedIn = true;
let hasPermission = false;

Booleans are mainly used in decisions.

For example:

Is the user logged in?
Did the form submit successfully?
Is the password correct?

Most conditions in programming rely on booleans.

4. null - Intentionally Empty

When I use null, I'm basically saying:

I’m intentionally keeping this empty for now.

let selectedUser = null;

This means:
I will assign a real value later.

5. undefined - Not Assigned Yet

If i declare a variable but don’t give it a value:

let score;

JavaScript automatically assigns it undefined.

That means:
The variable exist, but nothing is inside it yet.

The difference between null and undefined is subtle but important:

undefined => JavaScript gives it automatically
null => You assign it intentionally

What is Scope?

When I first heard the word scope, it sounded technical and abstract. But one I simplified it in my mind everything become clearer.

So, Scope simply answers one question:
Where can I access this variable?

That’s it……

Scope determines the visibility & accessibility of variables in different parts of your prograrm.

Let’s take an example of “The Rooms in a House”
Imagine scope as rooms inside a house

Each { } block is like a separate room.

If I place something inside one room, I can only access it inside that room. I cannot randomly walk into another room & expect that thing to be there.

In JavaScript, a block looks like this:

{
    let message = "Hello there";
    console.log(message); // It works
}
console.log(message); // ReferenceError

Here, message was created inside the block (inside the "room").

So when we try to access it outside the block, JavaScript throws a ReferenceError.

Not because the value is undefined
But because it does not exist in that scope.

That’s an important distinction.

Block Scope (let & const)

Variables declared using let and const follow block scope.

A block is anything inside { }:

if statements
for loop
while loop
plain curly braces
function

if (true) {
    let age = 22;
}
console.log(age); // ReferenceError

Here, age only exists inside that if block.

Once execution leaves that block, the variable is gone.

This behavior makes your code safer because:

It prevents accidental overwriting of variables
It avoids naming conflicts
It keeps variables limited to where they are needed

This is one of the main reason why JavaScript prefers let and const.

They give you controlled scope.

Function Scope

Before ES6, Javascript only had function scope.

That means variables declared with var are accessible anywhere inside the function they were declared in regardless of blocks.

function test() {
    if (true) {
        var name = "Nausheen";
    }
    
    console.log(name); // works
}

Even though name was declared inside the if block, it is accessible outside that block but still inside the function.

Why?
Because var doesn't follow block scope.

This difference is the root cause of many bugs in older JavaScript code.

Why `var` Is Problematic?

Let’s look at this code example:

if (true) {
    var count = 10;
}
console.log(count); // Works (unexpected behavior for beginners)

Here, count leaks outside the block.

This can cause:

Variable collisions
Hard to debug errors
Accidental overwrites
Confusing behavior in loops

That’s why modern JavaScript discourages to use var unless absolutely necessary.

Global Scope

If we declare a variable outside of any block or function, it belongs to the global scope.

Let’s see a Example:

let globalMessage = "Hi"; // Global variable
function greet() {
    console.log(globalMessage); // Accessible
}

Global variables can be accessed everywhere in the program.

But here’s the danger:

Too many global variables make your code messy & hard to maintain.
Think of global scope as the entire house, if you throw everything in the living room, it becomes chaos.

Good developers minimize global scope usage.

Function Inside Function

Until now, we talked about scope like rooms in a house.

Let’s now imagine something more interesting
what if a room had another room inside it?

Now let’s see what happens when functions are inside other functions…

Yes this is completely valid look at this code:

function outer() {
    let outerMessage = "Hello from outer";
    function inner() {
        console.log("Hello from inner");
    }
    
    inner();
}
outer();

Here, outer is one room, inner is smaller room inside it.

Now let’s test something important.

function outer() {
    let outerMessage = "Hello from outer";
    function inner() {
        console.log(outerMessage); // works
    }
    
    inner();
}
outer();

The inner function can access the outer function’s variable.

But, can outer access inner’s variable to, let test that also.

function outer() {
     function inner() {
        let secret = "Hidden"
    }
    
    inner();
    console.log(secret); // Error
}
outer();

Oops outer cannot access inner’s variables.

So, remember access only flow upward means:
Child -> Parent
Never Parent -> Child

This idea is the foundation of lexical scope.

But before we go there……
First we need to understand something deeper.

How JavaScript actually runs you code

How JavaScript Actually Runs Your Code (Execution context)

Most beginners think JavaScript reads code line by line.

Reads line 1
Then line 2
Then line 3…

But that’s not exactly true.

JavaScript runs your code in two phases.
And this is where everything changes.

Phase 1: Memory Creation Phase

Before executing anything…

JavaScript first scans you entire code.

It allocates memory for variables
Stores function declarations
Sets up scope

But keep this in mind:

Variables don’t get their real values yet.

var => initialized with undefined
let and const => created but not initialized
Functions => fully stored in memory

console.log(name); // undefined
var name = "Nausheen";

undefined why?

Because during memory phase:

var name = undefined;

Then during execution phase:

name = "Nausheen";

This behavior is called hoisting, but we’ll go deeper into that soon… yes we’re going to cover that too.

Phase 2: Code Execution Phase

Now JavaScript starts running the code line by line.

Values are assigned
Functions get executed
console.log() run

Memory Phase always comes first
Then comes the Execution Phase

Simple as that. Yes nothing scary

Call Stack

Every time a function runs… JavaScript creates a new execution context.

These execution contexts are stacked on top of each other.
Think of the call stack like a stack of plates

When you call a function:

Javascripit puts that function on top of the stack

When the function finishes:

JavaScript removes it from the top

That’s it

It always works Last In, First Out (LIFO).
The last function added is the first one removed

function one() {
    two();
}
function two() {
    console.log("Hello");
}
one();

Let’s see what happens step by step:

Global code starts running
one() is called -> added to stack
Inside one(), two() is called -> added on top
two() finishes -> removed
one() finishes -> removed
Back to global

So, flow looks llike this:

Global
one()
two()

Then it goes backward:

two() removed
one() removed
back to Global

This is how JavaScript manages execution

Hoisting - What It Actually is (And What Most People get Wrong)

Now that you understand execution context… Hoisting will make sense.

When I first learned hoisting, someone told me:

JavaScript moves variables to the top

And honestly?..

That explanation confused me more than it helped.

Because JavaScript doesn’t physically move your code
Nothing jumps to the top
Your code stays exactly where you wrote it.

So the question is what’s really happening?

To understand hoisting properly, we have to go back to something we already learned:

Execution context

Memory Phase

Execution Phase

Hoisting is simply a result of how JavaScript prepares memory before running code.

How `var` Hoisting Actually Works

Let’s see:

console.log(name); // undefined
var name = "Nausheen";

Output is undefined why not error?

Because during memory phase
JavaScript does this internally:

var name = undefined;

Then during execution phase:

name = "Nausheen";

So when console.log runs,
name exists but its value is undefined

So, remember this is important:

var is declared during compilation
It is also initialized to undefined during compilation

That’s why it’s accessible early.

Why `var` Can Be Dangerous

Now look at this:

function example() {
  console.log(x); // undefined
if (false) {
    var x = 10;
  }
  console.log(x); // undefined
}
example();

undefined
undefined

Even though the if block never ran.

Why?
Because var x was hoisted to the function scope.

This is the dangerous part.
var ignores block scope.

It can silently create undefined variables in unexpected places.

This is one of the biggest reasons modern JavaScript prefers let and const.

Function Hoisting

Function declarations behave differently it’s even more powerful.

They are not just declared
They are fully initialized during compilation

greet();
function greet() {
  console.log("Hello!");
}

This works perfectly.

Because during compilation:

greet: [complete function stored in memory]

The entire function body is available before execution begins.

That’s why function declarations are called:
Fully hoisted

Function Expression vs Function Declaration

Now this is important.

sayHi();
var sayHi = function () {
  console.log("Hi");
};

Now this throws:
TypeError: sayHi is not a function

Why?
Because only variable is hoisted

var sayHi = undefined;

Which causes the error.

The difference is

Function Declaration => Fully hoisted
Function Expression => Only variable hoisted

Now Let’s Talk About `let` and `const`

Here’s where things get misunderstood

Many people say:

let and const are not hoisted

That is wrong…

They are hoisted

But they behave differently

During compilation:

let and const are registered in memory
But they are NOT initialized

This creates something called… TDZ

Temporal Dead Zone (TDZ)

Another scary term TDZ. Ahh, now what’s that?
Don’t worry. I’ll keep it simple

This is one of the most misunderstood concepts.

The Temporal Dead Zone is:

The time between when a variable is hoisted

*And when it is initialized

Let’s see it:

console.log(age);
let age = 25;

This throws:
ReferenceError: Cannot access 'age' before initialization

Why?
Beause:

age exists in memory
But it is uninitialized
It is in the Temporal Dead Zone

The TDZ starts:
At the beginning of the block

And ends:
At the line where the variable is declard

TDZ Is About Time, Not Position

Very important, TDZ is not about where the variable is written.
It’s about time.

function test() {
  console.log(score);
  let score = 100;
}
test();

From the moment the function starts running,
score exists.

But until let score = 100 executes,
it is in the TDZ.

That’s why accessing it throws an error.

Proof That let Is Actually Hoisted

Look at this:

let x = "outer";
function demo() {
  console.log(x);
  let x = "inner";
}
demo();

This throws ReferenceError.

If let x inside demo was NOT hoisted,
JavaScript would use the outer x and print "outer".

But it doesn’t.

Why?
Because the inner x is hoisted to the function scope.
It creates a TDZ.

That proves:

let is hoisted
It is not initialized

That difference change everything.

How const Behaves

const works exactly like let regarding hoisting and TDZ.

But with one extra rule:
You must initialize it immediately.

const name; // SyntaxError

Correct:

const name = "Nausheen";

It is hoisted.
It has TDZ.
But it must be initialized.

Common misconceptions you should always remember

“Hoisting moves code to the top”
No.

Code stays exactly where you wrote it
Memory is prepared before execution

“Only var is hoisted”
Wrong.

All declarations are hoisted:

var
let
const
function
class

The difference is initialization timing.

“TDZ means variable doesn’t exist”
Wrong.

The variable exists.
It just cannot be accessed yet.

Why TDZ Is Actually a Good Thing

With var, this is allowed:

var total = total + 5;

This creates weird undefined behavior.

With let or const, you immediately get an error.

TDZ protects you from accidental bugs.
It forces cleaner code.
It makes JavaScript safer.