Subject: FVWM: gmplayer

From: "L.P http://MO-DE.net" <[email-masked]>
Date: Wed, 15 Jan 2003 04:58:57 -0800

I am using fvwm version 2.4.14 and when ever i try to launch "gmplayer" from the "Personal Menu" it freezes the fvwm wm.  If i launch it from terminal inside fvwm wm everything will be fine.

Lex

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 15 Jan 2003 17:43:53 +0000

On 15 Jan 2003 04:58:57 -0800, L.P http://MO-DE.net wrote:
> 
> I am using fvwm version 2.4.14 and when ever i try to launch "gmplayer"
> from the "Personal Menu" it freezes the fvwm wm.  If i launch it from
> terminal inside fvwm wm everything will be fine.

Please post your "Personal Menu" and other relevant parts that launch
gmplayer and freeze fvwm. What do you do to "unfreeze" it, exit X?

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Andy Arbon <[email-masked]>
Date: Wed, 15 Jan 2003 18:24:44 +0000

Hello,

I used to have problems with (g)mplayer. My solution was to launch an
xterm which launches mplayer (Exec exec xterm -iconic -e gmplayer). This
gives mplayer somewhere to display its output, which seems to keep it happy.

Probably not the solution to the problem, but in my case an acceptable
workaround.

Cheers,

Andy

Mikhael Goikhman wrote:
| On 15 Jan 2003 04:58:57 -0800, L.P http://MO-DE.net wrote:
|
|>I am using fvwm version 2.4.14 and when ever i try to launch "gmplayer"
|>from the "Personal Menu" it freezes the fvwm wm.  If i launch it from
|>terminal inside fvwm wm everything will be fine.
|

---

From: Jeremy Slade <[email-masked]>
Date: Wed, 15 Jan 2003 13:26:23 -0700

Andy Arbon writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 

I believe gmplayer has some options to suppress it's output --
e.g. -quiet or somesuch.  That should take care of it.

Jeremy
-- 
Jeremy Slade
Hewlett-Packard Company - Systems & VLSI Technology Division
[email-masked] (970) 898-7881

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 15 Jan 2003 22:17:48 +0000

> e.g. -quiet or somesuch.  That should take care of it.

It does not explain anything. It is perfectly fine for any Exec'd program
to write to stdout or stderr.

Actually, probably the problem is that gmplayer is an interactive program
and reads stdin. I just tried 2.4.14 and it does freeze when I enter:
Exec rm -i /tmp/some-existing-file

Although it is not supported to run interactive programs directly in Exec,
this is a problem with fvwm and it is strange that it is only with 2.4.x.
In 2.5.x it is fine if Exec'd process reads stdin except that this process
is stuck. Anyway, as a workaround try: Exec interactive-prog </dev/null
Or like you wrote: Exec xterm -e interactive-prog.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Wed, 15 Jan 2003 21:05:58 -0500

> Or like you wrote: Exec xterm -e interactive-prog.

I haven't tried it under 2.4.14 yet, but under current CVS it acted
strange.  The windows came up blank, and the little window with
the image of the player only had a title bar.

It acted completely normal when I added "&" to the end of the
command line.

I'm not sure what that means.
-- 
Dan Espen                           E-mail: [email-masked]
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Wed, 15 Jan 2003 21:25:00 -0500

> I'm not sure what that means.

Sorry, bad form to reply to myself.  I think I know what it
means.  I used the function isatty() to detect whether
I was interactive like this:

#include <unistd.h>
#include <stdio.h>

main () {
  printf("stdin is %d\n",isatty(0));
}

Then running this from Fvwm gave 2 different results, with just
plain Exec, you get "1".  With Exec and the ampersand, you get
"0".

---

From: Perry Hutchison <[email-masked]>
Date: Wed, 15 Jan 2003 18:35:52 -0800 (PST)

> plain Exec, you get "1".  With Exec and the ampersand, you get

In a shell which does not support job control (which presumably
includes any non-interactive shell), I suspect a background task's
stdin is redirected from /dev/null.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: RvB <[email-masked]>
Date: Thu, 16 Jan 2003 08:55:34 +0100

> stdin is redirected from /dev/null.

in zsh background jobs are stopped if it wants to read from stdin. at
least for the default configuration, how does bash handle this? :)

bye
	RvB <[email-masked]>
		http://rvb.dyndns.org

---

From: Dan Espen <[email-masked]>
Date: Thu, 16 Jan 2003 08:03:51 -0500

> Probably not the solution to the problem, but in my case an acceptable

There are changes checked in to the development and stable branchs to
fix this.  Thanks for the problem report.

A simpler temporary solution is just:

Exec gmplayer&

---

From: Perry Hutchison <[email-masked]>
Date: Thu, 16 Jan 2003 12:56:10 -0800 (PST)

> least for the default configuration, how does bash handle this? :)

The canonical implementation of job control is csh.  I imagine
others are similar.  However, I don't see how any shell can be
expected to provide job control *when run non-interactively*,
since the whole point of job control is to share the terminal
under interactive user control.

When FVWM performs "Exec foo &" it spawns a non-interactive shell to
interpret "foo &".  Noticing that it is not interactive, that shell
will run foo as a "background task" with /dev/null as stdin, rather
than as a "job" sharing the shell's terminal.

OTOH to perform "Exec xterm -e foo":

  FVWM spawns a non-interactive shell to interpret "xterm -e foo".

  The non-interactive shell spawns xterm with arguments "-e foo".

  xterm allocates a pty, and runs foo with its stdin/stdout/stderr
  connected to the pty.