Async commands in M-x compile

Async commands in M-x compile

[Antoine Levitt]

Hello,

Can someone explain to me why compile doesn't support asynchroneous
commands, and especially why it silently fails instead of displaying an
error message? I don't understand the mechanism involved here.

As a test, try M-x compile with "echo test > ~/test &" or "xclock &".

Thanks!

Antoine

Re: Async commands in M-x compile

[Ken Raeburn]

On Jun 29, 2010, at 18:43, Antoine Levitt wrote:
> Hello,
> 
> Can someone explain to me why compile doesn't support asynchroneous
> commands, and especially why it silently fails instead of displaying an
> error message? I don't understand the mechanism involved here.

The program run -- the shell -- exits (after having started some other program in background).  The compilation command has finished, and exited with an exit status that indicates success.  So, you're done.  I could argue that it "succeeded", though apparently not at doing whatever it is that you think it should do.

> As a test, try M-x compile with "echo test > ~/test &" or "xclock &".

Why would you need something like that?  Compilation mode already lets you continue doing stuff in Emacs while the compilation runs.  And you can use something like "make -j" to run multiple tasks in parallel, without losing track of the exit statuses of subprocesses, like you would with "&".

If you're not actually trying to do compilation, but just run some task in background without monitoring its progress or parsing error messages after failure, there's shell-mode, or you can give shell-command (M-!) a command ending with "&".

Ken

Re: Async commands in M-x compile

[Antoine Levitt]

Ken Raeburn <raeburn@raeburn.org> writes:

> On Jun 29, 2010, at 18:43, Antoine Levitt wrote:
>> Hello,
>> 
>> Can someone explain to me why compile doesn't support asynchroneous
>> commands, and especially why it silently fails instead of displaying an
>> error message? I don't understand the mechanism involved here.
>
> The program run -- the shell -- exits (after having started some other
> program in background).  The compilation command has finished, and
> exited with an exit status that indicates success.  So, you're done.
> I could argue that it "succeeded", though apparently not at doing
> whatever it is that you think it should do.

Yes, I would completely agree with that, except it _doesn't_ start the
program. Try running "xclock &"

>
>> As a test, try M-x compile with "echo test > ~/test &" or "xclock &".
>
> Why would you need something like that?  Compilation mode already lets
> you continue doing stuff in Emacs while the compilation runs.  And you
> can use something like "make -j" to run multiple tasks in parallel,
> without losing track of the exit statuses of subprocesses, like you
> would with "&".
>
> If you're not actually trying to do compilation, but just run some
> task in background without monitoring its progress or parsing error
> messages after failure, there's shell-mode, or you can give
> shell-command (M-!) a command ending with "&".

Well, to be fair, I'm actually using compilation for another purpose
than what it was built for. I want to perform the action "compile latex,
if there is already a viewer, bring it to the front, if not, run one",
ie,

rubber -d main && (wmctrl -a main.pdf || gnome-open main.pdf &)

But the last bit does not work, ie it doesn't run the viewer, the same
as when I do "xclock &", which just silently returns success without
starting the program, and I don't understand this behaviour.

>
> Ken

Re: Async commands in M-x compile

