pdflatex not found?

pdflatex not found?

[Peter Davis]

I'm trying to export PDF from org, but I'm getting the error:

pdflatex: Command not found. [3 times]

I've checked the definition of exec-path, and it includes "/usr/texbin", which is where tcsh tells me the executable is.

Any ideas?

Thank you!

-pd

Re: pdflatex not found?

[John Hendy]

On Mon, Oct 26, 2015 at 2:26 PM, Peter Davis <pfd@pfdstudio.com> wrote:
>
> I'm trying to export PDF from org, but I'm getting the error:
>
> pdflatex: Command not found. [3 times]
>
> I've checked the definition of exec-path, and it includes "/usr/texbin", which is where tcsh tells me the executable is.

Someone else might have a better answer, but can you check your system
itself first? I'm guessing "exec-path" is an Org/Emacs variable?

Just try:

$ which pdflatex

Or

$ pdflatex --version

That would be my suggestion for starters. At least then you know it's
definitely not your system/setup (my bet is that it is, though).


John

>
> Any ideas?
>
> Thank you!
>
> -pd
>
>

Re: pdflatex not found?

[Nick Dokos]

Peter Davis <pfd@pfdstudio.com> writes:

> I'm trying to export PDF from org, but I'm getting the error:
>
> pdflatex: Command not found. [3 times]
>
> I've checked the definition of exec-path, and it includes
> "/usr/texbin", which is where tcsh tells me the executable is.
>
> Any ideas?
>

Backtrace?

(setq debug-on-error t) and do the export again, possibly with
uncompiled code: (info "(org) Feedback") for the details of producing a
useful backtrace.

This should be SOP for any errors, *before* you post a question to the
list. You don't have to be able to read the backtrace; there are people
on the list who can and it makes the diagnosis *much* easier by pruning
the tree of "how did we get there" down to its essentials.  It will also
help me avoid sounding like a broken record.

And all instances of "you" is plural and all-inclusive ;-)
--
Nick

Re: pdflatex not found?

[Myles English]

John Hendy writes:

> On Mon, Oct 26, 2015 at 2:26 PM, Peter Davis <pfd@pfdstudio.com> wrote:
>>
>> I'm trying to export PDF from org, but I'm getting the error:
>>
>> pdflatex: Command not found. [3 times]
>>
>> I've checked the definition of exec-path, and it includes "/usr/texbin", which is where tcsh tells me the executable is.
>
> Someone else might have a better answer, but can you check your system
> itself first? I'm guessing "exec-path" is an Org/Emacs variable?
>
> Just try:
>
> $ which pdflatex
>
> Or
>
> $ pdflatex --version
>
> That would be my suggestion for starters. At least then you know it's
> definitely not your system/setup (my bet is that it is, though).
>
>
> John
>
>>
>> Any ideas?
>>
>> Thank you!
>>
>> -pd

pd,

After trying what has alreaddy been suggested you might try putting your
cursor after the last bracket of this and pressing C-x C-e to see what
emacs thinks your shell PATH environment variable is set to:

(getenv "PATH")

