Up until a couple days ago, I was using Gimp on OSX 10.7 normally with no issues. Then I installed Inkscape, but was unable to start it because of a language settings issue (the system is currently set to Japanese). I installed XQuartz to see if that made a difference, but it didn't, so I left it at that. Come time to do a bit of work with Gimp today, and it appears the same problems I faced with Inkscape made their way to Gimp as well (except this time it wasn't language-related). Here are the details:
Both X11 and XQuartz, when run normally, crash after briefly peeking up on the dock. A look at the Activity Monitor suggests XQuartz is trying its best behind the scenes to get started, as it is running but not visible, and starts up again as soon as I force-quit it.
When I run X11 and XQuartz from the terminal, X11 works, but gives me this:
X11.app: DISPLAY ("/tmp/launch-qlRWSF/org.macosforge.xquartz:0") does
not match our id ("org.x"), unsetting. X11.app: main(): argc=1
argv[0] = ./X11.bin
Waiting for startup parameters via Mach IPC. X11.app: Could not
connect to server (DISPLAY is not set). Starting X server. X11.app:
Launching /usr/X11/bin/startx: argv[0] = /bin/sh argv[1] = -c
argv[2] = /usr/X11/bin/startx
font_cache: Scanning user font directories to generate X11 font caches
font_cache: Updating FC cache xauth: file
/Users/christopher/.serverauth.22530 does not exist
launch_msg("CheckIn") IPC failure: Operation not permitted X11.app: No
launchd socket handed off, unsetting DISPLAY X11.app:
do_start_x11_server(): argc=6 argv[0] = /usr/X11/bin/X argv[1] =
:0 argv[2] = -nolisten argv[3] = tcp argv[4] = -auth argv[5] =
/Users/christopher/.serverauth.22530
Xquartz starting: X.Org X Server 1.10.6 Build Date: 20120513 X11.app:
DarwinProcessFDAdditionQueue_thread: Sleeping to allow xinitrc to
catchup. (EE) Error loading keymap /tmp/server-0.xkm (EE) XKB: Failed
to load keymap. Loading default keymap instead. /usr/X11/bin/xinit:
XFree86_VT property unexpectedly has 0 items instead of 1 font_cache:
Done
However, XQuartz starts without a problem from the terminal.
Finally, I found that when I call xterm from terminal, it just sits there without outputting anything or receiving any input. I think that's unusual behavior.
I checked out a couple key words from the X11 output, namely the display part and the keymap part, but found nothing out of the ordinary. The $DISPLAY value is as it should be, and the keymap seemed more connected to remote server issues than would apply in my case (these are local issues).
I appreciate any suggestions.
Ok, I was just being creatively stupid. I have been experimenting more with terminal lately, and as a result, put
exec $SHELL
in my .bash_profile. Removing that line solved my problem.
It didn't affect anything for the longest time, so I never caught it. Apparently that also affects the X11 processes.
Related
When I'm using XFoil (for Mac, XQuartz installed) and I'm trying to plot something, the above message comes out. Another thing, I've used the instructions of the following link to install Gnuplot and I'm worried I did some damage... it's all ok with this?
http://macappstore.org/gnuplot/
Please try to use
export DISPLAY=:0.0
within the shell, so GNUplot knows that it should use the standard display (i. e. your XQuartz environment)
On a MAC, install Xquartz and ensure it is running after your attempt to start your X application.
pgrep -fl Xquartz will show all the processes and their arguments that match Xquartz.
If you don't have pgrep, run /bin/ps -o 'pid,command' -e | grep Xquartz instead.
Look for the entry for the executable itself with the display set; something like this:
1182 /opt/X11/bin/Xquartz :0 -nolisten tcp -iglx -auth ...
The first number is the process id, or PID. If you wait 20-30 seconds and re-run the command, ensure the number is the same.
If the PID has changed, then you have the problem I ran into, where Xquartz is exiting with an error and the system is restarting it again, whenever I tried running xterm.
To check logs for an error, start the Console app found in /Applications/Utilities. In the search box, type Xquartz and press return, and you should see only the Xquartz entries.
The error log I saw was:
tput: No value for $TERM and no -T specified
-: line 0: exec: uid=501(...): not found
After some investigation, I figured out that all I needed to do was set TERM prior to running the X server, and this can only be done in a .x11run file created in your home directory.
Create ~/.x11run with the following content:
#!/bin/bash
export TERM=xterm-256color
# include other vars the X11 server may need
/Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin "${#}"
Then, make it executable: chmod +x ~/.x11run.
Next, log out (Apple icon top left, click Log Out), and then log back in, and try your app, in my case, xterm, and after several seconds, it finally appeared.
You have to install an xserver first. On a MAC you would use XQuartz. You need to download and install XQuartz and from within XQuartz (right click on the logo after start) start a terminal. In this terminal navigate to the location where xfoil is installed and run it. The DISPLAY variable (as shown in another answer) is automatically preset in this terminal. So no need to do this if you run as described here.
For the installation of xfoil (macOS Catalina) I had to compile the code. I followed these instructions which worked like a charm.
I try to be brave and switch from vi to emacs.
Now, I set up Emacs 26 on macOS via homebrew and start Emacs as daemon in the background.
I can use files using emacsclient -t. However, whenever I bring the Terminal into the background emacsclient exits within a few seconds.
See example Video here: https://cloud.familie-ganter.de/s/QwbK8cFBHnPjQ4d
I did a plain install. My init file does not contain anything except what you see in the video. The funny thing is whenever I start emacs directly in the Terminal, nothing at all happens when bringing it to the background.
What seems to be the problem?
I am lost …
I expect it to be something dumb and simple -- so please be nice, this is my first stackoverflow post.
I recently got a new Retina MacBook Pro, with Mountain Lion. Unfortunately, emacs is taking forever to startup (around 5s) on my new computer. I tried installing the latest homebrew version of emacs, but the problem persists. I don't have a .emacs file, so I'm clueless as to what could be causing the slow startup.
What tools do I have at my disposal to debug where emacs is spending its time during startup?
It looks like you need to have a fully-qualified domain name for your computer's hostname (e.g., myretina.local); otherwise, Emacs will be slow to start.
You can verify your hostname via Terminal with
hostname
and you can set it with
sudo scutil --set HostName myretina.local
For starters, run emacs -Q (which will start Emacs with no start-up files at all), and see whether that's still slow.
You may wish to read over the following, which explains all the various possible files which Emacs will look for by default:
C-hig (emacs) Init File RET
Changing hostname didn't do anything for me. What worked wonders for me seems counter intuitive, but now my emacs starts instantly from terminal. This is what I did
alias emacs=/Applications/Emacs.app/Contents/MacOS/Emacs --debug-init
However, it still takes a few seconds, sometime even 15 seconds, to start from the graphical interface. Weird!
Emacs should start up instantaneously in your setup
Mac build (from sources)
% time /Applications/Emacs.app/Contents/MacOS/Emacs --debug-init -eval '(kill-emacs)' -Q
/Applications/Emacs.app/Contents/MacOS/Emacs --debug-init -eval '(kill-emacs) 0.19s user 0.06s system 35% cpu 0.696 total
NS build downloaded from emacsformacosx.com
% time /Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs --debug-init -eval '(kill-emacs)' -Q
/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs --debug-init -eval -Q 0.17s user 0.08s system 35% cpu 0.691 total
I don't use homebrew for Emacs but it should be similar. Are you sure you're not loading non-standard packages some how?
There really is something totally broken with emacs. If nameservice collapses or routing is not fine, or your vpn tunnel is off, etc.
For us, sysadmins, starting vi is always an option:
# time emacs -debug-init -eval '(kill-emacs)' -Q
real 2m5.177s
user 0m0.029s
sys 0m0.024s
At this time the vpnc has died and caused some problems (routing and nameservice). Notice over 2 minutes!
After 30 years using emacs still do not understand why it really needs to resolve your hostname. For locking files there are better alternatives than that.
Managing hundreds/thousands of machines and VMs and setting individual host files is not really an answer. Manually it would take days/weeks and automatically generating. It really is as good as nothing.
Fixed by adding the local hostname and corresponding ip in /etc/hosts for me
I'm a long time GNU/Linux user. Even though OSX is much like GNU/Linux is many ways, it differs in some. For example, when I install Firefox I expect to be able to run firefox in a shell to start it. But not in OSX.
That gives me some trouble when running Emacs batch scripts. Lets say I have this script:
#!/usr/bin/env emacs --script
(message "Hello world!")
I can run it without any problems. But I'll be using the emacs builtin to OSX. And most of the times that's not possible since the Emacs version is pretty old.
Installing Emacs from scratch made it possible to create a Bash-script, which called some emacs binary file.
But installing Emacs from http://emacsformacosx.com/ I can not make this work. Can anyone think of a solution for this?
(1) Launch Emacs.
(2) Open Activity Monitor. (Applications > Utilities > Activity Monitor)
(3) Find Emacs in the list of running processes, under "Process Name".
(4) Select it.
(5) Choose "Inspect" from the Toolbar.
(6) In the window that opens, choose the "Open Files and Ports" tab.
(7) The name of the Emacs executable currently running should be the second line in the list. (The first line should be /Users/yourusername.) In my case it's /Applications/Emacs.app/Contents/MacOS/Emacs, which is pretty standard.
Yes, you dig out the path to the Emacs app emacs.
I've got X EMACS on my machine (not an emacs app), but the path will be something like
/Applications/Emacs.app/Contents/bin/emacs
You can find the exact path with ls from the command line.
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.