Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

dasht-server in macOS renders a blank page #51

Open
alazarolop opened this issue Jun 15, 2020 · 10 comments
Open

dasht-server in macOS renders a blank page #51

alazarolop opened this issue Jun 15, 2020 · 10 comments
Labels
help wanted question

Comments

@alazarolop
Copy link

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!
@alazarolop alazarolop changed the title dasht-server in macOS render a blank page dasht-server in macOS renders a blank page Jun 15, 2020
@sunaku
Copy link
Owner

sunaku commented Jun 18, 2020

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>
...

@sunaku sunaku added question and removed question labels Jun 18, 2020
@alazarolop
Copy link
Author

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.

@Dvisacker
Copy link

Dvisacker commented Oct 30, 2020 •
edited

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*/

@Tenzer
Copy link
Contributor

Tenzer commented Nov 19, 2020

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.

@sunaku
Copy link
Owner

sunaku commented Nov 20, 2020

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!

@Tenzer Tenzer mentioned this issue Nov 20, 2020
Merged
@Tenzer
Copy link
Contributor

Tenzer commented Nov 20, 2020

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.

@sunaku
Copy link
Owner

sunaku commented Nov 21, 2020

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. 🤔

@Tenzer
Copy link
Contributor

Tenzer commented Nov 21, 2020

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.

@sunaku
Copy link
Owner

sunaku commented Nov 21, 2020 •
edited

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

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

@Tenzer
Copy link
Contributor

Tenzer commented Nov 21, 2020

Thanks! I have updated the PR with that solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@sunaku @Tenzer @Dvisacker @alazarolop