I'm currently using Hyper terminal on a mac, but this question also applies to other types of terminals, e.g. iTerm
How do you change the terminal title from username#devicename:~ into just ~ or zsh.
Currently my shell is zsh with oh-my-zsh installed. I'm not looking for workarounds through powerline or themes.
One more question:
How do you reset back after running echo -n -e "\033]0;SERVER\007"?
Within ~/.zshrc
Uncomment the following line to disable auto-setting terminal title.
DISABLE_AUTO_TITLE="true"
I'm using this in my .zshrc:
# oh-my-zsh seems to enable this by default, not desired for
# workflow of controlling terminal title.
DISABLE_AUTO_TITLE="true"
function set_terminal_title() {
echo -en "\e]2;$#\a"
}
Have you googled to search for an answer? How about the following:
https://alvinalexander.com/blog/post/mac-os-x/change-title-bar-of-mac-os-x-terminal-window
echo -n -e "\033]0;YOUR TITLE HERE\007"
With iterm 2 3.3.3 there's a setting under preferences->profiles->general-basics->title that you can set to PWD (and a few other options). It seems they changed a few things related to this recently and this overrides whatever is in the .zshrc.
I'm guessing one of these options might turn of this behavior as well. In my case PWD is exactly what I want.
For Mac, first:
brew install wmctrl
then for Mac or Linux
wmctrl -r :ACTIVE: -N "~"
in the active window. Type man wmctrl if you want to say ways to select a window that is not active.
This works for me:
DISABLE_AUTO_TITLE="true"
case $TERM in xterm*)
precmd () {print -Pn "\e]0;%~\a"}
;;
esac
Related
Similar to this question: bash recursive xtrace, but for Zsh.
How can I make all the Zsh subshells inherit the xtrace option?
For example, if script1.sh is calling ./script2.sh and I run zsh -x script1.sh, I want script2.sh to also have the xtrace mode enabled.
For Bash, the answer is to export the SHELLOPTS variable.
Is there a solution for Zsh?
You can take advantage of startup/shutdown files in Zsh (see man zshall): Zsh will always read (and execute) the file $ZDOTDIR/.zshenv at startup (if ZDOTDIR is unset, HOME is used instead). So you can put set -x in $ZDOTDIR/.zshenv and every Zsh script will run with xtrace mode enabled.
This is how I used it in a script:
env_dir="$(mktemp -d)"
echo "set -x" > "${env_dir}/.zshenv"
export ZDOTDIR="${env_dir}"
zsh "$#"
unset ZDOTDIR
rm -rf "${env_dir}"
In fact, this solution can be used for Bash as well, using the BASH_ENV variable, which points to a file that will, similarly, be executed when Bash starts.
I'm trying to detect the presence of iTerm2 and if I run the following in iTerm2 (echo -n $'\e[5n'; read -s -t 0.1 line; printf '%q\n' "$line") the terminal responds with $'\033'\[ITERM2\ 3.2.1n$'\033'\[0n
However, if I am running a tmux session in the terminal, then tmux responds and gives me nothing.
Any idea how I can ask tmux to query the physical terminal to report its status?
Footnotes
Here is a description of [5n in the tmux source: https://github.com/tmux/tmux/blob/486ce9b09855ae30a2bf5e576cb6f7ad37792699/tools/ansicode.txt#L577
This might be iTerm2 only, since I haven't seen a response on any other terminal
According to ft in freenode's #tmux (and as seen in this Super User answer), you can use:
'\ePtmux;\e" STUFF_FOR_THE_TERMINAL_HERE "\e\\'
So, it would be something like:
echo -n $'\ePtmux;\e\e[5n\e\\'
I'm not following how the environment variable $NLSPATH value is being cleared/reset when running gmake. In my bash shell, if I issue echo $NLSPATH, I see the expected /usr/lib/nls/msg/%L/%N: (etc).
I then create a Makefile like this:
all:
echo $$NLSPATH
echo $$PATH
And running gmake all gives me
echo $NLSPATH
echo $PATH
/usr/bin:/etc:(etc as expected)
I also tried -e with the same result;
gmake -e all
echo $NLSPATH
echo $PATH
/usr/bin:/etc:(etc as expected)
I've looked at /etc/environment and /etc/.profile and $NLSPATH is set correctly there.
Also if I run the standard AIX make, the NLSPATH is shown as expected. So this seems to be gmake and/or the way it invokes the current shell.
Could someone suggest where I should be looking ? [EDIT]
As I'm new, I can't hit answer right away...
Finally found it - The following technote describes it (albeit briefly) as a security limitation;
http://www-01.ibm.com/support/docview.wss?uid=swg21516415
Issuing;
cd /opt/freeware/bin
sudo chmod -s make
solves this issue for me although I'm left wondering there is some aspect of gmake that may later expect the setuid flag.
IIRC GNU make on AIX needs the setgid flag in order to enable the -l flag, because on this OS you can't retrieve the load average of the system as a normal user (no idea why that is considered more of a security issue than having any program that needs to check the load average be setgid, but... no one asked me).
As long as you don't use -l when running GNU make, you won't have any problem.
I am wondering if anybody is able to get the vim prompt working properly using Mac OSx Mountain Lion the latest version. I am able to edit in vim mode on the command line but I have seen with zsh before that you can go into Vim mode which launches a vim editor and you can write you command there and then write and quit and it will add it to the next line in the terminal. There may be a plugin to do this I am not sure? Any help would be great.
This answer was posted here:
https://stackoverflow.com/a/903973/1031826
Basically, if you're using vi mode, you can add the following lines to your .zshrc:
autoload -U edit-command-line
zle -N edit-command-line
bindkey -M vicmd v edit-command-line
And you can press ESC-V to edit the current line in whatever your default editor is.
You can adjust the last line ("bindkey...") if you want to change the key binding used.
I can't seem to set a new $PATH such that it is used when executing commands via ssh user#host command. I have tried adding export PATH=$PATH:$HOME/new_path to ~/.bashrc and ~/.profile on the remote machine, but executing ssh user#host "echo \$PATH" shows that the change has not been picked up (it shows /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games). The remote machine is running Ubuntu 8.04.
I'm sure I could hack it into /etc/profile, but that's not a clean solution and it only works when one has root access.
As grawity said, ~/.bashrc is what you want, since it is sourced by non-interactive non-login shells.
I expect the problem you're having has to do with the default Ubuntu ~/.bashrc file. It usually starts with something like this:
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
You want to put anything for non-interactive shells before this line.
Do you have an ~/.bash_login or ~/.bash_profile?
Bash in interactive mode checks for these files, and uses the first existing one, in this order:
~/.bash_profile
~/.bash_login
~/.profile
So if you have an ~/.bash_profile, then whatever changes you do to ~/.profile will be left unseen.
Bash in non-interactive mode sometimes reads the file ~/.bashrc (which is also often source'd from the interactive scripts.) By "sometimes" I mean that it is distribution-dependent: quite oddly, there is a compile-time option for enabling this. Debian enables the ~/.bashrc reading, while e.g. Arch does not.
ssh seems to be using the non-interactive mode, so ~/.bashrc should be enough. When having problems like this, I usually add a few echo's to see what files are being run.
ssh documentation says:
If command is specified, it is executed on the remote host instead of a login shell.
which is why adding to the bashrc files doesn't work. you do however have the following options:
If the PermitUserEnvironment option is set in the sshd config, you can add your PATH setting to ~/.ssh/environment
ssh remotemachine 'bash -l -c "somecommand"'
You can always say:
ssh remotemachine 'export PATH=wedontneedastinkingpath; echo $PATH'
In addition to #signpolyma answer, you will have to add your export before these lines
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
Just had the same problem myself, solved it with:
ssh user#remotehost PATH=\$HOME/bin:\$PATH\; remote-command