zsh name in terminal changed to a number when logged in - macos

I used to see myname#my-Macbook... when I open my Terminal, but recently it changed to myname#192. Why did this happen, and is there a way to change it back? Thanks!

Check out what hostname returns. If it returns that number, search for changing the hostname. If not, your shell prompt has gotten messed up, and an easy way to fix it is to trash your shell config (.zshenv, .zshrc, etc).

Related

MacOS Big Sur not setting the COLUMNS environmental variable

I was having trouble using the shell vi editing mode - the cursor would move back a line sometimes. I finally tracked it down - Terminal is no longer setting COLUMNS, so the shell defaulted to 80.
I had a comment in my .profile that COLUMNS use to be set by TERMINAL, but now it isn't. I can't find anything in the Preferences that would appear to enable that.
Anyone know what happened, and how one might fix it. The original idea was users would resize windows, and pass the new size down to the shell so editing would work properly.
export COLUMNS=<number>
in your .bashrc.

Terminal/iTerm2 window name on macOS: how to un-stick SSH to show next process?

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.

Mac Terminal history - commands with past results

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

iTerm2 tab names change; what is this bash command?

I use iTerm2 as my terminal on OS X. When I SSH into a machine, I like to name my tabs by going into the session preferences (cmd + i). Whenever I run another bash command after setting this preference, the tab title goes back to the default that it was when I first SSHd in.
Browsing around for an answer, I found this answer by Chad that is working for me:
export PROMPT_COMMAND=''
echo -e "\033];MY_NEW_TITLE\007"
I don't really understand the PROMPT_COMMAND line, though I tried looking it up.
Can someone explain this in simple terms?
Same question for the 2nd line, as I don't even know how to begin researching that.
To keep the original tab:
Go to Iterm's Preferences > Profiles > Terminal
Uncheck "Terminal may set tab/window title"
Now you can name your tab, ssh into a server, exit and still keep the original tab name.
Credit to: https://groups.google.com/forum/#!topic/iterm2-discuss/czV-sv4ykzI
You can read iTerm2 escape code .
I didn't read the related iTerm2 code thoroughly, but it seems like an interface to manipulate iTerm2.
I guess iTerm2 does this magic by parse the output of screen if the contents fit special format(start by "\033]" and so on), iTerm2 will consider that's the information mean to sent to itself.
I used tabset node plugin. It works like a charm, and also color codes each tab, and has multiple options to color code, add a badge and even bring up a color picker to choose.

How to get Cmd-left/right working with iTerm2 and Vim (without requiring .vimrc changes)?

I want to be able to use Option-left and Option-right to skip words (and Cmd-left/right to go to beginning and end of lines) within Vim as it does at my shell prompt. My Iterm2 preferences have mappings to do this (e.g. Option-left to Esc-H and a one for option-right to Esc-F to skip over words), and this works in the shell locally or when ssh'd to a remote server.
When I use Vim locally or remotely, option-left works, but option-right does not. I suspect this is because Vim naturally listens for Esc-H, but not Esc-F. I am able to get around this by modifying .vimrc file to Esc-b to b and Esc-f to f, but I don't want to do this to every server I'm connecting to.
Similarly, I have the same desired setup for Cmd-left/right for going to beginning and end of a line. I can get this working in the shell via Iterm2 mappings (e.g. Cmd-left to Esc-[h), but Vim doesn't respond at all to this unless I map keys again (e.g. Esc-[h to ^).
Update: I just figured out how to get option-left/right working. I changed mapping in iTerm2 for these to be escape-[1;5D and escape-[1;5C respectively. I still want to solve the Cmd-left/right problem though (I changed my question's title to reflect this). Any ideas?
To mimic OS X's behavior of sending Cmd-left/right to the beginning/end of a line, I add the following mappings in iTerm2:
Cmd-left to escape-sequence [1~
Cmd-right to escape-sequence [4~
To mimic OS X's behavior of sending Option-left/right to the previous/next word, I add the following mappings in iTerm2:
Option-left to escape-sequence [1;5D
Option-right to escape-sequence [1;5C
Special thanks to this blog post for tracking down what I was missing with the cmd-left/right mappings
I'm using iTerm2 3.4.2 and there's actually a preset that you can select for your profile that enables this.
FWIW, dolan's answer didn't work for me on iTerm 2 1.0.0.20120203 on Mac OS X 10.7.3. His solution only inserted ~ and 5D/5C into my terminal when I pressed the shortcut keys.
Instead, I used the following solutions:
Cmd-left/right:
iTerm 2: How to set keyboard shortcuts to jump to beginning/end of line?
Option-left/right as well as option-delete:
http://hackaddict.blogspot.co.at/2007/07/skip-to-next-or-previous-word-in-iterm.html
YMMV, not sure why one set of solutions would work and not the other
I don't have MacOS, so I cannot exactly know your situation, but I recognize the problem from other OSes.
Basically, it would mean that the terminal sends keycodes that aren't understood by vim. I fixed it in the past by doing
TERM=something
export TERM
before invoking vim
E.g. in order to get all keys and syntax highlighting working on AIX 5.3 across Putty/screen, I needed to use
TERM=iris-ansi vim
There is a list of builtin terminal types if you pass a bad TERM

Resources