 Well, it's that time of the week again. It's time for chitchat across the pond. This is episode number 758 for February 4th, 2020 Oh, hello 2023, and I'm your host Allison Sheridan this week Our guest is Bart Bouchotte's with programming by stealth installment 144 how you doing today Bart? I am doing good Um, I did I it's funny that you tripped on 2023 because since this decade has started I can't type the year because my brain here is 2020 and it's like So I've been typing 202. Oh one two oh two oh two and now two oh two oh three I thought I was the only one. That's exactly what I've been doing Yes, because it's 2020. So your brain goes 2020. Oh sugar just gonna add a one or two or three Exactly. So anyway, there we are. Um So what the listeners won't know or care about because this is evergreen content is that you and I have had a small gap between part one and part two of this Very very related to installments here. So hopefully It sounds sensible when you listen to them back to back five years from now But we are on part two of our journey into shell scripting. I call it a journey. It's more of a brief holiday We're paying a little visit a tourist trip around shell scripting so In the previous installment we learned how to you know the basic anatomy of a shell script shebang line at the top and then Your terminal commands one after the other after the other and your comments with Pound symbols or octal torps or whatever we're calling them We learned that we can make variables We learned all the weirdness about you know accessing our variables with double quoted strings and we learned about single quoted strings and Concatenating strings by just sticking them back to back without even a plus symbol between them What else we learned last time that I think that's sort of the bulk of it But and I'm going to interrupt you right here as a setup for what you're going to say next After we worked on that I was working on making uh mermaid diagrams And I thought you know what I would really like to automate the way mermaid diagrams get created I would like to have a uh shell script that creates my mermaid diagrams for me And I thought okay, this is going to be great and I had went to do it and I said I don't know how to send variables into my uh my shell script Yeah, so what are we going to learn about and I ended up needing to know about something called exit code So what are we going to learn about today Barton? We are going to learn about those very two things because obviously if you just put a bunch of commands in a file It will do exactly the same thing every time Now mostly you wanted to do the same basic thing every time, but not Exactly the same thing every time. So you need some way of telling it. I want you to Do this thing with this thing And so we need a way of sending input and output now There's actually a grand total If you include all the inputs and all the outputs is actually grand total of six different inputs and outputs if you count them all Um, so the obvious one is you can pass it arguments, which you're going to talk about today You can also um, you can ask the user to type something in so you can basically prompt the user and say Please give me a blah blah blah. So we're going to learn about that today as well And the other thing you can do in terminal land is you can pipe things into a command, right? We we have done this many times where we some command pipe some other command Well, you can pipe things into your scripts Which also means that what have we got in terms of output? Well, you can pipe things out of your script through standard output There's also the standard error stream where your error messages go. So that's two outputs And then there is this weird thing called the exit code Which on the one hand is completely hidden and on the other hand is absolutely critical Because that exit code allows us to Take different actions depending on whether or not our terminal commands succeeded or failed or even how it failed because One of the things a creator of a terminal command can do is define the meaning of different exit codes You can say that in my command if I return with an exit code of 404 that means Something doesn't exist or in my command if I return an exit code of 101 It means you type the password wrong, right? You as a creator of the terminal command or shell script get to decide what the error codes mean and you put it in your documentation Anyway, we'll get to that later. So what I was looking for was something that would tell me is it going to fail And that got into some trickier stuff. I think I think that's called temporal mechanics Uh Yeah, well, I wanted it to check to see if the command was even there that it was trying to call Which is something we will learn next week. There is actually a way of doing that Okay, there is a very useful command called test But test makes no sense until we know what we're going to learn today because test is What is it someone once said, you know Unix is simple, but you need You need to be on lsd to notice the simplicity or something like the test command is It is sensible But only in the world of shell scripting So we need to get a little bit We're going to get our feet a bit more wet in that world and then we will come on to the joy of the test command Which is amazingly powerful So anyway, today we're going to look at three of the six possible ways of doing input and output And the reason we're not doing all six today is because in order to actually effectively use the pipe stuff We need to learn about conditional statements and loops And we can't really learn a recognition statement and loops this week. We need to do basic i o first So we're going to do half the i o within our loops and conditions And then we get to finish off with the piping stuff, which in some sense this ties it all together Because once you're into the piping stage your your shell script then becomes a first class citizen on the terminal Because the whole joy of the terminal is running this, you know, running your inputs through a sequence of commands Well, you can then start to chain your scripts together into sequences to do powerful things So that's that's why we're finishing there Okay, right So with all of that out of the way, there is a zip file for this installment But to be honest, I don't think a single one of the two files in that zip file is more than five lines long So you can probably just copy and paste but for sheer convenience. I've added the two files into the zip file anyway So I don't know one of them is 82 bytes part. I'm not sure It's about a character a byte although some of them contain smileys. That's two bytes for one smiley. So Anyway, um We will start with command line arguments because that is the most obvious way to push information in and out of a shell script So if you put A terminal command takes its arguments by having name of terminal command space argument space argument space argument If you want to pass arguments to your terminal command, you do exactly the same thing Um, but then the question becomes okay. That's how I send it to my terminal Or so to my script when I am in my script, how do I access them? Well, the answer is there is a variable called dollar one, which is the first argument There is one called a dollar two, which is the second argument and it continues add infinitum I think it goes up to 256, but it continues for some time And in case you're wondering why these computer scientists sensibly started from one for a change There is a dollar zero dollar zero is the actual command you use to call the script So our first example pbs 144 a dash args.sh Has the simple line echo open a double quote I am and then inside single quotes dollar zero comma my first arg is and then inside single quotes dollar one comma and my second arg is inside single quotes dollar two So if we run that script with dot slash pbs 144 a dash args that sh space pancakes space waffles That means that pancakes is our first argument and waffles is your second argument It prints out. I am inside single quotes dot pbs 144 a dash args that sh comma my first arg is pancakes and my second is waffles Perfectly sensible. I think I've seen this dollar zero dollar one dollar two nonsense in apple script. I think it does it the same way That is entirely plausible. I I know very little apple script. I know that if you do Regular expression matching in java script you get dollar one dollar two as well. I think Okay, I know and yeah, there are other languages that use them. It's a it's a it's a common thing Which yeah, so dollar one and dollar two etc are our arguments very straight So we don't have to save the arguments to a variable name. They have a variable name dollar one dollar two dollar three Exactly. They're just there for us to use which is fantastic The other thing we can do is we can ask the user for something right So and in fact if you once we learn if statements you can start making your terminal commands really friendly And you can say I'll go look for an argument and if I don't find an argument instead of throwing an error I can just ask the user for the thing. I want it So you could say if there is no dollar one then prompt the user to tell me their name or whatever as you can get very creative But the command we're interested in for getting input from the user is the read Command which is used for more than just reading input from the user But it's it's default behavior is to read from standard in And most of the time standard in is connected to your keyboard That's not true when you're dealing with pipes, but that's a problem. That's something we'll talk about You know the installment after next So for us today standard in is the keyboard. So the read commands default behavior is to read from the keyboard Uh, it needs one argument Which is the name of the variable it should read into in other words If you ask me for something from the keyboard, where do I put it? And you give it the name of the variable the confusing thing to terminal newbies is that Remember that the dollar sign is kind of saying fetch me the variable So the name of the variable doesn't have a dollar the dollar is how you access the variable So the first argument to go to read is not a dollar my variable name. It's just my variable name And that's something was Which is also true when you create a dollar. No, so it's just variable name, but when you call it, it's dollar variable name When you sign it, okay Correct and it's the same when you do with the equal sign right when you assign a variable you say, you know waffles equals pancakes And then the variable dollar waffles has the value pancakes because the dollar actually means fetch the value of Right. Okay. Okay. I think you told us that last time, but I think you should probably tell it to us every time I need to tell myself it every time one of the most common errors I get in with my work hat on when my shell script doesn't work is that it says there's there's no variable dollar dollar Whatever because I've put a dollar sign in when I name the variable Which then means it's actually when I try to access it. I should put two dollars in it Yeah, I do it all the time. I get around all the time. Which is why I keep repeating myself So we could use a read variable in conjunction with the echo command we learned last time and so we could say echo What's your name question mark and then we could say read space name Right and that would read the name into the variable name So That's two commands to do what's kind of one job I want to get the person to enter a name So to save you having to use two commands the read command has an argument called minus p or a flag called minus p That lets you specify a prompt So you can say read space minus p. What's your name? space name and that will Print to the user. What's your name and take the answer they give and stick it in the variable name So the advantage of that was just doing it all on one line instead of two lines It's all on one line. It also displays On the same line. So it's a little bit less cumbersome output because it's not a line of text and then a blank cursor sitting on an empty line It's That what you want and immediately the cursor is next to the question Oh, okay. It waits for you right there It waits for you right there, which is actually kind of nice And so if you want you can put a symbol like some people put like a little carrot symbol at the end of their prompts So that you sort of get a blinky cursor like you'd expect. Yeah, it's up to you Some people then I notice that you also put you put a space after you said, what's your name? You put space quote that way when they write their name, it'll be After it'll have a space in between Correct, which I discovered after running the script once again. Well, that doesn't look good So then I did it again Um, so we have our second example Which is just a little three line script says read minus p. What's your name into name read minus p What's your favorite fruit into fruit and then it echoes out inside double quotes high dollar name comma have some dollar fruit And then we close the dollar we close the double quote because the variable we called it fruit But I want to make it plural So then I immediately stick on to the end of it another string with single quotes with the s followed by space Followed by smiley and then I close my single quote. So that's two strings concatenated by just shoving them next to each other So when I run that command and I enter a bar to an apple you get a high bar to have some apples And it means my face So that's a good reference one for us to remember how to do that concatenation you asked us or taught us last time Precisely why I did it And it's something that comes up quite a lot actually playing around with those different strings and stuff So that's two out of our three methods of input for today. So What if my favorite fruit was bananas To have some bananas is Ah, yes, uh pluralization is surprisingly difficult in error messages With my workout on I tend to put s's in brackets a lot Oh, because I might be plural might not be might be plural might not matter moving on there is an amount of yeah There has been an amount of error I hope they're singular Anyway, it is a lot of error reporting end up doing Um Okay, so the last thing I want to talk about which is probably our biggest topic for today is exit codes So every time any terminal command finishes running the last thing it does as it hands back to the shell So a shell runs commands on your behalf The last thing a command does as it finishes is hand back to the shell an exit code Or if the command falls over in a giant big heap the shell will make up an exit code of I think one For I don't know what happened there, but it that guy just went away. I asked him to go do something and he vanished You know error code um, and so That exit code is a way for the command to signal What it did programmatically and so they're just a range of numbers from zero to 255 Because you can't have 256 anyway from zero to 255 And the person who wrote the command gets to decide what it means so a lot of A lot of times when you look at the man pages for a terminal command There'll be a section near the bottom called exit values or exit status or return codes or one of the very euphemisms for exit codes And it will just list the numbers and what they mean So I just basically picked internal command at random because I happened to have done a backup recently I would just went man or sink to see what was in there And lo and behold at the bottom of or sink is a very long list of error codes So error code zero means success error code one is syntax or usage error error two is protocol incompatibility error three selecting input or output files error four Requested action not supported an attempt was made to manipulate 64 bit files on a platform. They cannot support them And it goes on Actually, it's strange. I've got to go back and look. I had an rsync error that it needed to say Uh, your friend's house where you put your uh, your other Synology that you're backing up to using rsync had a power outage and I didn't come back up That's what it is to be Probably some sort of connection error error in socket. I owe. I'm going to guess probably error 10. Yeah, I'm gonna have to go find out hmm so anyway, they all have them and The one thing that's in common always Is that very counter-intuitively? zero means success Hmm and in almost all of computer science zero means false or not Or no, right? It's like not good And one means true or happy or one, you know, one is true Whereas here one is just the first of another 254 error states Right everything that isn't zero is bad Zero means nothing went wrong. Everything else means something went wrong And I have the choice of expressing that somethingness with these 254 possible numbers so in my brain I remember this counter-intuitive fact by never mentally calling them exit codes. I call them error codes in my head Oh on purpose zero error Zero error is how I remember that at zero is good Okay, now very careful when I type things and when I write documentation and when I you know when I'm communicating One of the nerds I'm very careful to translate it back to the proper usage of the word But in my head they're error codes And then I remember zero is good zero error. No problemo. All happy. Okay. Yeah. Yeah, that makes sense So these exit codes are always returned to the shell But we don't see them right when you run the ls command to have a look at a directory It returned an exit code of zero unless you ask it to list you a directory that doesn't exist So in order version you use some other exit code But you don't see that right it doesn't print out the list of files and then a zero Right. It's right invisible But it's not Invisible it's actually in a variable. It's in the specially named variable question mark Which you access with dollar question mark So if you say echo dollar question mark, it will show you The exit code from the previous command. Oh, wow Which is very useful when debugging things So I guess And the exit code of the echo command will be zero. So if you type Some command and then you say echo dollar zero dollar question mark It will give you the error code and if you do echo dollar question mark again It will not give you the error code anymore because the previous command is now the echo command which succeeded So we'll be back to zero So you really do need to check the exit code immediately and you don't get a second chance Because right you run another command. It's now something else So the exit codes Yeah, the exit codes are always there Therefore you can always access them with echo dollar question mark Can you do that inside the script? You can Because you've told it some command to do and you can so you could do that as as error checking maybe within a script Absolutely, you can so you can either just do it in the sense of I don't really care what went wrong if something went wrong do this Or you can use it in even a case statement and the terminal our bash has a case statement So you could actually say Case zero echo. Yay, you know, and then a different case for each of the possible What is case? I don't know what case is Sorry case is the equivalent of switch in javascript So you would say switch a and then you can say case It's like doing an if else but instead of typing if I see to say case one case two case three case four So instead of saying if For the case that the variable i'm switching is a one do this for the case that the variable is a two do this It's like saying if x w equals four do this else if x w equals two do this else if x w equals three do this Right, that's really cumbersome to type out So the switch statements that you say switch x case one some code case two some code Oh Yeah, I'm sure maybe I didn't talk about it in javascript There was a lot of episodes though I was gonna say if I did it would have been a roundabout. I would guess episode 14 or 15 Which is a we while ago 42 years ago Yeah, yeah fair yeah, but luckily we all know that my mind is like a steel trap and nothing has slipped through and in uh all these Right not a wine ball that you're trying to pour it into from a fire hose definitely not I do adore that analogy from your dad um Anyway, yeah the point being you can absolutely use those exit codes in your scripts to make your script react differently Well, the most simplest thing to do is to make it react to an error Just to make it do something sensible when anything went wrong Or you can use it to be very intelligent if you're using a command with well documented exit codes Then you can actually You know Save dollar question mark into a variable and then really do so work with that variable and have a bunch of different You know if statements and whatever It all depends on how important the thing is Like if your script's whole job is to do a certain thing and react in a sensible way Then you may spend 10 20 30 lines of code dealing with the possible exit codes because it's really important Or you may just not care. You may just think I think it worked Or it didn't and then you just write a very simple piece of code I'm I'm stuck on that. I don't understand what it can do other than succeed or fail Okay, so the the command returns an exit code at its discretion so it can use that exit code to tell you why it failed Okay, but you you talked about us writing the exit codes That we can write it. No not yet something. Oh I will be saying that but I haven't said that yet Okay, so you asked can I use these exit codes in my script? So in your in your script you might do something like Or sing I might do our order to know Okay, and our sink is going to spit back these pre-defined exit codes that the command our sink has to it Okay, correct. And so if you're doing an r sink and it's really critical to your script functionality Maybe maybe the functionality is like if or sink doesn't work try ftp Or maybe the functionality is if or sink fails for this reason then email Ron because his power is gone If or sink fails for this reason email steve because he's hugging too much bandwidth I mean I'm sort of making it up as I go along here But you may want to do different things if something like there is more to being broken than just is it broken, right? I think it's one of the when I put my work hat on I think the thing I hate most is when someone comes to me and says It doesn't work And they cease speaking It's like, no, no that is the start of something useful What? You know what should have happened. I'm a few more bars for me Yeah, exactly exactly that is the that is the perfect response because I generally just give a dirty look and sort of the gesture of, you know, continue Yeah, that's Exactly exactly. So anyway, yeah, the exit code is when they tell you Some completely extraneous piece of information that takes them forever to explain that you already know has nothing to do with this I had a woman on the ship who was on the cruise. We were just on who Her phone couldn't get email and she was convinced it was becomes because some website made her do two factor authentication And I could not get her to stop telling me about two factor authentication No, no has nothing to do with this problem She was connected to wi-fi Yeah, that knee bone is not connected to that ear joint, which doesn't even exist Yes, anyway, so you we can make use of these exit codes and zero good anything else bad Just different shit different flavors of bad, but zero good everything else bad so How does that affect our script, right? So our script is a collection of terminal commands If we use our script within Another script or within a terminal command Shouldn't it also have an exit code? Why yes, it should And the exit code of your script will be the exit code of the last command that ran Now at the moment since we haven't learned a bit loops or if statements or anything The last command to run in our script will be the bottom command at the script But as your scripts get more complicated the last command to run could be halfway up your script If you have an if statement or whatever right that that changes where things flow So your script Its exit code is the exit code of the last command to run There is a command whose specific job is to end a script With an exit code So if something goes wrong you can say exit space and then you type a number And so you can then decide that if You know my script is only supposed to run on a wednesday because that's when this business process happens And if someone runs the script on a thursday, I exit with code one And if Someone who's not an admin tries to run the scripts I exit with code two because actually I need to be an admin Because otherwise I know that something will fail Or you know you can start to build up these reasons and you would have them in your documentation So you then say if day of week not equal to wednesday exit one if You know user not in group wheel Exit two All right, you get the idea right so By default your script will end with whatever the exit code was of Whatever you last ran which is hopefully a successful exit code But if you want to end the script the command to end your script is exit And by default you exit one Actually, no by default you exit zero. I think we default your exit success But if you want to exit with a specific exit code then you exit Space the number and you can you can end your script early with a successful exit code by saying exit zero or if your script is supposed to Check if something is true and if it's not true make it true Well, if you check it's true and it is true your script is finished successfully So you can just at the very top of your script say if this thing exists exit zero And that will show us a successful execution Even if you didn't finish the script Okay So it is just basically think of them all as being functions that returns true or false Only instead of false you get to have lots of different shades of false Okay Now this is where Things get interesting We're now laying some really important foundation, which is so important. I want to say it twice So we're doing it today And then we're going to revisit it at the start of next time's discussion Which is all about if statements and loops and stuff because central to both conditional statements and loops are Basically boolean logic right checking for truthiness of some kind right and if statement Evaluates to a question of truthiness a loop continues until something truthy becomes faulty Right, you know the concept of truth and falseness is central to conditions and loops And the terminal does not have traditional booleans The terminal uses exit codes As its way of telling truthiness So an if statement on the terminal Looks at the result of a command To decide what to do and the way it looks at the command is it looks at its exit code So that means that everything Logicky on the terminal is in exit code logic Which means that if you write it down as a traditional truth table, it looks wrong to a computer scientist But if you write it in English, it looks correct So there are two boolean operators that are very important ampersand ampersand means a logical and And pipe pipe means a logical or And so normally in normal computer science world One and one is one or true and true is true In terminal world Zero and zero is zero Because if you say it in English it's fine is success Correct But is what is what is one and one? Well one and one is error and error is error So one in one still is one That is true, but so is two and one and so is 56 and 32 So actually the rest of the truth table becomes really confusing So the next entry will be zero and anything greater than one is one because success and any error is error I'm gonna correct you zero and anything greater than zero is one That is certainly what I tried to say. Yeah, that's so what I said that I was wrong So one and above as long as there's a one basically if there's any kind of a false in there An error in there it turns the the combination becomes an error Yes, okay, exactly. So greater than zero and greater than zero is one And there's also the or operator right, okay. Yeah, there's also the or operator which is Zero or zero is zero because success or success is success And then zero or greater than zero is Zero because success or error is still success Greater than zero or wait stop I want her to head Well, but explain why why is zero and and one zero or Zero or we're on the or table So true or false is true Why so zero Because that's how or works or means either of the one or the other is successful Only if that's what you only if that's what you ask it Okay, but i'm describing the rules for or so the rules for or are by definition True or false is true. That is the definition of of or okay. Okay. I forgot that all right So that means in terminal speak success or success is success success or error is success Error or success is success. The only way to get an error is error or error is error And that is super fun in an audio podcast for people absolutely however This is actually these two tables combined with a technique called lazy evaluation Gives us really Powerful quick to write if statements that don't even involve the word if Now bash can do way more and we're going to learn the way more next week But lazy evaluation is where the so in order to evaluate a true or false statement So you use the and operator There's something on one side of the and and something on the other and the answer of that whole statement Is going to depend on the rules in those two tables The way bash does it and this is common to a lot of programming languages Is if the first Result means that it doesn't matter what the second result is the outcome is already known The second one is not executed And that is guaranteed to you if I know enough after executing the first one I will not execute the second one. I will immediately return the result of the Operator and that's called lazy evaluation and that is a feature not a bug So would an example be um, I'm going to use and And I've already given it a what I've gotten an execute of one for the first thing and then it gets to the and It knows that the answer is going to be false Or error. Yes, precisely precisely and therefore will not do the second But if I gave it a one and an or it's like, well, I don't know I got to execute the second one Correct. Okay, and the inverse of that is also true. So you can use the two operators to achieve two things Only run the second command if the first fails And the opposite thing you often want to do Only run the second command if the first succeeds And they're both really powerful things to want to do Yeah, yeah, so to make it real world Here would be a snippet of a shell script that exits my script with a 404 error If we fail to restart the engine x, which is a web server So the command to restart engine x is system ctl restart engine x dot service, right Take it for me. That's just how it is in linux land. So I say the command a lot of times Yes, you have which is why I picked it. Uh, so system ctl restart engine x dot service or exit 404 So the exit 404 will only happen if system ctl is error Because if system ctl is true is success Give me a second to exhort observe this see if I can Follow what you're saying. So you've got a command or exit 404 If the first one succeeds By definition when it hits the or it's got to go to a sec. Well, no The opposite. Oh the opposite it will it will only Because it's success or anything if it if it succeeds It knows it succeeded it doesn't do the next thing Correct, but if it fails Then it exits 404, then you know it's an error and therefore it should execute the 404 Yeah, or I mean it doesn't have to be like the the thing after the or could be any other statement, right? So maybe it's you know logger to send something to syslog or Whatever you want to do in response to the error But you know exit 404 seems like a sensible thing to do because then if your script fails with an error 404 You know because you wrote it ah 404 engine x is cranky if it x is with 303 Maybe something else is cranky, you know, maybe my sequel is cranky or something, right? It's up to you to decide What your exit codes mean, but you can use that to then be more intelligent about things Or you could just use an echo statement and you could just say or echo It makes sense having followed that that truth table with you, but reading it looks funny command or exit 404 But is it so funny though if you say it out loud start engine x or be cranky It actually does kind of work in pseudo code, right? Yeah. Yeah And then the opposite thing what you also want to do very often Is do something and only do the second thing if the first one succeeded And the the use case for that is test the engine x config Then restart engine x because engine x can be running with a broken config because it only checks its config on start So it's very common to have a web server hosting, you know 50 websites for a large university And then you go make a small change because someone wants to change a redirect, you know forward slash twitter to go somewhere else or whatever Well, if you made a typo and you just type system ctl restart engine x you've just taken 50 websites off the air That is that makes people cranky at you So what you really want to do is a config test followed by the restart and so engine x minus t will do a config test So if you say engine x minus t ampersand ampersand system ctl restart engine x Well, then the restart only happens if engine x minus t succeeds Right, right, right, right, right. So it has to get the exit code of zero Because it knows when to hit the ampersand that if if it's got a one, it's not going to do the second thing. Oh, wow Correct. That's a good practical example Yes, and you use an awful lot because it's so much easier to just type ampersand ampersand or pipe pipe than it is to do a whole if statement So you will see a lot of this kind of you know, do something or be cranky or do something and follow through And that's basically the hat. That's how you do it in terminal land But of course you could do more with if else an elif which is the terminal's version of elsaif But as we learn in the next installment the terminal is very verbose about its if statements because It's not a statement. It's actually a whole bunch of commands So it takes one two it takes at least three commands to do an if statement on the terminal Up and it could be many more whereas this is just a one liner So this is why shell script geeks love these little ampersands and ores because they're so much easier than if But if it's fine as we learn about next time it does work and it's very powerful, but it's a bit verbose. It's a lot of typing Um, so yeah, anyway, that's where we're going. So At this stage, we know how to write a script. We know how to put some variables in it We know how to take input from the user in the most basic way So as arguments just asking the user we know how to return exit codes We even know how to use those exit codes for some basic logic Which means we're now ready to move on to what I think is the Is the is the raison d'etre for this entire little mini series The ability to control the flow of things inside the shell script in other words if something is true do something else and obviously keep doing this For this many times or until this thing happens or until this thing doesn't happen But basically the the ability to to branch and to loop And that that is what gives shell scripts great power And so that will be the entire focus of the next installment is that you know branching and looping And that will set us up perfectly to finish our exploration by looking at the plumbing as I call it in other words piping stuff into your script And making sure that your script plays nicely with people taking its output as a pipe into themselves So basically can I see it in the middle of a pipe? if you want to read ahead on uh doing the terminal plumbing bart did cover this in installment 15 of uh the taming the terminal series And there's a link in the show notes of course to that Yes, so that will explain the plumbing, but of course what we we're going to learn is how to play nice How do we be a good elbow joint? It's I guess How do you make stretch my analogy? Yes, exactly All right, how to be a part of the plumbing instead of just using it to connect together other people's commands All right, my script should be able to sit into That structure and play nice with with all the other terminal commands and scripts and things And so that's that is the final piece and then Then we have all of the tools we need to automate because there's a whole reason we care about this Is to automate our build process in our code Because now that we're starting to use lots of different tools to make complicated code that needs to be Built into a final version and stuff there's actually quite a few commands to go from source code to working product And I'm a lazy sod I'm also a typo prone sod so I need to script this stuff for my own sanity and for my own consistency and so that's why that's why we're doing this and so That's why this is only a short dip into shell scripting instead of you know We could spend months actually no us being us we could spend years Shell scripting but we're not going to so that's that is where we stand like learning this and This is the kind of thing had you taught me this four years ago I would have said I don't have anything to automate And it's been interesting watching the number of things that I've started to think hey I could do that faster I could do that without ever typing it the first time And now I'm in the mode where when I start to work on something I'm like That I'm going to do that twice. Let me automate that before I even start Again because yeah, or because the error code is always one when I'm doing it by hand Right and it's a good way to think about things right if I can express what I want to do as a piece of code Then I have to think about it logically for a start So I'm more likely to get it right but also I now have it versionable So the process has become something in version control And that's actually very powerful because you're in a captured process. So particularly on a shared team Capturing process is actually very powerful Yeah, yeah Well, this is fun And I'm glad for my first show back after a vacation that you would you went easy on us here Well, I went to believe it or not, right? This show was really fun to record and it wasn't very long But this is the most difficult one I've written in as long as I can remember really because Finding a path through what I want to do that doesn't involve me saying now ignore this line. We'll learn about it next week Okay, so hard to find your way around, huh? Okay I had to tiptoe my way around and it just was not coming together And I you almost got a panic tech message from me about eight hours ago, but then just the time everything fell into place So we did make it the anyway. Yes. I'm let's stop rambling on Let's keep it a short show and remember folks very important until next time happy computing If you learn as much from barn each week as I do I'd like you to go over to let's dash talk dot ie And press one of the buttons over there to help support him He does 98 of the work here I'm just the stooge that listens to him and asks the dumb questions If you go over to let's dash talk dot ie you can support him on patreon You can donate via paypal or you can use one of his referral links I really hope you'll go over and help him out in the meantime You can contact me at pod feet or check out all of the shows we do over there over at pod feet dot com Thanks for listening and stay subscribed