From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020314 Description of problem: If I click on the "Gnome paw" (Main menu) then go to "Programs" menu then go to "Graphics" menu and then click on "ImageMagick" entry nothing happens. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.click on Main menu 2.go to Programs Menu 3.go to Graphics Menu 4.click on ImageMagick entry Actual Results: nothing happens Expected Results: ImageMagick should start Additional info: if I type "display" in the gnome terminal then ImageMagick starts just fine.
Since the desktop file doesn't use any KDE specific tags and it works from KDE, I think this is a gnome bug.
I investigated this a bit - according to strace, gnome is running the command "display" fine, but then "display" exits for some reason - no error message given. Here is the end of the strace: 22924 open("/tmp/magicfu3JAt", O_RDONLY|O_LARGEFILE) = 4 22924 fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 22924 mmap2(NULL, 0, PROT_READ, MAP_PRIVATE, 4, 0) = 0 22924 fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 22924 fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 22924 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401d9000 22924 read(4, "", 4096) = 0 22924 fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 22924 close(4) = 0 22924 munmap(0x401d9000, 4096) = 0 22924 rmdir("/tmp/magicfu3JAt") = -1 ENOTDIR (Not a directory) 22924 unlink("/tmp/magicfu3JAt") = 0 22924 _exit(1) = ? Any ideas?
This is VERY odd, since it runs when started in any other way. Is there anything odd gnome does before starting an application, like clearing the environment or killing stdin/stdout/stderr completely? This seems to happen in something executed by display; At least with a quick grep, I can't find anything that would cause this strace snippet in ImageMagick itself.
I figured it out - "display" exits if it gets EOF on stdin. Try "display < /dev/null". I think the panel is correct to set up stdin this this way (it opens /dev/null on stdin).
*** Bug 62162 has been marked as a duplicate of this bug. ***
Hmm... display will accept images streams on standard input for and display them. According to the man page, you are supposed to specify the file as "-" for this to happen, but experiment shows that it does this even if you don't. One fix is to change the command to /usr/X11R6/bin/display SOMEFILE.png perhaps we could use /usr/share/doc/ImageMagick-5.4.3.11/images/magick.png or perhaps we could use a custom image. This fix works for me at least.
*** Bug 55950 has been marked as a duplicate of this bug. ***
*** Bug 63136 has been marked as a duplicate of this bug. ***
Why work around it with weird hacks, it's probably just a simple bug where it gets confused by an immediate EOF on stdin... it's just not handling stdin correctly.
In utilities/display.c, when display is checking for command line arguments and finds that no images are specified on the command line, it does the following: if (!isatty(STDIN_FILENO)) option=(char *) "-"; else option=(char *) "logo:Untitled"; So for non-tty terminals, it tries to read an image from standard out. This behavior is contrary to what the man page says, but I expect that there are some scripts out there that rely on it. You could simply change this to option=(char *) "logo:Untitled"; which would conform to the behavior described in the man page but may break some (arguably ill-written) scripts, or you could change the Gnome launcher command to "display logo:Untitled", which would not break anything. ...or you could check for an eof on stdin before automatically assuming it is an image stream.
s/standard out/standard in/ :-o
since this bug does not seem to be resolved, I suggest to issue an update to ImageMagick package which would remove the gnome menu entry of ImageMagick. that would solve all the problems. having a non-working default menu entry in the GNOME main menu gives a very bad reputation to RedHat Linux distribution.
Created attachment 58304 [details] patch for the ImageMagick-5.4.3.11-1 spec file to fix this problem
*** Bug 66458 has been marked as a duplicate of this bug. ***
*** Bug 65860 has been marked as a duplicate of this bug. ***
this bug is still present in Limbo
Yes, it is present Limbo public beta 1, but the latest ImageMagick rpm (ImageMagick-5.4.7-3 -- not in Limbo public beta 1) does fix this problem.