WEBVTT 00:00:00.000 --> 00:00:02.700 Right now, I mean, at this very second, your 00:00:02.700 --> 00:00:04.940 computer is basically lying to you. Oh, absolutely. 00:00:05.360 --> 00:00:07.960 Yeah, the the shiny desktop, the neatly organized 00:00:07.960 --> 00:00:09.919 folders you click on, the smooth little mouse 00:00:09.919 --> 00:00:12.160 pointer you drag across the screen. It's all, 00:00:12.480 --> 00:00:15.160 well, it's a polite graphical fiction. Very convincing 00:00:15.160 --> 00:00:17.480 one, to be fair. Right. But underneath all of 00:00:17.480 --> 00:00:19.879 that friendly veneer, the machine is actually 00:00:19.879 --> 00:00:23.300 still demanding that you speak to it in a super 00:00:23.300 --> 00:00:26.230 strict. like 60 year old language. And it is 00:00:26.230 --> 00:00:28.510 a language most people really only encounter 00:00:28.510 --> 00:00:31.730 in movies, you know, usually when a hacker is 00:00:31.730 --> 00:00:34.670 furiously typing green text on a black screen 00:00:34.670 --> 00:00:37.109 to, I don't know, bypass a firewall or something. 00:00:37.310 --> 00:00:39.090 Exactly. The classic Hollywood hacker scene. 00:00:39.189 --> 00:00:41.710 Yeah. But that intimidating scrolling wall of 00:00:41.710 --> 00:00:44.789 text is actually the command line interface or 00:00:44.789 --> 00:00:47.990 CLI. Yeah. And for decades, the tech industry 00:00:47.990 --> 00:00:52.020 has introduced mice. touchscreens, spatial computing, 00:00:52.259 --> 00:00:54.960 all of it. Yet this purely text -based method 00:00:54.960 --> 00:00:58.000 of communication remains the absolute power tool 00:00:58.000 --> 00:01:00.380 for interacting with a machine. It really does. 00:01:00.679 --> 00:01:03.439 So welcome to the deep dive. Our mission today 00:01:03.439 --> 00:01:06.859 is to decode that interface. We're using a really 00:01:06.859 --> 00:01:09.099 comprehensive Wikipedia article on the command 00:01:09.099 --> 00:01:12.629 line interface to pull apart why this seemingly 00:01:12.629 --> 00:01:16.030 archaic system isn't just a retro relic of the 00:01:16.030 --> 00:01:18.829 past, but the actual foundational architecture 00:01:18.829 --> 00:01:21.590 running the present. Because honestly, whether 00:01:21.590 --> 00:01:24.390 you are managing cloud servers or writing code 00:01:24.390 --> 00:01:28.790 or just typing a query into a web browser, understanding 00:01:28.790 --> 00:01:32.310 the mechanical reality of the CLI fundamentally 00:01:32.310 --> 00:01:35.709 alters how you perceive. the digital world. You 00:01:35.709 --> 00:01:38.329 stop seeing the interface as just a static picture 00:01:38.329 --> 00:01:40.250 and you start seeing the underlying logic of 00:01:40.250 --> 00:01:43.250 the operating system. I love that. So, to understand 00:01:43.250 --> 00:01:45.829 the logic of why we still use raw text to control 00:01:45.829 --> 00:01:47.909 modern silicon, we kind of need to strip away 00:01:47.909 --> 00:01:49.909 the graphics and look at the intense physical 00:01:49.909 --> 00:01:52.670 constraints of the mid -1960s. Oh yeah, it was 00:01:52.670 --> 00:01:54.629 a totally different world. Before the command 00:01:54.629 --> 00:01:56.489 line, communicating with the mainframe was an 00:01:56.489 --> 00:01:58.989 agonizingly slow and completely non -interactive 00:01:58.989 --> 00:02:00.569 process, right? Yeah, I mean you were dealing 00:02:00.569 --> 00:02:03.290 with batch processing via punched cards. Punched 00:02:03.290 --> 00:02:06.250 cards. like literal cardboard. Literal stiff 00:02:06.250 --> 00:02:10.250 cardboard. A programmer would physically punch 00:02:10.250 --> 00:02:13.050 holes into them to represent machine instructions, 00:02:13.110 --> 00:02:15.629 and then you'd hand a thick stack of them to 00:02:15.629 --> 00:02:17.750 a human operator and then you just wait. Wait, 00:02:17.750 --> 00:02:20.090 like an hour? Sometimes hours, sometimes overnight, 00:02:20.409 --> 00:02:22.610 just for the computer to execute them. And if 00:02:22.610 --> 00:02:25.909 you made a single typographical error like one 00:02:25.909 --> 00:02:28.530 wrong hole punched, you wouldn't know until the 00:02:28.530 --> 00:02:30.990 next day when the machine spit out a paper error 00:02:30.990 --> 00:02:33.710 code. Oh, wow. That is incredibly frustrating. 00:02:33.909 --> 00:02:36.210 There was zero back and forth. It was just, here's 00:02:36.210 --> 00:02:39.150 my batch. I hope it works. So the paradigm shifted 00:02:39.150 --> 00:02:42.199 when hardware evolved to include Teleprinters, 00:02:42.439 --> 00:02:45.620 right? The TTY machines. Exactly, TTY machines. 00:02:46.020 --> 00:02:49.000 These were essentially heavy mechanical typewriters 00:02:49.000 --> 00:02:51.860 wired directly into the computer. So you type 00:02:51.860 --> 00:02:54.740 a command, the computer processes it, and then 00:02:54.740 --> 00:02:57.479 it physically types a response back onto a continuous 00:02:57.479 --> 00:02:59.659 roll of paper. Right, and that finally created 00:02:59.659 --> 00:03:01.439 an interactive session. You didn't have to wait 00:03:01.439 --> 00:03:03.819 overnight. And eventually, that mechanical paper 00:03:03.819 --> 00:03:07.340 feed was replaced by a cathode ray tube screen. 00:03:07.419 --> 00:03:09.580 Yeah, what engineers at the time called a glass 00:03:09.580 --> 00:03:12.419 diddy? A glass pretty, I like that. And that 00:03:12.419 --> 00:03:14.840 hardware shift allowed for a massive software 00:03:14.840 --> 00:03:18.099 leap. It was largely driven by a staff member 00:03:18.099 --> 00:03:20.860 at the MIT Computation Center named Louis Poussin. 00:03:21.280 --> 00:03:24.639 OK, Louis Poussin. So in 1964, he built a tool 00:03:24.639 --> 00:03:28.280 called RUNCOM for executing scripts. But what's 00:03:28.280 --> 00:03:30.740 fascinating here is his true breakthrough was 00:03:30.740 --> 00:03:33.710 conceptual. How so? Well, He coined the term 00:03:33.710 --> 00:03:36.729 shell for the Multics operating system. He stopped 00:03:36.729 --> 00:03:39.930 treating commands as isolated single use triggers 00:03:39.930 --> 00:03:42.830 and started treating them as a cohesive programming 00:03:42.830 --> 00:03:45.250 language. OK, let's visualize that concept because 00:03:45.250 --> 00:03:47.590 the term shell is tossed around a lot. It is 00:03:47.590 --> 00:03:49.650 it. People often describe the shell as a bouncer 00:03:49.650 --> 00:03:51.969 at the door of the computer. But a bouncer just 00:03:51.969 --> 00:03:55.090 says yes or no. Right. The core of your operating 00:03:55.090 --> 00:03:58.210 system, the kernel, is highly sensitive and only 00:03:58.210 --> 00:04:01.289 speaks binary machine code. But you only speak 00:04:01.289 --> 00:04:03.879 a human language. like English. So the shell 00:04:03.879 --> 00:04:05.979 is really more like a hyper -strict translator 00:04:05.979 --> 00:04:08.780 at the United Nations. It sits between you and 00:04:08.780 --> 00:04:11.860 the kernel, demanding you use perfect unforgiving 00:04:11.860 --> 00:04:14.539 grammar so it can translate your intent into 00:04:14.539 --> 00:04:17.560 actual machine action without causing a catastrophic 00:04:17.560 --> 00:04:20.480 error. That is a great way to put it. And that 00:04:20.480 --> 00:04:23.120 translation mechanism became the blueprint for 00:04:23.120 --> 00:04:26.339 modern computing. Right. Puzan's conceptual framework 00:04:26.339 --> 00:04:28.879 was adapted by Glenda Schroeder, who built the 00:04:28.879 --> 00:04:33.300 first Multik shell. Then, in 1971 at Bell Labs, 00:04:33.860 --> 00:04:36.540 Ken Thompson built the V6 shell for Unix carrying 00:04:36.540 --> 00:04:39.079 over those exact principles. Okay, so a clear 00:04:39.079 --> 00:04:43.319 lineage. Yeah. And by 1977, Stephen Bourne introduced 00:04:43.319 --> 00:04:45.720 the Bourne shell. And this wasn't just a command 00:04:45.720 --> 00:04:48.199 executor anymore. Oh, was it? It was a fully 00:04:48.199 --> 00:04:50.639 structured scripting language that allowed for 00:04:50.639 --> 00:04:53.800 loops, variables, and conditional logic. This 00:04:53.800 --> 00:04:56.420 is the direct ancestor to the environments developers 00:04:56.420 --> 00:04:59.240 use today, like bash, which actually stands for 00:04:59.240 --> 00:05:01.839 born again shell, or the corn shell. Born again 00:05:01.839 --> 00:05:04.199 shell, classic programmer humor. Oh, absolutely. 00:05:04.360 --> 00:05:06.800 But because that UN translator is so strict, 00:05:07.339 --> 00:05:09.079 we need to look at the mechanics of the grammar 00:05:09.079 --> 00:05:12.420 demands. The universal pattern almost all CLIs 00:05:12.420 --> 00:05:15.319 follow is a highly rigid three -part sequence. 00:05:15.740 --> 00:05:17.740 Right. Prompt command and parameters. Let's break 00:05:17.740 --> 00:05:20.500 that down. Well, the prompt is the machine signaling 00:05:20.500 --> 00:05:22.660 its readiness to receive a string of characters, 00:05:23.120 --> 00:05:25.740 and it often provides vital context about your 00:05:25.740 --> 00:05:27.620 environment. Like what kind of context? Well, 00:05:27.779 --> 00:05:30.939 in Unix -like systems, a prompt ending in a dollar 00:05:30.939 --> 00:05:33.879 sign or a percent sign means you are operating 00:05:33.879 --> 00:05:36.600 with standard user privileges. OK, so you're 00:05:36.600 --> 00:05:39.819 a regular user. Exactly. Yeah. But a hash symbol, 00:05:40.100 --> 00:05:43.040 the pound sign, indicates you are the super user. 00:05:43.279 --> 00:05:47.819 or root. Root access. Yes. And that symbol is 00:05:47.819 --> 00:05:49.759 basically a warning. It tells you that you have 00:05:49.759 --> 00:05:52.319 the administrative authority to rewrite or permanently 00:05:52.319 --> 00:05:55.180 destroy anything on the file system. So tread 00:05:55.180 --> 00:05:58.000 carefully if you see the hash symbol. Very carefully. 00:05:58.160 --> 00:06:00.240 OK. So once you get the prompt, you provide the 00:06:00.240 --> 00:06:03.319 command. And the linguistic structure here maps 00:06:03.319 --> 00:06:05.360 directly to human grammar, which I find super 00:06:05.360 --> 00:06:07.680 interesting. It really does. The command is your 00:06:07.680 --> 00:06:09.680 verb. It's the action you want to take, like 00:06:09.680 --> 00:06:13.060 copy, move, or remove. Right. Then you add options, 00:06:13.660 --> 00:06:16.759 which basically act as adverbs modifying how 00:06:16.759 --> 00:06:19.360 the verb is executed. Like do it quietly, do 00:06:19.360 --> 00:06:22.740 it forcefully, or do it recursively. Yep, modifying 00:06:22.740 --> 00:06:24.800 the action. And finally, you have the parameters, 00:06:25.100 --> 00:06:27.819 which are the objects the verb acts upon. So 00:06:27.819 --> 00:06:30.600 specific files or directories. The structure 00:06:30.600 --> 00:06:33.540 is essentially do this action in this specific 00:06:33.540 --> 00:06:36.839 manner to this target file. Exactly. But here's 00:06:36.839 --> 00:06:39.699 the catch. The machine parses that sentence by 00:06:39.699 --> 00:06:42.300 looking for spaces. Yes, spaces. Yeah, because 00:06:42.300 --> 00:06:44.899 early computing environments in the 1970s had 00:06:44.899 --> 00:06:47.800 extreme memory limitations. We are talking single 00:06:47.800 --> 00:06:51.060 digit kilobytes of RAM. Wow. Barely anything. 00:06:51.339 --> 00:06:53.379 Right. So the developers couldn't afford to build 00:06:53.379 --> 00:06:56.379 complex, resource -heavy parsing algorithms that 00:06:56.379 --> 00:06:59.459 inferred a user's intent. They had to build highly 00:06:59.459 --> 00:07:02.680 rigid parsers. A space character explicitly meant 00:07:02.680 --> 00:07:04.420 the end of one argument and the beginning of 00:07:04.420 --> 00:07:06.639 the next. Which creates a massive conflict for 00:07:06.639 --> 00:07:09.439 the machine if a user creates a file named, say, 00:07:09.759 --> 00:07:11.839 my document with a space in the middle. Oh, a 00:07:11.839 --> 00:07:14.379 huge conflict. Because the space is being asked 00:07:14.379 --> 00:07:17.480 to do two completely incompatible jobs. It has 00:07:17.480 --> 00:07:20.839 to be part of a single file name and act as the 00:07:20.839 --> 00:07:23.519 grammatical separator between two different parameters. 00:07:23.740 --> 00:07:26.560 Yes, so the strict parser reads my as the first 00:07:26.560 --> 00:07:30.279 object and document as an entirely separate second 00:07:30.279 --> 00:07:33.399 object, which immediately causes a system error. 00:07:33.899 --> 00:07:36.360 So how do you get around that? To force the parser 00:07:36.360 --> 00:07:38.680 to understand your intent, you have to use an 00:07:38.680 --> 00:07:41.139 escape character, typically a backslash, immediately 00:07:41.139 --> 00:07:45.000 before the space. So you type My backslash space 00:07:45.000 --> 00:07:47.699 document, it mechanically signals to the shell 00:07:47.699 --> 00:07:49.879 to treat the next character not as a grammatical 00:07:49.879 --> 00:07:52.759 separator, but as a literal space character within 00:07:52.759 --> 00:07:55.689 a string. Alternatively, you can just wrap the 00:07:55.689 --> 00:07:57.810 entire phrase in quotation marks. Honestly, I 00:07:57.810 --> 00:07:59.930 have to admit some genuine frustration here on 00:07:59.930 --> 00:08:02.449 behalf of you, the listener, or anyone who has 00:08:02.449 --> 00:08:04.170 ever wrestled with this interface. I get it. 00:08:04.290 --> 00:08:06.709 We have massive amounts of RAM today. We have 00:08:06.709 --> 00:08:08.810 incredibly advanced artificial intelligence. 00:08:09.370 --> 00:08:12.329 Why force users to keep typing backslashes and 00:08:12.329 --> 00:08:15.029 brackets just to navigate a single space? It 00:08:15.029 --> 00:08:18.439 seems archaic, right? It does. Isn't this just 00:08:18.439 --> 00:08:21.120 overly complicated grammar? Why can't the computer 00:08:21.120 --> 00:08:23.319 just use context clues to figure out what I mean 00:08:23.319 --> 00:08:25.680 instead of clinging to a memory limitation from 00:08:25.680 --> 00:08:28.379 the 1970s? Well, the reliance on rigid syntax 00:08:28.379 --> 00:08:31.579 isn't a limitation anymore. It is a strict requirement 00:08:31.579 --> 00:08:34.700 for automation. What do you mean by that? Ambiguity 00:08:34.700 --> 00:08:38.220 is the enemy of scripted execution. If you write 00:08:38.220 --> 00:08:40.519 a script designed to comb through thousands of 00:08:40.519 --> 00:08:43.559 servers, find specific vulnerabilities, and patch 00:08:43.559 --> 00:08:46.200 them automatically at three in the morning, you 00:08:46.200 --> 00:08:49.139 cannot have a background process trying to guess 00:08:49.139 --> 00:08:51.879 your intent based on context clues. The system 00:08:51.879 --> 00:08:55.080 needs to know, with zero margin for error, exactly 00:08:55.080 --> 00:08:58.059 where a command ends and a variable begins. That 00:08:58.059 --> 00:09:01.419 extreme strictness guarantees deterministic reliability. 00:09:01.539 --> 00:09:04.000 OK, I see. That unforgiving grammar might seem 00:09:04.000 --> 00:09:06.960 incredibly hostile to a beginner, but that exact 00:09:06.889 --> 00:09:10.450 text -based precision is what gives the CLI its 00:09:10.450 --> 00:09:12.850 massive advantage over graphical user interfaces 00:09:12.850 --> 00:09:17.190 or GUIs because GUIs, you know, the desktop, 00:09:17.389 --> 00:09:20.269 the icons, the windows, they are fundamentally 00:09:20.269 --> 00:09:23.370 resource -heavy. They require significant processing 00:09:23.370 --> 00:09:27.110 power, memory, and graphics rendering. just to 00:09:27.110 --> 00:09:29.049 draw the interface on your monitor. Right. There 00:09:29.049 --> 00:09:30.990 is a lot going on behind the scenes just to show 00:09:30.990 --> 00:09:33.669 you a folder. But the CLI operates on pure text, 00:09:33.789 --> 00:09:36.549 requiring virtually zero overhead, making it 00:09:36.549 --> 00:09:39.789 blazingly fast. Speed is one factor, definitely. 00:09:40.049 --> 00:09:43.190 But composability is the real superpower. Composability? 00:09:43.509 --> 00:09:45.570 Yeah. In a graphical interface, you are fundamentally 00:09:45.570 --> 00:09:47.870 limited by the software developer's imagination. 00:09:48.590 --> 00:09:51.129 If they didn't program a specific button for 00:09:51.129 --> 00:09:54.690 a specific action, you simply cannot do it. Here's 00:09:54.690 --> 00:09:57.299 where it gets really interesting. I like to think 00:09:57.299 --> 00:10:00.559 of a GUI as ordering off a fast food menu. OK, 00:10:00.559 --> 00:10:02.600 I like that. It's highly accessible. You point 00:10:02.600 --> 00:10:04.139 at the picture of a burger, you get the burger. 00:10:04.879 --> 00:10:06.659 But you can only get exactly what is pictured 00:10:06.659 --> 00:10:09.139 on the board. The command line, on the other 00:10:09.139 --> 00:10:11.539 hand, is like having unrestricted access to a 00:10:11.539 --> 00:10:13.460 commercial kitchen. Oh, that's a perfect analogy. 00:10:13.820 --> 00:10:16.740 You have raw ingredients, industrial tools, and 00:10:16.740 --> 00:10:19.779 you can combine them in any configuration imaginable, 00:10:20.039 --> 00:10:22.379 even if the original toolmaker never anticipated 00:10:22.379 --> 00:10:24.809 it. And the mechanism that allows you to combine 00:10:24.809 --> 00:10:27.809 those tools in that kitchen is a concept called 00:10:27.809 --> 00:10:31.610 standard streams. Think of standard streams as 00:10:31.610 --> 00:10:34.090 digital plumbing built into the core of the operating 00:10:34.090 --> 00:10:37.210 system. When a program runs, it automatically 00:10:37.210 --> 00:10:40.879 opens three invisible pipes. standard input, 00:10:41.240 --> 00:10:44.720 standard output, and standard error. By default, 00:10:45.039 --> 00:10:47.379 standard input flows from your keyboard and standard 00:10:47.379 --> 00:10:50.240 output flows directly to your screen. But the 00:10:50.240 --> 00:10:52.919 CLI allows you to redirect that plumbing. So 00:10:52.919 --> 00:10:55.759 using redirection, I can use a greater than symbol 00:10:55.759 --> 00:10:58.240 to sever the connection to my screen entirely, 00:10:58.360 --> 00:11:00.539 right? Exactly. And tell the computer to route 00:11:00.539 --> 00:11:02.919 that data stream directly into a new text file. 00:11:03.159 --> 00:11:05.179 So it silently writes the results to the hard 00:11:05.179 --> 00:11:07.039 drive instead of displaying them to me. Yes. 00:11:07.230 --> 00:11:10.210 But the true paradigm shift happened in 1973 00:11:10.210 --> 00:11:13.049 when Douglas McElroy conceptualized the pipe, 00:11:13.269 --> 00:11:15.169 which is represented by the vertical bar character 00:11:15.169 --> 00:11:17.570 on the keyboard. The pipe. A pipe allows you 00:11:17.570 --> 00:11:20.070 to take the standard output stream of one program 00:11:20.070 --> 00:11:22.610 and connect it directly to the standard input 00:11:22.610 --> 00:11:25.710 stream of another program in real time within 00:11:25.710 --> 00:11:28.389 system memory. Let's map that back to the commercial 00:11:28.389 --> 00:11:31.070 pitching analogy. Because of pipes, you don't 00:11:31.070 --> 00:11:33.649 have to blend ingredients, pour them into a bowl, 00:11:33.970 --> 00:11:36.399 carry the bowl to the oven, and bake it. You 00:11:36.399 --> 00:11:38.840 can literally pipe the output of the blender 00:11:38.840 --> 00:11:41.360 directly into the oven and pipe the output of 00:11:41.360 --> 00:11:43.980 the oven directly into the freezer. Yes, exactly. 00:11:44.340 --> 00:11:46.559 In a real -world computing scenario, imagine 00:11:46.559 --> 00:11:49.179 you have a server with a million lines of log 00:11:49.179 --> 00:11:52.159 data, and you need to find one specific error 00:11:52.159 --> 00:11:54.360 code. That sounds like a nightmare in a GUI. 00:11:54.659 --> 00:11:57.340 It would be. In a GUI, you would open a massive 00:11:57.340 --> 00:11:59.720 text file, wait for the application to load it 00:11:59.720 --> 00:12:02.820 into memory, and hit Ctrl -F. It would likely 00:12:02.820 --> 00:12:04.960 freeze or completely crash your machine. Oh, 00:12:04.960 --> 00:12:07.340 for sure. But in a CLI, you run a command to 00:12:07.340 --> 00:12:10.059 read the file, pipe that text stream into a search 00:12:10.059 --> 00:12:12.840 tool like grep to filter for the error, pipe 00:12:12.840 --> 00:12:14.919 those results into a sort command to organize 00:12:14.919 --> 00:12:17.419 them chronologically, and then pipe that final 00:12:17.419 --> 00:12:20.679 output into a new file. You chain discrete, single 00:12:20.679 --> 00:12:23.080 -purpose tools together in one line of text, 00:12:23.240 --> 00:12:25.899 and the computer executes it in milliseconds. 00:12:26.379 --> 00:12:29.340 That is incredible. Having full access to that 00:12:29.340 --> 00:12:31.860 kind of digital plumbing is incredibly powerful. 00:12:32.139 --> 00:12:34.299 Right up until you realize that every tool in 00:12:34.299 --> 00:12:36.990 the kit seems to use completely different labels 00:12:36.990 --> 00:12:41.250 for their dials and switches. Ah, yes! The syntax 00:12:41.250 --> 00:12:43.309 for modifying commands, the options and flags 00:12:43.309 --> 00:12:46.070 we talked about earlier, is just a chaotic tower 00:12:46.070 --> 00:12:48.629 of babble. It really is. The chaos stems from 00:12:48.629 --> 00:12:51.389 the fact that option parsing is based entirely 00:12:51.389 --> 00:12:54.149 on convention, not hard operating system rules. 00:12:54.230 --> 00:12:56.330 What does that mean in practice? Well, when you 00:12:56.330 --> 00:12:58.950 type a command, the shell simply passes a raw 00:12:58.950 --> 00:13:01.509 string of text to the program. It is entirely 00:13:01.509 --> 00:13:04.230 up to that specific program's internal code to 00:13:04.230 --> 00:13:06.350 figure out how to parse those adverbs. Which 00:13:06.350 --> 00:13:08.330 means we end up with totally different standards 00:13:08.330 --> 00:13:10.210 depending on the cultural history. of the operating 00:13:10.210 --> 00:13:13.070 system. Right. On Unix -like systems, the convention 00:13:13.070 --> 00:13:17.289 is to use the ASCII hyphen, the minus sign for 00:13:17.289 --> 00:13:20.929 short options, like dash C for create. And the 00:13:20.929 --> 00:13:23.730 GNU project, which provides many core utilities 00:13:23.730 --> 00:13:26.690 for Linux, established a convention using a double 00:13:26.690 --> 00:13:29.789 hyphen for long, descriptive options, like dash 00:13:29.789 --> 00:13:32.750 dash create. Okay, makes sense. But contrast 00:13:32.750 --> 00:13:35.330 that with DOS and Windows environments. They 00:13:35.330 --> 00:13:38.200 traditionally use the forward slash So instead 00:13:38.200 --> 00:13:41.299 of typing a command followed by dash w, you would 00:13:41.299 --> 00:13:43.940 type the command followed by slash w. Exactly. 00:13:44.159 --> 00:13:46.419 Wait, hold on. You're telling me that a typo 00:13:46.419 --> 00:13:49.299 between a dash and a slash could accidentally 00:13:49.299 --> 00:13:52.419 delete a directory or crash a process just because 00:13:52.419 --> 00:13:55.259 a programmer in the 1980s preferred slashes? 00:13:55.519 --> 00:13:57.500 Pretty much, yeah. If we've had this underlying 00:13:57.500 --> 00:14:01.029 technology since the 1960s, Why on earth can't 00:14:01.029 --> 00:14:03.710 all developers just agree on one universal syntax? 00:14:04.289 --> 00:14:06.750 Why are we still fighting a hyphen versus slash 00:14:06.750 --> 00:14:09.549 war? Because we can't unify them. These systems 00:14:09.549 --> 00:14:12.169 grew in completely isolated silos with completely 00:14:12.169 --> 00:14:14.710 different philosophies. How so? Unix was developed 00:14:14.710 --> 00:14:17.169 in academic and research environments where developers 00:14:17.169 --> 00:14:19.789 valued extreme conciseness to save keystrokes 00:14:19.789 --> 00:14:22.230 on slow mechanical teletype machines. Right, 00:14:22.330 --> 00:14:25.490 the old TTYs. But DOS and really PC systems were 00:14:25.490 --> 00:14:27.929 developed in the microcomputer space, navigating 00:14:27.929 --> 00:14:31.110 entirely different file system structures. It 00:14:31.110 --> 00:14:34.330 is exactly like human languages evolving independently 00:14:34.330 --> 00:14:37.289 to solve the same problem of communication. Oh, 00:14:37.350 --> 00:14:40.590 I see. You cannot simply merge English and Japanese 00:14:40.590 --> 00:14:43.399 grammar today. Furthermore, there are millions 00:14:43.399 --> 00:14:46.100 of lines of legacy code, automated batch scripts, 00:14:46.279 --> 00:14:48.899 and server configurations running global infrastructure 00:14:48.899 --> 00:14:52.340 that rely on these exact, specific quirks. If 00:14:52.340 --> 00:14:54.620 you enforce a new standard now, you break the 00:14:54.620 --> 00:14:57.059 internet. So the legacy code basically dictates 00:14:57.059 --> 00:14:59.419 the present. Completely. And because of that 00:14:59.419 --> 00:15:02.360 fragmentation, trying to figure out how a specific 00:15:02.360 --> 00:15:05.860 tool works can be incredibly dangerous. Without 00:15:05.860 --> 00:15:08.940 visual menus to browse, users rely on built -in 00:15:08.940 --> 00:15:12.000 help commands. But our source material explicitly 00:15:12.000 --> 00:15:14.559 warns that typing a program's name without parameters, 00:15:14.840 --> 00:15:16.740 hoping it will print out a friendly help menu, 00:15:17.139 --> 00:15:19.679 is hazardous. Very hazardous. For some tools, 00:15:19.759 --> 00:15:21.980 running it without parameters just executes the 00:15:21.980 --> 00:15:23.940 program immediately with whatever default settings 00:15:23.940 --> 00:15:27.240 it has. That's terrifying. It is. To safely request 00:15:27.240 --> 00:15:30.019 a manual, users must memorize convention -based 00:15:30.019 --> 00:15:33.240 help flags. You might use slash question mark 00:15:33.240 --> 00:15:37.299 in DOS or dash or dash dash help in Unix. But 00:15:37.299 --> 00:15:39.559 again, because it's just a convention. Right. 00:15:39.720 --> 00:15:42.820 A Unix tool ported to Windows might misinterpret 00:15:42.820 --> 00:15:46.440 your slash question mark request as a literal 00:15:46.440 --> 00:15:49.419 file path. Oh, man. And once you do get the manual 00:15:49.419 --> 00:15:51.600 to print to the screen, you have to decipher 00:15:51.600 --> 00:15:54.620 the typographical syntax. Right. The brackets. 00:15:54.940 --> 00:15:57.960 Yeah. Manuals use angle brackets to denote parameters 00:15:57.960 --> 00:16:00.279 that are strictly required by the program and 00:16:00.279 --> 00:16:02.360 square brackets for parameters that are optional. 00:16:02.600 --> 00:16:04.460 You basically have to learn a meta language just 00:16:04.460 --> 00:16:06.460 to read the instructions for the actual language. 00:16:06.720 --> 00:16:09.100 So the learning curve is incredibly steep. The 00:16:09.100 --> 00:16:11.379 grammar is unforgiving, and the conventions are 00:16:11.379 --> 00:16:13.799 chaotic. Yet you don't actually have to be a 00:16:13.799 --> 00:16:16.340 Unix systems administrator configuring a network 00:16:16.340 --> 00:16:18.399 router to encounter a command line interface 00:16:18.399 --> 00:16:20.600 today. No, not at all. They're hiding in plain 00:16:20.600 --> 00:16:23.059 sight, embedded in the software we use constantly. 00:16:23.399 --> 00:16:26.720 Exactly. The text -based nature of the CLI makes 00:16:26.720 --> 00:16:29.220 it uniquely suited for specific applications 00:16:29.220 --> 00:16:32.019 where graphics fail entirely. Accessibility is 00:16:32.019 --> 00:16:33.899 a prime example. I wouldn't have thought of that. 00:16:34.139 --> 00:16:37.120 Yeah, for users with severe visual disabilities, 00:16:37.720 --> 00:16:40.590 navigate Creating a complex, mouse -driven graphical 00:16:40.590 --> 00:16:42.909 interface full of floating windows and hidden 00:16:42.909 --> 00:16:46.129 drop -downs is incredibly difficult. But, because 00:16:46.129 --> 00:16:49.029 a CLI operates entirely on sequential streams 00:16:49.029 --> 00:16:51.850 of text characters, the inputs and the system's 00:16:51.850 --> 00:16:54.409 responses can be translated instantly and perfectly 00:16:54.409 --> 00:16:57.929 to refreshable braille displays. Those devices 00:16:57.929 --> 00:17:00.370 mechanically raise and lower pins to form braille 00:17:00.370 --> 00:17:03.029 characters, and the sequential flow of a CLI 00:17:03.029 --> 00:17:05.829 fits perfectly into that hardware. The mechanical 00:17:05.829 --> 00:17:08.250 simplicity makes it vastly easier. more accessible. 00:17:08.710 --> 00:17:11.509 We also see the CLI structure perfectly preserved 00:17:11.509 --> 00:17:14.609 in entertainment. Early PC gaming relied entirely 00:17:14.609 --> 00:17:18.069 on specialized command lines. Oh, the text adventures. 00:17:18.269 --> 00:17:20.089 Yeah, if you played text adventure games like 00:17:20.089 --> 00:17:23.509 the 1975 classic Colossal Cave Adventure, you 00:17:23.509 --> 00:17:25.910 were operating a custom shell. You typed commands 00:17:25.910 --> 00:17:29.250 like get ring or look north at a prompt. And 00:17:29.250 --> 00:17:31.990 the game parsed your verb and your object, processed 00:17:31.990 --> 00:17:34.690 the logic, and returned a text stream describing 00:17:34.690 --> 00:17:37.819 the outcome. And that exact architecture actually 00:17:37.819 --> 00:17:41.099 survives in modern graphically intense video 00:17:41.099 --> 00:17:43.819 games through the developer console. Yes, the 00:17:43.819 --> 00:17:46.339 dev console. It's that pull -down text field 00:17:46.339 --> 00:17:49.259 where developers and players can input direct 00:17:49.259 --> 00:17:51.579 text commands to bypass the game's graphical 00:17:51.579 --> 00:17:54.279 interface, alter variables in the physics engine, 00:17:54.759 --> 00:17:57.740 or execute debugging scripts. It is a direct 00:17:57.740 --> 00:18:00.720 text -based back door to the software's kernel. 00:18:01.099 --> 00:18:03.960 But the most ubiquitous CLI, the one almost every 00:18:03.960 --> 00:18:06.700 single person listening to this uses daily, is 00:18:06.700 --> 00:18:09.400 the URL input field in a web browser. Absolutely. 00:18:09.579 --> 00:18:11.700 When you type into that bar, you aren't just 00:18:11.700 --> 00:18:14.099 typing an address to load a picture. You are 00:18:14.099 --> 00:18:16.359 passing parameters directly to remote servers. 00:18:16.539 --> 00:18:18.900 Our source article highlights that Google itself 00:18:18.900 --> 00:18:20.660 operates as the command line of the internet. 00:18:20.819 --> 00:18:22.859 That makes total sense. When you type a search 00:18:22.859 --> 00:18:25.160 query, you are entering a text string into a 00:18:25.160 --> 00:18:28.660 massive parsing engine. If you use specific modifiers, 00:18:28.839 --> 00:18:30.640 like putting quotation marks around a phrase 00:18:30.640 --> 00:18:33.599 to force an exact match, or typing site colon 00:18:33.599 --> 00:18:36.079 followed by a domain to restrict the search parameters, 00:18:36.559 --> 00:18:38.819 Google's parser detects that syntax. and executes 00:18:38.819 --> 00:18:41.660 a highly targeted search process. So it functions 00:18:41.660 --> 00:18:44.359 mechanically exactly like a command line interface. 00:18:44.740 --> 00:18:47.819 Yes. So what does this all mean for us? Are we 00:18:47.819 --> 00:18:50.099 essentially all still using command line interfaces 00:18:50.099 --> 00:18:53.019 just with a shiny graphical coat of paint slapped 00:18:53.019 --> 00:18:55.680 over the top? Pretty much. The graphical interface 00:18:55.680 --> 00:18:58.160 we all rely on is often just a wrapper. When 00:18:58.160 --> 00:19:00.660 you drag and drop a file icon on your desktop, 00:19:00.859 --> 00:19:03.500 the operating system is quietly translating your 00:19:03.500 --> 00:19:06.400 physical mouse movement into a text -based command 00:19:06.400 --> 00:19:08.660 line instruction in the background. The core 00:19:08.660 --> 00:19:11.000 architecture of how we talk to machines hasn't 00:19:11.000 --> 00:19:13.519 fundamentally changed. We've just built complex 00:19:13.519 --> 00:19:15.960 translation tools to hide the text from the user. 00:19:16.299 --> 00:19:18.599 The underlying reality is that the machine still 00:19:18.599 --> 00:19:21.740 expects text. We have just spent the last 40 00:19:21.740 --> 00:19:24.259 years building increasingly elaborate ways to 00:19:24.259 --> 00:19:27.200 avoid typing it. Wow. We have covered a massive 00:19:27.200 --> 00:19:29.440 amount of ground today. We stripped away the 00:19:29.440 --> 00:19:32.299 graphical illusion of modern computing to explore 00:19:32.299 --> 00:19:35.079 the physical constraints of batch processing 00:19:35.079 --> 00:19:38.380 punch cards. We unpacked Louis Puzan's brilliant 00:19:38.380 --> 00:19:41.220 conceptual leap to treat shell commands as a 00:19:41.220 --> 00:19:43.940 cohesive language. The unforgiving grammar of 00:19:43.940 --> 00:19:46.720 spaces and backslashes, the absolute magic of 00:19:46.720 --> 00:19:49.579 piping data streams between tools, and the chaotic 00:19:49.579 --> 00:19:52.720 legacy of hyphen versus slash conventions. All 00:19:52.720 --> 00:19:54.619 the way to the URL bar sitting at the top of 00:19:54.619 --> 00:19:57.069 your screen right now. So the next time you type 00:19:57.069 --> 00:19:59.710 a specific search query or chain keywords together 00:19:59.710 --> 00:20:02.650 to filter your inbox, recognize the mechanism 00:20:02.650 --> 00:20:05.009 at play. Right. You aren't just using an app. 00:20:05.210 --> 00:20:07.869 You are participating in a 60 -year -old tradition 00:20:07.869 --> 00:20:11.509 of direct, unmediated communication with silicon. 00:20:12.089 --> 00:20:15.329 You are bypassing the translation layer and speaking 00:20:15.329 --> 00:20:18.089 the machine's native conceptual language. Which 00:20:18.089 --> 00:20:19.670 leaves me with a final thought for you to mull 00:20:19.670 --> 00:20:22.400 over. The command line interface was originally 00:20:22.400 --> 00:20:25.119 designed by its pioneers to emulate the richness 00:20:25.119 --> 00:20:27.759 of human language. Yes, it was. It possesses 00:20:27.759 --> 00:20:30.920 verbs, adverbs, and objects. It allows for infinite, 00:20:31.160 --> 00:20:33.579 precise, and wildly creative combinations of 00:20:33.579 --> 00:20:36.359 tools to solve complex, unanticipated problems. 00:20:36.569 --> 00:20:39.250 When the technology industry shifted almost entirely 00:20:39.250 --> 00:20:42.430 to graphical user interfaces, where users are 00:20:42.430 --> 00:20:44.410 restricted to pointing at pre -drawn pictures 00:20:44.410 --> 00:20:46.470 and clicking on the limited options a developer 00:20:46.470 --> 00:20:49.470 decided to provide, did we actually take a technological 00:20:49.470 --> 00:20:51.849 step backward? That is a great question. Did 00:20:51.849 --> 00:20:55.029 we trade a powerful, infinite vocabulary for 00:20:55.029 --> 00:20:57.309 the digital equivalent of just pointing and grunting 00:20:57.309 --> 00:20:59.890 at a screen? It really forces us to question 00:20:59.890 --> 00:21:02.609 whether our modern, user -friendly tools are 00:21:02.609 --> 00:21:05.970 actually empowering us or fundamentally lim - 00:21:05.869 --> 00:21:08.609 what we can ask the machine to do. Something 00:21:08.609 --> 00:21:10.650 to think about the next time you see that green 00:21:10.650 --> 00:21:13.490 text scrolling across the terminal. They aren't 00:21:13.490 --> 00:21:16.410 just navigating a retro interface, they are wielding 00:21:16.410 --> 00:21:19.230 the most precise vocabulary on earth. Thanks 00:21:19.230 --> 00:21:20.250 for diving deep with us.