Return | |
##5 2017-01-19(Thu)15:28:16 (archived 2018-01-07(Sun)15:09:56) | |
_____________________________________________________________________ | |
so is this how Gopher search items work? | |
_____________________________________________________________________ | |
__[2017-01-19(Thu)15:41:01 #30]_______________________________________ | |
Yes, either ? or a tab character to separate the query from the | |
selector, ? lets you use queries in menu items where tab is already | |
used to separate fields | |
__[2017-01-22(Sun)16:58:00 #31]_______________________________________ | |
So can you do multiline posts? | |
__[2017-01-22(Sun)16:59:12 #32]_______________________________________ | |
Apparently not, everything following a newline in my last post | |
was swallowed... | |
__[2017-01-23(Mon)08:32:10 #33]_______________________________________ | |
Looks like that's the server treating | |
the same as in a selector... I think that's technically wrong but | |
using search items like this is such a kludge that it's probably | |
not uncommon. | |
__[2017-01-23(Mon)08:52:58 #34]_______________________________________ | |
are you using a Gopher client or netcat/telnet? I don't imagine | |
most clients allow for newlines in search queries anyway. | |
__[2017-01-25(Wed)10:55:27 #35]_______________________________________ | |
Ive | |
__[2017-01-25(Wed)10:58:40 #36]_______________________________________ | |
I've been piping stuff into netcat, yeah. I guess I should've | |
expected it when I didn't end my queries with | |
__[2017-01-25(Wed)11:05:55 #37]_______________________________________ | |
... | |
(whoops, forgot that you need to escape the backslash as well when | |
double quoting in the shell) and it still worked, but I figured | |
that was just netcat using SHUT_WR and the server making do. So | |
do embedded tabs work? test test | |
__[2017-01-25(Wed)11:10:20 #38]_______________________________________ | |
What the hell, and now it looks like the server interpreted my | |
CR-LF escapes. What's going on? | |
__[2017-01-25(Wed)12:37:24 #39]_______________________________________ | |
#37 wasn't the server, your tabs worked, but menu items (including | |
inline text) can't have tabs in them as tabs separate each part. As | |
for why | |
got turned in to a real | |
, that's a bad printf miss on my part! | |
__[2017-01-27(Fri)16:38:17 #40]_______________________________________ | |
Will have to try and document this later, but if you send text | |
encoded with base64 as the query to /chan/<thread>/postb64 it will | |
preserve formatting/newlines. | |
Like this. | |
I don't know how compatible this is with most Gopher servers, | |
but Bucktooth is apparently fine with long (>256 characters) | |
selectors. This way you're still technically posting over Gopher (vs | |
using telnet like Gopherchan) but have more control over formatting. | |
You can also put links in a post this way, by formatting them like: | |
0Testing<TAB>/rfc1436.txt<TAB>khzai.net<TAB>70 | |
Testing | |
Not sure if there's much use adding a Reply... link in threads for | |
this, most Gopher clients I've used will truncate a query to 256 | |
characters, so this will have to be done in a script, e.g.: | |
echo "/chan/<thread id>/postb64?$(base64 -w 0) | nc khzai.net 70 | |
which would read from stdin, convert that to base64 (-w 0 because | |
can't send newlines), and post it to the thread. | |
__[2017-01-28(Sat)09:54:52 #41]_______________________________________ | |
Let me try it out as well: | |
Indented text | |
Reply to this post | |
Some more text | |
__[2017-01-28(Sat)09:59:15 #42]_______________________________________ | |
Tab-indented text doesn't appear to work... | |
__[2017-01-28(Sat)12:27:13 #43]_______________________________________ | |
Lines with tabs are interpreted as Gopher items, perhaps it can | |
be made "smarter" to detect non-valid lines and convert those tabs | |
to spaces like in #37 and treat them like normal text lines. Tabs | |
ultimately can't appear in a Gopher menu since they are the separator | |
for each field in a line. | |