[Dan Nicolaescu]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> Ken Raeburn <raeburn@raeburn.org> writes:
>
>> On Jun 29, 2010, at 18:43, Antoine Levitt wrote:
>>> Hello,
>>> 
>>> Can someone explain to me why compile doesn't support asynchroneous
>>> commands, and especially why it silently fails instead of displaying an
>>> error message? I don't understand the mechanism involved here.
>>
>> The program run -- the shell -- exits (after having started some other
>> program in background).  The compilation command has finished, and
>> exited with an exit status that indicates success.  So, you're done.
>> I could argue that it "succeeded", though apparently not at doing
>> whatever it is that you think it should do.
>
> Yes, I would completely agree with that, except it _doesn't_ start the
> program. Try running "xclock &"
>
>>
>>> As a test, try M-x compile with "echo test > ~/test &" or "xclock &".
>>
>> Why would you need something like that?  Compilation mode already lets
>> you continue doing stuff in Emacs while the compilation runs.  And you
>> can use something like "make -j" to run multiple tasks in parallel,
>> without losing track of the exit statuses of subprocesses, like you
>> would with "&".
>>
>> If you're not actually trying to do compilation, but just run some
>> task in background without monitoring its progress or parsing error
>> messages after failure, there's shell-mode, or you can give
>> shell-command (M-!) a command ending with "&".
>
> Well, to be fair, I'm actually using compilation for another purpose
> than what it was built for. I want to perform the action "compile latex,
> if there is already a viewer, bring it to the front, if not, run one",
> ie,
>
> rubber -d main && (wmctrl -a main.pdf || gnome-open main.pdf &)

Have you tried AUCTeX?  It should be able to do this by default ...
Alternatively, you can use the infrastructure in tex.el to accomplish
what you want.

Re: Async commands in M-x compile

[Antoine Levitt]

Dan Nicolaescu <dann@gnu.org> writes:

> Antoine Levitt <antoine.levitt@gmail.com> writes:
>
>> Ken Raeburn <raeburn@raeburn.org> writes:
>>
>>> On Jun 29, 2010, at 18:43, Antoine Levitt wrote:
>>>> Hello,
>>>> 
>>>> Can someone explain to me why compile doesn't support asynchroneous
>>>> commands, and especially why it silently fails instead of displaying an
>>>> error message? I don't understand the mechanism involved here.
>>>
>>> The program run -- the shell -- exits (after having started some other
>>> program in background).  The compilation command has finished, and
>>> exited with an exit status that indicates success.  So, you're done.
>>> I could argue that it "succeeded", though apparently not at doing
>>> whatever it is that you think it should do.
>>
>> Yes, I would completely agree with that, except it _doesn't_ start the
>> program. Try running "xclock &"
>>
>>>
>>>> As a test, try M-x compile with "echo test > ~/test &" or "xclock &".
>>>
>>> Why would you need something like that?  Compilation mode already lets
>>> you continue doing stuff in Emacs while the compilation runs.  And you
>>> can use something like "make -j" to run multiple tasks in parallel,
>>> without losing track of the exit statuses of subprocesses, like you
>>> would with "&".
>>>
>>> If you're not actually trying to do compilation, but just run some
>>> task in background without monitoring its progress or parsing error
>>> messages after failure, there's shell-mode, or you can give
>>> shell-command (M-!) a command ending with "&".
>>
>> Well, to be fair, I'm actually using compilation for another purpose
>> than what it was built for. I want to perform the action "compile latex,
>> if there is already a viewer, bring it to the front, if not, run one",
>> ie,
>>
>> rubber -d main && (wmctrl -a main.pdf || gnome-open main.pdf &)
>
> Have you tried AUCTeX?  It should be able to do this by default ...
> Alternatively, you can use the infrastructure in tex.el to accomplish
> what you want.

I used to use AUCTeX, but there is a number of things it doesn't do (at
least, not without extensive coding, which I'm not prepared to
do). Rubber checks for dependencies (including \input and
\includegraphics), runs bibtex, and runs the right amount of times, all
in one run. It also produces clean error output, which is something that
has bugged me with AUCTeX. It's true that AUCTeX is able to run viewers
etc, but I'm looking for a one-command solution, which I achieved with
this shell line.

Re: Async commands in M-x compile

