WEBVTT 00:00:00.000 --> 00:00:03.160 So imagine for a second that you are just sitting 00:00:03.160 --> 00:00:06.280 at your computer. You open up a command prompt, 00:00:06.400 --> 00:00:08.759 or maybe you just hit the Windows key and you 00:00:08.759 --> 00:00:11.300 type in a single word. Right, like calculator 00:00:11.300 --> 00:00:15.439 or Python. Exactly, or Chrome. You hit Enter 00:00:15.439 --> 00:00:18.399 and instantly, I mean, in the absolute blink 00:00:18.399 --> 00:00:20.739 of an eye, the program just opens. Yeah, it's 00:00:20.739 --> 00:00:23.019 practically instantaneous. But stop and really 00:00:23.019 --> 00:00:24.899 think about the mechanics of that for a second. 00:00:25.179 --> 00:00:28.079 Your computer's hard drive has What, millions 00:00:28.079 --> 00:00:30.920 of files on it? Oh, easily. Yeah. Spread across 00:00:30.920 --> 00:00:32.899 hundreds of thousands of nested folders. Right. 00:00:33.219 --> 00:00:35.520 So how does the operating system know exactly 00:00:35.520 --> 00:00:39.119 where to find that one specific executable tool 00:00:39.119 --> 00:00:41.520 out of millions, the exact millisecond you ask 00:00:41.520 --> 00:00:43.859 for it? I mean, it's certainly not scanning the 00:00:43.859 --> 00:00:45.719 whole drive from top to bottom every single time. 00:00:45.799 --> 00:00:47.560 No, it definitely isn't. If it did that, it would 00:00:47.560 --> 00:00:52.179 be like trying to find a specific book in a massive, 00:00:52.420 --> 00:00:55.100 unorganized library by reading the sign of every 00:00:55.100 --> 00:00:57.409 single book. On every single shelf. Every time 00:00:57.409 --> 00:00:59.750 you wanted to read, the latency would just make 00:00:59.750 --> 00:01:02.509 the computer completely unusable. So instead, 00:01:02.549 --> 00:01:05.209 the machine relies on a map. But it's a very 00:01:05.209 --> 00:01:08.790 specific, highly structured, and entirely invisible 00:01:08.790 --> 00:01:11.689 map. OK, let's unpack this. Because today, our 00:01:11.689 --> 00:01:14.329 mission for this deep dive is to uncover that 00:01:14.329 --> 00:01:17.790 exact invisible map. It's a fun one. It really 00:01:17.790 --> 00:01:20.430 is. We are looking at a stack of documentation 00:01:20.430 --> 00:01:23.510 today, including this really comprehensive Wikipedia 00:01:23.510 --> 00:01:26.209 article dedicated to something called the path 00:01:26.209 --> 00:01:28.689 variable. Yes, the path environment variable. 00:01:28.810 --> 00:01:31.019 And we aren't just going to read. dry computer 00:01:31.019 --> 00:01:33.739 code today, we are really exploring this as a 00:01:33.739 --> 00:01:36.980 piece of foundational tech geography. This is 00:01:36.980 --> 00:01:39.299 the silent rule book dictating how operating 00:01:39.299 --> 00:01:41.980 systems actually locate and run programs. That 00:01:41.980 --> 00:01:44.359 includes everything from vintage old school Unix 00:01:44.359 --> 00:01:47.000 mainframes all the way up to the modern Windows 00:01:47.000 --> 00:01:48.640 or Mac machine you might be using right now. 00:01:49.000 --> 00:01:51.280 Yeah. But to really grasp how this map functions, 00:01:51.439 --> 00:01:53.540 we kind of have to establish a baseline, right? 00:01:53.659 --> 00:01:56.159 Like, what actually is this thing? Well, at an 00:01:56.159 --> 00:01:58.540 architectural level, It is what computer scientists 00:01:58.540 --> 00:02:01.540 call an environment variable. And the most crucial 00:02:01.540 --> 00:02:03.319 thing for you to understand right out of the 00:02:03.319 --> 00:02:06.540 gate is that an environment variable is not just, 00:02:06.540 --> 00:02:09.539 you know, one global map. It's not carved in 00:02:09.539 --> 00:02:11.979 stone and bolted to the wall for every program 00:02:11.979 --> 00:02:15.360 to share? No, not at all. Instead, each executing 00:02:15.360 --> 00:02:18.939 process and each user session gets its own unique 00:02:19.439 --> 00:02:21.840 customized path setting. Wait, I'm stuck on that. 00:02:21.900 --> 00:02:24.419 If every single app running right now, like your 00:02:24.419 --> 00:02:26.300 browser, your background updaters, your chat 00:02:26.300 --> 00:02:28.219 apps, if they all have their own personalized 00:02:28.219 --> 00:02:30.699 version of this map, doesn't that take up a massive 00:02:30.699 --> 00:02:33.300 amount of system memory? That's a great question, 00:02:33.340 --> 00:02:35.879 but no. The memory footprint of a text string 00:02:35.879 --> 00:02:38.180 is actually miniscule. Yeah. Even if you multiply 00:02:38.180 --> 00:02:40.580 it by 100 processes, it's nothing. Oh, I see. 00:02:40.580 --> 00:02:43.259 So it's just literally text. Exactly. And the 00:02:43.259 --> 00:02:46.460 benefit of having personalized maps far outweighs 00:02:46.460 --> 00:02:49.939 that tiny, tiny memory cost. it provides customized 00:02:49.939 --> 00:02:52.060 context. Give me an example of that. Well, if 00:02:52.060 --> 00:02:55.120 you log into a system, your map of where to look 00:02:55.120 --> 00:02:57.919 for tools might look completely different from 00:02:57.919 --> 00:03:02.139 the system administrator's map. Or, say, a specific 00:03:02.139 --> 00:03:05.500 piece of software might need to run a very specific 00:03:05.500 --> 00:03:07.960 older version of a tool. Like an old version 00:03:07.960 --> 00:03:09.840 of Python or something. Right. Well, the rest 00:03:09.840 --> 00:03:12.599 of the system uses the newest version. So... 00:03:12.599 --> 00:03:15.800 By giving that software its own localized environment 00:03:15.800 --> 00:03:18.520 variable, it can have a custom map that points 00:03:18.520 --> 00:03:20.520 only to the old version. Without breaking the 00:03:20.520 --> 00:03:22.580 rest of the computer. That makes perfect sense. 00:03:23.539 --> 00:03:25.860 It's like giving different departments in a company 00:03:25.860 --> 00:03:28.819 their own specific internal phone directories. 00:03:28.879 --> 00:03:31.060 That's a really good way to put it. But to understand 00:03:31.060 --> 00:03:34.580 why we even need this highly customized invisible 00:03:34.580 --> 00:03:36.599 routing system today, we kind of have to rewind 00:03:36.599 --> 00:03:39.219 the clock. We do. We have to go back to an era 00:03:39.219 --> 00:03:41.479 of computing where machines didn't actually need 00:03:41.479 --> 00:03:43.780 a map at all. Because they basically only had 00:03:43.780 --> 00:03:46.479 one single room for all their tools. Yeah. We're 00:03:46.479 --> 00:03:49.240 going back to the early days of Unix in the 1970s. 00:03:49.479 --> 00:03:52.060 It was a vastly simpler landscape back then. 00:03:52.240 --> 00:03:54.319 Let's use an analogy here for the listener. Imagine 00:03:54.319 --> 00:03:57.840 a carpenter working in a small workshop. And 00:03:57.840 --> 00:04:00.139 this carpenter has decided just for the sake 00:04:00.139 --> 00:04:02.780 of total simplicity, to keep every single tool 00:04:02.780 --> 00:04:06.639 in one giant bucket right in the middle of the 00:04:06.639 --> 00:04:10.020 room. Hammers, screwdrivers, saws, all of it. 00:04:10.300 --> 00:04:13.539 All of it. And he labels this bucket slash bin 00:04:13.539 --> 00:04:15.960 short for binary. So whenever he needs a tool, 00:04:16.360 --> 00:04:18.980 he just reaches into slash bin. Right. And early 00:04:18.980 --> 00:04:22.649 Unix systems operated exactly like this. The 00:04:22.649 --> 00:04:25.470 user interface, which we call the shell, is essentially 00:04:25.470 --> 00:04:27.350 the carpenter's brain that interprets what you 00:04:27.350 --> 00:04:30.490 type it, only looks for program names in that 00:04:30.490 --> 00:04:33.490 one specific directory. Just Slash Bin, which 00:04:33.490 --> 00:04:35.670 is an elegant, highly efficient system, assuming 00:04:35.670 --> 00:04:37.709 you have a very strictly limited number of tools, 00:04:37.910 --> 00:04:39.790 right? Assuming is the key word there. Because 00:04:39.790 --> 00:04:42.350 the single bucket system quickly broke down under 00:04:42.350 --> 00:04:44.170 the weight of progress. People just kept making 00:04:44.170 --> 00:04:46.449 more tools. Exactly. By the time we get to version 00:04:46.449 --> 00:04:48.670 3 of Unix, the Slash Bin directory had simply 00:04:48.670 --> 00:04:51.139 become too large. Operating systems were doing 00:04:51.139 --> 00:04:53.279 more. Developers were writing more utilities. 00:04:53.759 --> 00:04:56.319 And the storage limitations of early disk drives 00:04:56.319 --> 00:04:58.339 meant they literally couldn't fit everything 00:04:58.339 --> 00:05:00.740 onto the physical disk partition assigned to 00:05:00.740 --> 00:05:03.339 slash bin. Right. The system desperately needed 00:05:03.339 --> 00:05:06.100 another directory, like a second bucket. So they 00:05:06.100 --> 00:05:07.839 needed to build an expansion to the workshop. 00:05:08.379 --> 00:05:10.939 Precisely. So they created slash versus slash 00:05:10.939 --> 00:05:14.939 bin on a separate disk. But creating the folder 00:05:14.939 --> 00:05:17.779 introduces a massive logical hurdle. Because 00:05:17.779 --> 00:05:21.100 the operating system previously only knew to 00:05:21.100 --> 00:05:24.600 look blindly into one bucket. Yes. How do you 00:05:24.600 --> 00:05:27.639 program the shell to look in two places? And 00:05:27.639 --> 00:05:30.540 more importantly, in what priority order? If 00:05:30.540 --> 00:05:32.620 there are two hammers, which one does it grab? 00:05:32.980 --> 00:05:35.720 Ah. Thus the concept of a search path became 00:05:35.720 --> 00:05:38.339 officially baked into the operating system. Yeah. 00:05:38.639 --> 00:05:41.279 But if we connect it to the bigger picture, the 00:05:41.279 --> 00:05:43.680 fundamental concept of a search path actually 00:05:43.680 --> 00:05:46.259 originated even earlier than Unix. Hey, really? 00:05:46.399 --> 00:05:47.959 I always thought of Unix as kind of the absolute 00:05:47.959 --> 00:05:50.139 bedrock of modern OS architecture. Well, it's 00:05:50.139 --> 00:05:52.540 the bedrock that survived, yeah. But it was heavily 00:05:52.540 --> 00:05:56.040 influenced by a preceding, incredibly ambiguous 00:05:56.040 --> 00:05:58.879 mainframe operating system called Multics. Multics? 00:05:58.899 --> 00:06:01.240 I've heard of that. It was a joint project by 00:06:01.240 --> 00:06:04.600 MIT, Bell Labs, and General Electric. And it 00:06:04.600 --> 00:06:07.000 actually pioneered the idea of a hierarchical 00:06:07.000 --> 00:06:10.019 file system and, crucially, the search rules 00:06:10.019 --> 00:06:12.160 for navigating it. But it didn't survive. No. 00:06:12.420 --> 00:06:14.779 Multics ultimately collapsed under its own complexity. 00:06:15.360 --> 00:06:18.300 But the Bell Labs researchers who worked on it 00:06:18.300 --> 00:06:20.680 went on to build Unix. Oh, I see. Yeah, they 00:06:20.680 --> 00:06:23.439 took that complex multi -search concept and stripped 00:06:23.439 --> 00:06:26.980 it down into the elegant, streamlined path variable 00:06:26.980 --> 00:06:30.120 we know today. We are literally still using their 00:06:30.120 --> 00:06:32.899 solution to the overflowing bucket problem half 00:06:32.899 --> 00:06:35.540 a century later. That is wild. Okay, so Unix 00:06:35.540 --> 00:06:37.860 adopts this dynamic string of text to deal with 00:06:37.860 --> 00:06:40.439 the fact that slash bin was overflowing. I want 00:06:40.439 --> 00:06:42.459 to dig into the actual mechanics of how this 00:06:42.459 --> 00:06:45.139 works. Let's do it. understanding is that on 00:06:45.139 --> 00:06:47.240 modern Unix -like systems, and that includes 00:06:47.240 --> 00:06:50.360 Linux and Mac OS today, the operating system 00:06:50.360 --> 00:06:52.819 treats this map like a high -security vault. 00:06:53.019 --> 00:06:55.240 The rules are incredibly rigid. They are completely 00:06:55.240 --> 00:06:57.819 unforgiving. Yeah. And to keep things standardized, 00:06:58.079 --> 00:07:01.279 there is a family of standards called POCX, right? 00:07:01.620 --> 00:07:04.379 Which essentially defines how a Unix -like OS 00:07:04.379 --> 00:07:07.420 should behave. Correct. And under POSIX standards, 00:07:07.800 --> 00:07:10.959 the environment variable is written as $PATH. 00:07:11.149 --> 00:07:13.550 usually in all capital letters. Right. And the 00:07:13.550 --> 00:07:16.750 way you format this map is vital. It is a single 00:07:16.750 --> 00:07:19.290 continuous string of text containing directory 00:07:19.290 --> 00:07:22.449 names, and those names are separated by one specific 00:07:22.449 --> 00:07:24.949 delimiter character. The colon. The colon. So 00:07:24.949 --> 00:07:28.149 it's just a raw text string, like slash bin colon 00:07:28.149 --> 00:07:32.810 slash E -U -R slash bin. Exactly. Wait. If this 00:07:32.810 --> 00:07:35.209 map relies entirely on the colon to know where 00:07:35.209 --> 00:07:38.160 one folder ends and the next begins. What happens 00:07:38.160 --> 00:07:40.279 if I name a folder with a colon in it? Oh boy. 00:07:40.480 --> 00:07:42.540 Like, let's say I create a directory called project 00:07:42.540 --> 00:07:45.240 colon alpha. Does the map just break? It absolutely 00:07:45.240 --> 00:07:47.399 breaks. Yeah. Yeah, it's a hard limitation of 00:07:47.399 --> 00:07:49.899 the string parsing logic. Really? Just from a 00:07:49.899 --> 00:07:53.019 folder name? Yep. The parser inside a shell program, 00:07:53.139 --> 00:07:55.459 like the dash shell or the bash shell, reads 00:07:55.459 --> 00:07:58.100 that text string character by character. So the 00:07:58.100 --> 00:08:01.459 moment the CPU sees a colon and memory, it instantly 00:08:01.459 --> 00:08:03.740 interprets it as, end of this directory, start 00:08:03.740 --> 00:08:06.060 of the next. So there's no way around it? No, 00:08:06.060 --> 00:08:08.430 there is no escape character. You cannot tell 00:08:08.430 --> 00:08:10.889 the system, hey, this next colon is just part 00:08:10.889 --> 00:08:14.230 of a word. If you try to add projects colon alpha 00:08:14.230 --> 00:08:17.050 to your path, the system would search a folder 00:08:17.050 --> 00:08:19.949 named project, fail, and then try to search a 00:08:19.949 --> 00:08:23.310 separate folder named alpha. A whole naming convention 00:08:23.310 --> 00:08:25.790 outlawed just because of how the underlying map 00:08:25.790 --> 00:08:28.529 is drawn. I love quirks like that. It was a very 00:08:28.529 --> 00:08:30.410 literal system. So when the shell is reading 00:08:30.410 --> 00:08:32.509 the string, what exactly is the computer doing 00:08:32.509 --> 00:08:34.490 under the hood? Walk us through the microsecond, 00:08:34.590 --> 00:08:36.940 I hit enter on my keyboard. OK, so you... type 00:08:36.940 --> 00:08:39.980 a command, say python, and hit enter. The shell 00:08:39.980 --> 00:08:42.539 reads your dollar sign path variable strictly 00:08:42.539 --> 00:08:44.559 from left to right. Left to right. Got it. It 00:08:44.559 --> 00:08:46.519 takes the first directory, let's say slash bin, 00:08:46.820 --> 00:08:49.000 and appends your command to it. So it's looking 00:08:49.000 --> 00:08:53.120 for a file named slash bin slash python. It asks 00:08:53.120 --> 00:08:56.039 the file system, does this exist? And if it doesn't? 00:08:56.200 --> 00:08:58.620 If the answer is no, it immediately moves to 00:08:58.620 --> 00:09:01.179 the directory after the first colon. It tries 00:09:01.179 --> 00:09:05.220 slash bin slash python. Right. And it just repeats 00:09:05.220 --> 00:09:06.860 this until it gets a yes from the file system. 00:09:06.919 --> 00:09:09.080 And once it gets that yes? It triggers what is 00:09:09.080 --> 00:09:11.879 known as an exec call. This is an operation where 00:09:11.879 --> 00:09:14.700 the operating system pulls the trigger, allocating 00:09:14.700 --> 00:09:18.460 memory and CPU time to spark that specific file 00:09:18.460 --> 00:09:21.580 into life as a brand new child process. The search 00:09:21.580 --> 00:09:24.179 is over, and your program is running. Precisely. 00:09:24.519 --> 00:09:26.779 So what are the standard stops on the map for 00:09:26.779 --> 00:09:29.840 a typical Unix user? Well, for a standard user, 00:09:30.360 --> 00:09:32.620 the dollar sign path will typically include that 00:09:32.620 --> 00:09:35.100 original bucket slash bin plus the expansion 00:09:35.100 --> 00:09:38.220 bucket slash user slash bin. Often you'll also 00:09:38.220 --> 00:09:41.039 see slash user slash local slash bin for software 00:09:41.039 --> 00:09:42.799 you've compiled yourself. OK, pretty straightforward. 00:09:43.019 --> 00:09:46.320 But now, if you are the super -rooser, The system 00:09:46.320 --> 00:09:48.360 administrator with absolute control, your map, 00:09:48.500 --> 00:09:51.240 gets some extra highly restricted locations appended 00:09:51.240 --> 00:09:54.019 to it. You get slash bin and slash user slash 00:09:54.019 --> 00:09:56.740 bin. What does the 10 stand for? System or super 00:09:56.740 --> 00:09:59.580 user binaries. These contain deep administration 00:09:59.580 --> 00:10:02.559 commands like disk formatting tools that regular 00:10:02.559 --> 00:10:04.720 users shouldn't have anywhere near their search 00:10:04.720 --> 00:10:08.000 path. Ah, so the system admin gets a VIP pass 00:10:08.000 --> 00:10:10.740 to the secure tool sheds. Here's where it gets 00:10:10.740 --> 00:10:13.059 really interesting though. We've established 00:10:13.059 --> 00:10:15.360 that administrators treat this like a high -security 00:10:15.360 --> 00:10:18.080 vault, and that strictness comes down to one 00:10:18.080 --> 00:10:21.519 specific directory that regular users are often 00:10:21.519 --> 00:10:23.879 tempted to add to their map just out of sheer 00:10:23.879 --> 00:10:27.120 convenience. The current directory. Yes. In Unix, 00:10:27.379 --> 00:10:30.740 this is represented simply by a single dot. Sometimes 00:10:30.740 --> 00:10:33.740 a user will tweak their configuration to add 00:10:33.740 --> 00:10:36.600 the dot to the very front of their dollar sign 00:10:36.600 --> 00:10:39.100 path string. And what does that actually mean? 00:10:39.629 --> 00:10:41.730 instruct the operating system to do. It basically 00:10:41.730 --> 00:10:44.029 says before you check the standard buckets, before 00:10:44.029 --> 00:10:46.169 you look anywhere else, just look right here 00:10:46.169 --> 00:10:48.429 in the folder I am currently standing in. I can 00:10:48.429 --> 00:10:50.350 totally see the appeal of that. Like if I download 00:10:50.350 --> 00:10:52.750 a custom script to my downloads folder, I can 00:10:52.750 --> 00:10:54.629 just open a terminal, type the name of the script, 00:10:54.669 --> 00:10:56.330 and run it. I don't have to type out the whole 00:10:56.330 --> 00:10:59.190 long directory path. It's very convenient, but 00:10:59.190 --> 00:11:02.070 system administrators explicitly forbid this. 00:11:02.509 --> 00:11:05.639 They tell you to never ever put the current directory 00:11:05.639 --> 00:11:08.059 in the dollar sign path. Why are they so paranoid 00:11:08.059 --> 00:11:11.419 about it? Because of a severe security vulnerability, 00:11:12.019 --> 00:11:14.320 often delivered via a payload known as a tar 00:11:14.320 --> 00:11:17.100 bomb. A tar bomb. Okay, so if an attacker knows 00:11:17.100 --> 00:11:19.559 I'm lazy and I've put my current directory at 00:11:19.559 --> 00:11:22.159 the front of the map, could they just drop a 00:11:22.159 --> 00:11:24.500 fake tool in a folder I download? Yep. Like, 00:11:24.500 --> 00:11:26.539 name it something completely harmless and just 00:11:26.539 --> 00:11:28.559 wait for me to step on the landmine. You've hit 00:11:28.559 --> 00:11:30.860 on the exact mechanism of the trap. Let's say 00:11:30.860 --> 00:11:33.600 you download an archive file, a tar file, which 00:11:33.600 --> 00:11:35.860 is just the Unix equivalent of a zip file from 00:11:35.860 --> 00:11:38.919 some forum. Right. You extract it. A malicious 00:11:38.919 --> 00:11:42.860 tar bomb is engineered to dump extra hidden files 00:11:42.860 --> 00:11:45.419 directly into your current directory alongside 00:11:45.419 --> 00:11:48.139 the files you actually wanted. Let's say the 00:11:48.139 --> 00:11:50.879 attacker cleverly named their malicious script 00:11:50.879 --> 00:11:54.320 L's. Oh, wow. And ls is the core command to list 00:11:54.320 --> 00:11:56.220 the files in a directory. It's muscle memory. 00:11:56.360 --> 00:11:59.480 I mean, every Unix user types ls 50 times a day. 00:11:59.720 --> 00:12:02.600 Exactly. You unpack the archive, and naturally 00:12:02.600 --> 00:12:04.679 you want to see what files just appeared. You 00:12:04.679 --> 00:12:07.899 type ls and hit Enter. And because your current 00:12:07.899 --> 00:12:10.340 directory, the dot, is at the absolute front 00:12:10.340 --> 00:12:12.340 of your dollar sign path. The operating system 00:12:12.340 --> 00:12:14.559 follows your instructions. It looks at your current 00:12:14.559 --> 00:12:17.740 folder first. It sees the attacker's script named 00:12:17.740 --> 00:12:21.220 ls, assumes that is the tool you requested, and 00:12:21.220 --> 00:12:24.440 executes it. Wow! You just handed control of 00:12:24.440 --> 00:12:26.340 your machine over to malware simply because you 00:12:26.340 --> 00:12:29.000 wanted to list your files. Because the OS found 00:12:29.000 --> 00:12:30.860 a match and stopped looking before it ever reached 00:12:30.860 --> 00:12:33.799 the real legitimate ls command sitting safely 00:12:33.799 --> 00:12:36.659 over in the slashbin directory. That is terrifying. 00:12:36.879 --> 00:12:39.860 It is. And this vulnerability explains why the 00:12:39.860 --> 00:12:43.100 rules are so strict. Unix was built in the 1970s 00:12:43.100 --> 00:12:45.620 for university and corporate mainframes. You 00:12:45.620 --> 00:12:47.720 had 50 different users logged into the same machine 00:12:47.720 --> 00:12:50.460 simultaneously. So you couldn't trust anyone. 00:12:50.740 --> 00:12:52.779 Right. You could not trust the files in a shared 00:12:52.779 --> 00:12:54.799 directory because you couldn't trust the other 00:12:54.799 --> 00:12:58.360 users. The architecture assumes a hostile environment. 00:12:58.600 --> 00:13:01.399 That makes a lot of sense. That is why executing 00:13:01.399 --> 00:13:02.940 a program that is sitting right in front of you 00:13:02.940 --> 00:13:05.659 requires explicit intent. You either type out 00:13:05.659 --> 00:13:08.779 the absolute path, like slash home slash user 00:13:08.779 --> 00:13:11.500 slash script dot, or you use a relative path, 00:13:12.019 --> 00:13:15.500 typing dot slash script dot. Ah, the famous dot 00:13:15.500 --> 00:13:18.179 slash. I've used Linux and Mecos, and I've typed 00:13:18.179 --> 00:13:20.720 dot slash to run scripts a thousand times without 00:13:20.720 --> 00:13:22.600 really thinking about the underlying philosophy. 00:13:22.679 --> 00:13:25.909 To manual override. Right. By typing dot slash, 00:13:26.070 --> 00:13:28.330 you are explicitly bypassing the dollar sign 00:13:28.330 --> 00:13:31.009 path variable entirely. You are telling the shell, 00:13:31.169 --> 00:13:33.250 do not use the map. I am taking responsibility. 00:13:33.710 --> 00:13:36.149 Run the specific file located right here in this 00:13:36.149 --> 00:13:39.269 dot directory. Yes. It ensures you are intentionally 00:13:39.269 --> 00:13:41.970 executing a local file rather than accidentally 00:13:41.970 --> 00:13:44.070 stumbling into a naming trap like a tar bomb. 00:13:44.289 --> 00:13:47.289 OK. So Unix established this incredibly strict 00:13:47.289 --> 00:13:50.769 left to right colon separated map with a foundational 00:13:50.769 --> 00:13:53.309 philosophy of never trusting the current directory. 00:13:53.950 --> 00:13:56.669 But computing didn't stay entirely on shared 00:13:56.669 --> 00:13:59.129 mainframes. Eventually, we get the PC revolution, 00:13:59.750 --> 00:14:02.210 we get graphical user interfaces, we get DOS, 00:14:02.289 --> 00:14:05.629 OS2, and the rise of Windows. When computing 00:14:05.629 --> 00:14:08.269 shifted to those personal platforms, what happened 00:14:08.269 --> 00:14:11.570 to our invisible map? The rules in the map completely 00:14:11.570 --> 00:14:14.529 inverted. Really? Yeah. Microsoft and IBM took 00:14:14.529 --> 00:14:16.870 the concept of the path variable, but they altered 00:14:16.870 --> 00:14:18.769 its core behavior to fit a different paradigm. 00:14:19.429 --> 00:14:21.870 First, there's the syntax. On DOS and Windows, 00:14:22.009 --> 00:14:24.029 the variable is written as percent sign path 00:14:24.029 --> 00:14:26.570 percent sign. Okay. Instead of using colons to 00:14:26.570 --> 00:14:28.909 separate the directories, it uses semicolons. 00:14:29.409 --> 00:14:31.230 Semicolons versus colons? I mean, that's just 00:14:31.230 --> 00:14:33.129 a cosmetic syntax difference, right? Well, the 00:14:33.129 --> 00:14:36.330 syntax is cosmetic, but the behavioral change 00:14:36.330 --> 00:14:40.029 is architectural. In a massive departure from 00:14:40.029 --> 00:14:43.690 those strict Unix security rules, Windows systems 00:14:43.690 --> 00:14:46.149 are hard -coded to search the current working 00:14:46.149 --> 00:14:49.240 directory first by default. Wait, what? Yes. 00:14:49.480 --> 00:14:51.279 Only after it thoroughly searches the folder 00:14:51.279 --> 00:14:53.120 you're currently standing in does it move on 00:14:53.120 --> 00:14:56.779 to read the actual %path % variable, again reading 00:14:56.779 --> 00:14:59.200 left to right. But hold on. Windows engineers 00:14:59.200 --> 00:15:02.500 aren't stupid. Why would they intentionally bake 00:15:02.500 --> 00:15:06.639 a known documented security flaw, the exact tar 00:15:06.639 --> 00:15:08.679 bomb vulnerability we just described into their 00:15:08.679 --> 00:15:11.139 operating system, as the default behavior? Because 00:15:11.139 --> 00:15:13.740 of the context of the hardware. When DOS and 00:15:13.740 --> 00:15:15.200 early Windows were designed, they were running 00:15:15.200 --> 00:15:17.840 on personal computers. The PMBC is key here. 00:15:17.980 --> 00:15:20.879 Right. Personal. These were single -user, isolated 00:15:20.879 --> 00:15:23.080 machines sitting on a desk in a home office, 00:15:23.639 --> 00:15:25.940 completely disconnected from any network. There 00:15:25.940 --> 00:15:28.059 were no hostile university students sharing your 00:15:28.059 --> 00:15:30.159 hard drive. So if a file was in your current 00:15:30.159 --> 00:15:32.159 directory, you almost certainly put it there 00:15:32.159 --> 00:15:35.960 yourself. Precisely. Therefore, convenience and 00:15:35.960 --> 00:15:38.919 ease of use were prioritized over mainframe -style 00:15:38.919 --> 00:15:41.500 paranoia. So the assumption was just if they 00:15:41.500 --> 00:15:43.419 are looking at a folder, they probably want to 00:15:43.419 --> 00:15:45.799 run the things inside it. Exactly. And the way 00:15:45.799 --> 00:15:48.639 Windows searches is also broader. It isn't just 00:15:48.639 --> 00:15:51.000 looking for an exact extensionless file name 00:15:51.000 --> 00:15:53.100 match like Unix often does. What does it look 00:15:53.100 --> 00:15:56.139 for? Windows actively searches for specific executable 00:15:56.139 --> 00:15:59.759 extensions. It takes your command, appends .exe, 00:15:59.980 --> 00:16:03.029 and searches. Then it tries .com. Then it tries 00:16:03.029 --> 00:16:06.690 batch scripts like .bat or .cmd. It just iterates 00:16:06.690 --> 00:16:09.169 through them. Yes. Once it finds a match with 00:16:09.169 --> 00:16:11.590 one of those registered extensions, it spawns 00:16:11.590 --> 00:16:13.809 the new process. This brings up a massive question 00:16:13.809 --> 00:16:16.169 about software installation on Windows, because 00:16:16.169 --> 00:16:19.129 this feels like a recipe for total chaos. Oh, 00:16:19.129 --> 00:16:21.610 it can be. If the Windows system searches the 00:16:21.610 --> 00:16:24.509 percent path percent left to right, and the primary 00:16:24.509 --> 00:16:27.190 critical system directory like C colon backslash 00:16:27.190 --> 00:16:30.470 Windows backslash system 32 is usually the very 00:16:30.470 --> 00:16:32.250 first thing on the list. What happens when I 00:16:32.250 --> 00:16:34.210 install a bunch of new third -party programs? 00:16:34.309 --> 00:16:36.909 Like what kind of programs? Let's say I install 00:16:36.909 --> 00:16:40.429 Node .js and Python and a new graphics driver. 00:16:41.330 --> 00:16:43.629 Do they just quietly wait at the end of the line 00:16:43.629 --> 00:16:45.950 on the right side of the map? They absolutely 00:16:45.950 --> 00:16:47.929 do not wait politely at the end of the line. 00:16:48.330 --> 00:16:50.710 It's like having a VIP bouncer at a club holding 00:16:50.710 --> 00:16:52.990 a list, but every time a new software installer 00:16:52.990 --> 00:16:55.850 arrives, they just bribe the bouncer to write 00:16:55.850 --> 00:16:58.509 their name at the very top of the VIP list, pushing 00:16:58.509 --> 00:17:00.929 the actual owner of the club down to page two. 00:17:01.019 --> 00:17:03.700 No way. Yeah. To speed up their own load times, 00:17:04.019 --> 00:17:05.900 or sometimes to intentionally override existing 00:17:05.900 --> 00:17:08.759 system commands, Windows installers aggressively 00:17:08.759 --> 00:17:11.539 prepend their directory to the very front of 00:17:11.539 --> 00:17:14.740 the %path % variable. they cut in line. Oh man, 00:17:14.759 --> 00:17:16.619 that takes me right back to the old DOS era. 00:17:16.839 --> 00:17:19.140 You used to have to manually referee this process. 00:17:19.160 --> 00:17:21.440 You really did. If you installed a game or a 00:17:21.440 --> 00:17:23.700 utility, you would have to open up this specific 00:17:23.700 --> 00:17:27.500 system file called AutoXXAC .bat in a clunky 00:17:27.500 --> 00:17:30.119 text editor, and you would manually type out 00:17:30.119 --> 00:17:33.160 set path equals new program directory semicolon 00:17:33.160 --> 00:17:35.599 percent path percent. You're manually hard coding 00:17:35.599 --> 00:17:38.500 the map, defining the VIP list every single time 00:17:38.500 --> 00:17:41.160 the computer booted up. You were actively curating 00:17:41.160 --> 00:17:44.670 the priority list. Today, Windows installers 00:17:44.670 --> 00:17:47.569 do that curation for you, silently modifying 00:17:47.569 --> 00:17:50.250 the registry behind the scenes. They prepend 00:17:50.250 --> 00:17:52.190 themselves to the string. But that's got to cause 00:17:52.190 --> 00:17:56.089 problems, right? It does. This constant, invisible 00:17:56.089 --> 00:17:59.259 editing of the map. brings us to a critical degradation 00:17:59.259 --> 00:18:01.380 issue. So what does this all mean for the listener? 00:18:01.579 --> 00:18:04.400 Like, why is managing this invisible string of 00:18:04.400 --> 00:18:07.059 text actually matter to everyday performance? 00:18:07.259 --> 00:18:09.940 I mean, we've got NVMe solid state drives now. 00:18:10.460 --> 00:18:12.519 Processors are lightning fast. Does it really 00:18:12.519 --> 00:18:14.519 matter if the map is a little messy and bloated 00:18:14.519 --> 00:18:17.640 with 50 different software packs? What's fascinating 00:18:17.640 --> 00:18:19.799 here is that the physical speed of your hardware 00:18:19.799 --> 00:18:22.859 cannot negate the sequential logic of the search. 00:18:23.059 --> 00:18:25.609 Still has to do the math. Right. A bloated path 00:18:25.609 --> 00:18:28.029 variable has severe real -world consequences. 00:18:28.470 --> 00:18:31.369 The %path % makes it easy to run programs without 00:18:31.369 --> 00:18:34.369 knowing where they live. But if it is used unwisely, 00:18:34.509 --> 00:18:36.670 you force the operating system into a loop of 00:18:36.670 --> 00:18:38.890 endless busy work. Because it's checking everything. 00:18:39.210 --> 00:18:43.049 Yes. If you have too many locations listed, or 00:18:43.049 --> 00:18:46.730 crucially, invalid locations, like folders belonging 00:18:46.730 --> 00:18:49.670 to software you uninstalled months ago but that 00:18:49.670 --> 00:18:52.430 left their name on the map, the OS still has 00:18:52.430 --> 00:18:54.890 to check them. Because it is blindly following 00:18:54.890 --> 00:18:57.650 the algorithm, it starts at the left, it reads 00:18:57.650 --> 00:18:59.869 the string, goes to a directory that no longer 00:18:59.869 --> 00:19:02.910 exists, queries the file system, waits for the 00:19:02.910 --> 00:19:05.309 folder not found error, realizes it's a dead 00:19:05.309 --> 00:19:07.910 end, backs out, moves to the next semicolon, 00:19:08.009 --> 00:19:09.970 and tries the next one. Every single time you 00:19:09.970 --> 00:19:12.329 type a command, or more importantly, every time 00:19:12.329 --> 00:19:15.049 a background process asks the OS for a resource, 00:19:15.410 --> 00:19:17.789 the CPU is doing this sequential file system 00:19:17.789 --> 00:19:20.480 querying. That's a lot of wasted effort. It slows 00:19:20.480 --> 00:19:22.720 the entire computer down, yeah. It's like death 00:19:22.720 --> 00:19:25.220 by a thousand micro delays. But it actually gets 00:19:25.220 --> 00:19:27.059 much worse than just latency. How does it get 00:19:27.059 --> 00:19:29.559 worse than slowing down? Invalid locations in 00:19:29.559 --> 00:19:32.279 the path can cause silent, catastrophic failures 00:19:32.279 --> 00:19:34.359 of critical background infrastructure. Wait, 00:19:34.660 --> 00:19:37.180 seriously? Our sources highlight a specific scenario 00:19:37.180 --> 00:19:38.940 in an enterprise Windows Server environment. 00:19:39.539 --> 00:19:41.440 There's a core networking component called the 00:19:41.440 --> 00:19:44.000 server service, which handles file and print 00:19:44.000 --> 00:19:46.539 sharing. OK, that sounds important. It's a dependency 00:19:46.539 --> 00:19:49.200 for dozens of other network operations. If the 00:19:49.200 --> 00:19:52.359 system %path % variable becomes corrupted with 00:19:52.359 --> 00:19:55.039 invalid locations or just grows too long for 00:19:55.039 --> 00:19:57.339 the internal buffer to read, that server service 00:19:57.339 --> 00:19:59.539 can simply fail to start when the machine boots. 00:20:00.130 --> 00:20:03.630 Wow. Wait. So an entire corporate network, shared 00:20:03.630 --> 00:20:07.369 drives, printers, databases, could theoretically 00:20:07.369 --> 00:20:09.950 go offline, not because of a complex ransomware 00:20:09.950 --> 00:20:12.329 attack or a hardware failure, but just because 00:20:12.329 --> 00:20:14.710 a string of text with semicolons in it has a 00:20:14.710 --> 00:20:17.710 typo pointing to a folder that was deleted. Yes. 00:20:18.109 --> 00:20:20.150 The map is fundamentally broken, so the system 00:20:20.150 --> 00:20:22.730 simply refuses to navigate. The service throws 00:20:22.730 --> 00:20:25.920 an error and gives up. That is incredible. We've 00:20:25.920 --> 00:20:27.759 covered so much ground today. We've gone from 00:20:27.759 --> 00:20:30.119 a carpenter with a single bucket of tools to 00:20:30.119 --> 00:20:33.660 the overflowing slash user slash bin in early 00:20:33.660 --> 00:20:35.900 Unix mainframes. We really span the decades. 00:20:36.160 --> 00:20:39.299 We have. We've looked at the strict, colon -separated, 00:20:39.420 --> 00:20:42.640 highly paranoid lists of modern PR6 systems, 00:20:43.259 --> 00:20:45.700 all the way to the semi -colon -separated, occasionally 00:20:45.700 --> 00:20:48.299 bloated, line -cutting lists of modern windows. 00:20:48.839 --> 00:20:50.640 And through all of those decades of evolution, 00:20:51.200 --> 00:20:54.299 this simple string of text acts as the invisible 00:20:54.299 --> 00:20:57.609 engine for every single command we run. This 00:20:57.609 --> 00:20:59.650 raises an important question, really. We look 00:20:59.650 --> 00:21:02.970 at our modern devices. They have sleek graphical 00:21:02.970 --> 00:21:06.289 user interfaces, fluid animations, AI voice assistants. 00:21:06.309 --> 00:21:08.670 They feel so futuristic. But underneath all of 00:21:08.670 --> 00:21:11.789 that polished glass, the entire execution environment 00:21:11.789 --> 00:21:15.269 relies entirely on rigid, unforgiving, decades 00:21:15.269 --> 00:21:17.869 -old text strings inherited directly from the 00:21:17.869 --> 00:21:20.190 command line era. It's a skyscraper built on 00:21:20.190 --> 00:21:23.349 very old, very reliable, but very rigid foundations. 00:21:23.609 --> 00:21:25.380 Well said. And that leaves us with a thought 00:21:25.380 --> 00:21:27.660 for you, the listener, to cue on as you go about 00:21:27.660 --> 00:21:30.460 your day. We've seen how the path variable dictates 00:21:30.460 --> 00:21:32.619 the very reality of what a computer can see and 00:21:32.619 --> 00:21:34.680 do. It completely defines the boundaries of its 00:21:34.680 --> 00:21:36.799 world. It is the map. So it makes you wonder, 00:21:37.519 --> 00:21:39.720 what other invisible legacy rules are silently 00:21:39.720 --> 00:21:41.839 running in the background of your everyday devices? 00:21:42.400 --> 00:21:44.839 What other forgotten maps and text strings are 00:21:44.839 --> 00:21:47.160 determining what works, what fails, and what 00:21:47.160 --> 00:21:49.859 poses a security risk before you even click a 00:21:49.859 --> 00:21:50.059 mouse?