If you can't see the correct path in there then it should probably be
set in ~/.profile or equivalent for tcsh rather than in ~/.tcshrc (I
don't use tcsh so I just guessed that filename).

Myles

Re: pdflatex not found?

[Charles C. Berry]

On Mon, 26 Oct 2015, Myles English wrote:

>
>
> John Hendy writes:
>
>> On Mon, Oct 26, 2015 at 2:26 PM, Peter Davis <pfd@pfdstudio.com> wrote:
>>>
>>> I'm trying to export PDF from org, but I'm getting the error:
>>>
>>> pdflatex: Command not found. [3 times]
>>>
>>> I've checked the definition of exec-path, and it includes "/usr/texbin", which is where tcsh tells me the executable is.
>>
>> Someone else might have a better answer, but can you check your system
>> itself first? I'm guessing "exec-path" is an Org/Emacs variable?
>>
>> Just try:
>>
>> $ which pdflatex
>>
>> Or
>>
>> $ pdflatex --version
>>
>> That would be my suggestion for starters. At least then you know it's
>> definitely not your system/setup (my bet is that it is, though).
>>
>>
>> John
>>
>>>
>>> Any ideas?
>>>
>>> Thank you!
>>>
>>> -pd
>
> pd,
>
> After trying what has alreaddy been suggested you might try putting your
> cursor after the last bracket of this and pressing C-x C-e to see what
> emacs thinks your shell PATH environment variable is set to:
>
> (getenv "PATH")
>
> If you can't see the correct path in there then it should probably be
> set in ~/.profile or equivalent for tcsh rather than in ~/.tcshrc (I
> don't use tcsh so I just guessed that filename).
>

Or put something like

#+BEGIN_SRC emacs-lisp
(setenv "PATH"
      "/usr/bin:/bin:/usr/sbin:/sbin:/usr/texbin:/usr/local/bin")
#+END_SRC

in your init file.

HTH,

Chuck

Re: pdflatex not found?

[Peter Davis]

Nick Dokos <ndokos@gmail.com> writes:


> Peter Davis <pfd@pfdstudio.com> writes:
>
>> I'm trying to export PDF from org, but I'm getting the error:
>>
>> pdflatex: Command not found. [3 times]
>>
>> I've checked the definition of exec-path, and it includes
>> "/usr/texbin", which is where tcsh tells me the executable is.
>>
>> Any ideas?
>>
>
> Backtrace?

Sorry. Here's the backtrace:

Debugger entered--Lisp error: (error "PDF file ./test.pdf wasn't produced")
  signal(error ("PDF file ./test.pdf wasn't produced"))
  error("PDF file ./test.pdf wasn't produced")
  org-latex-compile("./test.tex")
  #[(file) "\301\b!\207" [file org-latex-compile] 2]("./test.tex")
  org-export-to-file(latex "./test.tex" nil nil nil nil nil #[(file) "\301\b!\207" [file org-latex-compile] 2])
  org-latex-export-to-pdf(nil nil nil nil)
  (org-open-file (org-latex-export-to-pdf nil s v b))
  (if a (org-latex-export-to-pdf t s v b) (org-open-file (org-latex-export-to-pdf nil s v b)))
  (lambda (a s v b) (if a (org-latex-export-to-pdf t s v b) (org-open-file (org-latex-export-to-pdf nil s v b))))(nil nil nil nil)
  org-export-dispatch(nil)
  call-interactively(org-export-dispatch nil nil)
  command-execute(org-export-dispatch)

This seems less useful to me than the *Messages* buffer:

Debug on Error enabled globally
org-babel-exp processing...
executing Dot code block...
Wrote /var/folders/d4/xb7t0gbd0f97p6494kz5xzdnmlncz8/T/babel-2213VOW/ob-input-22136yU
Code block evaluation complete.
Saving file /Users/davisp/Dropbox/HMH/test.tex...
Wrote /Users/davisp/Dropbox/HMH/test.tex
Processing LaTeX file ./test.tex...
pdflatex: Command not found. [3 times]
Entering debugger...
Mark set
End of buffer

I did verify that the shell, my default of tcsh, does show pdflatex at the right location, /usr/texbin/pdflatex

Thanks,
-pd

Re: pdflatex not found?

[Nick Dokos]

Peter Davis <pfd@pfdstudio.com> writes:

> Nick Dokos <ndokos@gmail.com> writes:
>
>
>> Peter Davis <pfd@pfdstudio.com> writes:
>>
>>> I'm trying to export PDF from org, but I'm getting the error:
>>>
>>> pdflatex: Command not found. [3 times]
>>>
>>> I've checked the definition of exec-path, and it includes
>>> "/usr/texbin", which is where tcsh tells me the executable is.
>>>
>>> Any ideas?
>>>
>>
>> Backtrace?
>
> Sorry. Here's the backtrace:
>
> Debugger entered--Lisp error: (error "PDF file ./test.pdf wasn't produced")
>   signal(error ("PDF file ./test.pdf wasn't produced"))
>   error("PDF file ./test.pdf wasn't produced")
>   org-latex-compile("./test.tex")
>   #[(file) "\301\b!\207" [file org-latex-compile] 2]("./test.tex")
>   org-export-to-file(latex "./test.tex" nil nil nil nil nil #[(file)
> "\301\b!\207" [file org-latex-compile] 2])
>   org-latex-export-to-pdf(nil nil nil nil)
>   (org-open-file (org-latex-export-to-pdf nil s v b))
>   (if a (org-latex-export-to-pdf t s v b) (org-open-file (org-latex-export-to-pdf nil s v b)))
>   (lambda (a s v b) (if a (org-latex-export-to-pdf t s v b)
> (org-open-file (org-latex-export-to-pdf nil s v b))))(nil nil nil nil)
>   org-export-dispatch(nil)
>   call-interactively(org-export-dispatch nil nil)
>   command-execute(org-export-dispatch)
>
> This seems less useful to me than the *Messages* buffer:
>

Yes, probably, but if I can get people to submit backtraces when getting
an error, we can cut down the email volume by a factor of 2.43 (making up
fictitious data to bolster my case...) In all seriousness, at least it
shows that you are not going down some strange path.

It's not clear to me why the error message in the message file is different
from the error message above though.

> Debug on Error enabled globally
> org-babel-exp processing...
> executing Dot code block...
> Wrote /var/folders/d4/xb7t0gbd0f97p6494kz5xzdnmlncz8/T/babel-2213VOW/ob-input-22136yU
> Code block evaluation complete.
> Saving file /Users/davisp/Dropbox/HMH/test.tex...
> Wrote /Users/davisp/Dropbox/HMH/test.tex
> Processing LaTeX file ./test.tex...
> pdflatex: Command not found. [3 times]
> Entering debugger...
> Mark set
> End of buffer
>
> I did verify that the shell, my default of tcsh, does show pdflatex at
> the right location, /usr/texbin/pdflatex
>

In combination, this pretty much says that org-latex-pdf-process was
called (by examining the code for org-latex-compile) and it is set to
the default value of invoking pdflatex three times (hence - probably -
the "command not found 3 times" error), so as I said the standard path.

As others have pointed out, your emacs does not know where to find
pdflatex, even though your tcsh might. If your emacs is started from a
tcsh that can find pdflatex, that would be strange; if it is started
from your desktop environment/window manager, not so much (there are
many things that could go wrong).

OTOH, if exec-path contains the directory where pdflatex resides, then
things are a bit screwy: exec-path is used by call-process, which is
used by shell-command, which is used by org-latex-compile: so pdflatex
should be found - that's a bit of a mystery.

What happens if you say M-x shell-command RET pdflatex RET?

Somebody suggested running "which pdflatex" in your shell - what does
that say?

And you say it should be in /usr/texbin - what happens if you invoke
it with an absolute path: "/usr/texbin/pdflatex" in your shell?

--
Nick

Re: pdflatex not found?

[Rainer M Krug]

Envoyé de mon iPhone

> Le 27 oct. 2015 à 01:14, Nick Dokos <ndokos@gmail.com> a écrit :
> 
> Peter Davis <pfd@pfdstudio.com> writes:
> 
>> Nick Dokos <ndokos@gmail.com> writes:
>> 
>> 
>>> Peter Davis <pfd@pfdstudio.com> writes:
>>> 
>>>> I'm trying to export PDF from org, but I'm getting the error:
>>>> 
>>>> pdflatex: Command not found. [3 times]
>>>> 
>>>> I've checked the definition of exec-path, and it includes
>>>> "/usr/texbin", which is where tcsh tells me the executable is.
>>>> 
>>>> Any ideas?
>>> 
>>> Backtrace?
>> 
>> Sorry. Here's the backtrace:
>> 
>> Debugger entered--Lisp error: (error "PDF file ./test.pdf wasn't produced")
>>  signal(error ("PDF file ./test.pdf wasn't produced"))
>>  error("PDF file ./test.pdf wasn't produced")
>>  org-latex-compile("./test.tex")
>>  #[(file) "\301\b!\207" [file org-latex-compile] 2]("./test.tex")
>>  org-export-to-file(latex "./test.tex" nil nil nil nil nil #[(file)
>> "\301\b!\207" [file org-latex-compile] 2])
>>  org-latex-export-to-pdf(nil nil nil nil)
>>  (org-open-file (org-latex-export-to-pdf nil s v b))
>>  (if a (org-latex-export-to-pdf t s v b) (org-open-file (org-latex-export-to-pdf nil s v b)))
>>  (lambda (a s v b) (if a (org-latex-export-to-pdf t s v b)
>> (org-open-file (org-latex-export-to-pdf nil s v b))))(nil nil nil nil)
>>  org-export-dispatch(nil)
>>  call-interactively(org-export-dispatch nil nil)
>>  command-execute(org-export-dispatch)
>> 
>> This seems less useful to me than the *Messages* buffer:
> 
> Yes, probably, but if I can get people to submit backtraces when getting
> an error, we can cut down the email volume by a factor of 2.43 (making up
> fictitious data to bolster my case...) In all seriousness, at least it
> shows that you are not going down some strange path.
> 
> It's not clear to me why the error message in the message file is different
> from the error message above though.
> 
>> Debug on Error enabled globally
>> org-babel-exp processing...
>> executing Dot code block...
>> Wrote /var/folders/d4/xb7t0gbd0f97p6494kz5xzdnmlncz8/T/babel-2213VOW/ob-input-22136yU
>> Code block evaluation complete.
>> Saving file /Users/davisp/Dropbox/HMH/test.tex...
>> Wrote /Users/davisp/Dropbox/HMH/test.tex
>> Processing LaTeX file ./test.tex...
>> pdflatex: Command not found. [3 times]
>> Entering debugger...
>> Mark set
>> End of buffer
>> 
>> I did verify that the shell, my default of tcsh, does show pdflatex at
>> the right location, /usr/texbin/pdflatex
> 
> In combination, this pretty much says that org-latex-pdf-process was
> called (by examining the code for org-latex-compile) and it is set to
> the default value of invoking pdflatex three times (hence - probably -
> the "command not found 3 times" error), so as I said the standard path.
> 
> As others have pointed out, your emacs does not know where to find
> pdflatex, even though your tcsh might. If your emacs is started from a
> tcsh that can find pdflatex, that would be strange; if it is started
> from your desktop environment/window manager, not so much (there are
> many things that could go wrong).
> 
> OTOH, if exec-path contains the directory where pdflatex resides, then
> things are a bit screwy: exec-path is used by call-process, which is
> used by shell-command, which is used by org-latex-compile: so pdflatex
> should be found - that's a bit of a mystery.
> 
> What happens if you say M-x shell-command RET pdflatex RET?
> 
> Somebody suggested running "which pdflatex" in your shell - what does
> that say?
> 
> And you say it should be in /usr/texbin - what happens if you invoke
> it with an absolute path: "/usr/texbin/pdflatex" in your shell?

Imiight have missed it - but which OS are you using?

Rainer

> 
> --
> Nick
> 
> 
> 

Re: pdflatex not found?

[Peter Davis]

Rainer M Krug <r.m.krug@gmail.com> writes:

> Envoyé de mon iPhone
>
>> Le 27 oct. 2015 à 01:14, Nick Dokos <ndokos@gmail.com> a écrit :
>> 
>> Peter Davis <pfd@pfdstudio.com> writes:
>> 
>>> Nick Dokos <ndokos@gmail.com> writes:
>> ...
>> Yes, probably, but if I can get people to submit backtraces when getting
>> an error, we can cut down the email volume by a factor of 2.43 (making up
>> fictitious data to bolster my case...) In all seriousness, at least it
>> shows that you are not going down some strange path.

I think the actual number is more like 2.17, but let's not quibble.

>> 
>> What happens if you say M-x shell-command RET pdflatex RET?

Not found.

>> Somebody suggested running "which pdflatex" in your shell - what does
>> that say?

Still not found. However, adding it to ~/.tcshrc seems to fix the problem. That makes sense, but leaves two questions:

1) Why am I able to run pdflatex (without specifying the path) just from the shell running in a terminal window?

