>start microsoft-edge:http://google.com
Its opened google.com in edge browser new tab. Now I want to close. Here I am using stop but its not working.
>stop microsoft-edge:http://google.com
If, by chance, the goal is to use Edge to "ping" a website then close Edge, I may have a solution.
The Chromium command line switch --no-startup-window used along with a url in Edge seem to have the effect of closing the application after background-loading the specified page in the background. The bits of documentation I've been able to find about Chromium's command-line switchesI've been able to find for this imply that the application should stay running in the background, but that does not seem to be the case (for me anyway) when used this way.
For example, if you wanted to schedule a recurring background random Bing search, like so you could (hypothetically) auto-collect⁕ Microsoft's Search & Earn points, you may be able to schedule an event to run a batch file every couple hours, something like:
start msedge --no-startup-window https://www.bing.com/search?q=%random%
The only way I could tell it was doing anything at all was by watching the Task Manager for Microsoft Edge to appear for a split second.
⁕This is just an example use case and is probably against the program's terms so don't actually use it for that.
taskkill /F /IM MicrosoftEdge.exe will kill it dead, but this will also terminate any other instances as well. In my experience, this force close will re-open with all tabs that were open before being "killed" even with Edge configured to not open with previous pages. My workaround to that was to taskkill /F /IM MicrosoftEdgeCP.exe repeatedly, with a 1 second delay, until all tabs were closed (going too fast did not kill all tabs). This also killed Edge when the last tab was closed.
Example
start https://www.bing.com/search?q=a
timeout 3
start https://www.bing.com/search?q=ab
timeout 3
start https://www.bing.com/search?q=abc
timeout 3
:KillEdge
timeout 1
taskkill /F /IM MicrosoftEdgeCP.exe
if %errorlevel% NEQ 0 (goto :eof) else (goto KillEdge)
**It work for me **
taskkill /IM msedge.exe /F
Related
I'm new to Linux.Yesterday I wrote some Python codes,now I'm using Linux to execute my codes,it may take a few hours. As my Linux is not native,it's a remote server,I use putty to connect to it.
Now ,I want to close putty and go to sleep.But I don't know how to find my process again and reenter it after I wake up and start putty.And also,I wrote some code to print progress rate，next time when I find the process,can I see the print info again?
Run screen, start your programm and close the connection. After logging in again, use screen -r to resume your session.
Alternatively nohup will do the trick.
screen is the best built-in tool that's always available for that, although it gets a bit weird around keyboard shortcuts, some of which sometimes don't work the way you want exactly.
I've found tmux to be much better in terms of usability.
Alternatively. take a look at mosh, which is trying to replace ssh. It's a mobile shell tool from MIT that supports intermittent connectivity, lots of praise there.
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
I'm using Cygwin's startx and want to customize my xinitrc so that I don't get any "magic" X programs on screen, i.e., programs that will cause the X server to terminate if I exit them. I don't want any X programs to start up on screen at all, actually; I just want to use the XWin menu, customized from my .XWinrc .
Ordinarily from a .xinitrc, I would make the last line run the window manager. Then I can exit X by exiting the window manager from its own provided interface.
In this case, though my window manager and my server are effectively the same process, because I am using the XWin server. I don't have a windows manager to execute. I am starting the server from my .xserverrc file:
exec XWin -multiwindow -clipboard -silent-dup-error
I can sleep at the end of my .xinitrc, in a loop:
while [ 1 -eq 1 ]
do
sleep 10
done
But that seems inelegant.
I can wait for a child process, either by starting it up as the last line in my .xinitrc, or by starting it up earlier in the background and waiting for it explicitly with "wait {PID}". But I can't wait for the XWin.exe process, because it is a parent process of my .xinitrc script, not a child process.
I can't start up XWin.exe at the end of .xinitrc; if I try, I get a different window manager apparently starting up, with XWin not in rootless mode, and then I get an immediate shutdown.
Is there a more elegant way to do this than sleeping in a loop? Is there a way to start XWin from my .xinitrc and wait on it? Is there a way to tell the .xinitrc shell script to simply wait and not exit, without sleeping, such that it will continue executing and do nothing until XWin.exe exits? Is there something I should be starting in the background as the last line of my .xinitrc, so as to give me a process to wait on without starting up an X program?
So, summarizing from Ben Bullock's answer, the answer to "How do I make .xinitrc do this?" is "Don't!" Never ask "How do I use X to do Y?" questions. :) Skip startx/.xinitrc entirely.
I am using Putty to connect to a remote server. What I want to know is if there is any way to write my commands and allow them to keep running after I close the session with Putty. The reason for this is that I do not want to keep the computer ON all the time. Is there any way to do this?.
Update with the solution
For my question as it is presented the best solution is use one of the commands provided such as nohup, because you do not have to install any additional software. But if you are in the same problem use screen, install it and use it. It is amazing.
I have selected the answer of Norman Ramsey as favourite because propose several solutions using commands and screen. But please check the other answers specially the one of PEZ, then you get an insight of what screen is able todo.
screen! It's the best thing since sliced bread. (Yeah, I know others have already suggested it, but it's so good the whole world should join in and suggest it too.)
screen is like, like, ummmm ... like using VNC or the like to connect to a GUI destop, but for command shell windows. You can have several shell "windows" open at once in the same screen session. You can do stuff like:
Start a screens session using "screen -dR" (get used to using -dR)
run some commands in one window
press CTRL-A,C to create a new window open a file there in vim
press CTRL-A,0 to go back to the first window and issue some command on the file you just edited
CTRL-A, 1 to go back to your vim session
CTRL-A, C for yet another window and maybe do "sudo - su" (because you just happen to need a full root shell)
CTRL-A, 0 and start a background process
CTRL-A, C to create yet a new window, "tail -f" the log for that background process
CTRL-A, d to disconnect your screen then CTRL-D to disconnect from the server
Go on vacation for three weeks
Log on to the server again and issue "screen -dR" to connect to your existing screen session
check the log in the the fourth window with CTRL-A, 3 (it's like you've been there watching it all the time)
CTRL-A, 1 to pick up that vim session again
I guess you're starting to get the picture now? =)
It's like magic. I've been using screen for longer than I can remember and I'm still totally amazed with how bloody great it is.
EDIT: Just want to mention there's now also tmux. Very much like screen, but has some unique features, splitting the windows being the most prominent one.
nohup, disown, and screen are all good but screen is the best because unlike the other two, screen allows you to disconnect from the remote server, keep everything running, and then reconnect later to see what is happening. With nohup and disown you can't resume interacting.
Try using GNU Screen. It allows you to have several shells open at once. And you can disconnect from those running shells (i.e. close session with Putty) and they will keep doing their thing.
What you are looking for is nohup.
See the wiki link for how to use it.
screen is the best.
Try:
screen -dmS "MyTail" tail -f /var/log/syslog
This start command in background.
Use screen -r to list, and or screen -r Mytail to enter session.
If more users need access same session, use: screen -rx MyTail, and both or more users share the session.
If you can't use screen (because, for instance, your SSH session is being programmatically driven), you can also use daemonize to run the program as a daemon.
One way that works well for me is at.
at works like cron, but for a one-time job. I used it today to download a large file without having to keep my session alive.
for example:
$ at 23:55
at> wget http://file.to.download.com/bigfile.iso
at> ^D
You pass at a time (in the future) and it gives you a prompt. You enter the commands you want to run at that time and hit ctrl+d. You can exit out of your session and it will run the commands at the specified time.
Wikipedia has more info on at.
./command & disown
ssh localhost && ./command && exit