[Dan Nicolaescu]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> Dan Nicolaescu <dann@gnu.org> writes:
>
>> Antoine Levitt <antoine.levitt@gmail.com> writes:
>>
>>> Ken Raeburn <raeburn@raeburn.org> writes:
>>>
>>>> On Jun 29, 2010, at 18:43, Antoine Levitt wrote:
>>>>> Hello,
>>>>> 
>>>>> Can someone explain to me why compile doesn't support asynchroneous
>>>>> commands, and especially why it silently fails instead of displaying an
>>>>> error message? I don't understand the mechanism involved here.
>>>>
>>>> The program run -- the shell -- exits (after having started some other
>>>> program in background).  The compilation command has finished, and
>>>> exited with an exit status that indicates success.  So, you're done.
>>>> I could argue that it "succeeded", though apparently not at doing
>>>> whatever it is that you think it should do.
>>>
>>> Yes, I would completely agree with that, except it _doesn't_ start the
>>> program. Try running "xclock &"
>>>
>>>>
>>>>> As a test, try M-x compile with "echo test > ~/test &" or "xclock &".
>>>>
>>>> Why would you need something like that?  Compilation mode already lets
>>>> you continue doing stuff in Emacs while the compilation runs.  And you
>>>> can use something like "make -j" to run multiple tasks in parallel,
>>>> without losing track of the exit statuses of subprocesses, like you
>>>> would with "&".
>>>>
>>>> If you're not actually trying to do compilation, but just run some
>>>> task in background without monitoring its progress or parsing error
>>>> messages after failure, there's shell-mode, or you can give
>>>> shell-command (M-!) a command ending with "&".
>>>
>>> Well, to be fair, I'm actually using compilation for another purpose
>>> than what it was built for. I want to perform the action "compile latex,
>>> if there is already a viewer, bring it to the front, if not, run one",
>>> ie,
>>>
>>> rubber -d main && (wmctrl -a main.pdf || gnome-open main.pdf &)
>>
>> Have you tried AUCTeX?  It should be able to do this by default ...
>> Alternatively, you can use the infrastructure in tex.el to accomplish
>> what you want.
>
> I used to use AUCTeX, but there is a number of things it doesn't do (at
> least, not without extensive coding, which I'm not prepared to
> do). 

Ask the AUCTeX list, using your preferred command should be one or two
lines of code, or just customization.

> Rubber checks for dependencies (including \input and
> \includegraphics), runs bibtex, and runs the right amount of times, all
> in one run. It also produces clean error output, which is something that
> has bugged me with AUCTeX. It's true that AUCTeX is able to run viewers
> etc, but I'm looking for a one-command solution, which I achieved with
> this shell line.

Then just run that command using one of the methods that were shown in
this thread.

Re: Async commands in M-x compile

[Antoine Levitt]

Dan Nicolaescu <dann@gnu.org> writes:

> Antoine Levitt <antoine.levitt@gmail.com> writes:
>
>> Dan Nicolaescu <dann@gnu.org> writes:
>>
>>> Antoine Levitt <antoine.levitt@gmail.com> writes:
>>>
>>>> Ken Raeburn <raeburn@raeburn.org> writes:
>>>>
>>>>> On Jun 29, 2010, at 18:43, Antoine Levitt wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> Can someone explain to me why compile doesn't support asynchroneous
>>>>>> commands, and especially why it silently fails instead of displaying an
>>>>>> error message? I don't understand the mechanism involved here.
>>>>>
>>>>> The program run -- the shell -- exits (after having started some other
>>>>> program in background).  The compilation command has finished, and
>>>>> exited with an exit status that indicates success.  So, you're done.
>>>>> I could argue that it "succeeded", though apparently not at doing
>>>>> whatever it is that you think it should do.
>>>>
>>>> Yes, I would completely agree with that, except it _doesn't_ start the
>>>> program. Try running "xclock &"
>>>>
>>>>>
>>>>>> As a test, try M-x compile with "echo test > ~/test &" or "xclock &".
>>>>>
>>>>> Why would you need something like that?  Compilation mode already lets
>>>>> you continue doing stuff in Emacs while the compilation runs.  And you
>>>>> can use something like "make -j" to run multiple tasks in parallel,
>>>>> without losing track of the exit statuses of subprocesses, like you
>>>>> would with "&".
>>>>>
>>>>> If you're not actually trying to do compilation, but just run some
>>>>> task in background without monitoring its progress or parsing error
>>>>> messages after failure, there's shell-mode, or you can give
>>>>> shell-command (M-!) a command ending with "&".
>>>>
>>>> Well, to be fair, I'm actually using compilation for another purpose
>>>> than what it was built for. I want to perform the action "compile latex,
>>>> if there is already a viewer, bring it to the front, if not, run one",
>>>> ie,
>>>>
>>>> rubber -d main && (wmctrl -a main.pdf || gnome-open main.pdf &)
>>>
>>> Have you tried AUCTeX?  It should be able to do this by default ...
>>> Alternatively, you can use the infrastructure in tex.el to accomplish
>>> what you want.
>>
>> I used to use AUCTeX, but there is a number of things it doesn't do (at
>> least, not without extensive coding, which I'm not prepared to
>> do). 
>
> Ask the AUCTeX list, using your preferred command should be one or two
> lines of code, or just customization.

