Some programs return immediately when launched from the command line, Firefox for example. Most utilities (and all the programs I've written) are tied to the shell that created them. If you control-c the command line, the program's dead.
What do you have to add to a program or a shell script to get the return-immediately behavior? I guess I'm asking two questions there, one for shell scripts and one for general, if they're different. I would be particularly interested to know if there's a way to get an executable jar to do it.
I'm almost embarrassed to ask that one but I can't find the answer myself.
Thanks!
start cmd
on Windows,
cmd &
on *nux
Here substitute
cmd = java -jar JarFile.jar
On *nux the fg and bg commands are your friends as well ...
You need to basically need to fork a process or create a new thread (or pretend to)
in *nux you can do this with an & after the command like this /long/script & or in windows you can create a BATCH file that executes your processes then exits (it does this naturally).
NOTE: there's no particularly good way to reference this process after you're forked it, basically only ps for the process list. if you want to be able to see what the process is doing, check out using screen (another linux command) that will start a session for you and let you "re-attach" to the screen.
to do this, install screen (sudo apt-get install screen or yum install screen). then type screen to create a new session (note, it will look like you didn't do anything). then, run your /long/command (without the &), then press CTRL + A + D (at the same time) to detach from it (it's still running!). then, when you want to re-attach, type screen -r.
Additionally, look for flags in any help message that allow you do this without using the above options (for instance in synergy you can say synergy --background)
A wrapper script consisting of nothing but:
your_prog_or_script &
Will launch the target and exit immediately. You can add nohup to the beginning of that line so it will continue running if the shell is exited.
For an executable program (as opposed to a shell script), on Linux/Unix use fork() and exec() and then exit the parent process, which will return to the shell. For details see the man pages, or some page like http://www.yolinux.com/TUTORIALS/ForkExecProcesses.html.
Related
I am currently running a python3 script in Ubuntu server 18.04. When i type new commands into the command line it just prints the commands. My terminal window looks like this:
mitch#server:`$ cd /home/mitch/folder
mitch#server:`/folder$ python3 main.py
file running ...
text i input just shows like this
I need to keep the script running and run other commands, how do i navigate back to:
mitch#server:`
I'm new to servers/Ubuntu/commands so this may seem trivial! Thank you
So you can't "navigate" back to that, since you're technically already there, you're just running a script in your shell which is occupying your shell - think of it like you opened a program in full screen.
But you have a few options:
The most basic is to run the script in the 'background' this is a simple as adding a & to the end of your command (note that it will still send any message from the script into your terminal - if your script is programmed to send messages that is).
Another option is to use a terminal multiplex like which lets you have multiple terminals open, as well as split screen terminals and many other features. One of the more popular multiplexers is called tmux, just keep in mind that it does have a bit of a learning curve to it, but is extremely useful once you learn it.
I am on windows machine, when I temporarily change to console using :sh then back to vim with exit command and then again back to console and it starts over. this causes me to lose my previous directory. Is there other way returning back to vim won't start the shell over?
Not really
https://stackoverflow.com/a/12089631/1427295
GVIM does not retain a "handle" to the shell that launched it in a way
that allows it to send commands back to it. Because of they
synchronous execution, you also cannot launch a shell from GVIM, keep
feeding it commands while also continue working in GVIM.
I'm afraid you have to use the functionality of your window manager to
launch (and then later re-activate) a shell window, and send the
commands as keystrokes to it. On Windows, this can be done (e.g. in
VBScript) via WshShell's Run(), AppActivate() and SendKeys() methods;
there are probably similar mechanisms for window control on Linux,
too.
If you don't mind having that shell inside your GVIM (emulated, with
all its drawbacks), though, there are plugins that enable that.
https://serverfault.com/a/95405
The Windows command interpreter ("cmd.exe") doesn't provide any
support for saving/exporting/keeping history, of, if it does,
Microsoft didn't document it and nobody was ever able to find it. You
can of course try to work around that, like Sean suggested, but
there's (or does appear to be) no built-in support for this
You may be able to output your command history using echo %cd% > prev_dir.txt then create a script that cds to the directory in prev_dir.txt, but you'd still have to remember to save your directory to the file before you exit the shell each time.
I have a program that needs to start another program. On my mac I did this using system("open path"), but on linux that doesn't work. and using system(./path) is not what I want since than it overtakes the running program.
So is there any way to get the same behaviour as the mac 'open path' command on linux?
(linux noob btw:p)
If you're running the application in a GUI environment, this should be possible but the approach is different. You need to start a new terminal instance explicitly.
Determine the path to your terminal application. This depends on the linux distribution.
Next, check the documentation of that particular terminal application and find out how it can be started to run an application (your application) instead of a shell. This probably involves using some application-specific command line options. Test that in a terminal window, until you have a command line that gives you the desired result. Things could get a little tricky if your application needs command line arguments as well. Use the -- option where necessary.
Then, all you need to do is run that command line from your "parent" application. I would advise however to not use system(). The exec... family functions (using fork and wait) provide better control.
I have a recurrent problem when using R with a Linux console. I sometimes suspend it with [Ctrl+Z], then put it to the background with bg, (execute some other commands), then put it to the foreground again with fg.
R resumes correctly with all the workspace intact, but when I type, the characters are invisible (just like when we type passwords).
I still can execute commands though, and I see the response. Moreover, when I type [enter], the prompt doesn't go to the next line, but does something like this: > > >.
Then I need to quit R using q(), in order that everything returns to normal. I didn't manage to find any reference to this problem on internet.
Would you have an idea? Thanks a lot for your help.
No direct answer but via
"Doctor, doctor, it hurts when I do this."
"Then just don't do this."
I would suggest that if you must have an R console open, place it inside screen --- or if you have it, byobu a fancier extensions, or even tmux.
Or even inside the One True Editor (TM) using ESS. For what it is worth, I always run emacs --daemon and then connect to the same R session either via emacsclient -nw on the terminal or under X11 via emacsclient -c (both of which I aliased to emt and emx). I also run byobu sessions for command-line work where I often use littler for command-line tasks and tests.
Unix is a multitasking system. There is no need to limit yourself to one prompt, especially if you suffer side-effects as a consequence.
Say for example, to open multiple instances of gedit editor I wrote a shell script like this-
gedit&
gedit&
gedit&
gedit&
But after I ran my shell script ./example.sh, I can find only one instance of gedit! I've even used the & operator, so that the shell doesn't wait for one instance to finish. Still I cannot see four instances of gedit.
Also I tried directly from the command prompt. If I just enter gedit& on the command line, it showed 1906 ( this is the PID of the newly created gedit process ), started one new gedit instance and returned to prompt again. When I typed gedit& on the command line, it showed 1909 this time, but no new instance of gedit! And I couldn't find any process with PID 1909 in the System Monitor too. Where did this new process go away?
Is the happening specific to gedit? If so, what is the generic behavior when creating multiple instances of a program?
It is specific to gedit. You are likely looking for gedit --new-window &.
From man gedit:
--new-window
Create a new toplevel window in an existing instance of gedit.
I came here, trying to start multiple instances of audacious.
Allowing only one instance is actually harder to implement, because the program needs to find and communicate with the instance already running. This is done via D-Bus. In order to prevent communication with the already started instance you can run the program in another D-Bus session:
nohup dbus-run-session audacious &
nohup dbus-run-session audacious &
Note: nohup will keep the program running even if the terminal is to be closed.
This method should also work for other programs which do not let the user choose between multiple instance vs. one instance.
Beware that this might introduce bugs, if multiple instances are accessing the same configuration files.
Tested with xfce 4.14.1 and dbus 1.12.20
For Scite:
scite -check.if.already.open=false &
A word of caution:
If you, like me, have your system running for multiple months and have edited some of your shortcuts or aliases to open with this hack, then after a while some programs will not start anymore because there are already too many open D-Bus session. In this case you have to kill the started D-Bus sessions, which do not close when the started program closes. The other way around, killing the D-Bus session, will also kill the opened program, so use with care! For me personally, I have some long running autostarted programs which I want to keep open (firefox), so I kill all but the first 10 D-Bus sessions with this:
for pid in $( ps --sort start_time -aux | grep dbus-daemon | tail +10 | awk '{ print $2; }' ); do kill $pid; done
The cleanest solution would be to write a launcher script which waits for the program to finish and then closes the opened D-Bus sessions. But this is a bit more difficult than it seems because it is hard to find the PID of the corresponding D-Bus session.
P.S.: I also used this hack because there seems to be some program on my system which, after a while, slows down the system's default file open dialog to take multiple minutes if not longer to open! Programs then seem to hang when trying to save or open files. A new D-Bus sessions seems to fix this for some reason. While writing this, I found that pkill gvfsd-trash also works and that it may have been this bug. So until this gets shipped, I guess I'll add pkill gvfsd-trash to my crontab.
This seems specific to gedit, perhaps there's some option to turn off the check for a running instance.
Looks like gedit is first looking for a running instance and simply ignores further start-requests (just a wild guess). But the manual page says, that you can open another window:
--new-window
Create a new toplevel window in an existing instance of gedit.
That wouldn't exactly solve your problem, but maybe that's what you were looking for in the first place.
Good luck,
Alex.
Using this in a script. I've found that it does what I need it to:
#!/bin/bash
xterm -e "gedit; bash" &disown