Open andrewcarver opened 6 years ago
The problem persisted following an upgrade of Ruby. Here is the trace I'm getting:
Traceback (most recent call last):
28: from C:/tools/ruby25/bin/asciidoctor:23:in '
@andrewcarver sorry for the late response.
Are we speaking of two problems:
I guess so. I was not aware, if it's true, that a citation in a comment block should not be checked. In any case, the error arises because 1) it checks this citation, and 2) it says it's not in the datafile, when in actuality it is. Uninstalling 0.8.0 (leaving 0.7.2 as my latest version), and leaving everything else the same, fixes it.
To shed a bit more light:
By the way, I HOPE that processing of citations within comments is a FEATURE, not a BUG! I really like it!!
I can tell you where the problem is arising for me; but, I'm not yet sure WHY it is:
It's in bibliographer_preprocessor.rb
, in the glob_pattern
method: the line
Dir.chdir(base_dir) { Dir.glob(pattern) }
is returning an empty array, even though the parameters the method received seem correct.
More specifically, the
Dir.glob(pattern)
bit is returning an empty array.
And the problem was in my pattern--to which Dir.glob()
took offense, regarding which way my slashes were leaning:
My pattern was ..\BibTeX_libraries\Biblical.bib
Dir.glob wants: ../BibTeX_libraries/Biblical.bib
So--the question is, should we force the Windows users to lean their slashes forward? Or is their some nice code-emendation that would catch that kind of pattern, and change the direction the user's slashes lean?
Here's a simple (perhaps too simple) fix:
Dir.chdir(base_dir) { Dir.glob(pattern.gsub( /\\/, '/')) }
That fixes my Windows-backslashes pattern... If you think that's a good idea (to start with, anyway), I can take this over to a new PR, and we can haggle over it there...
Uh-oh--THAT won't work: Dir.glob()
allows '\'
as an escape character...
"Note that this means you cannot use backslash on windows as part of a glob, i.e. Dir["c:\foo*"]
will not work, use Dir["c:/foo*"]
instead."
<ouch>
( http://ruby-doc.org/core-2.5.0/Dir.html )
Either we force the Windows users to lean their slashes forward, then; or, we force people not to escape metacharacters in their globs; or, ...??
Thanks @andrewcarver, your analysis is on point.
The problem here is that we'd like to allow globs (that's a must, I think), but Dir.glob
does not like \
. A possible solution is in #98 if you want to give it a spin. In essence, we can replace File::ALT_SEPARATOR
(that is, \
) only when the constant is defined (that is, on Win* systems). I think this is the solution with the leas amount of assumptions.
However, this brought to my attention another issue: we're using the space character as filename separator for bibliography-database
. Technically, that's a valid filename character for a filename. I'd rather put a warning in the readme saying to avoid it than write even more ad-hoc parsing. @ronaldtse I think that filenames containing spaces have not emerged as a common use case, so that should be enough.
I'm afraid that checking citations in block comments was a bug (fixed in 0.9.0
, see #75).
I'm also not sure why that would be a desirable feature. How were you using it @andrewcarver ?
I have now and then succumbed to the temptation to put relevant items in my bibliography that I've not actually cited anywhere -- but have read for research-purposes, and think them worth citing. (I believe that some other researchers are known to do this on occasion -- though it is forbidden in some scholarly contexts.) The only way to do this with asciidoctor-bibliography, of which I'm aware, was to cite the work(s) in a comment.
@paolobrasolin is there anything file “invalid” character we can rely on than a space? There are people who use this on Windows (plenty on Metanorma) that I am aware the issue will come up. As long as we have some way of handling spaces in filenames/directories, it’ll be fine.
@andrewcarver we got you covered, then! A couple of days ago version 0.10.0
introduced nocite
(see #97 and the readme) which allows you to do exactly that!
@ronaldtse I wouldn't go down that road. Reasoning about inter-os compatibility and validity of file names is a mess. Suffice it to say that the only two invalid characters (at filesystem level) in *nix are NUL
and /
. All others are valid and usually escaped only to let the shell interpret them literally.
Furthermore, I think that we need something that's both easy to read in the code and usable from the command line: setting bibliography-database
from the cli should not be a headache. For this reason delimiting filenames using single/double quotes doesn't sound good to me (once you need to interpolate some parameters on the CLI, quote nesting/escaping would be nasty).
Escaping literal (= non-delimiting) spaces looks like the cleanest solution to me. In fact, it's exactly what the shell does when handling filenames containing spaces.
# single file
:bibliography-database: foo.bib
asciidoctor ... -a bibliography-database=foo.bib
# multiple files
:bibliography-database: foo.bib bar.bib
asciidoctor ... -a bibliography-database='foo.bib bar.bib'
asciidoctor ... -a bibliography-database=foo.bib\ bar.bib # possible, wouldn't recommend
# filename contains space
:bibliography-database: the\ foo.bib
asciidoctor ... -a bibliography-database='the\ foo.bib'
asciidoctor ... -a bibliography-database="the\ foo.bib" # allows shell interpolation
# filename begins with space, contained in folder
:bibliography-database: the\\ foo.bib
asciidoctor ... -a bibliography-database='the\\ foo.bib'
asciidoctor ... -a bibliography-database="the\\\ foo.bib" # allows shell interpolation
As to whether this pattern would make sense on a win* shell, I'm still not 100% sure as I don't have one handy right now.
Folks, yesterday I updated from 0.7.2 to 0.8.0. It broke it: gave me an error that the first thng I cited was not in the database file (which it was). I uninstalled 0.8.0 (which put me back to 0.7.2), and everything worked.
I know I'm using a slightly older version of Ruby: ruby 2.4.2p198 (2017-09-14 revision 59899) [x64-mingw32] Could that be the issue? Thanks.
P.S. The citation about which it complained was in a comment block.