Speaker 1: Okay, let's unpack this. Imagine being able to tell your computer exactly what to do, not just step by step, but uh with intelligence allowing it to make decisions. Today, we're diving into the world of shell scripting. Specifically, how we give our scripts the power to choose, to adapt, and well, to interact with you. Speaker 2: Yeah, what's fascinating here is that we're moving beyond simple commands to building, you know, truly interactive tools. We'll explore the foundational elements of creating script, then quickly pivot to the core concept. cept of conditionals. These are the if this then that rules that make scripts truly dynamic. Speaker 1: And for this deep dive, we're looking at a series of insightful YouTube videos from Adriana Holden Guveta on shell scripting basics and conditionals, plus some supplementary web material, too, all focusing on practical application, getting hands-on. Speaker 2: Exactly. Speaker 1: So, here's where it gets really interesting. We're starting right at the very beginning, creating a script. It's uh it's not as daunting as it sounds. Speaker 2: We're talking about naming conventions, maybe like river.esh that ending. It's optional in Linux, right? Speaker 1: But helpful. Speaker 2: Yeah, it is. Yeah, it's not required for the system, but it's a good visual cue for humans. Tells you this is probably a shell script. Makes things easier to identify. Speaker 1: Okay. And we'd use an editor like say VI to create the file. Speaker 2: V nano, whatever you're comfortable with. Speaker 1: Inside the first crucial bit is that sheang line, that hashtag.binch at the very top. Speaker 2: Ah, yes, the shebang. Speaker 1: Its job is to tell the system how to execute the script. like use the program located at bench to run the following commands Speaker 2: and you might see bin bash sometimes too. Is there a big difference? Speaker 1: There is technically bin bash gives you access to bash specific features which can be more powerful but honestly for most basic scripting bench is uh generally sufficient. It's more portable sometimes too. Speaker 2: Got it. So inside the script after the shebang what's next? Maybe our first actual command Speaker 1: echo is the classic starting point just prints text to the screen Speaker 2: right like the uh the memorable firefly example Speaker 1: like Speaker 2: I can kill you with my brain. Speaker 1: Exactly. A bit more dramatic than hello world. Speaker 2: Right. But once you've written your script, say with that echo line, Speaker 1: you can't just run it immediately. Speaker 2: Ah, right. Permissions. Speaker 1: Permissions. By default, the file doesn't have execute permission. You need to grant it. Speaker 2: And that's the tramod plus x command. Speaker 1: That's the one tramod plus x. Your script name.esh. You might even see the file name change color in your terminal, maybe turn green, indicating it's now executable. Okay, so chimod plus x river.esh. And then to run it, Speaker 2: you type river.esh. Speaker 1: The dot slash tells the shell to look in the current directory for the executable. Speaker 2: And boom, I can kill you with my brain appears. Simple, but uh not very interactive yet. Speaker 1: True. That's where variables and input come in. Speaker 2: How do we make the script ask us something? Speaker 1: With the read command. If you put read answer in your script, it just pauses. It waits for you, the user, to type something and hit enter. Whatever I type gets stored. Speaker 2: Exactly. It gets stored in the variable named answer. And the neat thing about shell variables is they're untyped. Speaker 1: Untyped meaning Speaker 2: meaning you don't have to declare them as int or character or anything like in some other languages. They're like flexible boxes. They just hold whatever you put in them. Speaker 1: Okay. Flexible boxes. I like that. So how do we use the value in that box? Speaker 2: Use a dollar sign. Prefix a variable name with a dollar. So answer expands to whatever value is stored inside the answer variable. Ah, like in the other example, echo, I don't care that you said answer, I'll tell you anything. Speaker 1: Precisely. It slots your input right into the sentence. It's a fun way to see variables in action, even if it's a slightly uh cheeky hello world. Speaker 1: So, okay, we can get input with read, store it in a variable, and use it with the dollar. What does this all mean for building smarter scripts? How do we make the script decide based on that input? Speaker 2: That's the next leap. That's conditionals. Speaker 1: Conditionals, right? These let the script make choices, follow different paths, not like loops which just repeat things. Speaker 2: Exactly. Loops are for repetition. Conditionals are for decision points. The core structure for this is the if else statement. Speaker 1: If else sounds familiar, Speaker 2: it enables different blocks of code to run based on whether a certain condition is true or false. Speaker 1: Yeah. Speaker 2: If we connect this to the bigger picture, uh this is about giving your script that decision-m tree. Speaker 1: Let's build one. The basic if then else structure maybe using that Kaye example. Speaker 2: Sure. So the script asks echo, do you want to hear about Serenity's engine? Then it reads the input read answer. Speaker 1: Okay. Speaker 2: Now the conditional if condition then action else different action fi. The fi just marks the end of the if block. Speaker 1: So the condition would be checking what's an answer. Speaker 2: Right? Maybe you answer yes. Notice the square brackets and the spaces inside them are important. And the double quotes around answer and yes. Speaker 1: Double quotes. Why are those so important? Speaker 2: Ah they handle spaces or empty input gracefully. If someone just hits enter or types yes please without quotes. The script might break quotes prevent that. It's a common source of errors if you forget them. Speaker 1: Okay, so if answer yes, then what happens then? Speaker 2: Then you put the commands you want to run. If the answer is yes, maybe echo. Great. Let me tell you. Speaker 1: And the else part, Speaker 2: that's the fallback. If the condition answer yes is false, the code block after else runs instead. Speaker 1: Like the funny entitled Kaye version. Else echo. Too bad I'm going to tell you anyway, but now you owe me a strawberry. Speaker 2: Exactly. And then you always finish with fi to close the whole if. statement. Speaker 1: So if then fire mandatory. Else is optional but highly recommended. Speaker 2: Precisely. Else catches everything that didn't meet the if condition. Very useful for handling unexpected input. Speaker 1: But what if yes or no isn't enough? What if there are like three or four specific things we want to check before the general else? Speaker 2: Question. That's where LF comes in. It stands for else if. Speaker 1: Else if. Okay. Speaker 2: It lets you chain conditions. So if checks the first thing. If that's false, LF checks a second specific thing. If that's false, You could have another LF and so on. Speaker 1: And then a final else at the end for anything else. Speaker 2: Exactly. So for Kaye, if answer yes, then LF answer no, then echo. Ah, that's sad. I love talking about serenity. Echo. H, I don't understand that, but engines are cool. Speaker 1: F. That gives you much more control over different responses. Okay, let's unpack this further. We can make one decision. We can make several alternative decisions with L if. What about decisions within decisions? Speaker 2: Ah, nested conditionals. You got So an if inside another if. Speaker 1: Correct. An if statement placed inside the then block or sometimes even the else block of an outer if statement. Speaker 2: How is that different from just having two if statements one after the other. Speaker 1: Critically different. Speaker 2: A nested if only executes if the outer condition it's nested within was true. A second separate if would run regardless of the first one. Nesting creates dependent decisions. Speaker 1: Okay, that makes sense. But it sounds like it could get complicated quickly. How do we keep track? Readability becomes key. Let's revisit Kaylee. If the user answered yes to the engine question, Speaker 2: right? So, inside the then block of if answer. Yes. Exactly. Speaker 1: Exactly. Inside that block, you could ask a new question. Echo. Do you want to hear about the compressor or the fuel pump? Then you'd need another read command. Maybe read answer two. Speaker 2: Okay. Second input. Speaker 1: And then still inside that first then block, you'd put your nested if. If answer compressor, then echo compressor. Clearly, I know nothing about spaceship engines. L's echo blah blah blah. Fuel pump. Ah, I see. So that second if about the compressor or fuel pump only even gets asked, let alone answered if the first answer was yes. Speaker 2: Precisely. And this is where indentation really helps. It's not required by the shell, but tabbing that inner if statement makes it visually clear that it's part of the outer ifs then block. Speaker 1: Good practice for sanity sake. Speaker 2: Definitely. And remember, every if nested or not needs its own fi to close it. And again, double quotes are essential, especially if answer two could be something like fuel pump with a space. So, quotes spacing five for every if and indentation for readability. Got it. Now, what does this all mean for the kinds of conditions we can test? It's not just about matching words like yes or compressor. Speaker 1: Not at all. Shell scripting offers more. For numbers, you wouldn't use the single equal sign. Speaker 2: Oh, what do you Speaker 1: You use specific numerical comparison operators. Speaker 2: Disq for equals, d for not equals, L for less than or equal to, it d for greater than, ds for greater than or equal to. Speaker 1: So, Like if count initi five five Speaker 2: exactly if count nisk and defia then echo more than five items. Speaker 1: Yeah Speaker 2: using there would treat five as a string which usually isn't what you want for numerical logic. Speaker 1: Okay so different operators for numbers. What else can you check files? Speaker 2: Absolutely. There are file pest operators too. Ditch E checks if a file or directory exists. - F checks if it's a regular file. - G checks if it's a directory. Speaker 1: Oh, that sounds really useful. Speaker 2: It is. Think about checking if a configuration file exists before trying to read it. If - F is sissyconfig.com heft then source sissy myconfig.comconfs echo warning config file not found sv practical Speaker 1: that opens up a lot of possibilities but with all this power comes well probably a few tricky bits what are the common gotchas for learners working with conditionals Speaker 2: oh there are definitely a few classic ones number one without a doubt is spacing Speaker 1: spacing again Speaker 2: yes shell scripting is extremely ticky about spaces you need spaces around the square brackets in argua you need spaces around the comparison operators like as OBQ. So if thyro val will fail, it's probably the most common error. Speaker 1: Wow. Okay. Pay attention to the spaces. What else? Speaker 2: Using the correct comparison type. Using a reall when you meant AFU for numbers or vice versa. That'll trip you up. Speaker 1: String equals versus numerical equals. Got it. Speaker 2: Then there's the forgotten fi. Every single if needs a matching fi. If you nest them, it can be easy to lose track and forget one, leading to syntax errors. Indentation helps catch this. Speaker 1: Makes sense. Speaker 2: And finally, while not strictly an error, not having an else clause. I always recommend adding an else as a catch-all. It makes your script more robust because it handles situations you didn't explicitly plan for with your if or if conditions. It ensures there's always some path the script can take. Speaker 1: Those are great tips. So, what does this all mean for you, the learner? How can you take these building blocks, input, variables, if LF, nested ifs, and create something genuinely interactive and useful? Speaker 2: Well, now you can start building some really engaging things. Think about a simple knock-knock joke script. Speaker 1: A knockk knockock joke. How would Conditionals help there Speaker 2: because you need the user to give the right answer at each stage. After knockk knockock, you need them to say who's there. Speaker 1: Then you say orange. Then you need to say orange who. Speaker 2: Unnsted if is perfect here. If they give the wrong response at any point, the else branch can say something like, "Nope, that's not how the joke goes." And maybe exit. It enforces the structure of the interaction. Speaker 1: Ah, I see. It's not just branching, it's validating the sequence. That's clever. Speaker 2: Exactly. Or a more classic example, Choose your own adventure stories. This is practically built for nested if statements, Speaker 1: like a little text adventure game. Speaker 2: Precisely. Start with Echo. You stand before a dark cave. Do you enter or run away? Speaker 1: Then read choice one. If choice one, enter, then inside that block, you describe the cave and present another choice. Echo, you see a glittering sword and a dusty potion. Take sword or potion. The read choice two. Then another nested if based on choice two. Speaker 2: And each path leads to different outcomes or more choices. Speaker 1: Right. You can build complex branching narratives. It's really helpful to actually draw out the decision tree on paper first. Plan your endings for each path. You know, XKCD comic 1350 is a hilarious take on just how complex branching paths can get in real life, but illustrates the concept. Speaker 2: Oh, I know that one. It shows how quickly choices multiply. But yeah, it really highlights how these simple commands become powerful tools for storytelling and decision-making when you combine them like this. Speaker 1: Absolutely. You're designing an experience, not just executing comm. So we've gone from basic echo commands and getting input with read all the way to building decision trees with if l if nested conditions checking numbers checking files we've really given our scripts the ability to think react and well create interactive worlds. Speaker 2: We have and if we connect this to the bigger picture Speaker 1: mastering conditionals is uh it's a fundamental step. It moves you from just running commands to actually programming creating systems that respond intelligently to their environment to user input. But it forces you to think critically about all the possible outcomes, all the edge cases, Speaker 2: which ultimately leads to better, more robust scripts. Speaker 1: Definitely. Speaker 2: Okay. So, here's a provocative thought for you to mle over. How might you use nested conditionals, maybe in a slightly non-obvious way, to create a truly unexpected twist in a simple interactive story? Or thinking more practically, how could you use them to guide a user through, say, a troubleshooting process, but in a creatively personalized way using only these basic building blocks we talked about. What unconventional paths could you open up? Trying to anticipate not just the yes or no, but maybe the the sideways answers a user might give making the script feel almost preient. Speaker 1: That's a fun challenge. Speaker 2: Something to think about. Thanks for joining us on the deep dive. We can't wait to see the intelligent interactive scripts you create.