2) What's the point of defining the emacs exec-path, since I needed to define the shell's PATH variable anyway?

>> And you say it should be in /usr/texbin - what happens if you invoke
>> it with an absolute path: "/usr/texbin/pdflatex" in your shell?
>
> Imiight have missed it - but which OS are you using?

Sorry. It's OS X 10.10.5, using GNU Emacs 24.5.1

Thanks!
-pd

Re: pdflatex not found?

[Fatma Başak Aydemir]

I do not know the reasons but I had the same problem in the past on OS X.

exec-path-from-shell package is a nice solution for that.

https://github.com/purcell/exec-path-from-shell

27/10/15 14:43 tarihinde Peter Davis yazdı:
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> Envoyé de mon iPhone
>>
>>> Le 27 oct. 2015 à 01:14, Nick Dokos <ndokos@gmail.com> a écrit :
>>>
>>> Peter Davis <pfd@pfdstudio.com> writes:
>>>
>>>> Nick Dokos <ndokos@gmail.com> writes:
>>> ...
>>> Yes, probably, but if I can get people to submit backtraces when getting
>>> an error, we can cut down the email volume by a factor of 2.43 (making up
>>> fictitious data to bolster my case...) In all seriousness, at least it
>>> shows that you are not going down some strange path.
> I think the actual number is more like 2.17, but let's not quibble.
>
>>> What happens if you say M-x shell-command RET pdflatex RET?
> Not found.
>
>>> Somebody suggested running "which pdflatex" in your shell - what does
>>> that say?
> Still not found. However, adding it to ~/.tcshrc seems to fix the problem. That makes sense, but leaves two questions:
>
> 1) Why am I able to run pdflatex (without specifying the path) just from the shell running in a terminal window?
>
> 2) What's the point of defining the emacs exec-path, since I needed to define the shell's PATH variable anyway?
>
>>> And you say it should be in /usr/texbin - what happens if you invoke
>>> it with an absolute path: "/usr/texbin/pdflatex" in your shell?
>> Imiight have missed it - but which OS are you using?
> Sorry. It's OS X 10.10.5, using GNU Emacs 24.5.1
>
> Thanks!
> -pd
>

-- 
--------------------------------
Fatma Başak Aydemir
PhD Student at ICT International Doctoral School
Department of Information Engineering and Computer Science
University of Trento
Skype: fatmabasak.aydemir
E-mail: aydemir@disi.unitn.it

Re: pdflatex not found?

[Nick Dokos]

Fatma Başak Aydemir <aydemirfb@gmail.com> writes:

> I do not know the reasons but I had the same problem in the past on OS X.
>
> exec-path-from-shell package is a nice solution for that.
>
> https://github.com/purcell/exec-path-from-shell
>

Just the need for a package like that indicates that something is badly
broken on OS X, I think. To be fair, it's a mess on Linux as well, but
it is possible to make sure that variables you define (and export) in
your .profile get propagated to applications started by the DE/WM. In my
current installation (Fedora 21), that is done by
/etc/X11/xinit/xinitrc-common, which does this:

[ -r $HOME/.profile ] && . $HOME/.profile

Maybe OS X has a "hidden" mechanism like this?

> 27/10/15 14:43 tarihinde Peter Davis yazdı:
>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>
>>> Envoyé de mon iPhone
>>>
>>>> Le 27 oct. 2015 à 01:14, Nick Dokos <ndokos@gmail.com> a écrit :
>>>>
>>>> Peter Davis <pfd@pfdstudio.com> writes:
>>>>
>>>>> Nick Dokos <ndokos@gmail.com> writes:
>>>> ...
>>>> Yes, probably, but if I can get people to submit backtraces when getting
>>>> an error, we can cut down the email volume by a factor of 2.43 (making up
>>>> fictitious data to bolster my case...) In all seriousness, at least it
>>>> shows that you are not going down some strange path.
>> I think the actual number is more like 2.17, but let's not quibble.
>>
>>>> What happens if you say M-x shell-command RET pdflatex RET?
>> Not found.
>>
>>>> Somebody suggested running "which pdflatex" in your shell - what does
>>>> that say?
>> Still not found. However, adding it to ~/.tcshrc seems to fix the
>> problem. That makes sense, but leaves two questions:
>>
>> 1) Why am I able to run pdflatex (without specifying the path) just
>> from the shell running in a terminal window?
>>
>> 2) What's the point of defining the emacs exec-path, since I needed
>> to define the shell's PATH variable anyway?
>>

FWIW, I never define exec-path explicitly: it is set from my $PATH when
emacs starts.

