On Sun, 09 Sep 2012 05:57:45 -0400 Michael Hughes <mary...@compuserve.com> said:
it smells like gdm is .. well.. not being nice woth the freedesktop.org specs: http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html at least with you it isn't. it has worked fine for me in the past with gdm. so its a new change or a patch/change put in fedora 17. note the tryexec section: TryExec Key A .desktop file with a non-empty TryExec field MUST NOT be autostarted if the value of the TryExec key does NOT match with an installed executable program. The value of the TryExec field may either be an absolute path or the name of an executable without any path components. If the name of an executable is specified without any path components then the $PATH environment is searched to find a matching executable program. it does NOT say to EXECUTE it. i ASSUME it's trying to execute it and thus the execution returns an error code (non-0 return) because it cant connect to x at that point. i'm guessing here. if you replace the e exec path in tryexec with a shell script that logs something to /tmp eg: #!/bin/sh echo "tryexec executed at "`date` >> /tmp/tryexeclog and: TryExec=/tmp/tryexeclog.sh (or wherever u put the script) and chmod a+x tmp/tryexeclog.sh and then just bring up gdm and see if that log file gets an entry for the time gdm started... then gdm is actually executing the tryexec... that'd be REALLY bad and is imho a bad bug on gdm's part. it's not sensible to actually try execute the de/wm executable as this can have side-effects and it was never meant to be execed - just found and checked that it actually exists as an executable file. now... if it is checking the path for /usr/local/bin vs /usr/bin - that's just royally STUPID to do that. even more than actually doing an exec. but i suspect you have a bug report to be filed over in fedora land :) > Jeff > > Thanks for the reply. I removed the "TryExec" line from the > "Enlightenment.desktop" file and then E came up without any problems. > Before doing this, I installed XFCE to see if that might initialize > something. This caused the Session menu to appear with XFCE but still no > E. I would guess that the issue is having the target file in > "/usr/local/bin" instead of "/usr/bin". It is probably a bug in the > particular build. I thought I would keep an eye on it and report it if > it doesn't disappear with later updates or if it appears in the 32-bit > build. > > Mike > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