Yes, except I'd have to adjust the output to check for errors in a
format auctex expects, etc. I'm very happy with compilation, thank you
very much. Using auctex would be of no benefit here.

>
>> Rubber checks for dependencies (including \input and
>> \includegraphics), runs bibtex, and runs the right amount of times, all
>> in one run. It also produces clean error output, which is something that
>> has bugged me with AUCTeX. It's true that AUCTeX is able to run viewers
>> etc, but I'm looking for a one-command solution, which I achieved with
>> this shell line.
>
> Then just run that command using one of the methods that were shown in
> this thread.

Re: Async commands in M-x compile

[Giorgos Keramidas]

On Wed, 30 Jun 2010 11:58:06 +0200, Antoine Levitt <antoine.levitt@gmail.com> wrote:
> Ken Raeburn <raeburn@raeburn.org> writes:
>
>> On Jun 29, 2010, at 18:43, Antoine Levitt wrote:
>>> Hello,
>>> 
>>> Can someone explain to me why compile doesn't support asynchroneous
>>> commands, and especially why it silently fails instead of displaying an
>>> error message? I don't understand the mechanism involved here.
>>
>> The program run -- the shell -- exits (after having started some other
>> program in background).  The compilation command has finished, and
>> exited with an exit status that indicates success.  So, you're done.
>> I could argue that it "succeeded", though apparently not at doing
>> whatever it is that you think it should do.
>
> Yes, I would completely agree with that, except it _doesn't_ start the
> program. Try running "xclock &"

It may be starting the program and killing it too fast, e.g. because the
parent shell reaps its child processes before it exits.  Can you try
running a "nohup sh foo.sh" script that spawns the echo redirection to
see if this is indeed the case?

Re: Async commands in M-x compile

[Thien-Thi Nguyen]

() Antoine Levitt <antoine.levitt@gmail.com>
() Wed, 30 Jun 2010 00:43:49 +0200

   Can someone explain to me why compile doesn't support
   asynchroneous commands, and especially why it silently
   fails instead of displaying an error message? I don't
   understand the mechanism involved here.

   As a test, try M-x compile with
   "echo test > ~/test &" or "xclock &".

I think you mean to ask for "background" (job control) support.
M-x compile is already asynchronous.

If you want to the child process to not exit after it places
its own children processes in the background, you need to
tell it to ‘wait’, e.g.:

  M-x compile
  xclock & wait

Note that if you kill the *compilation* buffer, or interrupt
(via ‘C-c C-k’ aka ‘kill-compilation’) the child process,
most likely all of its children will likewise terminate.
Details depend on shell used and how that is initialized.

thi

Re: Async commands in M-x compile

