Recently I've changed my default system voice via "System Preferences > Dictation & Speech > Text to Speech > System Voice". If I open a new Terminal window and use the say command, the correct voice is used. However, the previous voice is still used if I use the say command within a tmux session.
I've tried restarting, shutting down tmux completely, and opening an entirely new tmux session with tmux new-session -s foobar and still it doesn't pick up the new preferred voice.
This is really a minor issue, but it eats at me that I have no idea why it's happening. Any ideas?
I'm pretty sure this is the same root cause as that other issue: many tools that need to interact with the UI (graphics, sounds...) fail within a tmux session: say, pbcopy/pbpaste, nohup, launchctl export|getenv|setenv, subl (Sublime Text command line tool), Retina rendering of apps launched under tmux, tools trying to access KeyChain (curl, ssh...), etc.
I remember GNU screen used to have the same problem but Apple patched it and now it works fine, but tmux still has the problem.
Solution (2017-05)
Borrowing from answers in linked issue, for tmux you can do this if you have Homebrew:
brew install reattach-to-user-namespace
Then put the following in your ~/.tmux.conf:
set-option -g default-command "reattach-to-user-namespace -l $SHELL"
I reproduced your issue on macOS 10.11.4, and the above fixed it.
See here for more info on the nature of the problem, and its workaround (using undocumented macOS APIs)
Better solution soon?
As mentioned in comment, future versions of tmux might do this dance natively, at least it's being worked on, and current master has the fix.
Related
I was upgrading everything in homebrew and zsh was upgrading and I was cycling through my open applications and accidentally closed iterm during the update. Now I can't open iterm and when I open the terminal I get the following error message:
login: /usr/local/bin/zsh: No such file or directory
I am not sure how I can switch back to bash until I correctly update zsh. I also can't type a single command in either iterm or termianl which makes sense (there's no zsh file). How can I finish upgrading zsh correctly or switch back to bash?
I have done a good amount of research and can't find someone having a similar issue.
Any guidance to how to solve this issue would be much appreciated, I currently can't do any of the development work I need to do.
Found this on Apple's suport site. Basically, you want to launch Terminal and go into Preferences. Change Shells open with from Default login shell to a valid shell (I recommend /bin/bash or even /bin/sh just to get you working again).
Once you can access your shell session, you can restore zsh.
Here's the full article... http://support.apple.com/kb/ta27005
I copy text from outside of Vim. ⌘V in other apps pastes text without problem. In MacVim, it doesn't work.
In Insert Mode, nothing appears. In Normal Mode, I get E353: Nothing in register +. This happens when set clipboard=unnamed is on or off.
Oddly enough, this was working before. What's wrong?
If you are using tmux and sometimes you initially launch MacVim via the mvim command-line program, then you might be encountering the problem that prompted me to write the reattach-to-user-namespace command.
My guess is that clipboard access worked on prior occasions because you happened to have launched MacVim via a “normal” GUI method (e.g. the dock, Finder, Spotlight, etc.). The clipboard later became inaccessible after you had quit the prior instance of MacVim and relaunched it through (e.g.) mvim from inside a tmux session.
The core problem is that programs launched in certain contexts (i.e. inside a tmux session) end up with an environment that denies them access to certain services (e.g. the OS X pasteboard).
The initial launch is the important one here. New windows started by mvim-in-tmux (even without the above-linked wrapper program) should have access to the clipboard as long as MacVim was previously started “via the GUI” (maybe there are still some MacVim windows open, or maybe you have MacVim configured to keep running even when there are no windows open). Correspondingly, to regain access to the clipboard you will need to close all your existing MacVim windows, quit the application, then restart it in a way that has access to the clipboard (e.g. via the GUI, or “inside” the wrapper).
Once you have the above-linked wrapper program installed (it is also available through MacPorts and Homebrew), you can use a command like reattach-to-user-namespace mvim to ensure that if it ends up starting a new MacVim instance, then that new instance will have access to the clipboard. You might use an alias, shell function, or a script to make sure you always “wrap” mvim.
Several other commands also benefit from “wrapping” (pbpaste, pbcopy, nohup, launchctl (depending on which subcommand you are using)), so you may want to “wrap” your whole shell instead of the individual commands. The bit of the process environment that the “wrapper” modifies is inherited by child processes, so “wrapping” your shell will affect most commands you run from it. If you are using tmux, you could configure your default-command to automatically “wrap” your default tmux shells:
set-option -g default-command "reattach-to-user-namespace -l zsh"
I am on OSX Mountain Lion. I've configured tmux.conf to lock the screen, but the screen only flashes, no locking takes place. (fyi, when i used GNU-screen, the screen did lock).
My system does not have a lock/slock or vlock, nor could i find these on homebrew or macports. I understand that Screen uses its own internal locking whereas tmux uses external locking. I do not care whether I am asked to enter a new passkey or the system password is used. So how to get tmux to lock the session/terminal ?
# Screen lock
bind-key C-x lock-server
bind-key x lock-server
bind-key -n M-x lock-server
set-option -g lock-after-time 0
set-option -g lock-server on
# set-option -g lock-command "vlock"
p.s. I am aware of other alternatives, but these typically require a mouse (hot corners) or a Mac keyboard (eject key).
As far as I know, OS X does not supply any variation of the tty-locking program that tmux requires.
You will probably need to find a third-party tty-locking program, try to port one from a related OS, or write your own.
This isn't an exact answer as you expected. #chris-johnsen gave the best answer about locking on OSX. I did however find two screen savers for the terminal. It doesn't lock the terminal but it does blank out the screen.
tmux has a built in time function that will blank the screen and display a clock. It is local to the window.
cmatrix is a terminal program that displays the matrix screen like in the movie. The con is that it doesn't lock and it eats up some CPU. But it is fun. It can be installed via homebrew
Here is how to get it working:
brew install cmatrix
Then add this to your ~/.tmux.conf:
set -g lock-command "cmatrix -s -b"
set -g lock-after-time 90
set -g lock-server on
In 90 seconds of inactivity it will display. Use the command tmux lock-server to test it.
I was disappointed to not see any valid responses for actually locking the screen. I'll continue looking for a way to properly lock the terminal session itself, but in the meantime I do have a functional alternative.
By running a command on the command line, you can lock your entire mac. The following command will make it happen:
/System/Library/CoreServices/Menu\ Extras/User.menu/Contents/Resources/CGSession -suspend
You can find a lot more about what's happening exactly at this page.
Tie that command into:
set-option -g lock-command
And you should have a way to functionally lock up your session. I know locking the entire machine is not the most desirable outcome, but this is at least a working alternative for now.
I'm using tmux on a macOsX moutain lion (10.8)
Whenever i'm in a terminal, pressing the Escape button results in the connection to the server being lost and tmux actually exiting. I experience the same behavior regardless in iterm2, terminal and while using any of zsh, bash or a normal login shell.
That's how it looks like:
Any hints? :)
I finally figured out that it was related to iterm2-tmux integration.
As you can read here in the Usage section just below the code box, the tmux-iterm2 integration makes the ESC key actually kill tmux, unless you actually use tmux -C.
This effect was actually undersirable for me since I was not using tmux -C and the ESC key is extremely important in programs like vim or mc.
I'm in a class that uses an implementation of Emacs on a school server. I'm on a mac running snow leopard, and I have my own implementation of Emacs on it. To access the server-Emacs, I ssh into the server and launch Emacs from its location there.
I'm relativly new to emacs, and I have a particular problem whenever I try to access the server-emacs from my local-emacs' shell-mode, having ssh'd into the server. It gives me the error that "Screen size -1x80 is too small", and doesn't launch the server-emacs.
I've the separate issue that when I try to do this in Apple's terminal, it does launch the server-emacs, but I really, really dislike the interface when emacs is launched within a terminal.
I've tried a couple of times to launch the server-emacs within a new window, in both scenarios, but apparently I'm not doing it right.
I think it'd be useful to understand what you're trying to do.
Do you just want to edit files on the server? If that's the case, read the documentation for tramp, and try:
C-x C-f //user#server:/path/to/file
If you really want to use the emacs running on the server, try creating a frame on your
(if so, look up tramp) If you want to actually use the emacs from the server, but have the window display on your mac:
ssh server
setenv DISPLAY mymac:0
emacsclient file &
This does assume you're running X11, and know how to resolve the display for your Mac. You can get X11 for the Mac here.
It's a bit hard to tell what you are doing, but you probably want to ssh to the server with an X tunnel, then run emacs there which will pop up the window on your mac.
First, don't use Terminal.
On your mac, start up X11 (google for XQuartz if you don't already have it).
Start up an XTerm (it should do this by default). From that XTerm, ssh to your server with the -Y option:
ssh -Y me#server.something
This should get you a remote shell and setup the DISPLAY environment to tunnel right back to your Mac's X server. Test it by running an xterm from there. If that works, you can instead run emacs. If that works, you can combine it with the ssh invocation:
ssh -Y me#server.something /usr/bin/emacs # or whatever path you need
You should set up ssh to not require a password but that's more than you asked for.
I think that Trey Jackson's suggestion of tramp (or the more old-fashioned 'ange-ftp) is probably your best bet.
In general, running emacs inside an emacs is never a good idea. You either want to run emacs on the server (in -nw mode inside the terminal, or via some $DISPLAY magic) or run it on your mac (via tramp). There isn't really a good way to do both.