Tag Info

Hot answers tagged


You should be able to do this in the same shell you're in with the wait command: $ sleep 30 & [1] 17440 $ wait 17440 && echo hi ...30 seconds later... [1]+ Done sleep 30 hi excerpt from Bash man page wait [n ...] Wait for each specified process and return its termination status. Each n may be a process ID or a ...


fg returns with the exit code from the program it resumes. You can therefore suspend your program with ^Z and then use fg && ... to resume it. $ /bin/myprog some output... ^Z [1]+ Stopped /bin/myprog $ fg && /usr/bin/mycleanup


If you are using bash, you can use the PIPESTATUS array variable to get the exit status of each element of the pipeline. $ false | true $ echo "${PIPESTATUS[0]} ${PIPESTATUS[1]}" 1 0


There are 3 common ways of doing this: Pipefail The first way is to set the pipefail option (ksh, zsh or bash). This is the simplest and what it does is basically set the exit status $? to the exit code of the last program to exit non-zero (or zero if all exited successfully). # false | true; echo $? 0 # set -o pipefail # false | true; echo $? 1 ...


nohup read the man page for nohup usage. nohup is the way it's been done long since before screen, tmux, etc were invented. Example: nohup my_long_running_proc & Runs "my_long_running_proc", and any console (stdout/stderr) messages go into a file called "nohup.out" in the directory from which the command was started.


You can use false (/bin/false, /usr/bin/false, or shell builtin): $ false || echo It failed. It failed. $ You can also use exit 1 from a subshell: $ (exit 1) || echo Gosh, it failed too. Gosh, it failed too. $


There is no significance to exiting with code 99, other than there is perhaps in the context of a specific program. Either way, exit exits the shell with a certain exit code, in this case, 99. You can find more information in help exit: exit: exit [n] Exit the shell. Exits the shell with a status of N. If N is omitted, the exit status is that ...


I think it works. But probably it doesn't do what you expect. $ exit & Will create a sub-shell process, and make it run as a background job which will just finish right away.


While not exactly what you asked, you could use #!/bin/bash -o pipefail so that your pipes return the last non zero return. might be a bit less coding Edit: Example [root@localhost ~]# false | true [root@localhost ~]# echo $? 0 [root@localhost ~]# set -o pipefail [root@localhost ~]# false | true [root@localhost ~]# echo $? 1


Try using the ssh connection termination escape sequence. In the ssh session, enter ~. (tilde dot). You won't see the characters when you type them, but the session will terminate immediately. $ ~. $ Connection to me.myhost.com closed. From man 1 ssh The supported escapes (assuming the default ‘~’) are: ~. Disconnect. ~^Z Background ssh. ...


It does work. & forks the shell, starting a new process (you could think of it as & exit, except of course that syntax actually means something else). exit is a shell built-in that ends the shell process -- in this case the new backgrounded shell. > exit & [1] 1709 > ps -p 1709 PID TTY TIME CMD [1]+ Done ...


The problem is that you're issuing wait in a subshell: if `wait $!`;then Because wait is a builtin, not a command, it's operating on the subshell, not your current shell. The output that you would see but aren't is: wait: pid 12344 is not a child of this shell ...with a return status of 1. To perform your test you will need to do it without using a ...


The status passed to exit() by a process is masked to a single byte, so it's limited to the range [0-255]. See the exit documentation: The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, or any other value, though only the least significant 8 bits (that is, status & 0377) shall be available to a waiting parent process. On two's complement ...