[Antoine Levitt]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () Antoine Levitt <antoine.levitt@gmail.com>
> () Wed, 30 Jun 2010 00:43:49 +0200
>
>    Can someone explain to me why compile doesn't support
>    asynchroneous commands, and especially why it silently
>    fails instead of displaying an error message? I don't
>    understand the mechanism involved here.
>
>    As a test, try M-x compile with
>    "echo test > ~/test &" or "xclock &".
>
> I think you mean to ask for "background" (job control) support.
> M-x compile is already asynchronous.
>
> If you want to the child process to not exit after it places
> its own children processes in the background, you need to
> tell it to ‘wait’, e.g.:
>
>   M-x compile
>   xclock & wait
>
> Note that if you kill the *compilation* buffer, or interrupt
> (via ‘C-c C-k’ aka ‘kill-compilation’) the child process,
> most likely all of its children will likewise terminate.
> Details depend on shell used and how that is initialized.
>
> thi

I should have been clearer. I really want to start a background job,
but the job doesn't start: when I do xclock &, it just returns without
starting xclock. "xclock & wait" works fine (so does "xclock" for that
matter), but the point is I don't want to wait for the process to
finish.

Re: Async commands in M-x compile

[Thien-Thi Nguyen]

() Antoine Levitt <antoine.levitt@gmail.com>
() Wed, 30 Jun 2010 12:01:27 +0200

   the point is I don't want to wait for the process to finish.

In this case, try ‘M-x shell-command RET xclock & RET’.
Note ampersand.

thi

Re: Async commands in M-x compile

[Antoine Levitt]

Yes, I understand that. What I don't understand is why this command does
not work when using compile.
Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () Antoine Levitt <antoine.levitt@gmail.com>
> () Wed, 30 Jun 2010 12:01:27 +0200
>
>    the point is I don't want to wait for the process to finish.
>
> In this case, try ‘M-x shell-command RET xclock & RET’.
> Note ampersand.
>
> thi

Re: Async commands in M-x compile

[Thien-Thi Nguyen]

() Antoine Levitt <antoine.levitt@gmail.com>
() Wed, 30 Jun 2010 21:30:54 +0200

   Yes, I understand that.
   What I don't understand is why this command does
   not work when using compile.

The two commands are different.  If you expect them to behave
the same, then you need to adjust your expectations.  That may
not help you to understand, but it will make your search for
an explanation easier.  Good luck!

thi

Re: Async commands in M-x compile

[Andreas Schwab]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> Yes, I understand that. What I don't understand is why this command does
> not work when using compile.

It does work, but the command is immediately killed by SIGHUP because
the session is closed.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Async commands in M-x compile

[Antoine Levitt]

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

Ah, thanks, that's it! Using nohup did the trick. Now my one-line solution
to all things latexy is

rubber -d main && (wmctrl -a main.pdf || nohup gnome-open main.pdf >
/dev/null)

which compiles the document and runs a viewer.

Thanks!
Antoine
On 30 June 2010 23:51, Andreas Schwab <schwab@linux-m68k.org> wrote:

> Antoine Levitt <antoine.levitt@gmail.com> writes:
>
> > Yes, I understand that. What I don't understand is why this command does
> > not work when using compile.
>
> It does work, but the command is immediately killed by SIGHUP because
> the session is closed.
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>

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

Re: Async commands in M-x compile

[Stefan Monnier]

>> Yes, I understand that. What I don't understand is why this command does
>> not work when using compile.
> It does work, but the command is immediately killed by SIGHUP because
> the session is closed.

Indeed.  Maybe we should try and change that (if it's even possible).


        Stefan

Re: Async commands in M-x compile

[Jan Djärv]

Stefan Monnier skrev 2010-07-01 03.30:
>>> Yes, I understand that. What I don't understand is why this command does
>>> not work when using compile.
>> It does work, but the command is immediately killed by SIGHUP because
>> the session is closed.
>
> Indeed.  Maybe we should try and change that (if it's even possible).
>

But you want SIGHUP to children if for example Emacs dies.  To change this is 
too complex.  Bash and ksh has disown to "nohup" children, but it is not portable.

	Jan D.