emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Re: Bibtex and latex export


From: Bernt Hansen
Subject: [Orgmode] Re: Bibtex and latex export
Date: Fri, 08 Oct 2010 08:01:17 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

suvayu ali <address@hidden> writes:

> On 7 October 2010 06:58, Eric S Fraga <address@hidden> wrote:
>> On Thu, 07 Oct 2010 09:29:59 -0400, Nick Dokos <address@hidden> wrote:
>>>
>>> Eric S Fraga <address@hidden> wrote:
>>>
>>> > On Wed, 06 Oct 2010 19:21:33 +0200, Achim Gratz <address@hidden> wrote:
>>> > >
>>> > > Hi Eric,
>>> > >
>>> > > Eric S Fraga <address@hidden> writes:
>>> > > > | /usr/bin/texi2dvi: Processing /home/ucecesf/.../file.tex ...
>>> > > > | egrep: Invalid range end
>>> > > > | /usr/bin/texi2dvi: cannot read .//home/ucecesf/.../file.tex, 
>>> > > > skipping.
>>> > >
>>> > > Something somewhere tries to make a local path from an absolute one by
>>> > > prepending "./", which fails (predictably).  Is the input readable at
>>> > > the original path?  Not sure the error message from egrep has to do with
>>> > > it or not, but it must be in any case one of the processes started by
>>> > > texi2dvi (does not show up on my system, I only have calls to grep when
>>> > > I trace it, but one of the sub-processes might still use it).  I think
>>> > > texi2dvi also invokes shell scripts, so any funny configuration in the
>>> > > environment, especially where path points to, could throw it off.
>>> >
>>> > As far as I know, there is nothing out of the ordinary with my paths
>>> > etc (please note that the /.../ above was an edit on my part to hide a
>>> > rather long path).  Any hints as to what I can do to explore this
>>> > would be most helpful.  How can I get a trace on what texi2dvi is
>>> > doing?  (sh -v /usr/bin/texi2dvi?)
>>> >
>>>
>>> There is an explicit egrep on line 1563 or thereabouts (my version
>>> says
>>>
>>> # texi2dvi --- produce DVI (or PDF) files from Texinfo (or (La)TeX) sources.
>>> # $Id: texi2dvi,v 1.104 2007/09/10 00:36:30 karl Exp $
>>>
>>> at the top of the file):
>>>
>>>
>>>   # If the COMMAND_LINE_FILENAME is not absolute (e.g., --debug.tex),
>>>   # prepend `./' in order to avoid that the tools take it as an option.
>>>   echo "$command_line_filename" | $EGREP '^(/|[A-z]:/)' >&6 \
>>>   || command_line_filename="./$command_line_filename"
>>>
>>>
>>> The regular expression seems a bit weird (upper case A to lower case
>>> z?), but I can't see off the top of my head how it gets tripped up.  For
>>> tracing, try
>>>
>>>    sh -x texi2dvi ....
>>>
>>> Nick
>>
>> Thanks Nick.  If I do this:
>>
>> : (setq org-latex-to-pdf-process '("sh -x /usr/bin/texi2dvi -p -b -c -V %f"))
>>
>> the following is a snippet of the output:
>>
>> ,----
>> | + echo /home/ucecesf/s/teaching/cape/lectures/matlab.tex+ egrep 
>> ^(/|[A-z]:/)
>> | egrep: Invalid range end
>> | + command_line_filename=.//home/ucecesf/s/teaching/cape/lectures/matlab.tex
>> | + test -r .//home/ucecesf/s/teaching/cape/lectures/matlab.tex
>> | + error 1 cannot read .//home/ucecesf/s/teaching/cape/lectures/matlab.tex, 
>> skipping.
>> `----
>>
>> Because the egrep fails completely, the script assumes that it does
>> need to prepend "./" to the file name even though the file name
>> already starts with "/" (and is definitely *not* a DOS type file name
>> ;-).
>>
>> I don't understand why the egrep is failing although it definitely has
>> something to do with A-z range; if I try the egrep at the shell and
>> use "A-Za-z" instead of "A-z", the command works fine.  Does it work
>> for anybody else on Linux?
>>
>> I wonder if the problem with the range is locale dependent?  My locale
>> is en_GB.UTF-8.  The manual page for egrep does indicate that ranges
>> may not mean the same thing in different locales and suggests using
>> locale C.  I don't want to change my locale but maybe it could be set
>> for the invocation of texi2dvi...  (yech).
>>
>> This is obviously not an org problem as such but I am surprised it's
>> working for anybody at all...
>>
>> I guess I'll stick to multiple invocations of pdflatex directly for
>> the time being.
>>
>
> I have the exact same problem ever since I updated org today. (from
> commit 344785b 2010-10-03 Bernt Hansen to commit 0901585 2010-10-06
> Eric Schulte)
>
> My locale is en_IN.utf8, and I am on Fedora 13. I couldn't quite
> understand the discussion where the bug actually is. To resolve this
> do I need to file a bug with the Fedora bugzilla? I am confused how
> can that be possible because I can successfully export to pdf if I
> downgrade org to commit 344785b.

Hi suvayu ali,

The change probably is in commit
59ba412 (Use texi2dvi for processing LaTeX to pdf, 2010-10-05)
where we switch from using pdflatex to texi2dvi if it is available.

Regards,
Bernt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]