-
Notifications
You must be signed in to change notification settings - Fork 12
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
DONT WRITE BACK TO YOUR BIBTEX-FILE: custom fields are imported with column-names that includes the values in the fields...!! #38
Comments
Please note that your input
Please note that the tone of your posting is insulting, maybe unintentionally. You have given a good description of your problem, perceived or not, for the maintainers (I am not among them) to look at. And that should have been it. |
I don't agree with you that it's insultating - to you, perhaps, but not generally. Of course that's not my intention: I'm stating that this bug seems to be so severe, that it should not be used to write a .bib-file, since this bug will in all likehood scramble the original bib-input. This seems to me to be aa very important point to get through, before anybody wrecks something important. |
The ALL CAPS and double exclamation points in the title... so authoritative and you couldn't even bother to create a reproducible bug report. Your post is 'insultating' to any developer. I conclude your GitHub comments "shouldn't be used" EXCLAMATION MARKS!!!!!! |
This bug nearly ruined an important .bib file i was using, so the all caps and !! was with the intention of making sure nobody else ruined something important they were doing. I find your suggestion that I "didn't bother including a reprex" to be rude - I spent quite a bit of time figuring out what the error was, so I could post it here. But of course, if two different people both thinks I wrote the report in a rude manner, I will take that into consideration. There was no bad faith involved, however. The all caps and exclamation mark was probably a bad idea. |
Leaving aside other discussions, I think there is a fair point on here. I would propose to implement a mechanism for creating a backup of the bib file just in case something goes wrong. I already did this on cffr: https://github.com/ropensci/cffr/blob/855608c8f6d3d7da0180db3e978143a288b6558b/R/write_bib.R#L65:L79 # If exists creates a backup
if (file.exists(file)) {
for (i in seq(1, 100)) {
f <- paste0(file, ".bk", i)
if (!file.exists(f)) break
}
if (verbose) {
message(
"Creating a backup of ",
file, " in ", f
)
}
file.copy(file, f)
}
|
So I've been trying to use this function for a while, but when using it and writing the file back to disk with df2bib(), Jabref suddenly told me
I found this puzzling, and tried troubleshooting the error. While doing this, I then stumbled upon something where using the eprint field, a entry that looked like this (very minimal)
was transformed into this
This problem does not appear to related to issue with the empty text fields that I was actually investigating. This seems to be an issue related to the package only having a specific set of fields, and any not in that list will be parsed with the name of the values IN the field as part of the column names. This means that
Eprint
gets converted into
Eprint..1607.01759..
So there are two serious bugs here, and only one of them is immediatly reproducible. I give up for now :)
I conclude that this package should be used with caution, and you should definitely NOT write back into a bibtex file that you need for anything reliable.
The text was updated successfully, but these errors were encountered: