Just run the command and then make use of the return code to determine whether the command ran successfully. That's an easy thing to do and quite commonly done in scripts. Know if whether a command that you ran completed successfully, not what kind This kind of command probably won't make a lot of sense to use except when all you want to Checking the return code will let you know if there were errors. This is the kind of thing that many sysadmins will do in a script to reduce the output that their scripts will generate. In the tar command shown above, we extract from a tar file, but hide possible errors from view. The benefit of crafted messages increases dramatically with the volume of data might otherwise be filling your screen. The use of /dev/null in the code above ensures that the person running the script sees a gentle error "creation failed" message rather than a "Permission denied" error. In a script, you're likely to do something like this: You can check return codes on the command line with simple checks like this: If it succeeded, the return code will always be 0. If the operation failed, the return code will be 1 or greater. For example, in the script excerpt below, we touch a file and then check to see if the file was updated or created by examining the return code - the code that tells us whether the command just processed was successfully completed. How nice.įortunately, you can tell if an operation is successful even if your output simply disappears - and this is key to using /dev/null in a script. And, if you can remove it, a reboot puts it back. Because of the file's nature, you can't change it in any way you can only use it. You read from /dev/null every time you empty an existing file using a command such as cat /dev/null > bigfile or just > bigfile. You write to /dev/null every time you use it in a command such as touch file 2> /dev/null. The file's read and write for everyone permissions make sense only when you think about how /dev/null is used. Size: 0 Blocks: 0 IO Block: 4096 character special fileĭevice: 11h/17d Inode: 3720 Links: 1 Device type: 1,3Īccess: (0666/crw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Yes, non-executable and empty, /dev/null still manages to do some very interesting things for its users. If you use the stat command to look at the file's metadata, you'll note that its size is reported to be 0. Notice also that it doesn't require execute permission to behave as it does. This tells you that it processes data character by character rather than block by block. Here it is on one of the systems I manage:Ĭrw-rw-rw- 1 root root 1, 3 Dec 12 20:00 /dev/nullĮxamining this long listing, you can see that /dev/null is a character device. That's probably a very good thing as /dev/null is a file that you wouldn't ever want to lose. Interestingly, this intriguing file is created anew every time you reboot your system. But how much have you thought about the file's many peculiarities? Let's take a deep dive into our systems' implementation of anti-matter and see how very unusual a thing it really is.įirst, the creation date of /dev/null is the date/time that your system last booted. Nearly everyone who spends time on the Unix command line has probably heard of /dev/null and a good many of us probably use it routinely - especially those of us who write scripts. Something of a bit bucket, black hole, and digital garbage disposal, /dev/null is one of the very clever things that Unix introduced into the computing world. Send errors in one direction, useful output in another.
Unix systems make it easy to make output that you don't want to see simply disappear.
0 kommentar(er)
