auctex
[Top][All Lists]
Advanced

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

Re: [AUCTeX] "No connection to bus" message in Cygwin Emacs


From: Sebastien Vauban
Subject: Re: [AUCTeX] "No connection to bus" message in Cygwin Emacs
Date: Thu, 11 Jun 2015 11:26:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (cygwin)

Hello Tassilo,

Tassilo Horn <address@hidden> writes:
> Sebastien Vauban <address@hidden> writes:
>
>>   auctex  11.88.6  available  gnu  Integrated environment for *TeX*
>
> Ok, that's what I guessed.  There's not AUCTeX in MELPA anyway.

;-)

>>>>> cygwin bash from the directory containing the master file
>>>>> haie-ecm.tex?
>>>>
>>>> I was expecting a potential problem, but got a PDF as expected:
>>>
>>> Very strange.  So the very same command issued by AUCTeX doesn't
>>> find your tex master wheras it just works from the command line.
>>> The only thing that would explain things is that it's run from
>>> a wrong directory in the AUCTeX case.
>>>
>>> When you do `C-c C-c latex RET'
>>
>> Note -- Reinstalling `auctex' generates the following output:
>>
>> [snip]
>>
>> Is this safe?  There are still quite a lot of warnings (206, if
>> I believe Anzu)...
>
> Yes, that's ugly but expected.  Almost all warnings are about style
> files accessing functions and variables from tex.el, latex.el, or
> font-latex.el.  Those will be available when the style files are
> loaded at runtime but they are not there at compile-time.  One could
> add tons of requires to the styles in order to silence the warnings
> but that would slow down the compilation quite a bit, so it's not
> really worth it.

OK.

>> Back to reapplying your workaround...
>>
>>> followed by `C-c C-l' to switch to the output buffer, what does `C-h
>>> v default-directory' return in there?  It should be the directory
>>> containing haie-ecm.tex.
>>
>> In this buffer:
>>
>>   ┌────
>>   │ Running `LaTeX' on `haie-ecm' with ``pdflatex -file-line-error
>> -interaction=nonstopmode "\input" haie-ecm.tex''
>>   │ This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2014/W32TeX)
>> (preloaded format=pdflatex)
>>   │  restricted \write18 enabled.
>>   │ entering extended mode
>>   │ LaTeX2e <2014/05/01>
>>   │ Babel <3.9l> and hyphenation patterns for 79 languages loaded.
>>   │ ! I can't find file `haie-ecm.tex'.
>>   │ <*> \input haie-ecm.tex
>>   │                        
>>   │ (Press Enter to retry, or Control-Z to exit)
>>   │ Please type another input file name
>>   │ ! Emergency stop.
>>   │ <*> \input haie-ecm.tex
>>   │                        
>>   │ !  ==> Fatal error occurred, no output PDF file produced!
>>   │ Transcript written on texput.log.
>>   │ 
>>   │ TeX Output exited abnormally with code 1 at Wed Jun 10 21:17:07
>>   └────
>>
>> I get the following:
>>
>>   ┌────
>>   │ default-directory is a variable defined in `C source code'.
>>   │ Its value is
>>   │ "/cygdrive/d/Users/sva/Personal/Lettres/"
>>   │ Local in buffer
>> *~/Personal/Business/Real-Estate/Apartment-Scorpios-Boulouris/Lettres/haie-ecm
>> output*; global value is nil
>>   │ 
>>   │   Automatically becomes permanently buffer-local when set.
>>   │   This variable is safe as a file local variable if its value
>>   │   satisfies the predicate `stringp'.
>>   │ 
>>   │ Documentation:
>>   │ Name of default directory of current buffer.  Should end with slash.
>>   │ To interactively change the default directory, use command `cd'.
>>   └────
>>
>> This seems to be what you expected... but, then, there is not obvious
>> reason for why it fails within Emacs...
>
> Eh, no!  Your tex file is
>
>   
> ~/Personal/Business/Real-Estate/Apartment-Scorpios-Boulouris/Lettres/haie-ecm.tex
>
> so I expect the default-directory in that buffer to be
>
>   ~/Personal/Business/Real-Estate/Apartment-Scorpios-Boulouris/Lettres/
>
> Or is that maybe some symlink to
> /cygdrive/d/Users/sva/Personal/Lettres/?

Sorry for the confusion I brought, but I moved my file to a shorter
path, to make things more concise and more clear -- at least, that was
my goal.

So, `default-directory' is well pointing to the right place.  That
wasn't the problem.

>> Euh, well, I may have a hint.  I'm using TeX Live, installed within
>> Windows.  Does it receive a path to the file written in the
>> `/cygdrive/d' way?  If yes, I guess TeX Live does not understand
>> where is the file.
>
> Hm, I think the line
>
>   pdflatex -file-line-error -interaction=nonstopmode "\input" haie-ecm.tex
>
> in the output buffer is literally what's executed...  I'll go
> checking...

Yes, now that I think once again about this, indeed, there is no "full"
path visible, so that shouldn't be the problem.

Another hint could be "^M" characters in the `C-c C-l' output?  See
http://screencast.com/t/TtZqSjKl.

> Ok, so (at least here) `TeX-run-command' will first cd into the
> directory containing the master file, and then it executes
>
>   <TeX-shell> <TeX-shell-command-option> \
>     pdflatex -file-line-error -interaction=nonstopmode \
>     "\input" haie-ecm.tex
>
> where TeX-shell is /bin/sh and TeX-shell-command-option is -c here.  So
> the file is really given as-is without path.

I second you.

> Could you try to run that command from the cygwin bash with the values
> you have for TeX-shell and TeX-shell-command-option?

  ┌────
  │ TeX-shell is a variable defined in `tex-buf.el'.
  │ Its value is "/bin/sh"
  │ 
  │ Documentation:
  │ Name of shell used to parse TeX commands.
  └────

  ┌────
  │ TeX-shell-command-option is a variable defined in `tex-buf.el'.
  │ Its value is "-c"
  │ 
  │ Documentation:
  │ Shell argument indicating that next argument is the command.
  └────

But I do indeed have a problem, as you can see on
http://screencast.com/t/jSqkHkRCc.

While the command

  pdflatex  -file-line-error   -interaction=nonstopmode "\input" haie-ecm.tex

does work from Cygwin, the following does NOT:

  /bin/sh -c "pdflatex  -file-line-error   -interaction=nonstopmode "\input" 
haie-ecm.tex"

and it outputs what you effectively see in the `C-c C-l' buffer.

> But anyway, the problem seems to be that the command is executed from
> the wrong directory as said above.

This does not seem to be the preferred explanation, right?

Best regards,
  Seb

-- 
Sebastien Vauban



reply via email to

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