- Dillo-dev - lists.mailman3.com

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, On Sat, Dec 20, 2025 at 01:24:55PM +0000, a1ex(a)dismail.de wrote: > > Hmm, I don't think I'm catching all possible errors from that > > socket. Maybe this patch can help: > > > > ---8<--- > > diff --git a/src/IO/control.c b/src/IO/control.c > > index 6f677e52..c6cd15bf 100644 > > --- a/src/IO/control.c > > +++ b/src/IO/control.c > > @@ -110,7 +110,7 @@ static void Control_read_cb(int fd, void *data) > > r = read(new_fd, buf, 1); > > _MSG("read = %zd\n", r); > > if (r < 0) { > > - if (errno == EINTR) { > > + if (errno == EINTR || errno == EAGAIN || errno == EWOULDBLOCK) { > > continue; > > } else { > > MSG_ERR("Control_read_cb %s\n", dStrerror(errno)); > > ---8<--- > > > > Let me know if that makes it work. > > Looks to be working now! Thanks for this very cool new feature, BTW! I took a closer look and it seems that this patch doesn't address the actual problem. The problem is that BSD inherits the non-blocking behavior while Linux doesn't (POSIX doesn't seem to indicate what should be done). We want the new_fd to work in blocking mode, so this patch should fix it for BSD and Linux (otherwise let me know): ---8<--- diff --git a/src/IO/control.c b/src/IO/control.c index 6f677e52..0d11187e 100644 --- a/src/IO/control.c +++ b/src/IO/control.c @@ -95,12 +95,30 @@ static void Control_read_cb(int fd, void *data) int new_fd = accept(control_fd, NULL, NULL); if (new_fd < 0) { - if (errno != EWOULDBLOCK) { - MSG("accept failed: %s\n", strerror(errno)); + if (errno == EAGAIN || errno == EWOULDBLOCK) { + /* Nothing? */ + return; + } else { + MSG_ERR("accept failed: %s\n", strerror(errno)); exit(1); } - /* Nothing? */ - return; + } + + /* From accept(2) man page: + * + * On Linux, the new socket returned by accept() does not inherit + * file status flags such as O_NONBLOCK and O_ASYNC from the + * listening socket. This behavior differs from the canonical BSD + * sockets implementation. Portable programs should not rely on + * inheritance or noninheritance of file status flags and always + * explicitly set all required flags on the socket returned from + * accept(). + * + * So, disable O_NONBLOCK flag explicitly. + */ + if (fcntl(new_fd, F_SETFL, 0) == -1) { + MSG_ERR("control socket fcntl failed: %s\n", strerror(errno)); + exit(1); } ssize_t r; ---8<--- Best, Rodrigo.

Dec. 20, 2025

Re: Remote control socket (experimental)

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > I have just merged the support to control dillo from a UNIX control > socket. There is now a new program called "dilloc" to send commands > from the CLI. If there is only one dillo process it will choose it, > otherwise it needs to be specified in the DILLO_PID env var. I just went to test this and ran into a possible issue. This is with a fully stock dillo build/install, running on OpenBSD 7.8 amd64: $ dillo -v Dillo Libraries: fltk/1.3.9 jpeg/3.1.2 png/1.6.50 webp/1.6.0 zlib/1.3.1.1-motley brotli/1.0.9 LibreSSL/4.2.0 Features: +GIF +JPEG +PNG +SVG +WEBP +BROTLI +XEMBED +TLS +IPV6 +CTL $ dillo paths: Creating directory '/home/user/.dillo/' paths: Cannot open file '/home/user/.dillo/dillorc': No such file or directory paths: Using /usr/local/etc/dillo/dillorc paths: Cannot open file '/home/user/.dillo/keysrc': No such file or directory paths: Using /usr/local/etc/dillo/keysrc paths: Cannot open file '/home/user/.dillo/domainrc': No such file or directory paths: Using /usr/local/etc/dillo/domainrc Domain: Default accept. dillo_dns_init: Here we go! (threaded) TLS library: LibreSSL 4.2.0 Cookies: Created file: /home/user/.dillo/cookiesrc Disabling cookies. paths: Cannot open file '/home/user/.dillo/hsts_preload': No such file or directory paths: Using /usr/local/etc/dillo/hsts_preload Nav_open_url: new url='about:splash' Dillo starts normally, then I do this: $ dilloc help Right away dillo exits and the console message shows this: ** ERROR **: Control_read_cb Resource temporarily unavailable This is with just one dillo process running, but I also tested with setting the DILLO_PID variable. That actually gives a working result for only one try, and then gives the error if you try again: $ dillo & [1] 12345 ... $ export DILLO_PID=12345 $ dilloc ping pong $ dilloc ping ** ERROR **: Control_read_cb Resource temporarily unavailable (dillo exits) I verified that the process ID remains unchanged and the variable is still set between dilloc runs, so I'm not sure what's going on. Happy to troubleshoot further if you have any suggestions. Regards, Alex

Dec. 20, 2025

Re: Remote control socket (experimental)

by Bobby Hiltz

That is exactly what happened. I didn't run dillo, I tried running `dilloc help` first. Like many errors, this one was between the keyboard and the chair.

Dec. 20, 2025

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, > Looks to be working now! Thanks for this very cool new feature, BTW! Nice! Let me know if you find some other problems. > PS. Any chance of adding an option to reload dillorc prefs too? :) That would be doable, but I'm not sure if we can just re-parse all settings as-is without propagating the new values to other parts of Dillo which might have made a copy. Which use case do you have in mind? For the user agent rotation? Best, Rodrigo.

Dec. 20, 2025

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, > Not a big deal, but I did need to manual make the ~/.dillo/ctl > directory. It is possible that I missed that part in the instructions. When running dillo it should create the directory on its own (let me know otherwise). But if you run dilloc first without the ctl directory, it will complain and exit: % dilloc ping error: cannot open /home/ram/.dillo/ctl directory: No such file or directory Even if the ctl directory is present but no dillo is found, it should fail with: % dilloc ping error: cannot find ctl socket, is dillo running? Maybe I can make the error message a bit more user friendly for the case when there is no directory. In any case, users should not need to create any directory. Best, Rodrigo.

Dec. 20, 2025

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, > Right away dillo exits and the console message shows this: > > ** ERROR **: Control_read_cb Resource temporarily unavailable Hmm, I don't think I'm catching all possible errors from that socket. Maybe this patch can help: ---8<--- diff --git a/src/IO/control.c b/src/IO/control.c index 6f677e52..c6cd15bf 100644 --- a/src/IO/control.c +++ b/src/IO/control.c @@ -110,7 +110,7 @@ static void Control_read_cb(int fd, void *data) r = read(new_fd, buf, 1); _MSG("read = %zd\n", r); if (r < 0) { - if (errno == EINTR) { + if (errno == EINTR || errno == EAGAIN || errno == EWOULDBLOCK) { continue; } else { MSG_ERR("Control_read_cb %s\n", dStrerror(errno)); ---8<--- Let me know if that makes it work. Best, Rodrigo.

Dec. 20, 2025

Re: Remote control socket (experimental)

by Bobby Hiltz

Hello, On Fri, 19 Dec 2025 18:29:03 +0100 Rodrigo Arias <rodarima(a)gmail.com> wrote: > I have just merged the support to control dillo from a UNIX control > socket. There is now a new program called "dilloc" to send commands > from the CLI. > ... > I think it will also be useful for users. I have been looking forward to this since I saw the demo on Mastodon. I am sure that I'll find a use. > Let me know if you find something that doesn't work well, it is > experimental for now. Not a big deal, but I did need to manual make the ~/.dillo/ctl directory. It is possible that I missed that part in the instructions. Best, Bobby Hiltz

Dec. 20, 2025

Remote control socket (experimental)

by Rodrigo Arias

Hi, I have just merged the support to control dillo from a UNIX control socket. There is now a new program called "dilloc" to send commands from the CLI. If there is only one dillo process it will choose it, otherwise it needs to be specified in the DILLO_PID env var. Use "dilloc help" to see all the commands available. It needs to be enabled at configure time with --enable-control-socket. The origin of this feature is to improve the test suite by controlling dillo automatically, but I think it will also be useful for users. In particular, the load and dump commands allow the manipulation of any loaded page as a UNIX pipeline: % dilloc dump | <manipulate-cmd> | dilloc load Or go to an alternative page from the current URL: % dilloc open $(dilloc url | sed 's/www\.reddit/old.reddit/') Let me know if you find something that doesn't work well, it is experimental for now. Best, Rodrigo.

Dec. 19, 2025

Re: CJK Fonts

by Bobby Hiltz

Hi, On Sun, 14 Dec 2025 22:49:56 +0000 <a1ex(a)dismail.de> wrote: > Do you have the desired font configured in ~/.dillo/dillorc ? > > Something like this should work (assuming you have the font available > in your OS): > > font_sans_serif="Noto Sans JP" Thanks. It is "Noto Sans CJK JP" on Debian like Rodrigo said. That will have to be my solution for those times I need to visit sites with Japanese (or other CJK fonts) until font substitution support is available. Best, Bobby

Dec. 15, 2025

Re: CJK Fonts

by a1ex＠dismail.de

Hi, "B Hiltz" <bbbhltz(a)mailbox.org> wrote: > I think I have compiled something wrong on my end. When visiting sites > with CJK fonts (e.g. > https://www.unicode.org/standard/translations/japanese.html) none of > the characters display (just empty blocks). Do you have the desired font configured in ~/.dillo/dillorc ? Something like this should work (assuming you have the font available in your OS): font_sans_serif="Noto Sans JP" Regards, Alex

Dec. 14, 2025