Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I know that with the "echo $?" I can understand that the last command run successfully or not but how about other commands? For example, I run a command on a remote server via SSH and execute a "dd" command and close my terminal and do another SSH and run "ls" command but "echo $?" show me the result of "ls" command not "dd" command. How can I understand the result of "dd" command?
You have to look for the exit code for "dd" directly. You can do that on the remote host before logging out of the server. Or, if running just a single program or script in an automated fashion, the SSH client will pass the exit code of that program or script. It will also pass the exit code of the last program or script run before "exit". So if you connect with "ssh", run "dd", and then do nothing else before exit, then you can see the exit code of "dd" with $? on the local system.
For example, I run a command on a remote server via SSH and execute a "dd" command and close my terminal and do another SSH and run "ls" command but "echo $?" show me the result of "ls" command not "dd" command. How can I understand the result of "dd" command?
By recording a transcript of all activities, outputs and command returns made or transpired in the console. To do that, after opening the console/tty you will enter the command--
then you may now proceed to issue commands whatever you do, ssh, dd, ls, vi, etc. After you do that console session you may check and review what returns echoed by the commands as they ran.
there you can find out whether the commands went good < 0 > or went error < 1 >. You will read the record even if you were not around. Just do not exit from the console. Should you have exited or quit from script CTL+D just redo the pre-pending of "script" anew.
Hope that helps.
Good luck and enjoy.
Last edited by malekmustaq; 08-09-2016 at 11:15 PM.
By tradition, Unix/Linux programs have two "standard outputs": STDOUT, which is for "normal" output, and STDERR, which is for "error" (or "status message") output.
Although normally both of these output streams are displayed to the console and intermingled there, you can redirect them separately. For instance, the following command discards the error-output of the foobar command, by directing it to "the bit-bucket" (/dev/null, while sending the standard-output to the disk-file bletch:
foobar >bletch 2>/dev/null
If you need to determine whether a command worked, you can test the command's exit-code for zero. (Zero means "success.") If you need details about why it [didn't ...] work, you must capture and parse the command's standard-error output.