> I can't reproduce this here.
> my steps:
> 1) + L to lock the screen
> 2) enter my password to unlock the screen
> 3) + Ins, which does `exec Eterm`
>
> This doesn't crash here. Am I following the right steps?
yeah... strange... i have the following modules loaded and enabled:
dropshadow, cloc
Hi!
After returning from a locked desktop, any command executed as an
action (keyboard shortcut - exec ) seems to trigger a crash. Can
anyone confirm this behaviour? Further, on doing a restart using the
crash dialog displayed, any command executed seems to leave zombie
processes after the command
> On the other hand, I can see that allowing programs to ask ecore_exe
> to use /bin/sh instead of whatever shell the user prefers to use would
> be a good idea.
+1. This is what system in the standard C library does as well. This
way, we can assure the client that we would be executing using the
> What happens if a setuid/setgid app is talked into loading a malicious
> loader? The hard-coded method is far safer. If you need loaders
> elsewhere, change PACKAGE_LIB_DIR at build time.
Correct me if I am wrong, but exposing an API to change the loader
path will essentially transfer security
Hi!
I don't know if this has been already discussed here... a search of
the archives failed to reveal anything though.
focus_last_focused_per_desktop doesn't seem to work well when sticky
windows are present. Trouble is, focus_stack is a global focus stack
rather than a per-desk variable, and henc
> to be able to install translations as a user in ~/.e/ AS WELL as on the
> system, so you dont need root/superuser access to add language support, and
> still support the existing gettext system. creating a whole lot of symlinks
> wastes inodes for a system that doesnt handle multiple base dir
> Also, I understand the limitation for my validation function and of
> setlocale with compound locales (colon separated lists). Supporting
> these kinds of locales is not currently supported by enlightenment and
> probably will not be for some time. The reason being that the
> bindtextdomain fun
> Can you explain why you do not want e to set any environment variables?
Atleast it is counter-intuitive to say that the function restores env
vars to their original values and then modify an env var. Secondly,
LANGUAGE is expressly meant for users, and I doubt if it is a good
thing for an app to
> Sorry, I made a few changes.
You still seem to be setting LANGUAGE to (LC_MESSAGES || LANGUAGE ||
LC_ALL || LANG), when one of them is non-null... Consider for example,
LC_MESSAGES = en_US, and LANGUAGE = NULL. That's why I moved that code
to the `else' part and set _e_intl_language later.
Ramk
> I don't really care about pop/mbox/etc .. besides, who uses that crap
> these days anyway? ;)
local mail from the system itself... cron jobs, debian update
notifications on my system... many others like this still use mbox!
--
WARN_(accel)("msg null; should hang here to be win compatible\n");
> On the other hand, the "rule out the presence of certain shell
> metacharacters" part may be a problem. I can state that it will not be
> a problem for emu, as anything that emu executes will be written
> specifically for emu. Other uses may have a problem though.
Well, my patch is pretty cons
Hi!
Though I got my developer access for E to maintain the ID3 loader
module in Imlib2 quite some time back, I've just joined this mailing
list. Just observed that ecore_exe_run passes all its calls to 'sh
-c'... this can be costly and unnecessary at times. Thought that if we
can rule out the pres
12 matches
Mail list logo
