WEBVTT 00:00:00.000 --> 00:00:02.120 Have you ever wondered how your computer just, 00:00:02.200 --> 00:00:05.280 well, knows things? Yeah, it really does seem 00:00:05.280 --> 00:00:07.660 like it just knows. Right, like how it magically 00:00:07.660 --> 00:00:10.679 knows exactly where to save your downloaded files 00:00:10.679 --> 00:00:14.880 or what language you speak or even how to find 00:00:14.880 --> 00:00:17.519 a program the very second you type its name into 00:00:17.519 --> 00:00:20.019 a command prompt. It's instant. Exactly. You 00:00:20.019 --> 00:00:22.100 don't have to hand it a map every single time. 00:00:22.239 --> 00:00:24.300 It just, you know, it just knows. It's a kind 00:00:24.300 --> 00:00:26.699 of everyday digital magic that we completely 00:00:26.699 --> 00:00:29.079 take for granted. I mean, we expect the operating 00:00:29.079 --> 00:00:33.039 system to have this flawless situational awareness. 00:00:33.320 --> 00:00:35.320 from the moment we turn the screen on. We really 00:00:35.320 --> 00:00:38.399 do. And today on the deep dive, we are pulling 00:00:38.399 --> 00:00:40.960 back the curtain on that everyday magic. We're 00:00:40.960 --> 00:00:43.679 using the Wikipedia article on environment variables 00:00:43.679 --> 00:00:46.979 as our treasure map, basically, to expose the 00:00:46.979 --> 00:00:48.840 invisible puppet strings running your machine. 00:00:48.920 --> 00:00:50.820 Which is a great way to describe it. Because 00:00:50.820 --> 00:00:53.020 these hidden strings, they dictate the behavior 00:00:53.020 --> 00:00:55.939 of almost every single program you run. Understanding 00:00:55.939 --> 00:00:58.840 them is, well, it's the ultimate shortcut to 00:00:58.840 --> 00:01:00.759 speaking the secret language of your computer. 00:01:01.000 --> 00:01:03.490 And what's wild is most users will go their entire 00:01:03.490 --> 00:01:07.950 lives without explicitly typing out or modifying 00:01:07.950 --> 00:01:10.189 an environment variable. Oh, absolutely never. 00:01:10.430 --> 00:01:13.010 Yeah. Yet their whole digital existence relies 00:01:13.010 --> 00:01:15.769 entirely on these unseen parameters functioning 00:01:15.769 --> 00:01:17.730 perfectly in the background. I like to picture 00:01:17.730 --> 00:01:22.019 it like this. Imagine an invisible room. Every 00:01:22.019 --> 00:01:24.640 time you double -click an icon or launch an app, 00:01:25.079 --> 00:01:27.879 that program wakes up, walks into this invisible 00:01:27.879 --> 00:01:29.959 room, and just looks around. Okay, I like that. 00:01:30.400 --> 00:01:32.060 And pinned to the walls are all these little 00:01:32.060 --> 00:01:35.659 notes, the environment variables. Giving the 00:01:35.659 --> 00:01:38.079 program instructions on how to behave who is 00:01:38.079 --> 00:01:40.680 currently logged in and like where to put things 00:01:40.680 --> 00:01:43.659 that visual works incredibly Well, yeah, but 00:01:43.659 --> 00:01:45.879 you know before we get to reading the notes on 00:01:45.879 --> 00:01:47.439 the wall We need to understand how that room 00:01:47.439 --> 00:01:49.459 gets built in the first place right the construction 00:01:49.459 --> 00:01:52.140 of it exactly Yeah, the architecture of how these 00:01:52.140 --> 00:01:54.439 variables are passed around your computer without 00:01:54.439 --> 00:01:57.409 you ever noticing well It's fundamental to how 00:01:57.409 --> 00:01:59.090 operating systems have functioned for decades. 00:01:59.269 --> 00:02:02.049 We're talking stretching back to version 7 Unix 00:02:02.049 --> 00:02:06.510 in 1979 Wow 1979 yeah and PC DOS in the early 00:02:06.510 --> 00:02:09.789 80s So the core mechanism of how they spread 00:02:09.789 --> 00:02:12.610 through this system It relies on this concept 00:02:12.610 --> 00:02:15.710 of the parent process and the child process right 00:02:15.710 --> 00:02:18.680 when you run a program the parent and that program 00:02:18.680 --> 00:02:21.439 needs to start another program, the child. It 00:02:21.439 --> 00:02:24.139 doesn't just launch the child into a void. It 00:02:24.139 --> 00:02:26.520 passes down its environment. All right, let's 00:02:26.520 --> 00:02:28.379 unpack this. It's like a parent passing down 00:02:28.379 --> 00:02:30.919 their genetic code. But in this case, the DNA 00:02:30.919 --> 00:02:33.340 tells the child process where it lives and what 00:02:33.340 --> 00:02:35.939 it's allowed to do. But that's not quite right, 00:02:36.020 --> 00:02:38.800 is it? Because DNA mixes traits. Yeah, it's not 00:02:38.800 --> 00:02:41.560 a mix. Right. This isn't mixing. It's more like 00:02:41.560 --> 00:02:43.900 a sci -fi cloning vat. A cloning vat is a much 00:02:43.900 --> 00:02:46.120 better analogy. The child doesn't get a mixture 00:02:46.120 --> 00:02:49.039 of traits. It gets a blunt one -to -one duplicate 00:02:49.039 --> 00:02:51.340 of the parent's runtime environment by default. 00:02:51.620 --> 00:02:54.719 Literally an exact copy. Exactly. And at a technical 00:02:54.719 --> 00:02:57.240 level, the system stores these variables as an 00:02:57.240 --> 00:02:59.710 associative array. Which, just to pull away from 00:02:59.710 --> 00:03:01.849 the jargon for a second, is basically a massive 00:03:01.849 --> 00:03:04.610 wall of labeled mailboxes. Yes. The label on 00:03:04.610 --> 00:03:06.669 the outside of the mailbox is the key. Like username 00:03:06.669 --> 00:03:08.689 and whatever data is shoved inside that mailbox 00:03:08.689 --> 00:03:12.150 is the value, like John. Spot on. And the mechanism 00:03:12.150 --> 00:03:14.629 for copying that wall of mailboxes, it happens 00:03:14.629 --> 00:03:17.310 in a microscopic fraction of a second, using 00:03:17.310 --> 00:03:19.629 two fundamental system commands. Okay, what are 00:03:19.629 --> 00:03:22.610 they? They're called fork and exec. In Unix -like 00:03:22.610 --> 00:03:24.530 systems, when a parent wants to create a child, 00:03:24.990 --> 00:03:27.990 it first calls fork. Fork. Got it. Right. And 00:03:27.990 --> 00:03:31.530 this command literally pauses time and creates 00:03:31.530 --> 00:03:34.930 a perfect, identical clone of the parent process. 00:03:35.050 --> 00:03:38.330 Oh, wow. Yeah. The memory, the open files, and 00:03:38.330 --> 00:03:40.590 the environment variables are all perfectly duplicated. 00:03:40.909 --> 00:03:43.689 So now we have two identical programs running. 00:03:43.810 --> 00:03:45.849 Right. But we don't want two of the same program. 00:03:45.889 --> 00:03:48.669 We want the new child program to start. Exactly. 00:03:48.710 --> 00:03:51.030 And this is where the parent has a tiny critical 00:03:51.030 --> 00:03:53.810 window to change the environment variables for 00:03:53.810 --> 00:03:55.909 the child. Ah, so it can meddle a little bit. 00:03:56.050 --> 00:03:58.330 It can. It can add a new note to the wall or 00:03:58.330 --> 00:04:00.490 take one away. And then once the environment 00:04:00.490 --> 00:04:03.610 is properly staged, the clone calls exec. And 00:04:03.610 --> 00:04:06.389 exec is the command that essentially like guts 00:04:06.389 --> 00:04:09.729 the cloned house but leaves the foundation. That's 00:04:09.729 --> 00:04:11.969 a great way to put it. It replaces the clone's 00:04:11.969 --> 00:04:14.210 memory with the brand new program you actually 00:04:14.210 --> 00:04:17.870 wanted to run. But crucially, it deliberately 00:04:17.870 --> 00:04:20.990 leaves that specific slice of RAM holding the 00:04:20.990 --> 00:04:24.089 environment variables completely untouched. If 00:04:24.089 --> 00:04:27.509 we connect this to the bigger picture, this design 00:04:27.509 --> 00:04:30.230 is an absolute master class in software architecture. 00:04:30.610 --> 00:04:34.889 Really? How so? Well, it allows programs to communicate 00:04:34.889 --> 00:04:37.550 complex user preferences completely silently. 00:04:37.769 --> 00:04:40.189 Just imagine if a software developer had to hard 00:04:40.189 --> 00:04:43.790 -code the exact literal path to every single 00:04:43.790 --> 00:04:46.689 user's personal documents folder directly into 00:04:46.689 --> 00:04:49.149 their application's code. Oh, that would be impossible. 00:04:49.550 --> 00:04:51.290 I mean, everyone's computer is set up differently. 00:04:51.410 --> 00:04:53.389 My files might be on a D drive. Yours might be 00:04:53.389 --> 00:04:56.089 on a network server. Exactly. By inheriting the 00:04:56.089 --> 00:04:57.769 environment, the app doesn't need to know anything. 00:04:57.889 --> 00:05:00.110 It just asks the room. Right. It simply wakes 00:05:00.110 --> 00:05:02.689 up PostExec, looks at the wall of mailboxes, 00:05:02.689 --> 00:05:05.209 and asks the system, hey, where does this specific 00:05:05.209 --> 00:05:08.050 user keep their files? and the variable provides 00:05:08.050 --> 00:05:09.970 the tailored answer. Wait, this breaks down when 00:05:09.970 --> 00:05:12.490 we talk about admin privileges, right? Because 00:05:12.490 --> 00:05:14.990 if I launch a program that requires root access, 00:05:15.050 --> 00:05:18.750 like a core system updater, I am the parent process, 00:05:18.769 --> 00:05:21.550 but I'm just a regular user. I shouldn't be allowed 00:05:21.550 --> 00:05:24.649 to pass my lowly, potentially compromised user 00:05:24.649 --> 00:05:28.410 variables up to a program with god mode access 00:05:28.410 --> 00:05:30.649 on the machine. You've hit on one of the most 00:05:30.649 --> 00:05:33.149 dangerous security tensions in operating system 00:05:33.149 --> 00:05:36.930 design. Really? Oh yeah. If a child process blindly 00:05:36.930 --> 00:05:39.569 trusts the environment handed down to it by the 00:05:39.569 --> 00:05:42.730 parent, the system is highly vulnerable. This 00:05:42.730 --> 00:05:45.709 is particularly prevalent with Unix Satuid programs. 00:05:45.889 --> 00:05:48.889 Right. Satuid meaning set user ID. These are 00:05:48.889 --> 00:05:51.290 programs designed to run with elevated authority, 00:05:51.769 --> 00:05:53.949 usually system administrator or root authority, 00:05:54.149 --> 00:05:57.149 even if a regular unprivileged user like me is 00:05:57.149 --> 00:05:59.149 the one who double clicked them. Exactly. They 00:05:59.149 --> 00:06:01.610 need that power to do things like change passwords 00:06:01.610 --> 00:06:04.189 or update network configurations. Here's where 00:06:04.189 --> 00:06:06.850 it gets really interesting. If anyone can define 00:06:06.850 --> 00:06:09.629 these variables, couldn't I just trick a highly 00:06:09.629 --> 00:06:12.889 secure program by telling it its library is actually 00:06:12.889 --> 00:06:15.730 a folder full of my own malicious code? You absolutely 00:06:15.730 --> 00:06:17.930 could. And historically, malicious actors have 00:06:17.930 --> 00:06:20.889 tried exactly that. Because programs often rely 00:06:20.889 --> 00:06:23.410 on external pieces of shared code to function, 00:06:23.970 --> 00:06:25.689 rather than carrying all the code themselves. 00:06:26.069 --> 00:06:29.269 In Unix, environment variables like LDLibraryPath 00:06:29.269 --> 00:06:32.230 and LDPreReload tell the system's dynamic linker 00:06:32.230 --> 00:06:34.550 where to find those shared libraries of code. 00:06:34.839 --> 00:06:37.939 So as a malicious user, before I launch that 00:06:37.939 --> 00:06:40.399 secure -situated program, I just swap out the 00:06:40.399 --> 00:06:43.019 note on the wall. Exactly. I change my LD library 00:06:43.019 --> 00:06:45.019 path variable to point to a hidden folder on 00:06:45.019 --> 00:06:47.560 my desktop filled with my own malicious virus 00:06:47.560 --> 00:06:50.459 code. Right. The highly privileged admin program 00:06:50.459 --> 00:06:53.980 wakes up, reads my fake map, loads my virus thinking 00:06:53.980 --> 00:06:56.579 it's a standard system library, and just executes 00:06:56.579 --> 00:06:59.620 it with maximum system authority. It's a brilliantly 00:06:59.620 --> 00:07:02.040 simple attack vector. Which is why this system 00:07:02.040 --> 00:07:04.120 has a built -in countermeasure. Thank goodness. 00:07:04.620 --> 00:07:06.560 Yeah. A core component of Unix -like systems 00:07:06.560 --> 00:07:08.800 is called Libachick. Yeah, it's the standard 00:07:08.800 --> 00:07:11.560 C library that acts as the foundational building 00:07:11.560 --> 00:07:15.399 block for almost all programs. And Lib anticipates 00:07:15.399 --> 00:07:17.779 this exact vulnerability. It acts like a bouncer 00:07:17.779 --> 00:07:20.379 at the dorm of a VIP club. A very aggressive 00:07:20.379 --> 00:07:24.019 bouncer. Deliberately, at startup, if Libret 00:07:24.019 --> 00:07:26.980 detects... that a process is running as a setuit 00:07:26.980 --> 00:07:29.639 program, meaning it has elevated privileges, 00:07:30.480 --> 00:07:32.660 it completely sanitizes the environment. It wipes 00:07:32.660 --> 00:07:35.220 it. Yeah, it unsets and deletes dangerous variables 00:07:35.220 --> 00:07:37.800 like LD library path before the program is even 00:07:37.800 --> 00:07:39.560 allowed to fully wake up and look at the wall. 00:07:39.680 --> 00:07:41.939 It doesn't just ask nicely. It rips those malicious 00:07:41.939 --> 00:07:44.379 notes right off the wall and burns them. It has 00:07:44.379 --> 00:07:47.819 to. If it leaves even one manipulated path behind, 00:07:48.240 --> 00:07:51.339 the entire operating system is compromised. Secure 00:07:51.339 --> 00:07:54.240 programs are explicitly hard -coded to distrust 00:07:54.240 --> 00:07:56.759 the environment they inherit. So they rely entirely 00:07:56.759 --> 00:08:00.120 on safe, hard -coded default values instead of 00:08:00.120 --> 00:08:02.459 whatever the parent process handed them. Precisely. 00:08:02.540 --> 00:08:04.660 So if Libric is the universal bouncer handling 00:08:04.660 --> 00:08:07.620 security, do all operating systems even speak 00:08:07.620 --> 00:08:09.759 the same language to the bouncer? Not at all. 00:08:09.819 --> 00:08:12.160 Because my understanding is the actual syntax, 00:08:12.300 --> 00:08:14.420 the grammar of how you write an environment variable 00:08:14.420 --> 00:08:16.800 changes wildly depending on what machine you 00:08:16.800 --> 00:08:19.519 are typing on. Oh, it is a complete Rosetta Stone 00:08:19.519 --> 00:08:23.100 situation. A variable on a Unix system looks, 00:08:23.720 --> 00:08:26.180 acts, and is assigned entirely differently than 00:08:26.180 --> 00:08:28.079 a variable on a Windows machine. Let's break 00:08:28.079 --> 00:08:30.860 down the Unix grammar first. Unix, Linux, Mac 00:08:30.860 --> 00:08:33.940 OS, they're all strictly case sensitive. Very 00:08:33.940 --> 00:08:36.659 strict. And to call a variable, you place a dollar 00:08:36.659 --> 00:08:39.309 sign in front of it. So dollar sign home, spelled 00:08:39.309 --> 00:08:41.970 in all capital letters. And that case sensitivity 00:08:41.970 --> 00:08:45.389 dictates the entire logic of the system. In Unix, 00:08:45.730 --> 00:08:48.529 dollar sign home in all uppercase is an entirely 00:08:48.529 --> 00:08:51.120 separate entity. from dollar sign home in all 00:08:51.120 --> 00:08:53.600 lowercase. So if I have an environment variable 00:08:53.600 --> 00:08:56.019 named John and another name John, Unix treats 00:08:56.019 --> 00:08:57.639 them like two completely different people who 00:08:57.639 --> 00:08:59.519 have never met, but Windows just assumes they're 00:08:59.519 --> 00:09:01.759 the same guy wearing a different hat. That captures 00:09:01.759 --> 00:09:04.220 the Windows philosophy perfectly. Yeah. DOS, 00:09:04.500 --> 00:09:07.899 OS2, and Windows command lines like cmd .exe 00:09:07.899 --> 00:09:12.360 are completely case insensitive. It's all the 00:09:12.360 --> 00:09:14.360 exact same mailbox. Right. And instead of the 00:09:14.360 --> 00:09:16.519 dollar sign at the front, Windows syntax wraps 00:09:16.519 --> 00:09:18.679 the variable in percent signs to identify it. 00:09:18.789 --> 00:09:20.830 you type percent, home path percent. It's like 00:09:20.830 --> 00:09:23.149 they wanted to make absolutely sure the system 00:09:23.149 --> 00:09:25.350 knew it was a variable from both sides. Yeah, 00:09:25.509 --> 00:09:27.789 exactly. But it's not just how you call them. 00:09:28.029 --> 00:09:30.009 The philosophies really clash when you look at 00:09:30.009 --> 00:09:31.990 how you assign them. Oh, definitely. In Unix, 00:09:32.110 --> 00:09:35.730 you can use commands like export or nv. Or, incredibly, 00:09:35.870 --> 00:09:37.970 you can just prefix a command with a variable 00:09:37.970 --> 00:09:41.129 assignment. And it only exists for that one specific 00:09:41.129 --> 00:09:44.039 command. And that localized assignment. is a 00:09:44.039 --> 00:09:46.700 massive advantage in Unix. You can change the 00:09:46.700 --> 00:09:49.779 room's decor for just one specific guest. You 00:09:49.779 --> 00:09:52.360 prefix the program launch with a variable, the 00:09:52.360 --> 00:09:54.399 program uses it, and as soon as that program 00:09:54.399 --> 00:09:57.419 closes, the room instantly resets to how it was 00:09:57.419 --> 00:09:59.970 before. It doesn't leak out and affect the rest 00:09:59.970 --> 00:10:01.929 of the system. Whereas Windows is historically 00:10:01.929 --> 00:10:04.950 much clunkier. You use the SE command. Yes. And 00:10:04.950 --> 00:10:06.870 once you set it, it's set for everything. You've 00:10:06.870 --> 00:10:09.190 globally changed the room for every program that 00:10:09.190 --> 00:10:11.529 launches in that window until you explicitly 00:10:11.529 --> 00:10:14.350 change it back or close the prompt. The syntax 00:10:14.350 --> 00:10:16.629 quirks reflect the underlying culture of the 00:10:16.629 --> 00:10:20.529 operating systems. Unix is strict, precise, and 00:10:20.529 --> 00:10:22.990 heavily compartmentalized. And Windows. Windows 00:10:22.990 --> 00:10:25.330 was historically built to be more forgiving and 00:10:25.330 --> 00:10:28.690 global. Though, to be fair, modern Windows has 00:10:28.690 --> 00:10:31.950 attempted to bridge this cultural gap with PowerShell. 00:10:32.110 --> 00:10:34.649 Oh, right, PowerShell. PowerShell adopts a much 00:10:34.649 --> 00:10:37.009 more Unix -like syntax. You use a dollar sign, 00:10:37.149 --> 00:10:39.710 like dollar sign, and V colon variable name. 00:10:39.830 --> 00:10:43.049 But underneath the hood, it remains fundamentally 00:10:43.049 --> 00:10:46.970 case -insensitive to honor decades of legacy 00:10:46.970 --> 00:10:49.330 Windows behavior. So they don't agree on the 00:10:49.330 --> 00:10:51.649 grammar. But do they agree on the vocabulary? 00:10:51.889 --> 00:10:54.090 Mostly, yes. We know how they speak, but what 00:10:54.090 --> 00:10:56.450 are they actually saying to these programs? Because 00:10:56.450 --> 00:10:58.710 there seems to be a universal hall of fame of 00:10:58.710 --> 00:11:01.669 variables that exist everywhere. There are undeniable 00:11:01.669 --> 00:11:04.009 classics that form the backbone of your daily 00:11:04.009 --> 00:11:06.929 computing. And the most critical, without a doubt, 00:11:07.110 --> 00:11:10.090 is the path variable. The path variable is the 00:11:10.090 --> 00:11:12.970 absolute unsung hero of your keyboard. It really 00:11:12.970 --> 00:11:14.850 is. If you open a terminal and type the word 00:11:14.850 --> 00:11:17.309 ping, the computer runs the network ping tool. 00:11:17.679 --> 00:11:19.980 but you didn't tell it where the ping tool lived. 00:11:20.639 --> 00:11:23.580 You didn't painstakingly type C colon backslash 00:11:23.580 --> 00:11:26.899 Windows backslash system32 backslash ping .exe. 00:11:27.019 --> 00:11:28.860 No one has time for that. Exactly. You just typed 00:11:28.860 --> 00:11:32.539 ping. And the system doesn't magically know where 00:11:32.539 --> 00:11:35.500 that executable file is located. It has to do 00:11:35.500 --> 00:11:38.779 a frantic room by room search. How does it know 00:11:38.779 --> 00:11:41.960 where to look? The path variable is simply a 00:11:41.960 --> 00:11:44.820 long text string containing a list of directories 00:11:44.820 --> 00:11:47.840 separated by semicolons. When you type a command 00:11:47.840 --> 00:11:50.480 without a full location, the operating system 00:11:50.480 --> 00:11:52.820 reads the path variable and checks the first 00:11:52.820 --> 00:11:56.279 folder on the list. If ping isn't there, it checks 00:11:56.279 --> 00:11:59.230 the second folder. then the third. It literally 00:11:59.230 --> 00:12:01.710 hunts through the hard drive in that exact order 00:12:01.710 --> 00:12:04.070 until it finds a match, which means there is 00:12:04.070 --> 00:12:06.490 a literal computational cost happening there. 00:12:06.690 --> 00:12:09.029 Absolutely. If your path variable is a mess and 00:12:09.029 --> 00:12:11.049 the folder containing your tools is at the very 00:12:11.049 --> 00:12:13.690 end of a list of 50 directories, your computer 00:12:13.690 --> 00:12:16.149 is wasting microscopic fractions of a second 00:12:16.149 --> 00:12:18.830 searching through 49 wrong folders every single 00:12:18.830 --> 00:12:20.990 time you type a command. The order fundamentally 00:12:20.990 --> 00:12:23.509 dictates performance and behavior. Then you have 00:12:23.509 --> 00:12:26.009 variables like temp, which dictate where programs 00:12:26.009 --> 00:12:28.250 are allowed to dump their temporary cache files. 00:12:28.309 --> 00:12:31.269 Right. And on Unix systems, you have highly flexible 00:12:31.269 --> 00:12:34.049 variables like browser. I love the browser variable, 00:12:34.210 --> 00:12:37.070 because it's a perfect example of graceful degradation. 00:12:37.230 --> 00:12:38.929 Yes, exactly. It doesn't just hold the name of 00:12:38.929 --> 00:12:41.009 one web browser. It holds a colon -separated 00:12:41.009 --> 00:12:44.190 list of fallbacks. It might say, try launching 00:12:44.190 --> 00:12:47.549 Firefox first. If Firefox crashes or isn't installed, 00:12:47.690 --> 00:12:50.009 try the secondary graphical browser. Right, it 00:12:50.009 --> 00:12:51.889 just moves down the list. If the user doesn't 00:12:51.889 --> 00:12:54.470 even have a monitor connected and they're just 00:12:54.470 --> 00:12:56.970 looking at a pure text terminal, fall back to 00:12:56.970 --> 00:13:00.070 Lynx, which is a purely text -based browser. 00:13:00.190 --> 00:13:03.610 It's a prioritized, contingency plan. When developers 00:13:03.610 --> 00:13:06.149 understand this vocabulary the system runs beautifully 00:13:06.149 --> 00:13:10.529 but there is a widespread chronic error developers 00:13:10.529 --> 00:13:13.549 make particularly on Windows that completely 00:13:13.549 --> 00:13:15.850 ruins the user experience. Oh I know where this 00:13:15.850 --> 00:13:18.470 is going. It involves the user profile variable. 00:13:18.669 --> 00:13:21.250 Oh, the user profile debacle. This is incredibly 00:13:21.250 --> 00:13:23.929 frustrating. It really is. User profile simply 00:13:23.929 --> 00:13:26.370 points to the root of a user's directory, for 00:13:26.370 --> 00:13:30.490 example. C colon backslash users backslash John. 00:13:30.730 --> 00:13:33.850 The intended behavior is that this folder holds 00:13:33.850 --> 00:13:36.570 your visible personal documents, pictures, and 00:13:36.570 --> 00:13:39.690 desktop files. But lazy application developers 00:13:39.690 --> 00:13:42.570 constantly use this variable to dump their apps 00:13:42.570 --> 00:13:45.690 hidden configuration files, crash logs, and cached 00:13:45.690 --> 00:13:48.610 data right into that main folder. It's like having 00:13:48.610 --> 00:13:51.490 a beautifully organized digital living room and 00:13:51.490 --> 00:13:54.289 a lazy plumber walks in and just dumps his greasy 00:13:54.289 --> 00:13:56.610 tool belt and dirty laundry right on your kitchen 00:13:56.610 --> 00:13:58.929 table instead of using the utility closet. That 00:13:58.929 --> 00:14:00.990 is exactly what it feels like. And this isn't 00:14:00.990 --> 00:14:03.490 just an aesthetic annoyance, is it? It actually 00:14:03.490 --> 00:14:06.129 braids things. It causes massive headaches for 00:14:06.129 --> 00:14:09.429 system administration. If you use a cloud backup 00:14:09.429 --> 00:14:12.809 tool to secure your personal files, that tool 00:14:12.809 --> 00:14:15.870 now wastes hours uploading gigabytes of useless 00:14:15.870 --> 00:14:18.789 hidden application cache files because the developer 00:14:18.789 --> 00:14:20.590 dumped them in your main user profile folder. 00:14:20.850 --> 00:14:22.029 Where are they actually supposed to be putting 00:14:22.029 --> 00:14:23.970 those files? They should be using the dedicated 00:14:23.970 --> 00:14:27.500 app data variables. Okay. Local data is the closet 00:14:27.500 --> 00:14:29.759 designed specifically for cache and settings 00:14:29.759 --> 00:14:32.779 that should stay on that specific physical machine. 00:14:33.360 --> 00:14:36.519 And AppData is meant for roaning settings. Imagine 00:14:36.519 --> 00:14:39.200 a corporate network where an employee logs into 00:14:39.200 --> 00:14:41.120 a different physical computer every morning. 00:14:41.200 --> 00:14:44.279 Oh, so it follows them. Exactly. The AppData 00:14:44.279 --> 00:14:47.059 variable ensures their specific app preferences 00:14:47.059 --> 00:14:49.600 roam across the network server and follow them 00:14:49.600 --> 00:14:52.679 to the new desk. When developers lazily default 00:14:52.679 --> 00:14:55.610 to user profile, they break roaming profiles 00:14:55.610 --> 00:14:57.909 entirely. It just brews that even the people 00:14:57.909 --> 00:15:00.250 writing the software don't always grasp the environment 00:15:00.250 --> 00:15:02.409 they're building for, but at least variables 00:15:02.409 --> 00:15:05.370 like path and user profile are static. They are 00:15:05.370 --> 00:15:09.210 literal notes pinned to the wall. True. But there 00:15:09.210 --> 00:15:13.009 is a completely different breed of variable, 00:15:13.289 --> 00:15:16.129 the shapeshifters, pseudo variables. Pseudo variables 00:15:16.129 --> 00:15:18.570 are a brilliant illusion. primarily utilized 00:15:18.570 --> 00:15:20.970 in DOS and Windows environments. They look like 00:15:20.970 --> 00:15:22.549 regular environment variables. You wrap them 00:15:22.549 --> 00:15:24.750 in percent signs just the same, but they aren't 00:15:24.750 --> 00:15:26.710 actually stored in the environment memory space 00:15:26.710 --> 00:15:29.490 at all. So what does this all mean for pseudo 00:15:29.490 --> 00:15:32.490 variables? Are they basically the operating system 00:15:32.490 --> 00:15:35.190 performing a magic trick, pretending to be a 00:15:35.190 --> 00:15:37.669 static sticky note, but actually acting as a 00:15:37.669 --> 00:15:40.590 tiny invisible calculator? The invisible calculator 00:15:40.590 --> 00:15:43.230 analogy is spot on. They are computed on the 00:15:43.230 --> 00:15:45.909 fly the exact millisecond you request them. Oh, 00:15:45.909 --> 00:15:48.669 wow. Take random, for instance. Every single 00:15:48.669 --> 00:15:50.950 time a script reads that variable, the operating 00:15:50.950 --> 00:15:53.950 system instantly generates a random integer between 00:15:53.950 --> 00:15:57.909 0 and 327667 and hands it over. Just makes it 00:15:57.909 --> 00:16:01.409 up on the spot. Exactly. Or CD, which dynamically 00:16:01.409 --> 00:16:03.730 calculates and returns your current directory. 00:16:03.929 --> 00:16:06.730 And CD even changes its answer based on who is 00:16:06.730 --> 00:16:09.470 asking. Yes, it does. If you run it under the 00:16:09.470 --> 00:16:12.389 ancient command .com shell, it computes the old 00:16:12.389 --> 00:16:15.929 -school truncated 8 .3 file name format. But 00:16:15.929 --> 00:16:19.429 if you ask it under the newer cmd .exe, it returns 00:16:19.429 --> 00:16:22.129 the modern full -length folder name. The dynamism 00:16:22.129 --> 00:16:25.889 is powerful. But... What's fascinating here is 00:16:25.889 --> 00:16:29.190 the sheer danger of dynamic computation if programmers 00:16:29.190 --> 00:16:31.570 aren't incredibly careful. Danger. Especially 00:16:31.570 --> 00:16:33.570 with the time -based pseudo -variables, time 00:16:33.570 --> 00:16:35.509 and date. They seem harmless enough, though. 00:16:35.590 --> 00:16:37.409 You ask for the time, it gives you the time. 00:16:37.490 --> 00:16:39.850 Let's walk through a standard scenario. A programmer 00:16:39.850 --> 00:16:42.090 writes an automated script to log a server event. 00:16:42.389 --> 00:16:44.870 The script asks the invisible calculator for 00:16:44.870 --> 00:16:47.610 the time variable, writes it down, does a tiny 00:16:47.610 --> 00:16:50.250 bit of processing, and then asks for the date 00:16:50.250 --> 00:16:52.090 variable. That sounds like standard operating 00:16:52.090 --> 00:16:55.610 procedure. It works flawlessly, 99 .9 % of the 00:16:55.610 --> 00:16:57.909 time. But imagine that automated script triggers 00:16:57.909 --> 00:17:00.149 precisely a fraction of a second before midnight. 00:17:00.230 --> 00:17:05.349 Oh, boy. It reads time and receives 11 .5959 00:17:05.349 --> 00:17:08.650 PM. OK. Then the script takes a few milliseconds 00:17:08.650 --> 00:17:12.220 to process. During those milliseconds, The clock 00:17:12.220 --> 00:17:15.440 strikes midnight. Oh no. The script then asks 00:17:15.440 --> 00:17:17.720 for date. Oh, I see the trap. It pulls the date 00:17:17.720 --> 00:17:20.660 for the brand new day. Yes. You end up with a 00:17:20.660 --> 00:17:22.839 terrifying rollover bug in your server logs. 00:17:23.759 --> 00:17:25.799 You have a timestamp claiming a critical event 00:17:25.799 --> 00:17:28.319 happened at 11 .59 p .m. on tomorrow's date. 00:17:28.559 --> 00:17:31.200 A physical impossibility. Recorded as an absolute 00:17:31.200 --> 00:17:33.619 fact entirely because pseudo -variables compute 00:17:33.619 --> 00:17:36.099 instantly upon the exact microsecond of the request. 00:17:36.509 --> 00:17:38.609 To avoid this, programmers have to read them 00:17:38.609 --> 00:17:41.670 in highly specific orders or capture them simultaneously. 00:17:42.109 --> 00:17:44.690 That is a nightmare scenario for anyone trying 00:17:44.690 --> 00:17:47.529 to audit a security log. It's amazing the system 00:17:47.529 --> 00:17:51.109 can do this instant dynamic math at all, considering 00:17:51.109 --> 00:17:53.609 where this all started. Very true. Early computers 00:17:53.609 --> 00:17:55.769 had to manage these environments with a fraction 00:17:55.769 --> 00:17:58.150 of the memory we have today, which led to some 00:17:58.150 --> 00:18:01.089 truly wild historical workarounds. We really 00:18:01.089 --> 00:18:03.509 have to remember how incredibly constrained early 00:18:03.509 --> 00:18:06.859 computing environments were. Today, your path 00:18:06.859 --> 00:18:09.640 variable alone is probably over a thousand characters 00:18:09.640 --> 00:18:12.720 long, full of complex directory routes. Easily. 00:18:12.980 --> 00:18:16.180 But, in early DOS and 16 -bit Windows, certain 00:18:16.180 --> 00:18:19.619 programs literally could not handle an environment 00:18:19.619 --> 00:18:23.660 variable whose total contents exceeded 128 characters. 00:18:24.000 --> 00:18:26.539 128 characters? That's shorter than an old tweet. 00:18:26.809 --> 00:18:29.069 It's nothing. If you tried to define where your 00:18:29.069 --> 00:18:31.049 word processor lived and where your temporary 00:18:31.049 --> 00:18:33.109 file should go, you'd run out of space immediately. 00:18:33.450 --> 00:18:35.630 What happens if you type character number 129? 00:18:35.829 --> 00:18:38.349 The system was ruthless. It didn't give you a 00:18:38.349 --> 00:18:40.789 polite error message. It aggressively truncated 00:18:40.789 --> 00:18:42.609 your command. Just cut it off. Mechanically, 00:18:42.730 --> 00:18:44.990 the system would forcefully insert an ASCII 13 00:18:44.990 --> 00:18:48.589 character right at position 127. And AC13 is 00:18:48.589 --> 00:18:51.069 a carriage return. It's the enter key. So the 00:18:51.069 --> 00:18:54.170 system just cuts you off mid -sentence and hits 00:18:54.170 --> 00:18:56.950 enter for you. Exactly. It executes whatever 00:18:56.950 --> 00:18:59.009 fragment of the command you manage to type before 00:18:59.009 --> 00:19:01.410 the limit. That's like trying to pack an instruction 00:19:01.410 --> 00:19:03.630 manual for building a spaceship onto a single 00:19:03.630 --> 00:19:06.069 post -it note, and if you go one letter over, 00:19:06.250 --> 00:19:08.650 the universe just deletes the rest of your sentence. 00:19:08.849 --> 00:19:11.509 And because RAM was so astronomically expensive, 00:19:12.190 --> 00:19:14.650 every single byte taken up by an environment 00:19:14.650 --> 00:19:17.230 variable was a byte stolen from the programs 00:19:17.230 --> 00:19:20.230 you were actually trying to run. Wow. This constraint 00:19:20.230 --> 00:19:23.589 birthed extreme memory hacks, particularly in 00:19:23.589 --> 00:19:26.529 DOS variants like Docker DOS. This brings us 00:19:26.529 --> 00:19:29.079 to the zero environment hacks. Why would you 00:19:29.079 --> 00:19:30.960 ever want to completely delete the environment? 00:19:31.319 --> 00:19:33.619 Think about loading a background driver in early 00:19:33.619 --> 00:19:36.319 DOS, say, the software to make your computer 00:19:36.319 --> 00:19:38.940 mouse work. Okay. That mouse driver is a child 00:19:38.940 --> 00:19:41.039 process, so it inherits the entire environment 00:19:41.039 --> 00:19:43.279 from the parent. But a mouse driver doesn't care 00:19:43.279 --> 00:19:45.599 about your path variable or your temp folder 00:19:45.599 --> 00:19:48.519 or what browser you prefer. It just sits in the 00:19:48.519 --> 00:19:50.920 background moving a cursor. Yet it was holding 00:19:50.920 --> 00:19:53.700 on to a full copy of the environment in precious 00:19:53.700 --> 00:19:56.960 RAM. just hoarding kilobytes of memory for absolutely 00:19:56.960 --> 00:19:59.480 no reason. So Docker DOS introduced commands 00:19:59.480 --> 00:20:03.180 like set in v or install slash z to deliberately 00:20:03.180 --> 00:20:06.200 strip the environment down to zero bytes right 00:20:06.200 --> 00:20:08.690 before loading the driver. You just absolutely 00:20:08.690 --> 00:20:11.069 starve the child process. You get no map. You 00:20:11.069 --> 00:20:13.630 get no variables. Just go do your job. By stripping 00:20:13.630 --> 00:20:16.170 the environment, they saved vital kilobytes of 00:20:16.170 --> 00:20:19.089 conventional memory, which in the 1980s and 90s 00:20:19.089 --> 00:20:21.450 was quite literally the difference between a 00:20:21.450 --> 00:20:23.769 high -end video game booting up successfully 00:20:23.769 --> 00:20:26.579 or crashing the machine entirely. That's wild. 00:20:26.700 --> 00:20:29.539 We also see the ghosts of this chaotic era preserved 00:20:29.539 --> 00:20:33.079 in variables like OS. Oh, right. If I open a 00:20:33.079 --> 00:20:34.619 modern Windows machine today and ask it what 00:20:34.619 --> 00:20:37.059 the OS is, it usually just spits back Windows 00:20:37.059 --> 00:20:39.460 underscore NT. It's pretty boring. Yeah. But 00:20:39.460 --> 00:20:41.319 back in the day, the values were all over the 00:20:41.319 --> 00:20:43.319 map. Because the market was flooded with competing, 00:20:43.880 --> 00:20:46.140 slightly different operating systems all desperately 00:20:46.140 --> 00:20:49.180 trying to be DOS compatible. Ah, the Clone Wars. 00:20:49.700 --> 00:20:53.690 Exactly. The OS variable was a lifeline for scripts 00:20:53.690 --> 00:20:56.069 to figure out what bizarre mutant system they 00:20:56.069 --> 00:20:58.789 were currently running on. Depending on the machine, 00:20:58.970 --> 00:21:01.809 that variable might return DR -DOS or PalmDOS 00:21:01.809 --> 00:21:05.569 or even CPC -DOs 4 .1 if it was running inside 00:21:05.569 --> 00:21:07.950 an emulator. It's like looking at a digital fossil 00:21:07.950 --> 00:21:10.430 record of the operating system wars. It truly 00:21:10.430 --> 00:21:14.069 is. The legacy of these extreme byte saving tricks 00:21:14.069 --> 00:21:17.170 is deeply embedded in why we still have certain 00:21:17.170 --> 00:21:20.369 variable structures, limitations, and syntactical 00:21:20.369 --> 00:21:22.490 quirks in command line tools today. Makes total 00:21:22.490 --> 00:21:24.910 sense. Understanding those historical constraints 00:21:24.910 --> 00:21:27.890 gives you a profound appreciation for the massive 00:21:27.890 --> 00:21:30.789 unrestricted dynamic environments our applications 00:21:30.789 --> 00:21:33.089 just casually lounge around in now. It really 00:21:33.089 --> 00:21:35.509 does. So to wrap this deep dive up, the next 00:21:35.509 --> 00:21:37.710 time you install a new piece of software or just 00:21:37.710 --> 00:21:39.329 casually double click a file on your desktop, 00:21:39.180 --> 00:21:42.099 or launch a web browser, take a second to appreciate 00:21:42.099 --> 00:21:45.140 the invisible room. There is an entire hidden, 00:21:45.140 --> 00:21:48.119 inherited genetic code of environment variables 00:21:48.119 --> 00:21:50.160 passing from parent to child in a fraction of 00:21:50.160 --> 00:21:53.119 a millisecond, negotiating folder paths, checking 00:21:53.119 --> 00:21:55.400 security limits with aggressive bouncers, and 00:21:55.400 --> 00:21:58.160 making the digital magic happen seamlessly. It 00:21:58.160 --> 00:22:02.220 is a remarkably resilient system. This raises 00:22:02.220 --> 00:22:04.559 an important question for you to explore. If 00:22:04.559 --> 00:22:06.960 environment variables were designed to give localized, 00:22:07.400 --> 00:22:09.559 personalized context to programs running on a 00:22:09.559 --> 00:22:12.700 single machine, what happens to this concept 00:22:12.700 --> 00:22:15.500 in our modern era of decentralized serverless 00:22:15.500 --> 00:22:17.700 cloud computing, where an app might be running 00:22:17.700 --> 00:22:19.839 across a thousand different machines simultaneously? 00:22:20.059 --> 00:22:21.940 Now that is an invisible room with a lot of moving 00:22:21.940 --> 00:22:23.920 walls. Thanks for joining us for this deep dive. 00:22:24.200 --> 00:22:24.740 See you next time.