dasht-server in macOS renders a blank page

Hi,

I've just install dasht with Homebrew in macOS Catalina. Searching within dasht works great, I can navigate through all the docsets I've installed real quick.

However, when I run dash-server and use the URL in Firefox, it renders a blank page. It also happens in Safari. I even try with the suggested code from man page dasht-server | xargs -n1 w3m and it also directs to a black page in terminal.

Should I install everything that I'm missing to get the functionality?
Thank you in advance!

What happens if you replace w3m with curl in this command line?

dasht-server | xargs -n1 curl

Could you also try running dasht-server separately and then curl?

$ dasht-server &
[1] 4132
http://127.0.0.1:54321

$ curl http://127.0.0.1:54321
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
<!DOCTYPE html>
<html>
...

This is the output for the complete command the first time I run it:

curl: (7) Failed to connect to 127.0.0.1 port 54321: Connection refused

However, the second time I do it, I get a terminal waiting showing "socat" in the title bar.

When separately:

$ dasht-server &
[1] 1101
http://127.0.0.1:54321
$ curl http://127.0.0.1:54321
$

I thought it could be related to macOS firewall, so I added a green rule for dasht-server, but I get the same outcome.

I am having the same issues (search works great but not with server)
Could it be related to the version of socat ? I installed socat with brew

socat -V
socat by Gerhard Rieger and contributors - see www.dest-unreach.org
socat version 1.7.3.4 on Jan  6 2020 15:04:07
running on Darwin version Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64, release 18.7.0, machine x86_64
features:
  #define WITH_STDIO 1
  #define WITH_FDNUM 1
  #define WITH_FILE 1
  #define WITH_CREAT 1
  #define WITH_GOPEN 1
  #define WITH_TERMIOS 1
  #define WITH_PIPE 1
  #define WITH_UNIX 1
  #undef WITH_ABSTRACT_UNIXSOCKET
  #define WITH_IP4 1
  #define WITH_IP6 1
  #define WITH_RAWIP 1
  #define WITH_GENERICSOCKET 1
  #undef WITH_INTERFACE
  #define WITH_TCP 1
  #define WITH_UDP 1
  #define WITH_SCTP 1
  #define WITH_LISTEN 1
  #define WITH_SOCKS4 1
  #define WITH_SOCKS4A 1
  #define WITH_PROXY 1
  #define WITH_SYSTEM 1
  #define WITH_EXEC 1
  #define WITH_READLINE 1
  #undef WITH_TUN
  #define WITH_PTY 1
  #define WITH_OPENSSL 1
  #undef WITH_FIPS
  #undef WITH_LIBWRAP
  #define WITH_SYCLS 1
  #define WITH_FILAN 1
  #define WITH_RETRY 1
  #define WITH_MSGLEVEL 0 /*debug*/

I've noticed this problem as well, and I've been able to narrow it down to the grep call on this line:

dasht/bin/dasht-server-http

Line 78 in 5a741da

if ! echo "$url" | grep -q '^/$\|^/?'; then

You can reproduce the problem without socat:

printf 'GET / HTTP/1.1\r\n' | dasht-server-http
HTTP/1.0 400 Bad Request

For some reason the grep call doesn't capture the case where $url only contains "/".

I tried to install GNU Grep via Homebrew to see if that made any difference, but it doesn't change anything.
I did however get it working by splitting the two different search patterns out via grep -e '^/$' -e '^/?'. Would that be an acceptable fix? If so, I can make a PR to fix this.

Great find! 👌 Please check if using -E with an unescaped alternation works (instead of two -e flags):

grep -q -E '^/$|^/?'

And yes, please do submit a PR. 🙇 I'll be happy to merge it. Cheers!

Please check if using -E with an unescaped alternation works (instead of two -e flags)

More or less, I had to change the query slightly. I've made #54 with a fix.

Nice catch! I forgot to escape ? under extended regexp mode in my suggested example. 😅

I wonder: since escaping was responsible for this bug, perhaps \? is just another bug waiting to happen?

Maybe your double -e approach is the better (more portable) solution since it doesn't use any escaping. 🤔

Possibly! I find the double -e approach easier to read since the two patterns become more distinct.

I was also wondering if grep even is necessary. The "/" pattern can easily be checked with a string equality check, and I guess the other pattern could be checked the same way by only looking at the first two characters of the string.

Serendipity! 🎉 We're totally on the same wavelength. 🤓 Yes, let's try that:

if ! test "$url" = / -o -z "${url##/\?*}"; then

Thanks! I have updated the PR with that solution.