--
Nick

Re: pdflatex not found?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

Peter Davis <pfd@pfdstudio.com> writes:

> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> Envoyé de mon iPhone
>>
>>> Le 27 oct. 2015 à 01:14, Nick Dokos <ndokos@gmail.com> a écrit :
>>> 
>>> Peter Davis <pfd@pfdstudio.com> writes:
>>> 
>>>> Nick Dokos <ndokos@gmail.com> writes:
>>> ...
>>> Yes, probably, but if I can get people to submit backtraces when getting
>>> an error, we can cut down the email volume by a factor of 2.43 (making up
>>> fictitious data to bolster my case...) In all seriousness, at least it
>>> shows that you are not going down some strange path.
>
> I think the actual number is more like 2.17, but let's not quibble.
>
>>> 
>>> What happens if you say M-x shell-command RET pdflatex RET?
>
> Not found.
>
>>> Somebody suggested running "which pdflatex" in your shell - what does
>>> that say?
>
> Still not found. However, adding it to ~/.tcshrc seems to fix the problem. That makes sense, but leaves two questions:
>
> 1) Why am I able to run pdflatex (without specifying the path) just from the shell running in a terminal window?
>
> 2) What's the point of defining the emacs exec-path, since I needed to define the shell's PATH variable anyway?
>
>>> And you say it should be in /usr/texbin - what happens if you invoke
>>> it with an absolute path: "/usr/texbin/pdflatex" in your shell?
>>
>> Imiight have missed it - but which OS are you using?
>
> Sorry. It's OS X 10.10.5, using GNU Emacs 24.5.1

I thought so.

OK - you have pdflatex in the terminal? If yes, you have to bring the
PATH from the terminal into emacs. I use

I use the package exec-path-from-shell for this (and use-package in general):

--8<---------------cut here---------------start------------->8---
(use-package exec-path-from-shell
  :ensure t
  :config 
  (exec-path-from-shell-initialize)
  (exec-path-from-shell-copy-env "LC_ALL")
  (exec-path-from-shell-copy-env "LANG")
  )
--8<---------------cut here---------------end--------------->8---

so
--8<---------------cut here---------------start------------->8---
(require 'exec-path-to-shell)
(exec-path-from-shell-initialize)
--8<---------------cut here---------------end--------------->8---

should do this.

Cheers,

Rainer


>
> Thanks!
> -pd

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: pdflatex not found?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]

Fatma Başak Aydemir <aydemirfb@gmail.com> writes:

> I do not know the reasons but I had the same problem in the past on OS X.

In from Yosemite onwards, programs started from the finder / spotlight /
gui (however you call this) do *not* inherit from the .bashrc
anymore. This caused many problems. Furthermore, there seems to be a
change from emacs 24.5 to emacs 25 in this regard (this is why I had to
add

--8<---------------cut here---------------start------------->8---
  (exec-path-from-shell-copy-env "LC_ALL")
  (exec-path-from-shell-copy-env "LANG")
--8<---------------cut here---------------end--------------->8---

to my emacs.org to get the LANG in R correct.

Unfortunately I can't find the thread on the internet anymore about
these problems.


>
> exec-path-from-shell package is a nice solution for that.

This is a lovely little package and very useful.

Cheers,

Rainer

>
> https://github.com/purcell/exec-path-from-shell
>
> 27/10/15 14:43 tarihinde Peter Davis yazdı:
>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>
>>> Envoyé de mon iPhone
>>>
>>>> Le 27 oct. 2015 à 01:14, Nick Dokos <ndokos@gmail.com> a écrit :
>>>>
>>>> Peter Davis <pfd@pfdstudio.com> writes:
>>>>
>>>>> Nick Dokos <ndokos@gmail.com> writes:
>>>> ...
>>>> Yes, probably, but if I can get people to submit backtraces when getting
>>>> an error, we can cut down the email volume by a factor of 2.43 (making up
>>>> fictitious data to bolster my case...) In all seriousness, at least it
>>>> shows that you are not going down some strange path.
>> I think the actual number is more like 2.17, but let's not quibble.
>>
>>>> What happens if you say M-x shell-command RET pdflatex RET?
>> Not found.
>>
>>>> Somebody suggested running "which pdflatex" in your shell - what does
>>>> that say?
>> Still not found. However, adding it to ~/.tcshrc seems to fix the problem. That makes sense, but leaves two questions:
>>
>> 1) Why am I able to run pdflatex (without specifying the path) just from the shell running in a terminal window?
>>
>> 2) What's the point of defining the emacs exec-path, since I needed to define the shell's PATH variable anyway?
>>
>>>> And you say it should be in /usr/texbin - what happens if you invoke
>>>> it with an absolute path: "/usr/texbin/pdflatex" in your shell?
>>> Imiight have missed it - but which OS are you using?
>> Sorry. It's OS X 10.10.5, using GNU Emacs 24.5.1
>>
>> Thanks!
>> -pd
>>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: pdflatex not found?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2696 bytes --]

Nick Dokos <ndokos@gmail.com> writes:

> Fatma Başak Aydemir <aydemirfb@gmail.com> writes:
>
>> I do not know the reasons but I had the same problem in the past on OS X.
>>
>> exec-path-from-shell package is a nice solution for that.
>>
>> https://github.com/purcell/exec-path-from-shell
>>
>
> Just the need for a package like that indicates that something is badly
> broken on OS X, I think. To be fair, it's a mess on Linux as well, but
> it is possible to make sure that variables you define (and export) in
> your .profile get propagated to applications started by the DE/WM. In my
> current installation (Fedora 21), that is done by
> /etc/X11/xinit/xinitrc-common, which does this:
>
> [ -r $HOME/.profile ] && . $HOME/.profile
>
> Maybe OS X has a "hidden" mechanism like this?

Nope - this is a "feature" since Yosemite.

Cheers,

Rainer

>
>> 27/10/15 14:43 tarihinde Peter Davis yazdı:
>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>
>>>> Envoyé de mon iPhone
>>>>
>>>>> Le 27 oct. 2015 à 01:14, Nick Dokos <ndokos@gmail.com> a écrit :
>>>>>
>>>>> Peter Davis <pfd@pfdstudio.com> writes:
>>>>>
>>>>>> Nick Dokos <ndokos@gmail.com> writes:
>>>>> ...
>>>>> Yes, probably, but if I can get people to submit backtraces when getting
>>>>> an error, we can cut down the email volume by a factor of 2.43 (making up
>>>>> fictitious data to bolster my case...) In all seriousness, at least it
>>>>> shows that you are not going down some strange path.
>>> I think the actual number is more like 2.17, but let's not quibble.
>>>
>>>>> What happens if you say M-x shell-command RET pdflatex RET?
>>> Not found.
>>>
>>>>> Somebody suggested running "which pdflatex" in your shell - what does
>>>>> that say?
>>> Still not found. However, adding it to ~/.tcshrc seems to fix the
>>> problem. That makes sense, but leaves two questions:
>>>
>>> 1) Why am I able to run pdflatex (without specifying the path) just
>>> from the shell running in a terminal window?
>>>
>>> 2) What's the point of defining the emacs exec-path, since I needed
>>> to define the shell's PATH variable anyway?
>>>
>
> FWIW, I never define exec-path explicitly: it is set from my $PATH when
> emacs starts.
>
> --
> Nick
>
>
>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: pdflatex not found?

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]

