Cannot run domterm on macos
bentxt opened this issue · comments
Hi,
I try another take on domterm on mac os x. Here is what I've done
- install everything according the website under Macos
- ./configure && make
- run ./bin/domterm
What happened:
- the first time I've run ./bin/domterm there was an error about Electron.app missing
- since then ./bin/domterm doesn't run anymore, nothing happens, even ./bin/domterm --help doesnt return anything
- then by accident I've opened Chrome and a few minutes after I just tried ./bin/domterm one more time. Now something happened: a white empty chrome window opens. The html source is not empty thought and the url is http://localhost:49260/no-frames.html#session-number=1&server-key=...
I also have a fresh Electron.app under ../ so the tree looks like
ls ../
DomTerm
Electron.app
and I can open electron manually with ./Electron.app/Contents/MacOS/Electron &
but ./bin/domterm results in nothing (no error, no log entry, nothing ....)
"since then ./bin/domterm doesn't run anymore, nothing happens, even ./bin/domterm --help doesnt return anything"
When things get messed up, sometimes you have to manually kill the background domterm process. Try ps ax|grep domterm|grep -v grep and kill (if need be kill -9) the listed processes.
Does DomTerm work if you use a regular browser instead of Electron? E.g. ./bin/domterm --browser or ./bin/domterm --firefox.
I'm thinking of buying a used MacBook so I can test on Mac. Any recommendations for minimum os/hardware versions?
When it comes to finding Electron, first do:
./bin/domterm status
Find the filename following Reading settings from:
In that file (create it if necessary) add the line:
command.electron=/FULL_PATH/Electron.app/Contents/MacOS/Electron
where /FULL_PATH is the directory containing Electron.app.
just to report back
show the status
./bin/domterm status
DomTerm version 2.1.0 (git describe: 2.1-21-gd67794e)
Copyright 2020 Per Bothner and others
Using Libwebsockets 3.2.0
Reading settings from: /Users/bkb/.domterm/settings.ini
Backend command socket: /Users/bkb/.domterm/default.socket
session#: 1, pid: -1, tty: /dev/ttys012
(detached)
kill all domterm processes
~/l/d/DomTerm> pkill domterm
show domterm status
./bin/domterm status
[...]
(no domterm sessions or server)
show domterm settings
cat ~/.domterm/settings.ini
frontend.default = electron;chrome
command.firefox = /Applications/Firefox.app/Contents/MacOS/firefox
command.electron = /Users/bkb/local/domterm/Electron.app/Contents/MacOS/Electron
command.chrome = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
"Prove" that my settings look ok
pwd
/Users/bkb/local/domterm/DomTerm
ls ../
DomTerm Electron.app
ls /Users/bkb/local/domterm/Electron.app/Contents/MacOS/
Electron
reset the ~/.domterm directory
cp ~/.domterm/settings.ini .
[I] bkb@skyfall ~/l/d/DomTerm> rm -rf ~/.domterm/
[I] bkb@skyfall ~/l/d/DomTerm> mkdir -p ~/.domterm
[I] bkb@skyfall ~/l/d/DomTerm> cp settings.ini ~/.domterm/
try to run domterm without success
./bin/domterm
[I] bkb@skyfall ~/l/d/DomTerm> ./bin/domterm status
[I] bkb@skyfall ~/l/d/DomTerm> (no output)
domterm process is no running in the background
pgrep domterm
[I] bkb@skyfall ~/l/d/DomTerm> (no output)
g_"
When things get messed up, sometimes you have to manually kill the background domterm process. Try
ps ax|grep domterm|grep -v grepandkill(if need bekill -9) the listed processes.
For that matter I use: pgrep and pkill
Does DomTerm work if you use a regular browser instead of Electron? E.g.
./bin/domterm --browseror./bin/domterm --firefox.
Unfortunately no, nothing happens and the output of status is always:
/bin/domterm status
DomTerm version 2.1.0 (git describe: 2.1-21-gd67794e)
Copyright 2020 Per Bothner and others
Using Libwebsockets 3.2.0
Reading settings from: /Users/bkb/.domterm/settings.ini
(no domterm sessions or server)
I'm thinking of buying a used MacBook so I can test on Mac. Any recommendations for minimum os/hardware versions?
Here is what I use as my everyday machine:
MacBook Air (13-inch, Early 2015)
It runs ok
I added a --verbose option that reports some of what is going on. It works best with the --no-daemonize option. A second --verbose adds even more detail. If you run
bin/domterm --no-daemonize --verbose --verbose
that may give us some clues.
./bin/domterm --no-daemonize --verbose --chrome
Reading settings file: /Users/bkb/.domterm/settings.ini
connecting to server socket '/Users/bkb/.domterm/default.socket': No such file or directory
creating server socket: '/Users/bkb/.domterm/default.socket'
starting frontend command: "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" 'file:///Users/bkb/.domterm/default.html#session-number=1'
which again results in a blank page on chrome, so this doesn't yield new insights for me. But what I noticed, that no urls can resolved. So for example 'http://localhost:54195/hlib/domterm-client.js' results in a 404 page
Puzzling. For what it's worth, on my laptop:
[~]1092$ ls -l /home/bothner/.domterm/default.socket
srw-------. 1 bothner bothner 0 Jan 25 08:18 /home/bothner/.domterm/default.socket
[~]1093$ cat /home/bothner/.domterm/default.html
<!DOCTYPE html>
<html><head>
<meta http-equiv='Content-Type' content='text/html; charset=UTF-8'>
<script type='text/javascript'>
var DomTerm_server_key = 'h8X9SA0g9HknbP8hIR5W';
var newloc = 'http://localhost:33467/no-frames.html' + location.hash;
newloc += (newloc.indexOf('#') >= 0 ? '&' : '#')+'server-key=' + DomTerm_server_key;
location.replace(newloc);
</script>
</head>
<body></body></html>
[~]1094$
"But what I noticed, that no urls can resolved."
Hm. That seems like a good clue, though not sure how to track it down.
What is the version of libwebsockets - on mine it is 3.2.0. You could try building libwebsockets from source (as described in the manual).
I have decided to order a used MacBook Pro, but it will be a few weeks. (I want to order it so it is likely to arrive when we're not out of town.)
Sorry I just saw, that I've missed the second --verbose. If the url gets requested here is the output
....
http request: /hlib/browserkeymap.js
http request: /hlib/commands.js
http request: /hlib/wcwidth.js
http request: /hlib/FileSaver.js
http request: /hlib/ResizeSensor.js
http request: /hlib/jquery.min.js
http request: /hlib/goldenlayout.js
http request: /hlib/domterm-layout.js
http request: /hlib/domterm-menus.js
http request: /hlib/qwebchannel.js
http request: /hlib/jsMenus.js
http request: /hlib/screenfull.js
http request: /hlib/domterm-client.js
....
Adding --enable-compiled-in-resources to the configure command would be worth a try - but it seems to be broken right now. More soon ....
I need a little more context. What should be different with this configuration? I could build it, but I see no difference during runtime.
This might be helpful: a --debug switch that would result in printing out the webroot.
Sorry I was unclear - --enable-compiled-in-resources was broken until 5 minutes ago. I'm still working on related issues, but it works for me now (though not in conjunction with --with-closure_compiler which I'm still working on).
"What should be different with this configuration?"
Note you have to do a git pull and start over (including autoreconfig -i). If using --enable-compiled-in-resources then the .js and .css are compiled into the domterm executable (in the generated file lws-term/resources.c) instead of from domterm.js. This uses different functions in libwebsockets so might be more likely to work.
"This might be helpful: a --debug switch that would result in printing out the webroot."
I added some more output to the --verbose option.
Looking into integrating the --verbose output with the libwebsockets logging framework.
omg it (mostly[1]) runs
wow and finally I even have inline images, so cool!
It smoothly runs a terminal inside neovim whichs run in a fish shell inside tmux :-)
thanks!
[1]: domterm html crashes (json parse fail), but I might open a new issue for this
Great.
Slightly off-topic: DomTerm has a lot of tmux's functionality builtin. Is there something in particular you're missing?