 This is how they get access to file systems to communicate with each other and things like this. So regardless of what higher level language you're using, this is happening. So just understand. OK. Couple announcements. I don't know why I'm searching for site.css. So I'm going to close that. Try to. Oh no, stop. OK, there we go. So how many people are receiving mail for the class? Hopefully everybody. Is anyone not receiving email for the class? I just registered. You just registered? OK, you'll be there tomorrow. Yeah, so you should all be getting mail. If you want to, as I pointed out earlier, if you want to get off the mailing list because you dropped the class, please don't email me. Just follow the link and you can remove yourself. I just add people. The script just adds people. OK, the syllabus is online. I think it's completely up to date at this point. So the core staff is on there. Locations are all up to date. Dates are up to date. Due dates for the assignments are correct, blah, blah, blah. There's links to the various playlists for the lecture videos and recitation videos, stuff like that. The first two videos are up. They're a little bit out of focus. I'm sorry about that. That was just my fault for not figuring the camera properly, but that should be fixed starting today. But those are up and we'll post them fairly promptly after class at this point. Starting today, yes, there we go. OK, recitations will start next week. So we're going to make a call about the 8 AM Friday recitation. That always seems to be, particularly in the middle of February, a fairly bleak time to hold recitation. So we're going to staff that recitation for a couple weeks. If there's only two people coming to it, and one of our teaching assistants is waking up really early in the morning and practically freezing to death on the way to campus to get here for it, we'll probably try to encourage the people that are coming to move to a different recitation. That is, unfortunately, one of the recitations that's in a larger room. So go figure. So there's no rule about recitations for this class. You don't have to go to them. You don't have to go to the one that the hub thinks that you should go to. If you're a graduate student, you can attend recitation. However, I wish one of the TAs was here. One of the recitations is in a room in Fronsack that I think is fairly small. I think that's the one on Wednesday. So if you're a graduate student and you'd like to go to recitation, I would suggest attending the Tuesday recitation, which is in a huge room. So there will probably be some extra space in there. The airdrop deadline is Monday. So this is sort of the critical point. Now, of course, you can withdraw later or whatever you end up with a W on your transcript or something, not a huge deal. But this is sort of like your last chance this weekend to look at the assignments, get started with things, and decide if this course is a good fit for you before there's some sort of issue with doing. OK. The assignment zero due date is today. There is nothing to submit. But I hope that many people are finished. How many people are done with assignment zero? Awesome. I'm so inspired. So I actually, for a brief minute today, believed that somebody in office hours was working on assignment two. I turned out to be wrong. But I was capable of believing that, because people seem like they're actually starting. So that's awesome. So please work on assignment one. Recitations next week will focus on assignment one. There's no more assignments here. I mean, assignment zero is simple. There's plenty of good assignment zero resources online. So we're not going to do anything in recitation assignment zero. We'll start on assignment one right away. And at some point early next week, we'll push out test 161. It'll be ready for assignment one. And you guys can start using that for your testing. OK. So sorry, there's just a few more announcements than usual. It's still the first week. Here's what we're going to try for office hours scheduling. So in the past, we did this huge doodle poll, and it was very messy and kind of frustrating for us to process. So what we're going to do is, Ali is working on finalizing a preliminary schedule that is based on last year's office hours. So we're going to put that up today. It'll be on the calendar for starting next week. Look at that. And if you can't, again, I would really try to encourage you to find four office hours a week that you can come to. If you can't come to four, we're going to send out a form for you to fill out to tell us that you can't and to propose some alternative office hours. So this is going to be kind of a two-stage process. We're going to distribute about maybe 80% of the office hours that we're definitely going to hold if they really don't work for you for some reason, make some suggestions about other times. We're also just let me do a quick straw poll here. How many people would be potentially interested in office hours after 5 PM? That's pretty good. How many people would be potentially interested in office hours on the weekends? I think you guys are going to be aware of the amount of help you're going to need, which is awesome. How many people would be interested in office hours located somewhere downtown, like the incubator or somewhere cool? OK, a few more hands went up. OK, cool. So we're going to ask about that, too, we have some alums this year that want to help out with the class but are actually working real jobs and so can't get here before 5 or would prefer to do things downtown so they don't have to drive into campus or whatever. So we'll let you know about this. This will be fun. This will be kind of an experiment. OK, so one last note about office hours. So this has already started to happen. So I am completely committed this semester to be welcoming nice Jeff as much as possible. And I think I've been doing a pretty good job with that. I mean, I always think so, so that's part of my problem. But here's where the rubber meets the road with office hours. So the people that are going to be helping you in office hours, some of those are my students, some of them are me. 301B is kind of our workspace. That's our lab. And when I hold office hours, I will probably hold them in the lab. I may not this year. I may try holding them on the first floor. But in general, just keep in mind two things. First of all, 301B is our space. So if you come in there, please make sure that you're coming in there during a time where we've invited you to be there. We do do other things sometimes. And so we need that space to do that. That's where I yell at my graduate students, and I don't want you guys to see that, because you'll think I mean. No, so that's where we do other cool stuff. So we want to make sure that that's OK. The other thing is the TAs that are going to be helping you. They're going to be putting in a lot of time and effort, but that doesn't mean that they are free for you to ask questions at any time. So don't just feel like, oh, OK, Scott's a really nice guy. And I know where Scott sits for 50 hours a week. So when I need to help with the class, I'm just going to walk in the door, which happens to be open, and I'm going to walk up to Scott and be like, hey, I have this problem. And the thing is Scott will probably help you, because Scott is a really kind and gentle person. But what I want Scott to be doing is something else. So when office hours are in progress, you can bother the TAs that are assigned to those office hours mercilessly. Outside of office hours, please leave them alone. You can ask questions on the forum. There's plenty of other ways to get help outside of the hours that we've designated for you to approach the TAs during office hours. Please don't email them individually. I've told them to not respond to those emails or tell you guys to post to the forum. I asked the course staff for this class to do a lot of work. A lot of that is in office hours. But please respect that they also do other things, and they need the time outside of office hours to do those things. So just be polite about that. OK, last thing about the semester. So I always promise to do this. And this here I think I'm actually, well, I do this in general. So it's possible that I will call on you during class. I know that that's like shocking. I might actually ask you, and you might not have your hand up. So you actually might be asked to participate in class and have me not raised your hand. This is just something I do. So I just might call on you. Point at you and be like, you. And of course, it's hard in this room, because there's 10 people over there being like, you know, obviously nobody wants to be that person. Maybe we'll do this. I had a tool a couple years ago where I could hit a button and a random face would show up on the slides. I was kind of awesome. I might bring that back, because I kind of like that. It was a little weird. I have to say, it's like, where is that person? And they're like, oh, not here. We're disguised to class, you know, whatever. So I may try that again. We'll see. This is not, I'm not doing this to be mean. I just want people to participate. And if you get the same 10 people that raise their hands all the time, they, of course, know everything. And not everybody knows everything. So I'm really just trying to get a good sampling of people. I'm also trying to keep you awake and keep you involved. So if I asked someone to raise their hand and answer a question, then you know how to opt out. So you don't even have to think about it. You're just like, I'm still on Facebook. This is cool. When I cold call people, then everyone, when I ask a question, people are like, I better think about that just a little bit. So this is why I do this. But if you don't know, just say I don't know. It's not a big deal. You're not going to be humiliated. This isn't like Harvard Law School. And everyone's going to get red faced and go home and contemplate dropping out of college and driving a truck or something like that. I think about that sometimes. But anyway, so you can just pass, do whatever. This is not designed to make people feel uncomfortable. And I hope it won't make people feel uncomfortable. If I do make you feel uncomfortable, no, that's not my attention. All right, so any questions about all this administrative? OK, let's get going. So operating system abstraction. So the operating system, does anyone remember? So we talked about this last time. How many people have sort of studied or feel like they're familiar with the idea of a computer science abstraction? How many people have heard the word before used in a computer science sense? But nobody knows what it means. Education, at least you know that the word exists and is sometimes associated with computer science. So what's the goal of an abstraction? The goal of the abstractions that the operating systems provide is really to make applications easier to build. And even if you don't realize this, again, the higher level code that you write, the node interpreter is much easier to write because of the underlying operating system abstractions that it's built on top of. So to some degree, one of the things that we've done to make computers easier and easier to use is layered abstraction after abstraction after abstraction. So now, at this point in computing history, for example, the fact that you can manipulate lists in Python is awesome. It's super powerful, and it's a great way to program. There is no notion of a list anywhere in the operating system. Whatever. So that's another abstraction that's being created by the Python interpreter, but it's really useful. But these are some of the oldest and lowest level software abstractions that we're going to create on the system. And the operating system is responsible for providing it. The goal of these is usually some mixture of things. One thing I want to do with abstractions is hide undesirable properties. Usually, those undesirable properties are undesirable properties of the underlying hardware. So my system doesn't have an infinite amount of memory. That's undesirable. My system doesn't have an infinite number of cores. That's also undesirable. My system doesn't have a disk that requires it to be addressed in units of 512 bytes or 1 kilobyte. That's undesirable. If I had to program, based on some of those abstractions, it would be very frustrating. And so the operating system is one of the first slides of defense in trying to make the machine easier for other software programs to use. I can, part of hiding these undesirable features can also be adding new capabilities. So things I can't do or things that would be very, very difficult to do. Remember, this is all software. The operating system is software. So anything that you can do in the operating system, you can probably do somewhere else. But if the operating system does it for me, then it's one fewer thing I have to implement. So if you could get the operating system to give you access to actual blocks of data on disk, you could write a file system in the user space. In fact, there are tools now for doing this. But the fact that the operating system already has a file system installed makes your life a lot easier. And then finally, sort of organizing information about the system. This is something else that the operating system is responsible for. Collecting and presenting and organizing information about what's running on the system, what's using different resources, and creating containers for other abstractions. And that's actually where we're going to start today. So abstractions, the operating system provides an interface. How many people have heard the word interface before? OK, how many people know what a software interface is? How many people feel like they could answer that question? OK, if I was teaching intro computer science, that would be the first thing I'd talk about in week one. It's what an interface is, because there's nothing more fundamental in computer science than an interface. An interface describes what a computer program does and how it interacts with the rest of the world. Git has an interface. Command line tools have an interface. I mean, you don't think about it that way, right? But if you type git dash dash help, it prints some information. I think that's how you do it. Maybe it's dash H or whatever. The commands that you provide to command line tools are a form of an interface. It's not a graphical interface, so you're not used to thinking about it this way. But computer programs have an interface. The interface is an agreement between the program and people that use the program about how things are going to work. And it's important that both the program itself and the users of the program or the users of the interface agree on how the interface works. So again, you can't use git without typing the proper commands. That's because the contract that you sign up to when you use git is that when I want to add a file, I'm going to run git add dot or whatever. That's just how it works. Now, the interfaces are really designed to separate policies, so kind of what is supposed to happen from the mechanisms for how the interface is implemented. And good interfaces allow the mechanism to change without the caller being aware of it. And we'll come back to this a bunch of times in the semester when we talk about various operating system interfaces and some of the underlying mechanisms for implementing it. So for example, files can be implemented by many different types of file systems. The file abstraction remains the same, the underlying way that the file systems lay out things on disk and the different types of trade-offs that result are very different. But the interface is the same. So actually, let's talk about an example abstraction that the operating system provides. So how many people know what a file is? Hopefully, everybody, I don't know. Maybe files aren't very popular anymore. I mean, files are one of those things that's kind of stuck in a little bit of a limbo. I mean, files, I guess when you download something from the internet, there needs to be somewhere for it to go on your computer. Maybe that's what files are for now. But files are sort of an example of a very, very powerful operating system abstraction. So if you know anything about the underlying properties of disks, what are some of the undesirable properties of disks that files try to hide? So it's an example of an undesirable property of the system that the file abstraction is trying to hide. Yeah? Yeah, so files, so when I open a file, I can logically address bytes in the file from 0 to the length of the file. That is not how things are laid out on disk. Does anyone ever run the beautiful Windows Defragrer? Does Windows still have a Defragrer? Please tell me it does. Thank you. It's awesome. How many people ever run it before? You should run it. It's really fun, right? It moves things around. The colors, like the red park, it's more and more red. And the green park, it's more and more green. And everything just feels really organized. That's probably one of the reasons I don't run Windows is I think I would run the Defragrer a lot. Because I just find it soothing. I like to clean up things. I'd be like, ooh, my disk is all pristine. But that's how things actually look on disk. On disk, that one file that you're addressing from 0 to the length of the file, that's split into pieces that are shattered all over the place. Some of them are one part of the disk, some of them are the other part of the disk. And as you're accessing the file, the disk is manically racing around, or it's flash now, whatever. So the different parts of the flash drive are working together to reassemble the file and give you this logical view of it that it's contiguous. What else? File systems. What else do you do? Yeah? Discs. Oh, so that's only partially true. Discs have names. What kind of names do disks have? How would you have to tell the disk? I want to open. Normally, if you say, OK, open sync.c. How would you have to tell the disk that? Open block 1,562. I mean, the disk has names. This has to have names. They're just names, not names that you want to use. So disks address things in many other parts of the system, using numbers and using zero-based indexing. As a human being, you probably don't want to address files that way. That would be very hard to remember. Does everyone old enough to remember CompuServe other than me? I think it's CompuServe. No one knows. So I can say whatever I want now. If you guys are so young, I could just make up things about the past. That's great. That's a good thing about getting older. Anyway, at some point, there was an internet service provider that, when it got started, it said, what kind of email addresses would people like? Well, certainly, they don't want first name dot last name at CompuServe.com. Instead, they want a 10-digit string of numbers. Because what else does a 10-digit string of numbers? A phone number. And people are so good at remembering phone numbers. So it's like, yeah, I want to be 7164642749 at AOL.com. Because that's easy to remember, and it's easy to tell people. So that was their username format. And of course, I think they went out of business very quickly. So names are important. Human-readable names are important. And many parts of the computer system are not set up to really provide human-readable names naturally. And so file systems do that as well. I think we got most of these. Oh, failures. So disks can fail. Flash drives fail. I know that you guys don't want to hear that, because it's the future. And you think flash drives are awesome, and there's nothing wrong with them. But flash drives fail. They wear out. Spinning disks certainly fail. Parts fly off. And they get all nasty inside and stuff like that. And then just things die. So file systems have features built in them that are designed to make disks more robust. That's another thing. So naming, fragmentation, robustness. File systems have caching features that can make slow disks seem faster. These are examples of these. All right, what about new capabilities that files add? Yeah. Are the most accurate to be a 58? Yeah, so I would actually consider these kind of like more organizing information. But yeah, you're right. I mean, these are new features. I can store more information about the file that might be useful. Yeah, OK. Permissions, ownership, the idea that one user can't access a file owned by another user. The disk has no idea. If you go to the disk and you're like, I want to read block to 32, it's like, OK, I don't know. Maybe that has all the passwords for the machine on it, but that's cool. Here we go. So yeah, file systems are in charge of enforcing it. What else? Yeah, file trees. So being able to expand and contract files. Again, you can do this on top of the disk yourself, but it's a mess. You don't want to. So file systems have this feature where the file can get larger, the file can get smaller, and the file system is intelligently allocating blocks on disk to make this happen for you. Organization, like directory trees, total abstraction. There is no directory tree on disk. There are just disk blocks with numbers. The file system is responsible for building that sort of abstraction, that new feature, that new capability, allowing you to organize things hierarchically on top of the lower level disk. And then someone already pointed this out, permissions, access time, modification time, all this stuff. This is something that file systems associate with their abstractions. And there's useful reasons to associate this kind of information with files, because modification time allows you to do various things, blah, blah, blah. Any questions at this point? I know we've been talking all about files, which we won't actually come back and talk about for a couple more months, but they're a good example of this. So to some degree, the overarching structure of this class is we sort of organize into three stove-piped segments. And what we're going to do is we're going to talk about various pieces of hardware and how the operating system builds abstractions on top of them, and what are some of the requirements and what are some of the trade-offs of doing that. So the thread is the, so what part of the system do you think threads are an abstraction for? Threads are tied to what? Well, what piece of hardware? CPU, right? So threads are an abstraction. Now threads have other properties. Threads are also tied to stacks and memory and other things. But threads are fundamentally an abstraction that's involved with helping multiplex the CPU. Address spaces, now you guys may not have heard of an address space before. Address spaces are a memory abstraction that's designed to help abstract memory those RAM chips that you put into your computer. Again, those do not have a very friendly interface and this makes the interface a lot better. And then files for disk and stable storage. We could also talk about the network. We could talk about virtualization. There's a bunch of other things. I think maybe we will talk about the network this year because it's kind of cool for a week or something if I can fit in some time later. But these are kind of the core operating system abstractions that we're going to talk about, and I just said that. Great. Again, to start what we need to do is actually kind of explain what the operating system does. And so to do that, we're going to start with this organizing principle. And the organizing principle on the operating system is this idea of a process. Names for processes vary. Does anyone know what Linux calls them? A task, yeah. So on Linux, these are called tasks. Windows probably has a different name for them. But every sort of operating system has some notion of a process. And I consider that to be the most fundamental operating system abstraction. And that's because they represent a collection of other abstractions that together are required for the computer to do something. To do the kind of things that you are familiar with it doing, to serve web pages, to run an MP3, no one runs MP3 players anymore, right? Does anyone use an MP3 player on their computer? That's awesome, yeah, holdouts. Yeah, anyway, so really maybe now it's like the browser, the browser, the browser, the browser, the browser, right? So the processes are required to run a browser, right? They're required to run a web browser. But any other sort of logical thing that your computer is doing is encapsulated in this abstraction that's called a process. And you know processes and applications. If you have a smartphone, every app on that smartphone runs as a separate process. It's sometimes several different processes, usually just one. So you guys are familiar with this abstraction even if you haven't been introduced to it before. Okay, now processes are not tied to a hardware component. Instead, you can think of processes as a container that holds other abstractions that are tied to the component. So a process, typically to get any useful work done on a computer, you need to use the CPU, you need to use memory, you might need to use some storage, you might need to use some network connections. And the process is what groups all of these things together. So a process can contain one or more threads, typically today, multiple threads, hopefully. Not all processes, but many processes today that contain multiple threads. An address space that allows the process to use memory. And then potentially multiple file handles, network sockets, and other things that allow the process to access local storage, communicate with other processes across the internet, et cetera. All right, again, I just said this. The other core, other than being an organizing principle, the other core property of the process is that processes represent a protection boundary on the system. On some level, one of the primary early goals for operating systems, remember we talked about multiplexing. Multiplexing is the idea of being able to allow multiple processes to use the computer at one time. And a core part of this is making sure that this happens safely. I don't want one process to be able to break another process, one process should not be able to crash the entire system. The operating system also tries to allocate resources between processes according to some set of rules that may or may not be fair to allow all processes to continue to make progress. There's ways if you have administrator access to prioritize different things so that things run faster, slower, whatever. But one way to think about this is anything that goes on between processes is done with the operating system keeping a very watchful eye on what's going on to make sure that things don't go wrong. Inside a process, you can do whatever you want. So the protection boundary is what causes, if you go on Timberlake and you run like, you might as well try this, right? I mean, I won't have to answer for it. So go on Timberlake and write like a fork bomb or something, right? And run it on Timberlake and see what happens, right? I guess I just actually did say that in class. Usually I say not to run the fork bomb on Timberlake, but it shouldn't crash the machine. If the machine is correctly set up. Or simpler example, a little bit nicer example so that Ken doesn't get mad at me. Go on Timberlake and write a program that just dereferences null and see what happens. On a well-behaved system, your program will crash immediately and it's gonna say segmentation fault, it's gonna dump some core, that's fine. What shouldn't happen is the machine shouldn't shut down or any other processes on the system should not fail. So this is critical. Inside a process, you can do whatever you want and you can make all sorts of dumb mistakes and dumb decisions, but those decisions are not supposed to affect the correct execution of other processes and they're also supposed to be isolated from the sort of continued operation of the system itself. All right, I'm gonna work on synchronizing with the slides this year. All right, now inside a process, communicating between various parts of the program is usually done using various types of memory sharing. That's how different threads communicate with each other. And all the threads within a process also share certain resources. So files that could open by one thread are typically visible to other threads and certain dynamically allocated memory and statically allocated global variables are visible to every process. Has anyone become, how many people have written a multi-threaded program before? Okay, we're gonna work on that this semester. Yeah, so if you've done any multi-threaded programming, you've probably become aware of this because you've noticed that I have two parts of the program that are now executing concurrently and they can both read and write certain shared variables and if I don't do that carefully, I can actually cause chaos. And we'll come back to that in a few weeks and we'll teach you guys how not to cause chaos when you do that. And then there's certain semantics for, for example, thread stacks and local variables. So if you allocate a local variable on your stack and see that is typically private to the thread. Now, it doesn't have to be. Threads can actually share those variables if they want to. It's very hard to get right, so people don't typically do it. But the general theme in here is, inside the process, most things are shared. Between processes, okay, so we'll come back to this. So within the process, if you wanna share stuff, you probably have to do some things to make sure that you get it right. And we'll come back to that in a few weeks. Now, for multiple processes to communicate with each other, so I've got process A and process B, let's say process A is one Android application, process B is another Android application, process A could be a web server, process B is like a Redis, key value store or something like this. This is trickier and the reason it's trickier is because the operating system is responsible for making sure that these processes don't crash each other. There are ways to do this, but the ways to do it are usually set up by the operating system and require consent from both parts of the system. So another way to think about is, if you're a process and you're just running along and you're just minding your own business, nobody else is supposed to be able to come and do stuff to you. If you wanna communicate with other processes, that's fine, you can set up a socket and you can let them connect to you and you can exchange messages and you can go along your happy way. But if all you wanna do is compute digits of pi, nobody should be like trying to get you to serve a webpage or poking you in different memory areas or whatever. So I mean, to the degree that you want to just do your own private work, that's totally cool. If you want to set up ways to exchange information with other processes, you can do that too, but those things require your consent. All right, and there's a bunch of different ways to do this, you can use shared files, those sockets that you guys have seen, sys161 setting up, if it fails, that's one way for two processes to communicate. So the reason why sys161 sets those up is it communicates with a couple of other processes like GDB and a statistics collection process that we have. Signals, pipes, shared memory, these are all different ways to enable various types of IPC. And all these require some degree of coordination and cooperation among the processes they're using. Right, and again, I just can't send random signals to other processes, yeah. Give me an example, that's probably true. I don't know exactly how that's done. That's a good question, yeah. You mean like there's a gooey pop-up window? Yeah, I don't know, that may be done using some form of IPC, yeah, that's a good question. Any other questions about this? All right, so let's talk about a couple of different ways of actually doing IPC. And these are actually, there's a number of examples throughout the rest of today's lecture and for the next couple of days that you guys can actually, if you have a computer, you have a terminal in front of you if you want to do this later, you can kind of pop up a terminal window and follow along. So these will always, most of these will work. In fact, they should all work, okay? Simplest form of IPC out there is something called a return code. So when you run a program on your computer, when the program exits, it gets to return one piece of information. It's known as a return code. Now return codes, the semantics of return codes are completely up to the process itself. And so there really is no rhyme or reason for why return codes mean what they mean. You have to look at the process that generated them. But there is one return code that is typically special, does anyone know what it is? Zero, what does it mean? Success, nothing went wrong. Whatever you wanted to do, happened. Okay, I always like that about, I always find it kind of feel like Linux is like this great servant OS, right? Because when it does what you want, it just doesn't say anything else. It's like remove the file, boom. That's what you want like a good servant to be like. Don't ask any questions, don't tell me any extraneous information, just do exactly what I asked. You can ask questions if like I asked you to do something stupid or confusing, right? And it does. But if it's like remove the entire directory tree, okay, cool, done, right? So if you wanna play around with exit codes, there's a couple of little toy programs on your system. These also exist on your OS 161 installation. What do you think bin true does? What's true? Zero. That's always interesting, right? Zero is true. So if you run bin true, all it does is return zero. What about bin false? Turns non-zero. I think it returns one in this case. So if you run bin true, I mean we could just do this right here, right? I guess I promised I wouldn't do this again this year, but why not? If I run bin true, oh, wait, hold on. Come over here terminal. Oh, it's in full screen mode, nevermind. If I run bin true on my machine, all that's gonna happen is I'm gonna get another prompt. And the reason is bin bash took the exit code from bin true, it said it's zero. So whatever it wanted to do must have happened and doesn't give me any more information. If I run bin false, you'll see I get this extra piece of information. And you may have seen this from bash before when a program that you try to run from the terminal returns a non-zero exit code, bash will tell you what the exit code was. Even if the program produces no other output. And the reason is usually something went wrong. So here you can see that false exited with exit code one and bash decided to tell me about that. And the reason that bash tells me about that is because a non-zero exit code typically means that something went wrong. False doesn't print any output, it just returns one. Any questions about this example? So this is a very, very, very simple basic form of IPC. And there are rules which we'll come back to when we talk about how processes create other processes about who gets to know the exit code for a particular process. I might think about a little bit about what this example demonstrates about some of what those rules are. Uh-oh. It's not the noise that I wanted this to generate. All right. Okay. Yeah. There's another trick. Has anyone ever done this before? Oh yeah, I can see who the real bash users are. If you ran a program and you don't know what its exit code was and you want to know, usually zero, but maybe you ran it like, you know, in some way that hid the exit code, you can look at the bash variable dollar sign question mark. That always contains the exit code of the last process that you ran. So if I appear after I run been true, if I waited for it to finish and then echoed dollar sign question mark, it would be zero. Okay. And look, I just did that. Yeah. Been true, zero, been false, one. Okay. Pipes. How many people have built a Unix shell pipeline before using the pipe character? This is gonna be such a fun semester for you guys. Okay. Pipes. Pipes are really a programming tool, fundamentally. They're a way to build complicated, semi-complicated logical sort of tools from simple, simple tools. And this is a Unix programming philosophy. Unix gives you these simple utilities. And the goal is by combining them together in various ways I can make interesting things happen. So here's one way to find out, and technically this doesn't do the right thing, but what I did here is I ran PS AUX. Does anyone know what this does? Yeah. Yeah. So PS is a tool to inspect the processes that are running on the system. And this is actually something for the first couple weeks I would really encourage you guys to go through some of these examples in your Ubuntu virtual machine. You have a Linux based environment and these commands will work on that environment because these give you some, this is some way of starting to collect information from the operating system and get a sense of what's going on. So PS with the arguments AUX will list all the processes on the system. And then, so what is this command? You know what PS AUX does? If you look at the output, what happened here? Someone explained to me what happened here. Someone who doesn't know what happened here because they've ran this command before or something like this. Yeah. Yeah, so grepchallon, what does grep do? Grep looks for a string. What does grep look at, but here's the interesting thing about grep. What is grep searching through here? Yeah. Yeah, so what Pype does is it takes the output from the first command and it passes it to the second command as input. So normally if you run grep, you have to tell grep what files to look at, right? Has anyone used grep to look around your source tree? It's pretty useful if you get used to it. Yeah, so normally when you use grep, you give it some files to look at, right? But I haven't given it any files. What I've done is I've set up a pipeline so it's looking through the output of another command. So I take PS AUX, that generates a list of all. If I just run PS AUX, I see everything that's running on the system. But in this case, I'm only interested in commands where challon appears somewhere in the output of PS. And you can see most of these processes are owned by me, but there's a few cases here that they're owned by root and these are SSH sessions that are assigned to me. So in most cases, it matched challon here or on both parts of it, but a few cases it matched challon over here. So grep looks on a line by line base. Any questions about this example? You can use pipes to build arbitrary sort of processing. You could think of this as sort of like a modular-based processing system. I take the output from one thing, pipe into the next thing, do some more processing on that, pipe it somewhere else. Usually by the time you've built a shell pipeline that's like three or four commands long, it's probably time to start thinking about doing it in some other way. But real hardcore system administrators will build these things that have like 10 commands in them that are like 15 lines long and they do something useful. All right, yeah, there we go. So and the way this is done, we'll come back to this when we talk about four because it's kind of cool. So what pipe does is it manipulates the file handles between the two processes so that grep ps thinks it's right into standard out but what it's right into is actually standard in of the grep program. So grep thinks it's reading input from standard in but it's actually reading the output of ps. All right, yes, a series of tubes. You know, it's Ted Smith. I miss him, I miss that Ted Stevens, right? I don't know what happened to him. Actually, I can probably guess what happened to him. Sad, it looks sort of old. Sorry, I shouldn't put, well, actually I have no idea what happened to Ted Stevens except I don't hear his name in the news anymore so that's all I know. Kill, does anyone know what kill does? False, false, not true. Yeah, it does that by default but what else can it do? Yeah, it can send any signal to a process. Kill has a terrible name, right? You can use kill to send a signal to a process but it causes it to reload its configuration file. Kill sends signals, right? Now if you run a bare kill without telling it what to do, it'll send what's called sigterm which is the signal that says, please shut down. Has anyone ever used sigterm before? How many people have used sigterm? Everybody in the class, raise your hand. Just raise your hand. There we go, this is the exercise part of the class. You've all used sigterm, you don't know it. How have you used sigterm? You have delivered sigterm to a process before, I bet. Unless you've had a very, very charmed life, yeah. Control C, did you know that's what control C did? There you go. Control C delivers sigterm to the process that's currently running in your terminal, that's how it works. Has anyone had a process that wouldn't shut down when you hit control C? That's because it's possible for a process to stop responding to control C. Control C is you tapping the process on the shoulder and being like, by the way, I would like you to shut down now. I'm serious. Most processes do the right thing. They're like, okay, okay, I got it, I got it. Some are like, no, no, I cannot, you know, cannot stop. Cannot stop computing digits of pi, must compute digits of pi, right? And so for that reason, there exists a different signal. So there's sigterm and then there's a more appropriately named signal that's called sigkill. And sigkill is, I'm not being nice anymore, right? Like you will die. The important thing about sigkill is that you can only deliver sigkill to things that you own, right? The processes that you created, unless you run pseudo, right? So for example, you don't want to be able to go onto Timberlake and start killing off all the other people's barnyards or whatever they're doing. Or animals in the barnyard or whatever. So yeah, so kill delivers signals. And signals are another very, very simple form of IPC, right? I mean, the difference between signals and return codes, I can receive a signal at any point in time. And the process is really responsible for determining how it responds to signals. And signals are actually quite useful. So for example, if I want to reload the configuration of a daemon, right? So I do this all the time. You know, I've changed some settings on Nginx, which is a web server. I want Nginx to reload its configuration file without stopping, because if it stops, then all of the hits to ops class are going to go down for like a fraction of a second. I don't want that, right? Somebody, a student might be mad. So rather than having that fraction second of downtime, there's a signal you can send to Nginx will call it to reload its configuration automatically without shutting down. So that's cool, right? All right, I think we're out of time for today. We will pick up here on Monday. Please work on assignment zero. We have office hours now. If you want to come and get help on assignment one, that's also a pool. Assignment one is due in three weeks.