This reminds me that I think I have this problem unless I open Emacs from a
command line.

On Tuesday, October 27, 2015, Nick Dokos <ndokos@gmail.com> wrote:

> Fatma Başak Aydemir <aydemirfb@gmail.com <javascript:;>> writes:
>
> > I do not know the reasons but I had the same problem in the past on OS X.
> >
> > exec-path-from-shell package is a nice solution for that.
> >
> > https://github.com/purcell/exec-path-from-shell
> >
>
> Just the need for a package like that indicates that something is badly
> broken on OS X, I think. To be fair, it's a mess on Linux as well, but
> it is possible to make sure that variables you define (and export) in
> your .profile get propagated to applications started by the DE/WM. In my
> current installation (Fedora 21), that is done by
> /etc/X11/xinit/xinitrc-common, which does this:
>
> [ -r $HOME/.profile ] && . $HOME/.profile
>
> Maybe OS X has a "hidden" mechanism like this?
>
> > 27/10/15 14:43 tarihinde Peter Davis yazdı:
> >> Rainer M Krug <r.m.krug@gmail.com <javascript:;>> writes:
> >>
> >>> Envoyé de mon iPhone
> >>>
> >>>> Le 27 oct. 2015 à 01:14, Nick Dokos <ndokos@gmail.com <javascript:;>>
> a écrit :
> >>>>
> >>>> Peter Davis <pfd@pfdstudio.com <javascript:;>> writes:
> >>>>
> >>>>> Nick Dokos <ndokos@gmail.com <javascript:;>> writes:
> >>>> ...
> >>>> Yes, probably, but if I can get people to submit backtraces when
> getting
> >>>> an error, we can cut down the email volume by a factor of 2.43
> (making up
> >>>> fictitious data to bolster my case...) In all seriousness, at least it
> >>>> shows that you are not going down some strange path.
> >> I think the actual number is more like 2.17, but let's not quibble.
> >>
> >>>> What happens if you say M-x shell-command RET pdflatex RET?
> >> Not found.
> >>
> >>>> Somebody suggested running "which pdflatex" in your shell - what does
> >>>> that say?
> >> Still not found. However, adding it to ~/.tcshrc seems to fix the
> >> problem. That makes sense, but leaves two questions:
> >>
> >> 1) Why am I able to run pdflatex (without specifying the path) just
> >> from the shell running in a terminal window?
> >>
> >> 2) What's the point of defining the emacs exec-path, since I needed
> >> to define the shell's PATH variable anyway?
> >>
>
> FWIW, I never define exec-path explicitly: it is set from my $PATH when
> emacs starts.
>
> --
> Nick
>
>
>
>

-- 
John

-----------------------------------
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

[-- Attachment #2: Type: text/html, Size: 3997 bytes --]

Re: pdflatex not found?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3094 bytes --]

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> This reminds me that I think I have this problem unless I open Emacs from a
> command line.

Yup - this is one way of circumvent the problem: by starting emacs from
the command line.


>
> On Tuesday, October 27, 2015, Nick Dokos <ndokos@gmail.com> wrote:
>
>> Fatma Başak Aydemir <aydemirfb@gmail.com <javascript:;>> writes:
>>
>> > I do not know the reasons but I had the same problem in the past on OS X.
>> >
>> > exec-path-from-shell package is a nice solution for that.
>> >
>> > https://github.com/purcell/exec-path-from-shell
>> >
>>
>> Just the need for a package like that indicates that something is badly
>> broken on OS X, I think. To be fair, it's a mess on Linux as well, but
>> it is possible to make sure that variables you define (and export) in
>> your .profile get propagated to applications started by the DE/WM. In my
>> current installation (Fedora 21), that is done by
>> /etc/X11/xinit/xinitrc-common, which does this:
>>
>> [ -r $HOME/.profile ] && . $HOME/.profile
>>
>> Maybe OS X has a "hidden" mechanism like this?
>>
>> > 27/10/15 14:43 tarihinde Peter Davis yazdı:
>> >> Rainer M Krug <r.m.krug@gmail.com <javascript:;>> writes:
>> >>
>> >>> Envoyé de mon iPhone
>> >>>
>> >>>> Le 27 oct. 2015 à 01:14, Nick Dokos <ndokos@gmail.com <javascript:;>>
>> a écrit :
>> >>>>
>> >>>> Peter Davis <pfd@pfdstudio.com <javascript:;>> writes:
>> >>>>
>> >>>>> Nick Dokos <ndokos@gmail.com <javascript:;>> writes:
>> >>>> ...
>> >>>> Yes, probably, but if I can get people to submit backtraces when
>> getting
>> >>>> an error, we can cut down the email volume by a factor of 2.43
>> (making up
>> >>>> fictitious data to bolster my case...) In all seriousness, at least it
>> >>>> shows that you are not going down some strange path.
>> >> I think the actual number is more like 2.17, but let's not quibble.
>> >>
>> >>>> What happens if you say M-x shell-command RET pdflatex RET?
>> >> Not found.
>> >>
>> >>>> Somebody suggested running "which pdflatex" in your shell - what does
>> >>>> that say?
>> >> Still not found. However, adding it to ~/.tcshrc seems to fix the
>> >> problem. That makes sense, but leaves two questions:
>> >>
>> >> 1) Why am I able to run pdflatex (without specifying the path) just
>> >> from the shell running in a terminal window?
>> >>
>> >> 2) What's the point of defining the emacs exec-path, since I needed
>> >> to define the shell's PATH variable anyway?
>> >>
>>
>> FWIW, I never define exec-path explicitly: it is set from my $PATH when
>> emacs starts.
>>
>> --
>> Nick
>>
>>
>>
>>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: pdflatex not found?

[Cook, Malcolm]

> 
 > John Kitchin <jkitchin@andrew.cmu.edu> writes:
 > 
 > > This reminds me that I think I have this problem unless I open Emacs from a
 > > command line.
 > 
 > Yup - this is one way of circumvent the problem: by starting emacs from
 > the command line.

And, just to chime in late in the conversation, if your emacs was installed as an mac application using, say, http://emacsformacosx.com/ then you can start it from the command line as:

	open -a /Applications/path/to/emacs

