emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Robert Goldman <rpgoldman@sift.info>
To: emacs-orgmode@gnu.org, e.fraga@ucl.ac.uk
Subject: Re: Making an index in latex export --- surprisingly difficult
Date: Thu, 28 Apr 2011 06:04:37 -0500	[thread overview]
Message-ID: <4DB949C5.7020107@sift.info> (raw)
In-Reply-To: <87d3k6g1xv.fsf@ucl.ac.uk>

On 4/28/11 Apr 28 -4:28 AM, Eric S Fraga wrote:
> Robert Goldman <rpgoldman@sift.info> writes:
> 
> [...]
> 
>> I looked at that thread and unfortunately it petered out (partly because
>> it went off into a different direction to solve an easier problem with
>> conflicting style files).
>>
>> The last message from Eric Fraga states:
>>
>>> Oh well, there goes that theory.  The web link you gave yesterday
>>> would seem to indicate that the problem is present if you invoke the
>>> bibtex command from another directory and this does not appear to be
>>> the case here.  Very strange.
>>
>> It's not actually invoking the bibtex command from another directory,
>> AFAICT, but invoking the bibtex command on an argument that is an
>> /absolute/ pathname.  This is now forbidden for makeindex and bibtex (I
>> don't know if it's permitted for pdflatex or not, but I suspect it is,
>> since the pdflatex part of the export process is working --- pdflatex
>> may not honor openout_any=p).
> 
> If the file is indeed in the /current/ directory, then a simple fix may
> be to use %b for the file argument to makeindex?  I have no problems
> with bibtex using
> 
> ,----
> | org-latex-to-pdf-process is a variable defined in `org-latex.el'.
> | Its value is ("pdflatex %f" "bibtex %b" "pdflatex %f" "pdflatex %f")
> `----
> 
> Note the use of %b instead of %o or %f.  I've never used makeindex so
> cannot be sure this would work.
> 

No, actually this does not work, since the expansion of %b is still an
absolute pathname, rather than a relative pathname.  The only difference
is that the file extension is removed.  Here's a snippet from my
*trace-output* buffer when I trace the shell-command function:

command="makeindex -o
/Users/rpg/obtw/obtw-trunk/memos/plan-representation/manual.ind
/Users/rpg/obtw/obtw-trunk/memos/plan-representation/manual.idx"

The entry from my org-latex-to-pdf-process is:

"makeindex -o %b.ind %b.idx"

So using the basename is orthogonal to the underlying problem, which is
that absolute pathnames are always used.

When I restore the openout_any = p setting, I see:

rpg% makeindex -o
/Users/rpg/obtw/obtw-trunk/memos/plan-representation/manual.ind
/Users/rpg/obtw/obtw-trunk/memos/plan-representation/manual.idx


makeindex: Not writing to
/Users/rpg/obtw/obtw-trunk/memos/plan-representation/manual.ind
(openout_any = p).
Can't create output index file
/Users/rpg/obtw/obtw-trunk/memos/plan-representation/manual.ind.

Note that this isn't something one needs any org-mode testing to verify
--- you can just figure out what %b will expand to, and test
interactively with the shell using makeindex or bibtex, if you have a
recent texlive, with the paranoid settings.

The only "solution" I know (aside from disabling the texmf.cnf security
setting) would be to have org ensure that its CWD is the document
directory when running these programs and use relative pathnames.  I
don't know that this solution is compatible with correct use of
EXPORT_FILE_NAME, however....

This seems like a very crippling security setting -- it would break many
plausible uses of the tex suite when they are run under program control
(I could easily imagine scenarios with make that would result in the use
of absolute pathnames, too); I'm surprised it was made.

Best,
r

  reply	other threads:[~2011-04-28 11:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-26 21:09 Making an index in latex export --- surprisingly difficult Robert Goldman
2011-04-26 21:26 ` Suvayu Ali
2011-04-26 21:44   ` Robert Goldman
2011-04-28  9:28     ` Eric S Fraga
2011-04-28 11:04       ` Robert Goldman [this message]
2011-04-28 11:52         ` Eric S Fraga
2011-04-26 21:52 ` Nick Dokos
2011-04-26 21:58   ` Robert Goldman
2011-04-26 23:14     ` Nick Dokos
2011-04-27  1:32       ` Robert Goldman
2011-04-27  6:35     ` Nick Dokos
2011-04-27  7:38       ` Thomas S. Dye
2011-05-09  6:08       ` Tom Dye

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DB949C5.7020107@sift.info \
    --to=rpgoldman@sift.info \
    --cc=e.fraga@ucl.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).