-
Notifications
You must be signed in to change notification settings - Fork 4
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.
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
Shell error in generated docs #43
Comments
Yikes. The @oubiwann and anyone else reading this, do you have experience writing a Haskell port? Can it be done? Or, is there a better, more platform-independent way to "shell out" to |
Hrm, I think At the risk of throwing more engineering at the problem, it may be worth setting up lodox to use logjam ... this would allow for easier debugging be interested parties. If you like that idea, we can open a feature ticket, and I'll get that running so that this issue (and future ones) may be more easily debugged ... it will mean adding an |
logjam could be cool. |
Re: breaking up thrushing. Something like the following should get the job done. (At work now, so I can't fully dive in...) (->> `[,pandoc ,(escape markdown)]
(doto (io_lib:format "~s -f markdown_github -t html <<< \"~s\"")
(->> (list) (io:fwrite "** PANDOC CMD: ~p~n")))
(lists:flatten)
(os:cmd)) |
Oooh, that sounds interesting. I'd like to see that in action! |
Okay, so two problems, one minor.
(io_lib:format "~s -f markdown_github -t html <<< \"~s\"") needs to be changed to this: (io_lib:format "~s -f markdown_github -t html <<< '~s'") That will prevent Bash from barfind on parens that are in the here-string.
Some examples will illustrate the problem. Current, broken (on Linux) behaviour: > (os:cmd "/usr/bin/pandoc -f markdown_github -t html <<< '\\`\\`\\`commonlisp\n(_SRS)\n\\`\\`\\`'")
"/bin/sh: 1: Syntax error: redirection unexpected\n" Getting it to work with > (os:cmd "bash -c \"/usr/bin/pandoc -f markdown_github -t html <<< '\\`\\`\\`commonlisp\n(_SRS)\n\\`\\`\\`'\"")
"<pre class=\"sourceCode commonlisp\">
<code class=\"sourceCode commonlisp\">(_SRS)</code>
</pre>\n" Parameterizing the > (set cmd "/usr/bin/pandoc -f markdown_github -t html <<< '\\`\\`\\`commonlisp\n(_SRS)\n\\`\\`\\`'")
"/usr/bin/pandoc -f markdown_github -t html <<< '\\`\\`\\`commonlisp\n(_SRS)\n\\`\\`\\`'"
> (os:cmd (lists:flatten (io_lib:format "bash -c ~s" `(,cmd))))
"/bin/sh: 1: Syntax error: redirection unexpected\n"
> (os:cmd (++ "bash -c \"" cmd "\""))
"<pre class=\"sourceCode commonlisp\">
<code class=\"sourceCode commonlisp\">(_SRS)</code>
</pre>\n" I'm not submitting a patch for this due to the fact that there are all sorts of ways one might solve this, but the most obvious that works (appending strings) breaks your style (e.g., you won't be able to use the The approach that I might take would be to define |
This required hacking the lodox source to support Linux. I used the approach outlined in this bug report: * quasiquoting/lodox#43
Thanks for looking into it further. Seems like a tricky, platform specific issue.. It seems like writing to temp files would work but that's kind of a last resort. I may explore writing a Haskell port since that sounds fun anyway. Maybe a cone on host type with platform-specific solutions will suffice for now. |
👍 for bash-cmd for now though. |
(io_lib:format "~s -f markdown_github -t html <<< '~s'") breaks code blocks and more, for me. |
TIL here strings write to a temporary file anyway, so I'm doing it manually with some promising initial success. |
^ includes some config overhaul see I'm not married to |
Pasted example for convenience: {lodox,
[{apps,
[{lodox,
[{'source-uri',
"https://github.com/quasiquoting/lodox/blob/{version}/{filepath}#L{line}"},
{'output-path', "relative/path/to/output"}]}]}]}. N.B. |
|
So, I spoke too soon about the docs I had generated for the lgeo project :-(
Turns out all the docstrings are rendered with this error instead of the actual docstrings:
Here's a screenshot:
Note that I'm running on Linux, not Mac OS X ... (there are differences in how they handle redirection).
The text was updated successfully, but these errors were encountered: