DVI command not found

[Haines Brown]

When I installed TL2011 on Debian Squeeze, I mistakenly first purged
my old TL2009. As a result, while TL2011 and biber work fine, some
applications no longer work.

For example, muttprint generates the error: "Line 591: LaTeX didn't
work. There's no DVI file". Muttprint did fine before installing
TL2011.

What should I do. I tried reinstalling muttprint, but that didn't
help.

Haines Brown

[Martín Marqués]

No *.log file to look at? For some reason muttprint isn't generating
the .dvi file.

2011/9/5 Haines Brown <hai...@histomat.net>:

> --
> You received this message because you are subscribed to the Google Groups "LaTeX Users Group" group.
> To post to this group, send email to latexus...@googlegroups.com.
> To unsubscribe from this group, send email to latexusersgro...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/latexusersgroup?hl=en.
>
>

--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador

[Haines Brown]

On Mon, Sep 05, 2011 at 08:47:59PM -0300, Mart�n Marqu�s wrote:
> No *.log file to look at? For some reason muttprint isn't generating
> the .dvi file.

No log file for mutt or muttprint, if that is what you mean. The logs
in /var/logs don't seem to have any relevant information.

I'm surprised that muttprint is responsible for generating the .dvi. I
assumed that it looked to the latex command to do this work, and so I
assumed the problem was finding the latex command. The command $ which
latex gives a proper response, but I feared that muttprint looked for
the old location for this command, which I purged.

I might mention that another application that does not work is AUCTeX.
I presently have to issue my tex commands from a terminal. If in
emacs I issue the command "C-c C-c latex", I get the error: "LaTeX:
Problems after [0] pages." This error usually means a path problem,
which is another reason I suspected muttprint couldn't find the latex
command. However:

$ which latex
/home/haines/texlive/2011/bin/i386-linux/latex

$ echo $PATH
/home/haines/texlive/2011/bin/i386-linux:/usr/local/bin:...

I've put DEBUG = "1" into .muttprintrc, but can't test it while
composing this message. I started another session of mutt and tried to
print it. It failed, but was a bit more informative:

...
DEBUG => 1
...
cat: write error: Broken pipe
Muttprint Version 0.73 -- Error
======================================================================

Line 725: Could not print with lpr -Plp:

Not sure what this means. However, it did generate a
/var/muttprint.log (probably I missed it because of its location). It
is a long log that includes old biber information.

This is pdfTeX, Version 3.1415926-2.3-1.40.12 (TeX Live 2011)
restricted \write18 enabled.
entering extended mode
(./mail.tex
LaTeX2e <2011/06/27>

At the end is this:

...
LaTeX Warning: Unused global option(s):
[compat2].

No file mail.aux.
...
(/home/haines/texlive/2011/texmf-dist/tex/latex/base/t1cmtt.fd)

AED: lastpage setting LastPage

LaTeX Warning: Reference `LastPage' on page 1 undefined on input line 53.
[1] (./mail.aux) )
Output written on mail.dvi (1 page, 1928 bytes).
Transcript written on mail.log.
...
[1]
lpr: The printer or class was not found.
Muttprint Version 0.73 -- Error
======================================================================

Line 725: Could not print with lpr -Plp:

Does this mean that muttprint did run pdftex on the mail message to
generate a .dvi file? I looked for the .dvi file. I found suspects in
/tmp. For example:

xdvi-8lU2hW

$ file xdvi-mVfVOS
xdvi-mVfVOS: TeX DVI file (TeX output 2011.02.22:1408\213

$ dvips xdvi-mVfVOS

$ ls | grep ps
...
xdvi-mVfVOS.ps

$ lpr xdvi-mVfVOS.ps

And it prints. So it seems that muttprint is failing to execute dvips
on the temporary dvi file created by muttprint, although dvips is in
the PATH environment:

$ which dvips
/home/haines/texlive/2011/bin/i386-linux/dvips

Haines

[Peter Flynn]

I wouldn't expect it to. You could show us line 591 with some lines of context so that we can see if there is anything obvious there. If you're trying to format email, there is a risk that some email gets sent with bogus encoding information, which will cause subsequent processes (both mailers and LaTeX) to gag on it.

///Peter

[Peter Flynn]

On Tue, Sep 6, 2011 at 3:51 AM, Haines Brown <hai...@histomat.net> wrote:

On Mon, Sep 05, 2011 at 08:47:59PM -0300, Martín Marqués wrote:
> No *.log file to look at? For some reason muttprint isn't generating
> the .dvi file.

No log file for mutt or muttprint, if that is what you mean. The logs
in /var/logs don't seem to have any relevant information.

The log wouldn't be there. It would be wherever muttprint does its work (/tmp if the authors are sensible folk).
 

I'm surprised that muttprint is responsible for generating the .dvi.

It's not. It just calls LaTeX as an inferior shell.
 

I assumed that it looked to the latex command to do this work,

It does.

and so I assumed the problem was finding the latex command.

Could be.
 

The command $ which latex gives a proper response, but I feared that muttprint looked for
the old location for this command, which I purged.

If you have since reinstalled muttprint, then it should have found the new location, provided you have installed LaTeX somewhere that muttprint can find it.
 

I might mention that another application that does not work is AUCTeX.
I presently have to issue my tex commands from a terminal.  If in
emacs I issue the command "C-c C-c latex", I get the error: "LaTeX:
Problems after [0] pages." This error usually means a path problem,
which is another reason I suspected muttprint couldn't find the latex
command.

Sounding more and more likely.
 

However:

 $ which latex
 /home/haines/texlive/2011/bin/i386-linux/latex

 $ echo $PATH
 /home/haines/texlive/2011/bin/i386-linux:/usr/local/bin:...

Is this a shared system (lots of other users logging in) and you have no root access?
If not, why have you installed TeX in your personal home directory?
No wonder nothing else can find it.

To make that work, you would need to rewrite the environment in which muttprint (and probably everything else on your system that uses TeX) to acquire your personal $PATH.
Better, wipe TeX and reinstall it system-wide in /usr/local/texlive/2011/... so that everything can find it.
If you have no root access and can't do that, you'll have to get into some much deeper surgery.
 

I've put DEBUG = "1" into .muttprintrc, but can't test it while
composing this message. I started another session of mutt and tried to
print it. It failed, but was a bit more informative:

 ...
 DEBUG                 => 1
 ...
 cat: write error: Broken pipe
 Muttprint Version 0.73 -- Error
 ======================================================================

 Line 725: Could not print with lpr -Plp:

Not sure what this means.

It means you don't have a printer installed. At least, not in any place that muttprint can find it.
 

However, it did generate a
/var/muttprint.log (probably I missed it because of its location).

/var is a bit unusual but that looks good to know.
 

It
is a long log that includes old biber information.

 This is pdfTeX, Version 3.1415926-2.3-1.40.12 (TeX Live 2011)

OK, at least it's the right version.
 

  restricted \write18 enabled.
 entering extended mode
 (./mail.tex
 LaTeX2e <2011/06/27>

At the end is this:

 ...
 LaTeX Warning: Unused global option(s):
   [compat2].

compat2 is an option in several package, but I see from http://ftp.heanet.ie/pub/CTAN/tex/macros/latex/contrib/geometry/changes.txt that it was removed from the geometry package last year. Perhaps muttprint doesn't know this and is still configured to use it. But it's only a warning, not an error.
 

No file mail.aux.

That is normal on a first run.
 

 (/home/haines/texlive/2011/texmf-dist/tex/latex/base/t1cmtt.fd)

 AED: lastpage setting LastPage

 LaTeX Warning: Reference `LastPage' on page 1 undefined on input line 53.

That too is normal on a first run. It sounds like it's using the lastpage package in order to do "Page n of m" numbering, for which LaTeX requires running twice. Perhaps muttprint doesn't know this.
 

 [1] (./mail.aux) )
 Output written on mail.dvi (1 page, 1928 bytes).

Good news; you have some output.
 

 Transcript written on mail.log.
 ...
 [1]
 lpr: The printer or class was not found.
 Muttprint Version 0.73 -- Error
 ======================================================================

 Line 725: Could not print with lpr -Plp:

Bad news: you can't print it because you have no visible printer (but we knew that already).

Does this mean that muttprint did run pdftex on the mail message to
generate a .dvi file?

Yes.
 

I looked for the .dvi file.

I'd look where the log file is.
 

I found suspects in /tmp. For example:

 xdvi-8lU2hW

Some kind of temporary output.
 

 $ file xdvi-mVfVOS
 xdvi-mVfVOS: TeX DVI file (TeX output 2011.02.22:1408\213

Open it with your DVI viewer and see what it contains.
 

 $ dvips xdvi-mVfVOS

 $ ls | grep ps
 ...
 xdvi-mVfVOS.ps

 $ lpr xdvi-mVfVOS.ps

And it prints. So it seems that muttprint is failing to execute dvips
on the temporary dvi file created by muttprint, although dvips is in
the PATH environment:

No, it's failing to print it because it hasn't been configured to know where your printer is. If the command it uses is piped from dvips, that would account for the broken pipe error you mentioned earlier. It's finding dvips, but failing to pass its output to the printer.
 

///Peter

[Haines Brown]

On Tue, Sep 06, 2011 at 09:06:49AM +0100, Peter Flynn wrote:

> Is this a shared system (lots of other users logging in) and you have no
> root access?

> If not, why have you installed TeX in your personal home directory?
> No wonder nothing else can find it.

Ouch! If my memory is correct, the manual only spoke of these as two
options, and I had no idea that installing in my home directory would
cause such problems.

> To make that work, you would need to rewrite the environment in
> which muttprint (and probably everything else on your system that
> uses TeX) to acquire your personal $PATH. Better, wipe TeX and
> reinstall it system-wide in /usr/local/texlive/2011/... so that
> everything can find it. If you have no root access and can't do
> that, you'll have to get into some much deeper surgery.

I need advice here. To purge my existing installation of TL2011, is it
best simply to use tlmgr to delete all the items it lists as installed
(a paranoid is speaking)?

> > I found suspects in /tmp. For example:
> >
> > xdvi-8lU2hW
> >
> Some kind of temporary output.
>
> > $ file xdvi-mVfVOS
> > xdvi-mVfVOS: TeX DVI file (TeX output 2011.02.22:1408\213
> >
> Open it with your DVI viewer and see what it contains.

Yes, the document displays properly.

> > $ lpr xdvi-mVfVOS.ps

> > And it prints. So it seems that muttprint is failing to execute
> > dvips on the temporary dvi file created by muttprint, although
> > dvips is in the PATH environment:

> No, it's failing to print it because it hasn't been configured to
> know where your printer is. If the command it uses is piped from
> dvips, that would account for the broken pipe error you mentioned
> earlier. It's finding dvips, but failing to pass its output to the
> printer.

Don't understand. I assume that muttprint's finding the printer has
nothing to do with the problem discussed above that muttprint and
AUCTeX don't know the LaTeX executables are in my home directory.

Thanks for your clearing up a number of issues.

Haines

[Peter Flynn]

On Tue, Sep 6, 2011 at 10:15 PM, Haines Brown <hai...@histomat.net> wrote:

Ouch! If my memory is correct, the manual only spoke of these as two
options, and I had no idea that installing in my home directory would
cause such problems.

I'm not completely certain that it does: it just looked it from how you described the problem. And I'm not an expert in how TL installs itself: I may be misunderstanding it here.

Unix-based systems are inherently multi-user capable, so the assumption is usually that you keep software in separate places

• stuff installed by or on behalf of the operating system in /usr/bin
• stuff you add from the outside world in /usr/local/bin
• stuff you write yourself in ~/bin

although this is by no means always adhered to. /usr/share is often used for stuff that multiple users would want access to. But it also means that third-party software needs to be where system utilities will find it, which means binaries either have to be in /usr/bin or in /usr/local/bin, or you have to modify the system path so that every inferior task starts with a path that includes all the places that private installations of software have been put.
 

I need advice here. To purge my existing installation of TL2011, is it

best simply to use tlmgr to delete all the items it lists as installed
(a paranoid is speaking)?

I believe you should simply be able to type rm -rf ~/texlive
This will just remove the whole tree. Assuming a) you didn't put anything personal in any of the lower directories (in which case move them out first) and b) you didn't accept the installation suggestion that TL should symlink all its binaries to /usr/local/bin or ~/bin or somewhere similar (in which case you'll have to delete those entries).

I just installed TL on a server from the links on http://tug.org/texlive/acquire-netinstall.html because the machine doesn't have a DVD drive, and it worked fine: type sudo install-tl.sh and go off for a coffee :-)

However...it does say on the TUG pages:

You do not need to be root (administrator on Windows) to install, use, or manage TeX Live. In fact, we recommend installing it as a normal user

I actually disagree with this in respect of Linux, simply because I have found — as you did — that other applications need to be able to find TeX, and they're not going to look in a user's personal directories for it :-)  This advice may be enough for the simplest user who runs an editor and a viewer and nothing else, but once you migrate to using system utilities (eg muttprint) that assume the presence of TeX, it needs to be visible.

> Open it with your DVI viewer and see what it contains.

Yes, the document displays properly.

Yay :-)
 

> No, it's failing to print it because it hasn't been configured to
> know where your printer is. If the command it uses is piped from
> dvips, that would account for the broken pipe error you mentioned
> earlier. It's finding dvips, but failing to pass its output to the
> printer.

Don't understand. I assume that muttprint's finding the printer has
nothing to do with the problem discussed above that muttprint and
AUCTeX don't know the LaTeX executables are in my home directory.

Closely linked.

1. I don't know how or where your printer is installed, but if it was installed using one of the standard CUPS apps or web clients, then it will have a name, and that name will be in /etc/printcap where applications can find it. The fact that muttprint was looking for a printer called just 'lp' indicates that either the printer really was installed with that name (in which case it should have worked) or that the printer was installed by some other mechanism that has left no trace behind it for other programs to identify it.
2. The error you quoted showed a broken pipe. This means that muttprint was trying to execute a compound command such as dvips -f somefile.dvi | lpr -Plp and that failing to find the dvips command meant that piping the output to lpr for printing would fail, breaking the pipeline.

It's not certain, just deduction, and I may be entirely wrong. Clearly at some stage, muttprint did find dvips, because it produced some PS output; although the fact that the filename started with xdvi- is a little odd. And you can print using lpr with no -P argument, so lpr is presumably picking up the printer name from /etc/printcap in the normal way (so why was muttprint trying to use -Plp, I wonder...)

So perhaps all is OK, and programs can find your TeX, but they may need configuring to do so. Is there a .muttprintrc file with details of where it looks for stuff?

Emacs can certainly be configured in your .emacs file to say where stuff is, although I've never needed to do it. AUCTeX should pick up the location of TeX in the same way.

///Peter

[Haines Brown]

I reinstalled TL2011, this time as root and using default /usr/local/ directory,
and the problem persists.

Line 591 in which file? My .muttrc, .muttprintrc and
/var/muttprint.log files are not that big. That line in .emacs is
irrelevant.

Let me add these old issue:

1. When I reinstalled TL2011 with option -gui=wizard last night, this
time it fell back to the text mode installation without the GUI

2. In emacs, M-x getenv does not show /usr/local/texlive..., although
it is in my $PATH. Should getenv command have included /usr/local/texlive?