and get the environment variables you expect...

 > 
 > 
 > >
 > > On Tuesday, October 27, 2015, Nick Dokos <ndokos@gmail.com> wrote:
 > >
 > >> Fatma Başak Aydemir <aydemirfb@gmail.com <javascript:;>> writes:
 > >>
 > >> > I do not know the reasons but I had the same problem in the past on OS X.
 > >> >
 > >> > exec-path-from-shell package is a nice solution for that.
 > >> >
 > >> > https://github.com/purcell/exec-path-from-shell
 > >> >
 > >>
 > >> Just the need for a package like that indicates that something is badly
 > >> broken on OS X, I think. To be fair, it's a mess on Linux as well, but
 > >> it is possible to make sure that variables you define (and export) in
 > >> your .profile get propagated to applications started by the DE/WM. In my
 > >> current installation (Fedora 21), that is done by
 > >> /etc/X11/xinit/xinitrc-common, which does this:
 > >>
 > >> [ -r $HOME/.profile ] && . $HOME/.profile
 > >>
 > >> Maybe OS X has a "hidden" mechanism like this?
 > >>
 > >> > 27/10/15 14:43 tarihinde Peter Davis yazdı:
 > >> >> Rainer M Krug <r.m.krug@gmail.com <javascript:;>> writes:
 > >> >>
 > >> >>> Envoyé de mon iPhone
 > >> >>>
 > >> >>>> Le 27 oct. 2015 à 01:14, Nick Dokos <ndokos@gmail.com
 > <javascript:;>>
 > >> a écrit :
 > >> >>>>
 > >> >>>> Peter Davis <pfd@pfdstudio.com <javascript:;>> writes:
 > >> >>>>
 > >> >>>>> Nick Dokos <ndokos@gmail.com <javascript:;>> writes:
 > >> >>>> ...
 > >> >>>> Yes, probably, but if I can get people to submit backtraces when
 > >> getting
 > >> >>>> an error, we can cut down the email volume by a factor of 2.43
 > >> (making up
 > >> >>>> fictitious data to bolster my case...) In all seriousness, at least it
 > >> >>>> shows that you are not going down some strange path.
 > >> >> I think the actual number is more like 2.17, but let's not quibble.
 > >> >>
 > >> >>>> What happens if you say M-x shell-command RET pdflatex RET?
 > >> >> Not found.
 > >> >>
 > >> >>>> Somebody suggested running "which pdflatex" in your shell - what
 > does
 > >> >>>> that say?
 > >> >> Still not found. However, adding it to ~/.tcshrc seems to fix the
 > >> >> problem. That makes sense, but leaves two questions:
 > >> >>
 > >> >> 1) Why am I able to run pdflatex (without specifying the path) just
 > >> >> from the shell running in a terminal window?
 > >> >>
 > >> >> 2) What's the point of defining the emacs exec-path, since I needed
 > >> >> to define the shell's PATH variable anyway?
 > >> >>
 > >>
 > >> FWIW, I never define exec-path explicitly: it is set from my $PATH when
 > >> emacs starts.
 > >>
 > >> --
 > >> Nick
 > >>
 > >>
 > >>
 > >>
 > 
 > --
 > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
 > UCT), Dipl. Phys. (Germany)
 > 
 > Centre of Excellence for Invasion Biology
 > Stellenbosch University
 > South Africa
 > 
 > Tel :       +33 - (0)9 53 10 27 44
 > Cell:       +33 - (0)6 85 62 59 98
 > Fax :       +33 - (0)9 58 10 27 44
 > 
 > Fax (D):    +49 - (0)3 21 21 25 22 44
 > 
 > email:      Rainer@krugs.de
 > 
 > Skype:      RMkrug
 > 
 > PGP: 0x0F52F982

Re: pdflatex not found?

[Charles C. Berry]

On Mon, 26 Oct 2015, Nick Dokos wrote:

> Peter Davis <pfd@pfdstudio.com> writes:
>
>> Nick Dokos <ndokos@gmail.com> writes:
>>
>>
>>> Peter Davis <pfd@pfdstudio.com> writes:
>>>
>>>> I'm trying to export PDF from org, but I'm getting the error:
>>>>
>>>> pdflatex: Command not found. [3 times]
>>>>
>>>> I've checked the definition of exec-path, and it includes
>>>> "/usr/texbin", which is where tcsh tells me the executable is.
>>>>
>>>> Any ideas?
>>>>
>>>
>>> Backtrace?
>>
>> Sorry. Here's the backtrace:
>>
>> Debugger entered--Lisp error: (error "PDF file ./test.pdf wasn't produced")
>>   signal(error ("PDF file ./test.pdf wasn't produced"))
>>   error("PDF file ./test.pdf wasn't produced")
>>   org-latex-compile("./test.tex")
>>   #[(file) "\301\b!\207" [file org-latex-compile] 2]("./test.tex")
>>   org-export-to-file(latex "./test.tex" nil nil nil nil nil #[(file)
>> "\301\b!\207" [file org-latex-compile] 2])
>>   org-latex-export-to-pdf(nil nil nil nil)
>>   (org-open-file (org-latex-export-to-pdf nil s v b))
>>   (if a (org-latex-export-to-pdf t s v b) (org-open-file (org-latex-export-to-pdf nil s v b)))
>>   (lambda (a s v b) (if a (org-latex-export-to-pdf t s v b)
>> (org-open-file (org-latex-export-to-pdf nil s v b))))(nil nil nil nil)
>>   org-export-dispatch(nil)
>>   call-interactively(org-export-dispatch nil nil)
>>   command-execute(org-export-dispatch)
>>
>> This seems less useful to me than the *Messages* buffer:
>>
>
> Yes, probably, but if I can get people to submit backtraces when getting
> an error, we can cut down the email volume by a factor of 2.43 (making up
> fictitious data to bolster my case...) In all seriousness, at least it
> shows that you are not going down some strange path.
>
> It's not clear to me why the error message in the message file is different
> from the error message above though.
>
>> Debug on Error enabled globally
>> org-babel-exp processing...
>> executing Dot code block...
>> Wrote /var/folders/d4/xb7t0gbd0f97p6494kz5xzdnmlncz8/T/babel-2213VOW/ob-input-22136yU
>> Code block evaluation complete.
>> Saving file /Users/davisp/Dropbox/HMH/test.tex...
>> Wrote /Users/davisp/Dropbox/HMH/test.tex
>> Processing LaTeX file ./test.tex...
>> pdflatex: Command not found. [3 times]
>> Entering debugger...
>> Mark set
>> End of buffer
>>
>> I did verify that the shell, my default of tcsh, does show pdflatex at
>> the right location, /usr/texbin/pdflatex
>>
>
> In combination, this pretty much says that org-latex-pdf-process was
> called (by examining the code for org-latex-compile) and it is set to
> the default value of invoking pdflatex three times (hence - probably -
> the "command not found 3 times" error), so as I said the standard path.
>
> As others have pointed out, your emacs does not know where to find
> pdflatex, even though your tcsh might. If your emacs is started from a
> tcsh that can find pdflatex, that would be strange; if it is started
> from your desktop environment/window manager, not so much (there are
> many things that could go wrong).
>
> OTOH, if exec-path contains the directory where pdflatex resides, then
> things are a bit screwy: exec-path is used by call-process, which is
> used by shell-command, which is used by org-latex-compile: so pdflatex
> should be found - that's a bit of a mystery.

