On Thu, 07 Oct 2010 09:29:59 -0400, Nick Dokos <nicholas.dokos@hp.com> wrote:
> 
> Eric S Fraga <ucecesf@ucl.ac.uk> wrote:
> 
> > On Wed, 06 Oct 2010 19:21:33 +0200, Achim Gratz <Stromeko@nexgo.de> wrote:
> > > 
> > > Hi Eric,
> > > 
> > > Eric S Fraga <ucecesf@ucl.ac.uk> 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.

cheers,
eric