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.
Related
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.
I need script which works in the background, waiting for a key to be pressed. I have a script which works when terminal is on. When I try to use & - it's not working correctly. The script works in background but keypress doesn't do anything. When I try use nohup then I have error of read - bad descriptor.
Can someone help me?
When the terminal is on (and is selected, in case of a terminal emulator running on x server), the input (key strokes, etc.) is directed to the terminal; hence, your program works.
Now, consider an example: let's say that you created a script that runs on the background, and it is activated by pressing the letter "a". If pressing "a" triggered your script (with terminal closed), then the user would never be able to (for example) type the letter "a" in a word document or a web search without triggering the script!
Therefore, what you are looking for is a key bind, or a keyboard shortcut, which would bind a key (combination) such as ctl+j+k to launch the script you want.
In Linux, that can be done somewhat easily, see this for Ubuntu or this for Lubuntu.
Important: if your script needs to be root to work, then you generally will have to evoke it via gksu or gksudo, otherwise it will not run
I have been working with two terminal windows in my Mac (dev/prod), both had shown the commands and results history (scrolling up) for the last 6 months of work, which was very helpful to run periodic commands and to check past errors.
Yesterday I turn off my mac and closed both terminal windows manually, but today when opening the terminal it has no history at all. There is a way to recover the windows with all the history for past commands and their results?
I know there is a .bash_history file but it only shows commands typed but not the results.
Thanks in advance.
Bash's history only store executed commands, not their output, and only a limited number of them (usually 500, as defined by environment variable HISTFILESIZE). This won't help in your situation.
From what I can see, it appears that Terminal store save window's state (including console history) inside directory /Users/<user>/Library/Saved Application State/com.apple.Terminal.savedState/. Files in this directory are modified in real time whenever new events occurs in the terminal window, and unless I am mistaken, should be included in Time Machine backups. Therefore, it seems that if you can restore files in this directory from some former backup, you should get back your history. You could even try some "file undelete" tools in that directory, though these tools are rather rare on OS X.
The procedure for this should be that you first quit Terminal, then restore the whole directory (for example using Time Machine), then simply launch Terminal. These saved state files use a custom binary format, that you can't be read otherwise than by the Terminal program itself.
By the way, it might be worth mentioning that you can, at anytime, save the content of a Terminal window to a text file, from the Shell menu. You might consider doing it periodically, in the future, given that your terminal's history appears to have some significant value...
if using zsh check your /etc/zshrc for the history file location, mine has
# Save command history
HISTFILE=${ZDOTDIR:-$HOME}/.zsh_history
HISTSIZE=2000
SAVEHIST=1000
also check your ~/.zshrc incase the defaults for these have been changed
Probably a very simple question. I just thought, after someone suggested it here, of trying (and installing) Python 3.6 on a Mac - I've been happily using 2.7 since now. I've never used the IDLE before having done everything via the command line + ATOM to write the program.
I see that 'normally' you should be able to write your program in the shell and then run it in the RUN window. However, I don't see a RUN mode in window, just the possibility of using, which you are anyhow, the shell window. I hope that makes sense!
Is this normal, or have I missed something?
p.s. I'm using OS X 10.8, if that's of any importance.
I am not exactly sure what you are asking, and whether it has anything to do with OSX, but I can explain IDLE. IDLE has two types of main window: a single Shell and multiple Editor windows.
Shell simulates python running in the interactive REPL mode that you get when you enter 'python' (or 'python3') in a console or terminal window. (The latter depends on the OS.) You enter statements at the >>> prompt. A single-line statement is run when you hit Enter (or Return). A multi-line statement is run when you hit Enter twice. This is the same as in interactive Python.
Editor windows let you enter a multi-statement program. You run the programs by selecting Run and Run module from the menu or by hitting the shortcut key, which by default is F5 (at least on Windows and Linux). This runs the program much the same as if you enter python -i myprogram.py in a console. Program output and input goes to and is received from the Shell window. When the program ends, Python enters interactive mode and prints an interactive prompt (>>>). One can then interact with the objects created by the program.
You are correct that Run does not appear on the menu bar of the Shell. It is not needed as one runs a statement with the Enter key.
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.