shell-command (and call-process, I guess) seems not to use exec-path -
at least not always.

For example:

#+BEGIN_SRC emacs-lisp :results output
(shell-command "which ebrowse")
#+END_SRC

fails to find ebrowse even though exec-path leads to it.

And

#+BEGIN_SRC emacs-lisp
(shell-command "echo $PATH" "*path*")
#+END_SRC

shows what (getenv "PATH") yields - not exec-path

Give `setenv' a try.

Best,

Chuck

>
> What happens if you say M-x shell-command RET pdflatex RET?
>
> Somebody suggested running "which pdflatex" in your shell - what does
> that say?
>
> And you say it should be in /usr/texbin - what happens if you invoke
> it with an absolute path: "/usr/texbin/pdflatex" in your shell?
>
> --
> Nick
>
>
>
>

Re: pdflatex not found?

[Peter Davis]

Rainer M Krug <Rainer@krugs.de> writes:

>>
>> Sorry. It's OS X 10.10.5, using GNU Emacs 24.5.1
>
> I thought so.
>
> OK - you have pdflatex in the terminal? If yes, you have to bring the
> PATH from the terminal into emacs. I use
>
> I use the package exec-path-from-shell for this (and use-package in general):
>
> (use-package exec-path-from-shell
>   :ensure t
>   :config 
>   (exec-path-from-shell-initialize)
>   (exec-path-from-shell-copy-env "LC_ALL")
>   (exec-path-from-shell-copy-env "LANG")
>   )
>
> so
> (require 'exec-path-to-shell)
> (exec-path-from-shell-initialize)
>
> should do this.
>

Thanks, Rainer. This also raises a question:

If I run emacs from Finder, which shell governs its behavior? I use both zsh and tcsh in iTerm 2. (

I think I have tcsh set as my default, but I haven't figured out how to get Ruby/Rails, etc. running from there, so I still use zsh
for some development.)

Thanks!
-pd

Re: pdflatex not found?

[Nick Dokos]

Rainer M Krug <Rainer@krugs.de> writes:

> Fatma Başak Aydemir <aydemirfb@gmail.com> writes:
>
>> I do not know the reasons but I had the same problem in the past on OS X.
>
> In from Yosemite onwards, programs started from the finder / spotlight /
> gui (however you call this) do *not* inherit from the .bashrc
> anymore. This caused many problems.

I can understand not inheriting from .bashrc: shells should only use
that for interactive initializations (aliases and such).

$HOME/.profile however is another matter: it is read by a login shell
(in a non-graphical or console environment) and so its settings are
inherited by everybody started from that login shell: that's where env
variables are supposed to be defined and exported. Desktop environments
have to go to some lengths to read it and initialize things but as I
mentioned in my previous message, they *do* do that (on Linux - although
the mechanism varies by distro, hence the "mess" comment).

If OS X does not use $HOME/.profile to initialize the environment of programs
(even in the graphical enviroment), that seems to me to be a serious
bug. 

-- 
Nick

Re: pdflatex not found?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]

Peter Davis <pfd@pfdstudio.com> writes:

> Rainer M Krug <Rainer@krugs.de> writes:
>
>>>
>>> Sorry. It's OS X 10.10.5, using GNU Emacs 24.5.1
>>
>> I thought so.
>>
>> OK - you have pdflatex in the terminal? If yes, you have to bring the
>> PATH from the terminal into emacs. I use
>>
>> I use the package exec-path-from-shell for this (and use-package in general):
>>
>> (use-package exec-path-from-shell
>>   :ensure t
>>   :config 
>>   (exec-path-from-shell-initialize)
>>   (exec-path-from-shell-copy-env "LC_ALL")
>>   (exec-path-from-shell-copy-env "LANG")
>>   )
>>
>> so
>> (require 'exec-path-to-shell)
>> (exec-path-from-shell-initialize)
>>
>> should do this.
>>
>
> Thanks, Rainer. This also raises a question:
>
> If I run emacs from Finder, which shell governs its behavior? I use both zsh and tcsh in iTerm 2. (

To quote from the website
[[https://github.com/purcell/exec-path-from-shell]]:

,----
| Motivation
| 
| Ever find that a command works in your shell, but not in Emacs?
| 
| This happens a lot on OS X, where an Emacs instance started from the GUI
| inherits a default set of environment variables.
| 
| This library works solves this problem by copying important environment
| variables from the user's shell: it works by asking your shell to print
| out the variables of interest, then copying them into the Emacs
| environment.
| 
| Compatibility
| 
| If you use a non-POSIX-standard shell such as tcsh or fish, your shell
| will be asked to execute sh as a subshell in order to print out the
| variables in a format which can be reliably parsed. sh must be a
| POSIX-compliant shell in this case.
| 
| Note that shell variables which have not been exported as environment
| variables (e.g. using the "export" keyword) may not be visible to
| `exec-path-from-shell'.
`----

Maybe this helps you? I have never used anything different than bash and
never Ruby - so I can't help you there.

Cheers,

Rainer

>
> I think I have tcsh set as my default, but I haven't figured out how
> to get Ruby/Rails, etc. running from there, so I still use zsh
> for some development.)
>
> Thanks!
> -pd

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: pdflatex not found?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]

Nick Dokos <ndokos@gmail.com> writes:

> Rainer M Krug <Rainer@krugs.de> writes:
>
>> Fatma Başak Aydemir <aydemirfb@gmail.com> writes:
>>
>>> I do not know the reasons but I had the same problem in the past on OS X.
>>
>> In from Yosemite onwards, programs started from the finder / spotlight /
>> gui (however you call this) do *not* inherit from the .bashrc
>> anymore. This caused many problems.
>
> I can understand not inheriting from .bashrc: shells should only use
> that for interactive initializations (aliases and such).

Right.

>
> $HOME/.profile however is another matter: it is read by a login shell
> (in a non-graphical or console environment) and so its settings are
> inherited by everybody started from that login shell: that's where env
> variables are supposed to be defined and exported. Desktop environments
> have to go to some lengths to read it and initialize things but as I
> mentioned in my previous message, they *do* do that (on Linux - although
> the mechanism varies by distro, hence the "mess" comment).
>
> If OS X does not use $HOME/.profile to initialize the environment of programs
> (even in the graphical enviroment), that seems to me to be a serious
> bug. 

Aparently it is not.

Cheers,

Rainer
-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: pdflatex not found?

[Peter Davis]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]


On 10/27/15 12:45 PM, Rainer M Krug wrote:
>
>     Nick Dokos <ndokos@gmail.com> writes:
>
>
>     If OS X does not use $HOME/.profile to initialize the environment of programs
>     (even in the graphical enviroment), that seems to me to be a serious
>     bug.
>
> Aparently it is not.

According to 
<http://www.science.unitn.it/~fiorella/guidelinux/gs/node153.html>, 
.profile is bash-specific. tcsh has a different set of login/session 
initialization files.

-pd



[-- Attachment #2: Type: text/html, Size: 1083 bytes --]

Re: pdflatex not found?

[Nick Dokos]

Rainer M Krug <Rainer@krugs.de> writes:

> Nick Dokos <ndokos@gmail.com> writes:
>
>> Rainer M Krug <Rainer@krugs.de> writes:
>>
>>> Fatma Başak Aydemir <aydemirfb@gmail.com> writes:
>>>
>>>> I do not know the reasons but I had the same problem in the past on OS X.
>>>
>>> In from Yosemite onwards, programs started from the finder / spotlight /
>>> gui (however you call this) do *not* inherit from the .bashrc
>>> anymore. This caused many problems.
>>
>> I can understand not inheriting from .bashrc: shells should only use
>> that for interactive initializations (aliases and such).
>
> Right.
>
>>
>> $HOME/.profile however is another matter: it is read by a login shell
>> (in a non-graphical or console environment) and so its settings are
>> inherited by everybody started from that login shell: that's where env
>> variables are supposed to be defined and exported. Desktop environments
>> have to go to some lengths to read it and initialize things but as I
>> mentioned in my previous message, they *do* do that (on Linux - although
>> the mechanism varies by distro, hence the "mess" comment).
>>
>> If OS X does not use $HOME/.profile to initialize the environment of programs
>> (even in the graphical enviroment), that seems to me to be a serious
>> bug. 
>
> Aparently it is not.
>

They do things differently at Apple:

http://stackoverflow.com/questions/135688/setting-environment-variables-in-os-x

has some answers: imo, the launchd.conf method should be avoided (it
applies to every user), but the environment.plist method (whatever that
is) seems to be the right solution - and although it did not work for
Spotlight-launched applications (whatever Spotlight is) in 10.5, it
apparently works in 10.6 or later.

As you can imagine, all my knowledge comes from that article and
references therein: take it with the appropriate grain of salt.

Anyway, this is very far from org-mode, so maybe it should be pursued in
a different forum.

--
Nick

Re: pdflatex not found?

[Nick Dokos]

Peter Davis <pfd@pfdstudio.com> writes:

> On 10/27/15 12:45 PM, Rainer M Krug wrote:
>
>         Nick Dokos <ndokos@gmail.com> writes:
>
>         If OS X does not use $HOME/.profile to initialize the environment of programs
>         (even in the graphical enviroment), that seems to me to be a serious
>         bug. 
>         
>     Aparently it is not.
>
> According to <http://www.science.unitn.it/~fiorella/guidelinux/gs/node153.html>, .profile is
> bash-specific. tcsh has a different set of login/session initialization files.
>

No, it does not say that .profile is bash-specific at all: it
just says it's used by bash and not used by tcsh. What *is*
specific to bash is $HOME/.bash_profile.

$HOME/.profile is used by the original Bourne shell and its descendants,
ksh and bash - Wikipedia says it's also used by zsh.  AFAIK, it is
mandated by POSIX. It is not used by csh and its descendants (they use
.login instead).

But when setting up the window environment on Linux, the various scripts
are executed by whatever POSIX shell is available on the system (usually
sh on Linux), because a POSIX shell is supposed to be part of a POSIX
system, so guaranteed to be available (which is not true of csh/tcsh).
Hence .profile is the common denominator.

--
Nick

Re: pdflatex not found?

[Peter Davis]

On 10/27/15 1:50 PM, Nick Dokos wrote:
> Peter Davis <pfd@pfdstudio.com> writes:
>> According to <http://www.science.unitn.it/~fiorella/guidelinux/gs/node153.html>, .profile is
>> bash-specific. tcsh has a different set of login/session initialization files.
>>
> No, it does not say that .profile is bash-specific at all: it
> just says it's used by bash and not used by tcsh. What *is*
> specific to bash is $HOME/.bash_profile.

Sorry.

> But when setting up the window environment on Linux, the various scripts
> are executed by whatever POSIX shell is available on the system (usually
> sh on Linux), because a POSIX shell is supposed to be part of a POSIX
> system, so guaranteed to be available (which is not true of csh/tcsh).
> Hence .profile is the common denominator.

Yes, .profile is the common denominator ... except where it isn't.

Thanks,
-pd

Re: pdflatex not found?

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

Peter Davis <pfd@pfdstudio.com> writes:

> On 10/27/15 1:50 PM, Nick Dokos wrote:
>> Peter Davis <pfd@pfdstudio.com> writes:
>>> According to <http://www.science.unitn.it/~fiorella/guidelinux/gs/node153.html>, .profile is
>>> bash-specific. tcsh has a different set of login/session initialization files.
>>>
>> No, it does not say that .profile is bash-specific at all: it
>> just says it's used by bash and not used by tcsh. What *is*
>> specific to bash is $HOME/.bash_profile.
>
> Sorry.
>
>> But when setting up the window environment on Linux, the various scripts
>> are executed by whatever POSIX shell is available on the system (usually
>> sh on Linux), because a POSIX shell is supposed to be part of a POSIX
>> system, so guaranteed to be available (which is not true of csh/tcsh).
>> Hence .profile is the common denominator.
>
> Yes, .profile is the common denominator ... except where it isn't.

And on OS X everything is different anyway and changes from time to time.

Cheers,

Rainer
>
> Thanks,
> -pd
>
>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

Re: pdflatex not found?

[Alan Schmitt]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

On 2015-10-27 17:06, "Cook, Malcolm" <MEC@stowers.org> writes:

>> 
>  > John Kitchin <jkitchin@andrew.cmu.edu> writes:
>  > 
>  > > This reminds me that I think I have this problem unless I open Emacs from a
>  > > command line.
>  > 
>  > Yup - this is one way of circumvent the problem: by starting emacs from
>  > the command line.
>
> And, just to chime in late in the conversation, if your emacs was installed as
> an mac application using, say, http://emacsformacosx.com/ then you can start
> it from the command line as:
>
> 	open -a /Applications/path/to/emacs
>
> and get the environment variables you expect...

An alternative, that seems to be cross platform, is to populate
variables when emacs start. This is what I do here:

#+begin_src emacs-lisp
;; **** fetch env variables from zshrc
(let ((vars (split-string-and-unquote (shell-command-to-string ". ~/.zshrc; export") "\n")))
  (mapcar (lambda (X) (let ((var_val (split-string-and-unquote X "=")))
                        (setenv (car var_val) (cadr var_val)))) vars)
  (setq exec-path 
        (append
         (split-string-and-unquote (getenv "PATH") ":")
         exec-path)))
#+end_src

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated October 26, 2015, Mauna Loa Obs.): 398.51 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]