In .emacs the relevant lines are:
(add-to-list 'load-path "/usr/local/texlive/2011/bin/i386-linux/")
(setq reftex-plug-into-AUCTeX t)

3. When I do C-c C-c latex on a .tex file with emacs, I get:
"LaTeX: problems after [0] pages."
Apparently this usually indicates a PATH problem.

I start a session of mutt from command line other than the one I'm
using to write this message and try to print a message in it. I get
this error in the terminal:

cat: write error: Broken pipe
Muttprint Version 0.73 -- Error

Line 725: Could not print with lpr -Plp:

I now check the muttprint.log for this muttprint run:

This is pdfTeX, Version 3.1415926-2.3-1.40.12 (TeX Live 2011)

restricted \write18 enabled.
entering extended mode
(./mail.tex
LaTeX2e <2011/06/27>

...

LaTeX Warning: Unused global option(s):
[compat2].

...

*geometry* detected driver: dvips
...
Output written on mail.dvi (1 page, 1700 bytes).
...

lpr: The printer or class was not found.
Muttprint Version 0.73 -- Error

Line 725: Could not print with lpr -Plp:

There are files such as /tmp/xdvi-8lU2hW which I find are in fact DVI
files, which xdvi will display and dvips will convert to .ps files
that I can print. No idea where this mail.dvi file is.

Haines

[Martín Marqués]

2011/9/7 Haines Brown <hai...@histomat.net>:

>  Line 725: Could not print with lpr -Plp:
>
> I now check the muttprint.log for this muttprint run:
>
>  This is pdfTeX, Version 3.1415926-2.3-1.40.12 (TeX Live 2011)
>   restricted \write18 enabled.
>  entering extended mode
>  (./mail.tex
>  LaTeX2e <2011/06/27>
>  ...

If it's using pdftex, then the output will be a PDF file, and not a .dvi.

[Peter Flynn]

On Wed, Sep 7, 2011 at 3:31 PM, Haines Brown <hai...@histomat.net> wrote:

I reinstalled TL2011, this time as root and using default /usr/local/ directory,
and the problem persists.

Oh dear. But muttprint is finding TeX, so the problem must lie deeper in muttprint.
 

Line 591 in which file? My .muttrc, .muttprintrc and
/var/muttprint.log files are not that big. That line in .emacs is
irrelevant.

As I wasn't familiar with muttprint I just installed it (and mutt, which I don't normally use) from the .debs in my Ubuntu repos.

I copied /usr/share/doc/muttprint/sample-muttprintrc-en to ~/.muttprintrc as they suggest, and edited .muttprintrc and changed the default printer "lp" to the name of my printer (if you haven't done this, you probably should: without it, it will try to print on a printer called "lp").

It's not clear what you have to do to use it, and the man page is not very useful, so I opened my mail with mutt, saved the first message to /tmp/testmail, exited mutt, and typed muttprint /tmp/testmail

It's just sitting there doing nothing. Looks like it's broken to me. Lines 591-3 of /usr/bin/muttprint, however, says

unless (-e $Temp{dvi}) {
    fatalError "Latex didn't work. There's no DVI file. If you ".
        "write a bugreport, please include a mail where printing fails.";

This is fairly clear (for Perl): if it hasn't produced a .dvi file, there is a problem and it doesn't know what to do. However, I didn't get that far anyway.
 

Let me add these old issue:

1. When I reinstalled TL2011 with option -gui=wizard last night, this
  time it fell back to the text mode installation without the GUI

I have never used the GUI, so I'm not sure what this was doing. If it ended up installing OK, then I wouldn't worry about it.
 

2. In emacs, M-x getenv does not show /usr/local/texlive..., although
  it is in my $PATH. Should getenv command have included /usr/local/texlive?

No. There is nothing in TeX Live of relevance to Emacs. All TeX does when it processes a .tex file in latex-mode is spawn a subshell and use the value of the internal Emacs command latex-run-command to call out to the operating system "latex..." or "pdflatex..." or whatever it's configured to do, and rely on your PATH to know where LaTeX is.

  In .emacs the relevant lines are:
  (add-to-list 'load-path "/usr/local/texlive/2011/bin/i386-linux/")
  (setq reftex-plug-into-AUCTeX t)

I don't think you want to have that add-to-list in there at all. There is nothing Emacs-y in TeX's bin directories. The Emacs load-path refers to directories where you want it to look for .el or .elc files (Emacs-lisp).

However, if you are using AUCTeX (which I loathe, and refuse to install; sorry :-) then do whatever they say.

3. When I do C-c C-c latex on a .tex file with emacs, I get:
  "LaTeX: problems after [0] pages."
  Apparently this usually indicates a PATH problem.

That error message probably comes from auctex.el or one of its subfiles. It is not one of LaTeX's own error messages. I'm afraid this is beyond my capabilities to answer: you need an AUCTeX expert.
 

I start a session of mutt from command line other than the one I'm
using to write this message and try to print a message in it.

Ah. I opened mutt again and looked at a message and then hit "p".
It printed, but not with muttprint: just a plain-text printout. Presumably there is something I would need to do to tell mutt to pretty-print using muttprint rather than its internal print-plain-text routines...aha, in the documentation it says to add set print_command="muttprint" to my .muttrc -- OK, that's working now: it runs muttprint and produces a nicely-formatted email.
 

I get
this error in the terminal:

 cat: write error: Broken pipe
 Muttprint Version 0.73 -- Error

 Line 725: Could not print with lpr -Plp:

We already know the solution to this: edit your ~/.muttprintrc and change "lp" to the name of your printer. If you don't have a .muttprintrc, copy the one they suggest (I gave the name above).
 

I now check the muttprint.log for this muttprint run:

 This is pdfTeX, Version 3.1415926-2.3-1.40.12 (TeX Live 2011)

  restricted \write18 enabled.
 entering extended mode
 (./mail.tex
 LaTeX2e <2011/06/27>

 ...

 LaTeX Warning: Unused global option(s):
   [compat2]

We know the answer to this as well: muttprint is out of date and is referring to an option that no longer exists. It's in /usr/bin/muttprint at line 1388 in my copy, as an option to the documentclass command. I didn't get an error message, because muttprint did all its work behind the scenes, and in any case it's a warning, not an error.
 

  *geometry* detected driver: dvips
 ...
 Output written on mail.dvi (1 page, 1700 bytes).
 ...

 lpr: The printer or class was not found.
 Muttprint Version 0.73 -- Error
 Line 725: Could not print with lpr -Plp:

There are files such as /tmp/xdvi-8lU2hW which I find are in fact DVI
files, which xdvi will display and dvips will convert to .ps files
that I can print. No idea where this mail.dvi file is.

It was a temporary file anyway. You need to fix that bogus "lp" name first though, then at least it will have something to print onto.

///Peter

[Peter Flynn]

2011/9/7 Martín Marqués <martin....@gmail.com>

If it's using pdftex, then the output will be a PDF file, and not a .dvi.

 

No, only if it is run in PDF mode. pdflatex with the pdf switch off will produce a standard DVI file.
Most TeX systems now use pdftex as the default anyway.

///Peter
 

[Haines Brown]

On Wed, Sep 07, 2011 at 02:10:50PM -0300, Mart�n Marqu�s wrote:
> 2011/9/7 Haines Brown <hai...@histomat.net>:
> > �Line 725: Could not print with lpr -Plp:
> >
> > I now check the muttprint.log for this muttprint run:
> >
> > �This is pdfTeX, Version 3.1415926-2.3-1.40.12 (TeX Live 2011)
> > � restricted \write18 enabled.
> > �entering extended mode
> > �(./mail.tex
> > �LaTeX2e <2011/06/27>
> > �...
>
> If it's using pdftex, then the output will be a PDF file, and not a .dvi.

Yes, but I described what actually happened. I can only guess pdfTeX
was put into its DVI mode for some reason.

Haines

[Peter Flynn]

On Wed, Sep 7, 2011 at 10:01 PM, Haines Brown <hai...@histomat.net> wrote:

Because that's what muttprint does. It generates DVI-->Postscript to print with.

///Peter

[Haines Brown]

On Wed, Sep 07, 2011 at 08:23:23PM +0100, Peter Flynn wrote:

> 3. When I do C-c C-c latex on a .tex file with emacs, I get:
> > "LaTeX: problems after [0] pages."
> > Apparently this usually indicates a PATH problem.
> >
>
> That error message probably comes from auctex.el or one of its subfiles. It
> is not one of LaTeX's own error messages. I'm afraid this is beyond my
> capabilities to answer: you need an AUCTeX expert.

I worked for years without AUCTeX and never missed it. I haven't found
it to be any use and so now uninstall it. Without it I still get the
same error message when in emacs I fun the latex command.

However, the removal of auctex produced some surprises. First
aptitude reported this:

dpkg: dependency problems prevent configuration of muttprint:
muttprint depends on texlive-latex-extra; however:
Package texlive-latex-extra is not configured yet.
dpkg: error processing muttprint (--configure):
dependency problems - leaving unconfigured

Further, I found that I can only run it as root if I provide the full path.

$ which tlmgr
/usr/local/texlive/2011/bin/i386-linux/tlmgr

$ echo $PATH
/usr/local/texlive/2011/bin/i386-linux:/usr/local/bin:...

# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

I've never had to worry about root's own path before, so not sure what
needs to be done. For root, do I just put a line like

PATH=/usr/local/texlive/2011/bin/i386-linux:$PATH; export PATH

into /root/.bashrc, in /etc/bash.bashrc, or append to /etc/profile?

I copied the sample muttprintrc to ~/, with additon of line:

set print_command="muttprint"

But no results.

> > this error in the terminal:
> >
> > cat: write error: Broken pipe
> > Muttprint Version 0.73 -- Error
> >
> > Line 725: Could not print with lpr -Plp:

> We already know the solution to this: edit your ~/.muttprintrc and change
> "lp" to the name of your printer. If you don't have a .muttprintrc, copy the
> one they suggest (I gave the name above).

Sorry, but I have doubts. First, prior to updating TL, I had no
problem with a primitive .muttprintrc file that did not have any
reference to the printer. Second, I can in fact issue the lp command
on a file to print it. I've got /usr/bin/lp. /usr/bin is in user's and
root's environment. My now modified (expanded) .muttprintrc file has
PRINTER="lp". If the lp command is in the environment, when muttprint
calls PRINTER, it should work.

Haines

[Peter Flynn]

On Wed, Sep 7, 2011 at 11:46 PM, Haines Brown <hai...@histomat.net> wrote:

I worked for years without AUCTeX and never missed it. I haven't found
it to be any use and so now uninstall it. Without it I still get the
same error message when in emacs I fun the latex command.

One of the problems with AUCTeX is it's so hard to remove. I don't know what it does internally but it sure messes up Emacs for later use.
 

However, the removal of auctex produced some surprises. First
aptitude reported this:

 dpkg: dependency problems prevent configuration of muttprint:
  muttprint depends on texlive-latex-extra; however:
   Package texlive-latex-extra is not configured yet.

That doesn't sound good, except you said you installed TL from the DVD, so you don't have the texlive-latex-extra.deb anyway. This may be one of the problems. If you stick with the packages in your repos, it will all play nicely together, but it won't be as up-to-date as installing it all from source. What distro of Linux are you using?
 

 dpkg: error processing muttprint (--configure):
  dependency problems - leaving unconfigured

I wouldn't worry too much about this: you can configure muttprint manually.
 

Further, I found that I can only run it as root if I provide the full path.

Run what as root? LaTeX? You wouldn't normally run anything except system utilities as root. For that reason, root's default path does not include TeX's path. You could add it, but why would you want to run LaTeX as root?
 

 $ which tlmgr
 /usr/local/texlive/2011/bin/i386-linux/tlmgr

 $ echo $PATH
 /usr/local/texlive/2011/bin/i386-linux:/usr/local/bin:...

 # echo $PATH
 /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Those all look correct.
 

I've never had to worry about root's own path before, so not sure what
needs to be done.

Nothing.
 

For root, do I just put a line like

 PATH=/usr/local/texlive/2011/bin/i386-linux:$PATH; export PATH

into /root/.bashrc, in /etc/bash.bashrc, or append to /etc/profile?

I don't understand why you want to run LaTeX as root. You could certainly add it as you describe to /root/.bashrc but what are you running that you need to run LaTeX as root?
 

I copied the sample muttprintrc to ~/, with additon of line:

 set print_command="muttprint"

No, that line goes in your .muttrc to tell mutt that you want to use muttprint to print with.
It's the only line in my .muttrc

In .muttprintrc you must change the line PRINTER="lp" to whatever the name of your printer is. Mine is called Betty, so I have PRINTER="Betty"
 

> We already know the solution to this: edit your ~/.muttprintrc and change
> "lp" to the name of your printer. If you don't have a .muttprintrc, copy the
> one they suggest (I gave the name above).

Sorry, but I have doubts. First, prior to updating TL, I had no
problem with a primitive .muttprintrc file that did not have any
reference to the printer. Second, I can in fact issue the lp command
on a file to print it.

Of course you can. This has nothing whatever to do with it.
 

I've got /usr/bin/lp. /usr/bin is in user's and
root's environment. My now modified (expanded) .muttprintrc file has
PRINTER="lp". If the lp command is in the environment, when muttprint
calls PRINTER, it should work.

No. You are confusing the lp command with the name of the printer. It's very unfortunate that the author of muttprint chose the name "lp" for the mnemonic indicating a default printer. You must change that "lp" to the name of your printer (what you called it when you installed it; or perhaps the abbreviated name that your printer installation routine picked for you). It will not work until you do this.

///Peter

[Haines Brown]

I must have been tired. I apparently conveyed some misimpressions.

On Thu, Sep 08, 2011 at 09:22:43PM +0100, Peter Flynn wrote:
> On Wed, Sep 7, 2011 at 11:46 PM, Haines Brown <hai...@histomat.net> wrote:
>
> > I worked for years without AUCTeX and never missed it. I haven't found
> > it to be any use and so now uninstall it. Without it I still get the
> > same error message when in emacs I fun the latex command.
> >
>
> One of the problems with AUCTeX is it's so hard to remove. I don't know what
> it does internally but it sure messes up Emacs for later use.
>
>
> > However, the removal of auctex produced some surprises. First
> > aptitude reported this:
> >
> > dpkg: dependency problems prevent configuration of muttprint:
> > muttprint depends on texlive-latex-extra; however:
> > Package texlive-latex-extra is not configured yet.
> >
>
> That doesn't sound good, except you said you installed TL from the DVD, so
> you don't have the texlive-latex-extra.deb anyway. This may be one of the
> problems. If you stick with the packages in your repos, it will all play
> nicely together, but it won't be as up-to-date as installing it all from
> source. What distro of Linux are you using?

I removed it without remembering that it's now integrated into emacs.
Also, installed TL from CTAN and so do have the texlive-latex-extra, I
think.

> > Further, I found that I can only run it as root if I provide the full path.
> >

"It" here refers to tlmgr.

> > $ which tlmgr
> > /usr/local/texlive/2011/bin/i386-linux/tlmgr
> >
> > $ echo $PATH
> > /usr/local/texlive/2011/bin/i386-linux:/usr/local/bin:...
> >
> > # echo $PATH
> > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

> Those all look correct.

I believe I have a deep environmental problem, and so was here just
experimenting (running tlmgr as root) to expose it. All these, as you
say, seem correct. However:

# tlmgr -gui
bash: tlmgr: command not found
root@engels:/home/haines#

However, # /usr/local/texlive/2011/bin/i386-linux/tlmgr does work. If
this inconsistency is to be expected, I've no idea why.

> I don't understand why you want to run LaTeX as root.

I don't.

> > I copied the sample muttprintrc to ~/, with additon of line:
> >
> > set print_command="muttprint"
> >
>
> No, that line goes in your .muttrc to tell mutt that you want to use
> muttprint to print with.

Again, I misspoke (probably comes from my total absorption every
waking hour with very intense work, when even eating is disruptive; it's
hard to divert my concentration to deal computer problems). I had the
line in the right place.

> In .muttprintrc you must change the line PRINTER="lp" to whatever the name
> of your printer is. Mine is called Betty, so I have PRINTER="Betty"

Thanks. replaced PRINTER="lp" with

PRINTER="HP_LaserJet_1320_series"

and this allowed muttprint to work.

> No. You are confusing the lp *command* with the name of the printer. It's

> very unfortunate that the author of muttprint chose the name "lp" for the

> mnemonic indicating a default printer. You must change that "lp" to the *
> name* of your printer (what you called it when you installed it; or perhaps

> the abbreviated name that your printer installation routine picked for you).
> It will not work until you do this.

Ah, this explains it all! I'm now free to get back to my other
problems. I appreciate all your help.

Haines

[Peter Flynn]

On Fri, Sep 9, 2011 at 2:50 PM, Haines Brown <hai...@histomat.net> wrote:

I must have been tired. I apparently conveyed some misimpressions.

I too seem to have misunderstood things :-)
 

I removed it without remembering that it's now integrated into emacs.

Also, installed TL from CTAN and so do have the texlive-latex-extra, I
think.

No, texlive-latex-extra is the name of a Debian package (as used in Ubuntu and other systems).
TL on CTAN has things called "bundles", and of course "packages" has an entirely different meaning inside LaTeX, but if you installed TL from CTAN then you should not have texlive-latex-extra (unless you have also installed the Debian texlive packages as well, leaving you with two TeX installations).
 

"It" here refers to tlmgr.

OK. Never used it. I install the entire system from the Ubuntu repos, even though it's out of date and doesn't use tlmgr (2009: they are working on 2011) and anything newer that I really need, I download and install from CTAN into my ~/texmf tree.
 

I believe I have a deep environmental problem, and so was here just

experimenting (running tlmgr as root) to expose it.

Aha.
 

All these, as you say, seem correct. However:

 # tlmgr -gui
 bash: tlmgr: command not found

Right. Because the TL binaries directory is not in root's path, so it won't find them when you just give the program name. The search path specifies where to look: if the program is elsewhere it won't see it.
 

However, # /usr/local/texlive/2011/bin/i386-linux/tlmgr does work.

Right. You can always run programs if you give their full path manually.
 

If this inconsistency is to be expected, I've no idea why.

It's not an inconsistency as such: it's the standard way that search paths work (everywhere: DOS/Windows, Macs, Linux, Unix,...).
 

Thanks. replaced PRINTER="lp" with

 PRINTER="HP_LaserJet_1320_series"

and this allowed muttprint to work.

Excellent.

We now return you to your regularly-scheduled programming...

///Peter

[Haines Brown]

On Fri, Sep 09, 2011 at 09:57:34PM +0100, Peter Flynn wrote:

> > Also, installed TL from CTAN and so do have the texlive-latex-extra, I
> > think.
> >
>
> No, texlive-latex-extra is the name of a Debian package (as used in Ubuntu
> and other systems).

Oh, things get complicated :-(. latex-base is on CTAN, but it says
better to install it from my distribution's archive. That is
apparently what I did, and I find that it is automatically installed
with my operating system. But it is TL 2009, while I installed TL2011
from CTAN. Could this version incompatibility be a problem?

> but if you installed TL from CTAN then you should not have
> texlive-latex-extra (unless you have also installed the Debian

> texlive packages as well, leaving you with *two* TeX installations).

To prevent having both TL 2009 and TL 2011, I foolishly tried to
remove the former by hand, and that may be the root of my problem.

> > # tlmgr -gui
> > bash: tlmgr: command not found
> >
>
> Right. Because the TL binaries directory is not in root's path

Yes, I see that now, but somehow had the impression that it was in
root's path. My bad.

> We now return you to your regularly-scheduled programming...

Gott sei Dank!

The initial problem was that in emacs when I issue the "C-c C-c latex"
command on a .tex file, I get the error: "LaTeX: problems after [0]
pages". I issue various tex related commands from command line without
a problem. This error, I gather is usually due to the latex executable
not being in emac's shell's PATH. However:

$ echo $PATH
/usr/local/texlive/2011/bin/i386-linux:/usr/local/bin...

$ which latex
/usr/local/texlive/2011/bin/i386-linux/latex

In ~/.emacs I have (other than a bunch of biber stuff):

(add-to-list 'load-path "/usr/local/texlive/2011/bin/i386-linux/")

Not sure this needed or desirable, but probably harmless. It comes
quite late in the .emacs file. I don't know that I need put anything
into .emacs to handle LaTeX.

The following are to help out AUCTeX, which I don't use anyway:

(setq TeX-auto-save t)
(setq TeX-parse-self t)
(setq-default TeX-master nil)

These lines to enable RefTeX:

(add-hook 'LaTeX-mode-hook 'turn-on-reftex) ; with AUCTeX LaTeX mode
(add-hook 'latex-mode-hook 'turn-on-reftex) ; with Emacs latex mode

To integrate RefTeX with AUCTeX:

(setq reftex-plug-into-AUCTeX t)

Haines

[Peter Flynn]

On Sat, Sep 10, 2011 at 3:17 AM, Haines Brown <hai...@histomat.net> wrote:

Oh, things get complicated :-(. latex-base is on CTAN, but it says
better to install it from my distribution's archive. That is
apparently what I did, and I find that it is automatically installed
with my operating system. But it is TL 2009, while I installed TL2011
from CTAN. Could this version incompatibility be a problem?

Yes, very much. Apart from the difference in packages 2009-2011, the distro setup has stuff in completely different places to the CTAN version. You need to stick with one or the other.
 

To prevent having both TL 2009 and TL 2011, I foolishly tried to

remove the former by hand, and that may be the root of my problem.

Removing the system-installed stuff by hand may cause problems if you now go to the system installer (is this Ubuntu or what? And which version?) because if you try to remove the package, it won't find it. You may be able to force it to remove it despite that by using aptitude from the command line with some kind of --force argument, but I've never done that, so you'd need advice from one of the Linux forums.
 

The initial problem was that in emacs when I issue the "C-c C-c latex"

OK, that's an AUCTeX command, I think. Regular Emacs latex-mode uses C-c C-f
 

command on a .tex file, I get the error: "LaTeX: problems after [0]
pages". I issue various tex related commands from command line without
a problem. This error, I gather is usually due to the latex executable
not being in emac's shell's PATH. However:

It will be, if it's in your own path, and you are running Emacs from your own account.
It won't be if you run it as root. All Emacs needs is to trust that when it spawns a shell and says "latex" that the system will find LaTeX and run it.
 

In ~/.emacs I have (other than a bunch of biber stuff):

 (add-to-list 'load-path "/usr/local/texlive/2011/bin/i386-linux/")

That won't achieve anything, AFAIK. The Emacs load-path is used for finding Emacs .el (mode) files. It has nothing whatever to do with finding system executables.
 

Not sure this needed or desirable, but probably harmless.

Proably. There just aren't any .el or .elc files in that directory (obviously), so all it will do is slow things down fractionally if it ever tries searching it for anything.
 

It comes
quite late in the .emacs file.

There should be a first line in .emacs saying something like (mine):

(setq load-path (cons (expand-file-name "/usr/share/emacs/site-lisp") load-path))

This is what tells Emacs where to find any additional Emacs modes you may add. For example, my site-lisp directory contains things like psgml-mode, xml-mode. xsl-ide-mode and a bunch of others.
 

I don't know that I need put anything into .emacs to handle LaTeX.

No, you shouldn't need anything except TeX installed and usable from your own command line (which means that the latex command and others are in your path.
 

The following are to help out AUCTeX, which I don't use anyway:

Right.
 

These lines to enable RefTeX:

I can't speak for that as I have never used it.

///Peter

[Haines Brown]

I haven't solved the problem, but I've been able to at least define it
more sharply. I have two ways to start emacs: from a terminal and from
a key combination macro defined in ~/fluxbox/keys. Strangely, each
method gives emacs a different environment.

Starting emacs from xterm gives emacs the environment that I want. It
includes the texlive path and I have access to the LaTeX commands I
need. However, I normally start emacs with a key combo defined in
~/.fluxbox/keys (so I'm able readily to select different emacs
configuration files for different purposes). The one relevant here is:

Control Mod1 e :ExecCommand xterm -e emacs &

When I start emacs this way (Ctl-Alt-e), texlive is strangely missing
in the emacs environment. Since the macro is based on xterm, I've no
idea how fluxbox manages to remove the texlive portion of it unless
somehow it redefines the environment to accord with /etc/profile. I
have not tried appending

PATH=/usr/local/texlive/2011/bin/i386-linux:$PATH; export PATH

to the /etc/profile file. It probably would be a workaround, but I
shouldn't have to do it.

On Sat, Sep 10, 2011 at 10:29:16PM +0100, Peter Flynn wrote:
> On Sat, Sep 10, 2011 at 3:17 AM, Haines Brown <hai...@histomat.net> wrote:
>
> > Oh, things get complicated :-(. latex-base is on CTAN, but it says
> > better to install it from my distribution's archive. That is
> > apparently what I did, and I find that it is automatically installed
> > with my operating system. But it is TL 2009, while I installed TL2011
> > from CTAN. Could this version incompatibility be a problem?
>
> Yes, very much. Apart from the difference in packages 2009-2011, the distro
> setup has stuff in completely different places to the CTAN version. You need
> to stick with one or the other.

So are you are saying that if I install TL2011 from CTAN (because
current Debian archive only supplies TL2009, and thus does not readily
support biber), I should also install latex-base from there as well? I
don't see how this could have anything to do with the environment
inconsistency described above.

...

> > command on a .tex file, I get the error: "LaTeX: problems after [0]
> > pages". I issue various tex related commands from command line without
> > a problem. This error, I gather is usually due to the latex executable
> > not being in emac's shell's PATH. However:
> >
>
> It will be, if it's in your own path, and you are running Emacs from your
> own account.
> It won't be if you run it as root. All Emacs needs is to trust that when it
> spawns a shell and says "latex" that the system will find LaTeX and run it.

My comments above seem to have narrowed things down a bit. That is, starting
emacs from fluxbox macro does not provide emacs with an adequate environment.

> > In ~/.emacs I have (other than a bunch of biber stuff):
> >
> > (add-to-list 'load-path "/usr/local/texlive/2011/bin/i386-linux/")
> >
>
> That won't achieve anything, AFAIK. The Emacs load-path is used for finding
> Emacs .el (mode) files. It has nothing whatever to do with finding system
> executables.

I commented the line and find it is not needed, but doing so did not
help, either.

> > It comes
> > quite late in the .emacs file.
>
> There should be a first line in .emacs saying something like (mine):
>
> (setq load-path (cons (expand-file-name "/usr/share/emacs/site-lisp")
> load-path))

Not quite what I have:

(setq load-path (nconc (list "~/lisp") load-path))
(setq load-path (append load-path (list
"~/elisp"
"~/elisp/bbdb"
"~/elisp/html-helper-mode"
"~/elisp/dictionary"
"~/elisp/tex"
"~/elisp/w3m/"
)))

I assume (hope) these are functionally the same.

Haines

[Peter Flynn]

On Sun, Sep 11, 2011 at 1:05 PM, Haines Brown <hai...@histomat.net> wrote:

I haven't solved the problem, but I've been able to at least define it
more sharply. I have two ways to start emacs: from a terminal and from
a key combination macro defined in ~/fluxbox/keys. Strangely, each
method gives emacs a different environment.

I just click on an icon (Ubuntu 11.04). But typing emacs & from a terminal will always work. I've never used fluxbox though. You still haven't told me what Linux distro you are using, though. Is there some secret about this?
 

Starting emacs from xterm gives emacs the environment that I want. It
includes the texlive path and I have access to the LaTeX commands I
need. However, I normally start emacs with a key combo defined in
~/.fluxbox/keys (so I'm able readily to select different emacs
configuration files for different purposes). The one relevant here is:

 Control Mod1 e :ExecCommand xterm -e emacs &

I have no idea what facilities fluxbox provides. It looks sane.
 

When I start emacs this way (Ctl-Alt-e), texlive is strangely missing

in the emacs environment.Since the macro is based on xterm, I've no

idea how fluxbox manages to remove the texlive portion of it unless
somehow it redefines the environment to accord with /etc/profile. I
have not tried appending

Me neither. You need to talk to the fluxbox people about this.
 

So are you are saying that if I install TL2011 from CTAN (because
current Debian archive only supplies TL2009, and thus does not readily
support biber), I should also install latex-base from there as well? I
don't see how this could have anything to do with the environment
inconsistency described above.

I don't understand why you are treating latex-base as something special.
If you install a full distro of TeX, you'll get everything you need, including LaTeX, which includes latex-base. My usual recommendation these days (disk space being plentiful and cheap) is just to install the whole thing and be done with it.
 

My comments above seem to have narrowed things down a bit. That is, starting
emacs from fluxbox macro does not provide emacs with an adequate environment.

If Emacs started from fluxbox gets no response (or an error) from issuing the "latex" command, then fluxbox's way of starting Emacs is broken.
 

I commented the line and find it is not needed, but doing so did not

help, either.

Nor would it. It's just irrelevant.
 

> (setq load-path (cons (expand-file-name "/usr/share/emacs/site-lisp")
> load-path))

Not quite what I have:

 (setq load-path (nconc (list "~/lisp") load-path))

This is some kind of personal Lisp directory, I guess.
 

 (setq load-path (append load-path (list
       "~/elisp"
       "~/elisp/bbdb"
       "~/elisp/html-helper-mode"
       "~/elisp/dictionary"
       "~/elisp/tex"
       "~/elisp/w3m/"
 )))

You have a lot of personal elisp directories. Also fine, I assume.
 

I assume (hope) these are functionally the same.

Maybe. I've never seen them expressed that way. I just put all extra .el files into /usr/share/emacs/site-lisp (which was created for the purpose when I installed Emacs from the Ubuntu repos), and byte-compile them in situ if needed. But Emacs doesn't care where they are, so long as they are visible in the load-path.

But that just makes sure than when you visit a .tex file, it fires up tex-mode or latex-mode (or AUCTeX, if you use it). Those modes include a keystroke or menu command that makes Emacs run [La]TeX on the current buffer: the whole thing is at that point handed over to the operating system to run, and whatever Emacs mode you are in reproduces the shell output, or (in the case of AUCTeX) watches for the creation of the log file, and reports on it.

All this has nothing whetever to do with where TeX is installed, though. Emacs simply relies on the command "latex" being available to the shell.

///Peter

[Haines Brown]

On Sun, Sep 11, 2011 at 04:03:05PM +0100, Peter Flynn wrote:
> On Sun, Sep 11, 2011 at 1:05 PM, Haines Brown <hai...@histomat.net> wrote:
>
> > I haven't solved the problem, but I've been able to at least define it
> > more sharply. I have two ways to start emacs: from a terminal and from
> > a key combination macro defined in ~/fluxbox/keys. Strangely, each
> > method gives emacs a different environment.
> >
>
> I just click on an icon (Ubuntu 11.04). But typing emacs & from a terminal
> will always work. I've never used fluxbox though. You still haven't told me
> what Linux distro you are using, though. Is there some secret about this?

Sorry about that. "Debian" was in my previous message, but rather
hidden by all my crud. I'm running Debian Squeeze.

I don't have any "icons" (I run without any desktop environment), but
readily start a terminal with a fluxbox macro. Fluxbox does have a
menu hierarchy raised by RMB that includes access to terminals, but I
don't use it becaue I avoid the mouse.

Does emacs have an icon in a desktop environment, and did you mean
that I click it? But my question is in a fluxbox context, for raising
a terminal with a fluxbox macro and using it to start emacs gives me a
different environment than if I start emacs directly with the fluxbox
macro for it. However, there is nothing in fluxbox having to do with
environment. It only defines windows and supports some simple keyboard
macros to access executables.

> Me neither. You need to talk to the fluxbox people about this.

Yes, that I'll obviously have to do. The xterm macro is simply:

Control Mod1 e :ExecCommand xterm -e emacs &

This cuts texlive from emacs' environment, but if I run the command
$ xterm -e emacs, the environment is what it should be.

> If Emacs started from fluxbox gets no response (or an error) from issuing
> the "latex" command, then fluxbox's way of starting Emacs is broken.

That is a conclusion I'm coming to.

> You have a lot of personal elisp directories. Also fine, I assume.
>
> > I assume (hope) these are functionally the same.

No problem at that end.

Peter, I've reached the end of your patience, I'm sure. It seems I
must raise the issue in the fluxbox forum, and I'll not continue to
make your life complicated. All your help is much appreciated.

Haines

[Peter Flynn]

On Sun, Sep 11, 2011 at 7:57 PM, Haines Brown <hai...@histomat.net> wrote:

Sorry about that. "Debian" was in my previous message, but rather
hidden by all my crud. I'm running Debian Squeeze.

No, I'm sorry, I should have read more carefully.
 

I don't have any "icons" (I run without any desktop environment),

Ah, OK. Makes sense.
 

but readily start a terminal with a fluxbox macro. Fluxbox does have a
menu hierarchy raised by RMB that includes access to terminals, but I

don't use it because I avoid the mouse.

I have a small difficulty with extended typing, so I tend to use the mouse more.
 

Does emacs have an icon in a desktop environment, and did you mean
that I click it?

Yes, if you install Emacs from the system's package manager (eg dpkg, apt, Synaptic, or whatever) then it adds Emacs to the menu of installed programs, and you can drag the icon out onto the desktop, or into your tool bar ("panel" or "dock" or whatever your GUI-of-choice calls it). I assume it makes the addition to such menus if you have a graphical desktop installed, even if you are not actually using it at the time you install an application, but I have never tested that.
 

But my question is in a fluxbox context, for raising
a terminal with a fluxbox macro and using it to start emacs gives me a
different environment than if I start emacs directly with the fluxbox
macro for it. However, there is nothing in fluxbox having to do with
environment. It only defines windows and supports some simple keyboard
macros to access executables.

Right, but xterm is capable of inheriting your login environment (eg .bashrc or .profile or whatever) each time you fire up an xterm, in the same way that su - does.
 

> Me neither. You need to talk to the fluxbox people about this.

Yes, that I'll obviously have to do. The xterm macro is simply:

 Control Mod1 e :ExecCommand xterm -e emacs &

A little poking reveals that the -ls argument to xterm provides the environment of the login shell, but it won't work with -e because there might be conflicts. The man page suggests that you try

Control Mod1 e :ExecCommand xterm -e /bin/bash -l -c "emacs" &

But what happens if you just use

Control Mod1 e :ExecCommand emacs &

Does that open Emacs in a window without going through an xterm?

This cuts texlive from emacs' environment, but if I run the command

$ xterm -e emacs, the environment is what it should be.

Pass on that. You need someone who knows more X than I do.
 

Peter, I've reached the end of your patience, I'm sure. It seems I
must raise the issue in the fluxbox forum, and I'll not continue to
make your life complicated. All your help is much appreciated.

Not a problem, it's always a learning experience. Thanks too for your patience.

///Peter

[Haines Brown]

On Sun, Sep 11, 2011 at 10:13:11PM +0100, Peter Flynn wrote:

> Yes, if you install Emacs from the system's package manager (eg
> dpkg, apt, Synaptic, or whatever) then it adds Emacs to the menu of
> installed programs, and you can drag the icon out onto the desktop,
> or into your tool bar ("panel" or "dock" or whatever your
> GUI-of-choice calls it). I assume it makes the addition to such
> menus if you have a graphical desktop installed, even if you are not
> actually using it at the time you install an application, but I have
> never tested that.

This is largely news to me. Interesting. My education seems to have
stopped after VAX and DOS.

It seems that xterm started by Fluxbox macro does not source
~/.bashrc, but instead picks just the environment defined by
/etc/profile. This is true of these lines in Fluxbox:

Control Mod1 e :ExecCommand xterm -e emacs &

Control Mod1 e :ExecCommand emacs

However, the line you suggested solved the problem:

Control Mod1 e :ExecCommand xterm -e /bin/bash -l -c "emacs" &

I suspect there's some internal damage in fluxbox that remains a
mystery (xterm must be raised by macro, but not working in fluxbox
menu), but thanks to your help I've now got a work-around. Thank you
again.

Haines