The only way that statement can be reached is if the exec itself fails; if it succeeds, the ffmpeg command replaces the shell completely. (Pedantically, the && will fail in that case also so it can't be reached at all.) You don't want to exec it, just run it.


Ctrl-D or exit is the same. If you using the "X", the window manager sends a terminate signal to the shell. Which has at the end the same result. If the shell does not react, the user usually gets a warning and can then force the shell to end (equal to kill -9 $PID). There is one small difference between the "X"- and exit-method if you are using zsh as ...


Because in UNIX/POSIX, the exit code of a program is defined to be an unsigned 8-bit value. Converting -1 to unsigned 8-bit gives 255. Edit to add: To give more detail: the wait*() family of system calls in UNIX encode the result of a process into a single 32bit integer. The 32 bits of that result are further broken up to provide information such as ...


In addition to @Chris Down, there is some return code that reserved for the shell, they have special meaning: RETVAL Meaning 1 General errors 2 Misusage 127 Command not found You can refer to this for more details.


I think you are mixing two things the return value typically indicates if a command was successful (return value 0) or not (anything else). You can get the return value of a command from the variable $? grep -c returns the count to stdout, to capture the count you can use something like variable=$(grep -c pattern filename) Afterwords you can ...


set -e ? set: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...] Set or unset values of shell options and positional parameters. Change the value of shell attributes and positional parameters, or display the names and values of shell variables. Options: -a Mark variables which are modified or created for export. -b Notify of job ...


What I do when possible is to feed the exit code from foo into bar. For example, if I know that foo never produces a line with just digits, then I can just tack on the exit code: { foo; echo $?; } | awk '!/[^0-9]/ {exit($0)} {…}' Or if I know that the output from foo never contains a line with just .: { foo; echo .; echo $?; } | awk '/^\.$/ {getline; ...


Both the kernel and the C runtime do some of the work. Some of the things that the C runtime does which the kernel doesn't do: it runs handlers previously registered with atexit() and it arranges for the integer return value from main() to be returned to the system as if with exit(). Of course in the end the kernel will reap all resources (files, memory) ...


Use tmux or screen to provide a persistent session environment for the command to run in. Using tmux, this could be accomplished in the following way: Start a new session environment: tmux new -s my-session-name Run your command: longrunningcommand Close your terminal window, SSH session or manually detach from tmux using Ctrl+b, then d Reconnect to your ...


Test it with the command xclock. Open a console, type xclock Close the console. xclock disappears. Now type xclock & xclock still disappears cause it is still a sub-process of your shell. Now type xclock & disown Now xclock is no longer a sub-process of your shell and you can close the console and xclock will keep running. I documented ...


You got the right return code, sftp session executed correctly so the return code is 0. You should use scp instead, it does not returns 0 if it fails to copy. You could do something like : file=file_pattern`date -d "last month" +%m%Y`.csv remote=USER@remote.server.com:/rsdir1/rsdir2/rsdir3/$file local=/rsdir1/rsdir2/rsdir3/$file if scp -q $remote ...


The $? variable holds the return value of the last command. You could do this: echo "root:passwd" | chpasswd RET=$? Or test directly, e.g. echo "root:passwd" | chpasswd if [ "$?" -ne 0 ]; then echo "Failed" fi


You could decide that the exit status 77 for instance means exit any level of subshell, and do set -E trap '[ "$?" -ne 77 ] || exit 77' ERR (echo here; (echo there; (exit 12); echo ici; exit 77); echo not here); echo not here either set -E in combination with ERR traps is a bit like an improved version of set -e in that it allows you to define your own ...


Remove the backticks. As is, you're executing wait in a subshell, which doesn't have access to the parent shell's jobs, so it will immediately fail. If you want the exit status, get the value of $? immediately after the wait. command_here & wait status=$?


As seen earlier, vfork does not allow the child process to access the parent's memory. exit is a C library function (that's why it's often written as exit(3)). It performs various cleanup tasks such as flushing and closing C streams (the files open through functions declared in stdio.h) and executing user-specified functions registered with atexit. All these ...


Perhaps wmctrl could be of some assistance. You could use the -c option that closes a window gracefully: wmctrl -c chrome The string chrome is matched against the window titles. Note that the window might not close if some message pops-up (e.g. when you have multiple tabs open).


Found it just before hitting the "ask question" button. I looked at the ABS, which suggests this is exit code 128 + signal SIGTSTP (even though no process exited). I then found out I inspect check the exit status using kill -l $? which reports TSTP, or "stop typed at tty", for 148.

Only top voted, non community-wiki answers of a minimum length are eligible