Why does biber segfault using a macro in the author field?
up vote
2
down vote
favorite
Before I updated my TexLive2018 (Win7-64bit, Texstudio) 5 minutes ago, the following code compiled fine:
documentclass[12pt]{article}
usepackage{filecontents}
begin{filecontents}{bib.bib}
@book{authorA20,
author = {Author, A.},
translator = {Translator, A.},
title = {These and that},
subtitle = {Nothing special},
volume = 1,
location = {Here and there},
publisher = {Who knows},
year = {2020},
isbn = {978-0-000-00000-2},
}
@book{buthorB22,
author = {authorSn, authorGivenname},
shorthand = {volTwoShorthand},
translator = {volTwoTranslator},
title = {volTwoTitle},
subtitle = {volTwoSubtitle},
volume = {volTwoNumber},
location = {volTwoLocation},
publisher = {volTwoPublisher},
year = {volTwoYear},
isbn = {volTwoIsbn},
}
end{filecontents}
usepackage{xstring} %<- provides StrLeft/-Right (s. below)
newcommand{authorSn}{Buthor}
newcommand{authorGivenname}{B.}
newcommand{volTwoTranslator}{Translator, B.}
newcommand{volTwoTitle}{These and that}
newcommand{volTwoSubtitle}{Nothing special}
newcommand{volTwoNumber}{2}
newcommand{volTwoLocation}{Here and there}
newcommand{volTwoPublisher}{Who knows}
newcommand{volTwoYear}{2022}
newcommand{volTwoShorthand}{StrLeft{authorSn}{3}%
StrRight{volTwoYear}{2}}
newcommand{volTwoIsbn}{978-1-111-11111-1}
usepackage[style=alphabetic]{biblatex}
addbibresource{bib.bib}
begin{document}
Wow cite{authorA20}!
Crazy cite{buthorB22}!
printbibliography
end{document}
After the update, biber 2.12 reproducible segfaults. I don't know exactly what biber version I've used before (my previous updated was some time ago, in this summer).
The problematic field seems to be author = {authorSn, authorGivenname}
. If I replace this field using hard coded values, e.g. author = {Bauthor, B.}
the compilation succeeds, with obvious - in my opinion harmless - warnings.
Running biber --tool --validate-datamodel bib.bib
SEGV, too.
biblatex biber
|
show 10 more comments
up vote
2
down vote
favorite
Before I updated my TexLive2018 (Win7-64bit, Texstudio) 5 minutes ago, the following code compiled fine:
documentclass[12pt]{article}
usepackage{filecontents}
begin{filecontents}{bib.bib}
@book{authorA20,
author = {Author, A.},
translator = {Translator, A.},
title = {These and that},
subtitle = {Nothing special},
volume = 1,
location = {Here and there},
publisher = {Who knows},
year = {2020},
isbn = {978-0-000-00000-2},
}
@book{buthorB22,
author = {authorSn, authorGivenname},
shorthand = {volTwoShorthand},
translator = {volTwoTranslator},
title = {volTwoTitle},
subtitle = {volTwoSubtitle},
volume = {volTwoNumber},
location = {volTwoLocation},
publisher = {volTwoPublisher},
year = {volTwoYear},
isbn = {volTwoIsbn},
}
end{filecontents}
usepackage{xstring} %<- provides StrLeft/-Right (s. below)
newcommand{authorSn}{Buthor}
newcommand{authorGivenname}{B.}
newcommand{volTwoTranslator}{Translator, B.}
newcommand{volTwoTitle}{These and that}
newcommand{volTwoSubtitle}{Nothing special}
newcommand{volTwoNumber}{2}
newcommand{volTwoLocation}{Here and there}
newcommand{volTwoPublisher}{Who knows}
newcommand{volTwoYear}{2022}
newcommand{volTwoShorthand}{StrLeft{authorSn}{3}%
StrRight{volTwoYear}{2}}
newcommand{volTwoIsbn}{978-1-111-11111-1}
usepackage[style=alphabetic]{biblatex}
addbibresource{bib.bib}
begin{document}
Wow cite{authorA20}!
Crazy cite{buthorB22}!
printbibliography
end{document}
After the update, biber 2.12 reproducible segfaults. I don't know exactly what biber version I've used before (my previous updated was some time ago, in this summer).
The problematic field seems to be author = {authorSn, authorGivenname}
. If I replace this field using hard coded values, e.g. author = {Bauthor, B.}
the compilation succeeds, with obvious - in my opinion harmless - warnings.
Running biber --tool --validate-datamodel bib.bib
SEGV, too.
biblatex biber
2
You'll have to wait for someone more knowledgeable to explain what has changed for this new behavior. But, in the meantime, you could tryauthor = {relaxauthorSn, relaxauthorGivenname}
. You will still continue to receive warnings on youryear
andisbn
fields though.
– gusbrs
Nov 25 at 23:36
1
@gusbrs Thanks a lot for this workaround - seems to work fine. Now I'm completely relaxed. ;-)
– lAtExFaN
Nov 25 at 23:43
1
Well, don't get too comfy. You are indeed stretching what biber expects there. As you see, even when it runs, sorting seems wrong. Do you have a strong reason to use this?
– gusbrs
Nov 25 at 23:53
1
Well, that's a good requirement in general, I concur. But usually there's more than one way to achieve it. You could invert the logic here, you could call the data from the bibentry to fill in your macros, and then use them in the other places you need. If you think that might be an alternative, extend your MWE to show some use cases of the macros elsewhere, and I see what can do.
– gusbrs
Nov 26 at 0:06
4
how can biber possibly sort the bibliography without having access to the names? (it shouldn't segfault of course but it can't work)
– David Carlisle
Nov 26 at 0:22
|
show 10 more comments
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Before I updated my TexLive2018 (Win7-64bit, Texstudio) 5 minutes ago, the following code compiled fine:
documentclass[12pt]{article}
usepackage{filecontents}
begin{filecontents}{bib.bib}
@book{authorA20,
author = {Author, A.},
translator = {Translator, A.},
title = {These and that},
subtitle = {Nothing special},
volume = 1,
location = {Here and there},
publisher = {Who knows},
year = {2020},
isbn = {978-0-000-00000-2},
}
@book{buthorB22,
author = {authorSn, authorGivenname},
shorthand = {volTwoShorthand},
translator = {volTwoTranslator},
title = {volTwoTitle},
subtitle = {volTwoSubtitle},
volume = {volTwoNumber},
location = {volTwoLocation},
publisher = {volTwoPublisher},
year = {volTwoYear},
isbn = {volTwoIsbn},
}
end{filecontents}
usepackage{xstring} %<- provides StrLeft/-Right (s. below)
newcommand{authorSn}{Buthor}
newcommand{authorGivenname}{B.}
newcommand{volTwoTranslator}{Translator, B.}
newcommand{volTwoTitle}{These and that}
newcommand{volTwoSubtitle}{Nothing special}
newcommand{volTwoNumber}{2}
newcommand{volTwoLocation}{Here and there}
newcommand{volTwoPublisher}{Who knows}
newcommand{volTwoYear}{2022}
newcommand{volTwoShorthand}{StrLeft{authorSn}{3}%
StrRight{volTwoYear}{2}}
newcommand{volTwoIsbn}{978-1-111-11111-1}
usepackage[style=alphabetic]{biblatex}
addbibresource{bib.bib}
begin{document}
Wow cite{authorA20}!
Crazy cite{buthorB22}!
printbibliography
end{document}
After the update, biber 2.12 reproducible segfaults. I don't know exactly what biber version I've used before (my previous updated was some time ago, in this summer).
The problematic field seems to be author = {authorSn, authorGivenname}
. If I replace this field using hard coded values, e.g. author = {Bauthor, B.}
the compilation succeeds, with obvious - in my opinion harmless - warnings.
Running biber --tool --validate-datamodel bib.bib
SEGV, too.
biblatex biber
Before I updated my TexLive2018 (Win7-64bit, Texstudio) 5 minutes ago, the following code compiled fine:
documentclass[12pt]{article}
usepackage{filecontents}
begin{filecontents}{bib.bib}
@book{authorA20,
author = {Author, A.},
translator = {Translator, A.},
title = {These and that},
subtitle = {Nothing special},
volume = 1,
location = {Here and there},
publisher = {Who knows},
year = {2020},
isbn = {978-0-000-00000-2},
}
@book{buthorB22,
author = {authorSn, authorGivenname},
shorthand = {volTwoShorthand},
translator = {volTwoTranslator},
title = {volTwoTitle},
subtitle = {volTwoSubtitle},
volume = {volTwoNumber},
location = {volTwoLocation},
publisher = {volTwoPublisher},
year = {volTwoYear},
isbn = {volTwoIsbn},
}
end{filecontents}
usepackage{xstring} %<- provides StrLeft/-Right (s. below)
newcommand{authorSn}{Buthor}
newcommand{authorGivenname}{B.}
newcommand{volTwoTranslator}{Translator, B.}
newcommand{volTwoTitle}{These and that}
newcommand{volTwoSubtitle}{Nothing special}
newcommand{volTwoNumber}{2}
newcommand{volTwoLocation}{Here and there}
newcommand{volTwoPublisher}{Who knows}
newcommand{volTwoYear}{2022}
newcommand{volTwoShorthand}{StrLeft{authorSn}{3}%
StrRight{volTwoYear}{2}}
newcommand{volTwoIsbn}{978-1-111-11111-1}
usepackage[style=alphabetic]{biblatex}
addbibresource{bib.bib}
begin{document}
Wow cite{authorA20}!
Crazy cite{buthorB22}!
printbibliography
end{document}
After the update, biber 2.12 reproducible segfaults. I don't know exactly what biber version I've used before (my previous updated was some time ago, in this summer).
The problematic field seems to be author = {authorSn, authorGivenname}
. If I replace this field using hard coded values, e.g. author = {Bauthor, B.}
the compilation succeeds, with obvious - in my opinion harmless - warnings.
Running biber --tool --validate-datamodel bib.bib
SEGV, too.
biblatex biber
biblatex biber
edited Nov 25 at 23:34
asked Nov 25 at 23:25
lAtExFaN
567418
567418
2
You'll have to wait for someone more knowledgeable to explain what has changed for this new behavior. But, in the meantime, you could tryauthor = {relaxauthorSn, relaxauthorGivenname}
. You will still continue to receive warnings on youryear
andisbn
fields though.
– gusbrs
Nov 25 at 23:36
1
@gusbrs Thanks a lot for this workaround - seems to work fine. Now I'm completely relaxed. ;-)
– lAtExFaN
Nov 25 at 23:43
1
Well, don't get too comfy. You are indeed stretching what biber expects there. As you see, even when it runs, sorting seems wrong. Do you have a strong reason to use this?
– gusbrs
Nov 25 at 23:53
1
Well, that's a good requirement in general, I concur. But usually there's more than one way to achieve it. You could invert the logic here, you could call the data from the bibentry to fill in your macros, and then use them in the other places you need. If you think that might be an alternative, extend your MWE to show some use cases of the macros elsewhere, and I see what can do.
– gusbrs
Nov 26 at 0:06
4
how can biber possibly sort the bibliography without having access to the names? (it shouldn't segfault of course but it can't work)
– David Carlisle
Nov 26 at 0:22
|
show 10 more comments
2
You'll have to wait for someone more knowledgeable to explain what has changed for this new behavior. But, in the meantime, you could tryauthor = {relaxauthorSn, relaxauthorGivenname}
. You will still continue to receive warnings on youryear
andisbn
fields though.
– gusbrs
Nov 25 at 23:36
1
@gusbrs Thanks a lot for this workaround - seems to work fine. Now I'm completely relaxed. ;-)
– lAtExFaN
Nov 25 at 23:43
1
Well, don't get too comfy. You are indeed stretching what biber expects there. As you see, even when it runs, sorting seems wrong. Do you have a strong reason to use this?
– gusbrs
Nov 25 at 23:53
1
Well, that's a good requirement in general, I concur. But usually there's more than one way to achieve it. You could invert the logic here, you could call the data from the bibentry to fill in your macros, and then use them in the other places you need. If you think that might be an alternative, extend your MWE to show some use cases of the macros elsewhere, and I see what can do.
– gusbrs
Nov 26 at 0:06
4
how can biber possibly sort the bibliography without having access to the names? (it shouldn't segfault of course but it can't work)
– David Carlisle
Nov 26 at 0:22
2
2
You'll have to wait for someone more knowledgeable to explain what has changed for this new behavior. But, in the meantime, you could try
author = {relaxauthorSn, relaxauthorGivenname}
. You will still continue to receive warnings on your year
and isbn
fields though.– gusbrs
Nov 25 at 23:36
You'll have to wait for someone more knowledgeable to explain what has changed for this new behavior. But, in the meantime, you could try
author = {relaxauthorSn, relaxauthorGivenname}
. You will still continue to receive warnings on your year
and isbn
fields though.– gusbrs
Nov 25 at 23:36
1
1
@gusbrs Thanks a lot for this workaround - seems to work fine. Now I'm completely relaxed. ;-)
– lAtExFaN
Nov 25 at 23:43
@gusbrs Thanks a lot for this workaround - seems to work fine. Now I'm completely relaxed. ;-)
– lAtExFaN
Nov 25 at 23:43
1
1
Well, don't get too comfy. You are indeed stretching what biber expects there. As you see, even when it runs, sorting seems wrong. Do you have a strong reason to use this?
– gusbrs
Nov 25 at 23:53
Well, don't get too comfy. You are indeed stretching what biber expects there. As you see, even when it runs, sorting seems wrong. Do you have a strong reason to use this?
– gusbrs
Nov 25 at 23:53
1
1
Well, that's a good requirement in general, I concur. But usually there's more than one way to achieve it. You could invert the logic here, you could call the data from the bibentry to fill in your macros, and then use them in the other places you need. If you think that might be an alternative, extend your MWE to show some use cases of the macros elsewhere, and I see what can do.
– gusbrs
Nov 26 at 0:06
Well, that's a good requirement in general, I concur. But usually there's more than one way to achieve it. You could invert the logic here, you could call the data from the bibentry to fill in your macros, and then use them in the other places you need. If you think that might be an alternative, extend your MWE to show some use cases of the macros elsewhere, and I see what can do.
– gusbrs
Nov 26 at 0:06
4
4
how can biber possibly sort the bibliography without having access to the names? (it shouldn't segfault of course but it can't work)
– David Carlisle
Nov 26 at 0:22
how can biber possibly sort the bibliography without having access to the names? (it shouldn't segfault of course but it can't work)
– David Carlisle
Nov 26 at 0:22
|
show 10 more comments
1 Answer
1
active
oldest
votes
up vote
5
down vote
accepted
Interestingly on my machine I can reproduce the segfault (I don't get any error report, Biber just dies and does not write a .bbl
) in about 70% of runs, while the other 30% compile just fine (with slightly weird data in the .bbl
: family={volTwoTranslator}, familyi={rbibinitperiod}
).
You can and should probably report this at https://github.com/plk/biber/issues (Stackexchange is not a bug tracker), but it might turn out that there is no good way to solve this in Biber. Biber relies on the Perl module Text::BibTeX, which in term delegates its work to the C library btparse
. Catching errors (especially segfaults) from that module sometimes proves a little difficult.
In this case it seems that the code to parse names, in particular the code that deals with name initials, is ill-equipped to deal with a name that consists only of macros. Remember that Biber does not know LaTeX, which means that it does not expand/unpack macro definitions (except in very specific, hard-coded cases). At the same time Biber needs access to the proper string values of fields to do its job: Sorting can only be performed as expected if Biber really knows the expansion of the macros and not just their name. And – this is the issue here – initials can only be generated from names if their string values are known.
There are two workaround that I can think of.
As mentioned by gusbrs in the comments already, use
relax
in theauthor
field:relax
can be used as a marker for BibTeX/btparse
in names to tell it to parse the current bit of the name differently.
author = {relaxauthorSn, relaxauthorGivenname},
compiles to
family={relaxauthorSn},
familyi={\bibinitperiod},
given={relaxauthorGivenname},
giveni={\bibinitperiod}}}%
which is still wrong, but at least does not let Biber die.
BibTeX treats groups in names that start with a control sequence as one character, which means that
{'E}cole
would be abbreviated as{'E}
and not as{'}
or{E}
or something else. In BibTeX this allows for the neat trick{relax Th}omas
to get "Th." as name initial (this no longer works in Biber).
You can turn off the calculation of initials by giving them yourself with the extended name format.
author = {family={authorSn}, given={authorGivenname},
family-i={authorSn}, given-i={authorGivenname}},
compiles to
family={authorSn},
familyi={authorSnbibinitperiod},
given={authorGivenname},
giveni={authorGivennamebibinitperiod}}}%
still not great, but better than nothing.
Of course you could give the real initials explicitly if you determine them yourself beforehand.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
Interestingly on my machine I can reproduce the segfault (I don't get any error report, Biber just dies and does not write a .bbl
) in about 70% of runs, while the other 30% compile just fine (with slightly weird data in the .bbl
: family={volTwoTranslator}, familyi={rbibinitperiod}
).
You can and should probably report this at https://github.com/plk/biber/issues (Stackexchange is not a bug tracker), but it might turn out that there is no good way to solve this in Biber. Biber relies on the Perl module Text::BibTeX, which in term delegates its work to the C library btparse
. Catching errors (especially segfaults) from that module sometimes proves a little difficult.
In this case it seems that the code to parse names, in particular the code that deals with name initials, is ill-equipped to deal with a name that consists only of macros. Remember that Biber does not know LaTeX, which means that it does not expand/unpack macro definitions (except in very specific, hard-coded cases). At the same time Biber needs access to the proper string values of fields to do its job: Sorting can only be performed as expected if Biber really knows the expansion of the macros and not just their name. And – this is the issue here – initials can only be generated from names if their string values are known.
There are two workaround that I can think of.
As mentioned by gusbrs in the comments already, use
relax
in theauthor
field:relax
can be used as a marker for BibTeX/btparse
in names to tell it to parse the current bit of the name differently.
author = {relaxauthorSn, relaxauthorGivenname},
compiles to
family={relaxauthorSn},
familyi={\bibinitperiod},
given={relaxauthorGivenname},
giveni={\bibinitperiod}}}%
which is still wrong, but at least does not let Biber die.
BibTeX treats groups in names that start with a control sequence as one character, which means that
{'E}cole
would be abbreviated as{'E}
and not as{'}
or{E}
or something else. In BibTeX this allows for the neat trick{relax Th}omas
to get "Th." as name initial (this no longer works in Biber).
You can turn off the calculation of initials by giving them yourself with the extended name format.
author = {family={authorSn}, given={authorGivenname},
family-i={authorSn}, given-i={authorGivenname}},
compiles to
family={authorSn},
familyi={authorSnbibinitperiod},
given={authorGivenname},
giveni={authorGivennamebibinitperiod}}}%
still not great, but better than nothing.
Of course you could give the real initials explicitly if you determine them yourself beforehand.
add a comment |
up vote
5
down vote
accepted
Interestingly on my machine I can reproduce the segfault (I don't get any error report, Biber just dies and does not write a .bbl
) in about 70% of runs, while the other 30% compile just fine (with slightly weird data in the .bbl
: family={volTwoTranslator}, familyi={rbibinitperiod}
).
You can and should probably report this at https://github.com/plk/biber/issues (Stackexchange is not a bug tracker), but it might turn out that there is no good way to solve this in Biber. Biber relies on the Perl module Text::BibTeX, which in term delegates its work to the C library btparse
. Catching errors (especially segfaults) from that module sometimes proves a little difficult.
In this case it seems that the code to parse names, in particular the code that deals with name initials, is ill-equipped to deal with a name that consists only of macros. Remember that Biber does not know LaTeX, which means that it does not expand/unpack macro definitions (except in very specific, hard-coded cases). At the same time Biber needs access to the proper string values of fields to do its job: Sorting can only be performed as expected if Biber really knows the expansion of the macros and not just their name. And – this is the issue here – initials can only be generated from names if their string values are known.
There are two workaround that I can think of.
As mentioned by gusbrs in the comments already, use
relax
in theauthor
field:relax
can be used as a marker for BibTeX/btparse
in names to tell it to parse the current bit of the name differently.
author = {relaxauthorSn, relaxauthorGivenname},
compiles to
family={relaxauthorSn},
familyi={\bibinitperiod},
given={relaxauthorGivenname},
giveni={\bibinitperiod}}}%
which is still wrong, but at least does not let Biber die.
BibTeX treats groups in names that start with a control sequence as one character, which means that
{'E}cole
would be abbreviated as{'E}
and not as{'}
or{E}
or something else. In BibTeX this allows for the neat trick{relax Th}omas
to get "Th." as name initial (this no longer works in Biber).
You can turn off the calculation of initials by giving them yourself with the extended name format.
author = {family={authorSn}, given={authorGivenname},
family-i={authorSn}, given-i={authorGivenname}},
compiles to
family={authorSn},
familyi={authorSnbibinitperiod},
given={authorGivenname},
giveni={authorGivennamebibinitperiod}}}%
still not great, but better than nothing.
Of course you could give the real initials explicitly if you determine them yourself beforehand.
add a comment |
up vote
5
down vote
accepted
up vote
5
down vote
accepted
Interestingly on my machine I can reproduce the segfault (I don't get any error report, Biber just dies and does not write a .bbl
) in about 70% of runs, while the other 30% compile just fine (with slightly weird data in the .bbl
: family={volTwoTranslator}, familyi={rbibinitperiod}
).
You can and should probably report this at https://github.com/plk/biber/issues (Stackexchange is not a bug tracker), but it might turn out that there is no good way to solve this in Biber. Biber relies on the Perl module Text::BibTeX, which in term delegates its work to the C library btparse
. Catching errors (especially segfaults) from that module sometimes proves a little difficult.
In this case it seems that the code to parse names, in particular the code that deals with name initials, is ill-equipped to deal with a name that consists only of macros. Remember that Biber does not know LaTeX, which means that it does not expand/unpack macro definitions (except in very specific, hard-coded cases). At the same time Biber needs access to the proper string values of fields to do its job: Sorting can only be performed as expected if Biber really knows the expansion of the macros and not just their name. And – this is the issue here – initials can only be generated from names if their string values are known.
There are two workaround that I can think of.
As mentioned by gusbrs in the comments already, use
relax
in theauthor
field:relax
can be used as a marker for BibTeX/btparse
in names to tell it to parse the current bit of the name differently.
author = {relaxauthorSn, relaxauthorGivenname},
compiles to
family={relaxauthorSn},
familyi={\bibinitperiod},
given={relaxauthorGivenname},
giveni={\bibinitperiod}}}%
which is still wrong, but at least does not let Biber die.
BibTeX treats groups in names that start with a control sequence as one character, which means that
{'E}cole
would be abbreviated as{'E}
and not as{'}
or{E}
or something else. In BibTeX this allows for the neat trick{relax Th}omas
to get "Th." as name initial (this no longer works in Biber).
You can turn off the calculation of initials by giving them yourself with the extended name format.
author = {family={authorSn}, given={authorGivenname},
family-i={authorSn}, given-i={authorGivenname}},
compiles to
family={authorSn},
familyi={authorSnbibinitperiod},
given={authorGivenname},
giveni={authorGivennamebibinitperiod}}}%
still not great, but better than nothing.
Of course you could give the real initials explicitly if you determine them yourself beforehand.
Interestingly on my machine I can reproduce the segfault (I don't get any error report, Biber just dies and does not write a .bbl
) in about 70% of runs, while the other 30% compile just fine (with slightly weird data in the .bbl
: family={volTwoTranslator}, familyi={rbibinitperiod}
).
You can and should probably report this at https://github.com/plk/biber/issues (Stackexchange is not a bug tracker), but it might turn out that there is no good way to solve this in Biber. Biber relies on the Perl module Text::BibTeX, which in term delegates its work to the C library btparse
. Catching errors (especially segfaults) from that module sometimes proves a little difficult.
In this case it seems that the code to parse names, in particular the code that deals with name initials, is ill-equipped to deal with a name that consists only of macros. Remember that Biber does not know LaTeX, which means that it does not expand/unpack macro definitions (except in very specific, hard-coded cases). At the same time Biber needs access to the proper string values of fields to do its job: Sorting can only be performed as expected if Biber really knows the expansion of the macros and not just their name. And – this is the issue here – initials can only be generated from names if their string values are known.
There are two workaround that I can think of.
As mentioned by gusbrs in the comments already, use
relax
in theauthor
field:relax
can be used as a marker for BibTeX/btparse
in names to tell it to parse the current bit of the name differently.
author = {relaxauthorSn, relaxauthorGivenname},
compiles to
family={relaxauthorSn},
familyi={\bibinitperiod},
given={relaxauthorGivenname},
giveni={\bibinitperiod}}}%
which is still wrong, but at least does not let Biber die.
BibTeX treats groups in names that start with a control sequence as one character, which means that
{'E}cole
would be abbreviated as{'E}
and not as{'}
or{E}
or something else. In BibTeX this allows for the neat trick{relax Th}omas
to get "Th." as name initial (this no longer works in Biber).
You can turn off the calculation of initials by giving them yourself with the extended name format.
author = {family={authorSn}, given={authorGivenname},
family-i={authorSn}, given-i={authorGivenname}},
compiles to
family={authorSn},
familyi={authorSnbibinitperiod},
given={authorGivenname},
giveni={authorGivennamebibinitperiod}}}%
still not great, but better than nothing.
Of course you could give the real initials explicitly if you determine them yourself beforehand.
edited 2 days ago
answered Nov 26 at 7:37
moewe
83.6k8107321
83.6k8107321
add a comment |
add a comment |
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f461746%2fwhy-does-biber-segfault-using-a-macro-in-the-author-field%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
You'll have to wait for someone more knowledgeable to explain what has changed for this new behavior. But, in the meantime, you could try
author = {relaxauthorSn, relaxauthorGivenname}
. You will still continue to receive warnings on youryear
andisbn
fields though.– gusbrs
Nov 25 at 23:36
1
@gusbrs Thanks a lot for this workaround - seems to work fine. Now I'm completely relaxed. ;-)
– lAtExFaN
Nov 25 at 23:43
1
Well, don't get too comfy. You are indeed stretching what biber expects there. As you see, even when it runs, sorting seems wrong. Do you have a strong reason to use this?
– gusbrs
Nov 25 at 23:53
1
Well, that's a good requirement in general, I concur. But usually there's more than one way to achieve it. You could invert the logic here, you could call the data from the bibentry to fill in your macros, and then use them in the other places you need. If you think that might be an alternative, extend your MWE to show some use cases of the macros elsewhere, and I see what can do.
– gusbrs
Nov 26 at 0:06
4
how can biber possibly sort the bibliography without having access to the names? (it shouldn't segfault of course but it can't work)
– David Carlisle
Nov 26 at 0:22