I know this question looks like dozen of others: but, I am trying to get insight into why this script acts the way it does and if there is any draw back to it like memory leak or other.
The script its simple:
cd "C:\me\python\.venv" && start C:\me\python\.venv\env\Scripts\activate
There is a windows that opens briefly then closes then another command window opens with the virtual environment open as I need. This question is not about the virtual environment in any way. I am trying to understand the command window.
It seems buggy that a command window opens to change directories then closes and then another opens the virtual environment in another window. I can live with this I guess until I run across a seemless way to do this; but, isn't there a better way to do this?
Is the window opening then closing the behavior of the command prompt when changing directories? No! The script could be written simply as:
start C:\me\python\.venv\env\Scripts\activate
and there is still an occurence of a window opening prior to the window with the virtual environment started.
Is there any after affects from doing it this way, like background process open or memory leak or what have you?
Anyone know where to read the "readme" on this behavior?
Thank you much!
Use this code:
cd "C:\me\python\.venv" && C:\me\python\.venv\env\Scripts\activate
the start command is not necessary and that's what opens one more window and lets the previous one close.
This command create a new windows asynchronously.
Related
I'm wondering whether others have experienced this issue (below in bold) and/or found a workaround: in macOS (any version that I've tried which provides Terminal access, so I'm assuming OS X on up; on any hardware), a Terminal or iTerm2 window gets named with the active top-level process until it ends or you quit it. Expected behavior for all systems with Terminal access, right?
When using SSH in Terminal or iTerm2 on macOS, the name of the remote machine populates the top of the window. Also expected. The unexpected comes when you exit out of the SSH session, and the name of the remote machine you had SSH'ed into persists in the window banner; there is no more visibility in the window banner of your current top-level running process, until and unless you close the window (losing some access to command history), and open a new window.
I've never seen this process-stuck behavior on the banner of a Terminal window in any other OS; various forms of Terminal on Linux distros exit out of SSH and get back to showing the top-level running process fine, as does CMD or PowerShell in Windows. What's going on with macOS, and why has this behavior never been addressed, at least as for as my limited DuckDuckGo-fu (or !G-fu) can find?
Has anyone else experienced this?
Insight welcome. Thanks!
There's no "process stick" going on.
Let's address several things here.
First, please note... "shell" != "terminal", and if you think it does, you are mistaken.
You state:
When using SSH in Terminal or iTerm2 on macOS, the name of the remote
machine populates the top of the window.
Yes, if the remote shell sets the terminal window title. Usually in a prompt. Sometimes in a shell initialization rc file. With ksh you even see people overloading things like cd(1), which is a little silly.
Then you state:
The unexpected comes when you exit out of the SSH session, and the
name of the remote machine you had SSH'ed into persists in the window
banner
Because the remote shell set the title of the terminal window and the local shell does not reset it when it regains control.
And finally:
What's going on with macOS, and why has this behavior never been
addressed, at least as for as my limited DuckDuckGo-fu (or !G-fu) can
find?
If you want whatever shell you are using to do something, configure it to do that thing. Otherwise, it will not do that thing. There's nothing to address... it's not broken.
macOS default init for ksh doesn't set any prompt at all, for zsh all that's set up is user name, machine name, and current $PWD, and bash is the same. None of them set the terminal window title.
Seems rather obvious what's going on.
So. If you want your terminal window titles to reflect this information:
the local shell needs to set the window title
the remote shell(s) need to set the window title
It seems you have the second one handled, so fix the first one. Most people do it by adding control codes to the shell prompt so that it changes the window as reliably as possible.
You may find this reference helpful.
I want to set a global shortcut that will open a certain file. When there already is a gvim window that has that file open, I want it to focus on that window, and select the tab with that file. If there isn't, I want it to be opened in a new gvim window, regardless of whether there already are other gvim windows.
I can do part of this with --remote and --servername, but I can't find a way to detect whether there already is a remote server running with the name I use, so I can't quite get everything to work together to come to what I described above.
OK, turns out most can be done using the default behavior of --remote-silent. The whole setup is a matter of making an AutoHotkey script like this:
#!^+1::
Run "c:\Program Files (x86)\vim\vim74\gvim.exe" --servername org --remote-silent %DROPBOX%\org\TODO.org
WinActivate, TODO.org
Return
AHK is needed for the global hotkey as well as activating the window; vim (using --servername and --remote-silent) will start a new session called 'org' if there isn't one yet, and start it otherwise. It even gets the tab activation right when there already is a server called 'org' but if that server has another tab active.
When i click on a .rb file to run it a CMD window pops up for a brief second and then closes again. This is probably a really nooby question thats easily fixed but i've looked everywhere for help. But like i said it pops up for a brief second and i THINK while its up its executing the code but when the codes done it closes so i don't know if i'm making mistakes in code or other important things like that.
Run the program through the command prompt (CMD), that way you can see the result, otherwise the window closes when the program exits.
Alternatively, you can prevent the program from exiting by putting some sort of blocking instruction at the end of the script, such that the program waits for user input before exiting.
Press Windows_Key+R and then type CMD. Browse to the location of the file and then type ruby your_ruby_file.rb. The program is running, but Windows automatically closes the window upon completion of the command.
To get Windows to run your *.rb files through Ruby when you click on them in the UI, you have to associate the .rb extension with the ruby.exe executable. Such an association is called a "Windows File Association." Here's a Microsoft Knowledge Base article that'll tell you how to create such a thing.
http://support.microsoft.com/kb/307859
I'm just meddling with OSX after a few years on Linux. There's a lot that I'm liking, but one thing that's slowing me down is that if I run the 'terminal' command via shortcut/spotlight/quicksilver, it whisks me off to any existing terminal in whatever space already has a terminal instance open.
I regularly like to pop up a terminal, run a quick command and then close it again, all the while staying in whatever desktop space I happen to be on.
...So, how do I do that on Mac?
Cheers...
Go to System Preferences -> Exposé & Spaces -> Spaces and check When switching to an application, switch to...
Download this tool called Visor
It lets you quickly get a tabbed drop down terminal using a hotkey like Ctrl-`.
Insanely convenient for working in the shell.
Try this tool: https://github.com/nmadhok/OpenInTerminal
This is a really handy tool for programmers on Mac as it lets you open the folder directly in Terminal. You can select multiple folders to open them in multiple terminal windows. You can also select files to open the parent directory in Terminal. This application works with Finder as well as without Finder which is a plus!
I started using vim for my programming projects (mostly Ruby) and mostly everything works just as I want but I have a problem with compiling.
Lets say I am working on a Ruby script and I want to run it. I type :ruby sometging.rb (mapped to some other key). Then vim opens a new cmd.exe window and runs 'ruby something.rb'. Then it waits for me to press ENTER to close the window and continue working on the script.
Is there a way to configure vim on windows so that it always runs the script I'm working on in a separete window (always the same one, if none exists => open one), and not ask me to confirm with enter?
Don't know about gvim, but in normal vim you could put something like
map R <ESC>:tabnew<CR><ESC>:;%!ruby filename.rb<CR>
in your ~/.vimrc which would execute a Ruby file in a newtab when pressing R in command mode.
I've not used Ruby, but for I've found Dr Chip's RunView plugin really useful for running other interpreted languages.
Once it's installed, you can enter:
:RunView! <interpreter>
(where <interpreter> is presumably 'ruby' in your case) and it will open a (vertically if you include the !) split window with the output from passing the contents of the current window to the interpreter. Each time it is run, a new result log is appended to the end of the file (with a date and time stamp separating them).
If you have any issues with it, I'd recommend you contact Dr Chip via the Vim mailing list: he's very helpful (in fact he wrote the original version of RunView in response to a request I made on the mailing list).
This isn't exactly perfect but I use this to launch Python scripts.
command -nargs=* PY3 !start cmd /K Python.exe "%:p" <args>
It starts up a window that stays alive and doesn't interfere with my VIM window. Unfortunately it doesn't load it into an existing window.