[E-devel] straight exec'ing for ecore_exe_run

2005-11-29 Thread Ramkumar R
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 presence of certain shell metacharacters in the
string passed to the function, we can tokenize it ourselves and call
execvp, without the intermediate sh. Since E's 'exec' action uses
this, we could see a significant reduction in the useless sh -c
processes spawned due to use of keybindings etc. If no one has
problems with this approach, I could make a commit.

Ramkumar.

--
WARN_(accel)("msg null; should hang here to be win compatible\n");
   -- WINE source code


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] straight exec'ing for ecore_exe_run

2005-11-29 Thread Ramkumar R
> 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 conservative currently (anything suspicious,
pass over to sh), and I read through SUSv3 before coming up with the
code. So, I hope there won't be many problems. Did much of the testing
using -binding-key-add and exec. But since I can't weed out the bugs
otherwise, I guess I will commit. All fingers crossed :)

Ramkumar.

--
WARN_(accel)("msg null; should hang here to be win compatible\n");
   -- WINE source code


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] imap/biff

2005-12-02 Thread Ramkumar R
> 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");
   -- WINE source code


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] LC_* are now wrongly cleared by e

2005-12-03 Thread Ramkumar R
> 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.

Ramkumar

--
WARN_(accel)("msg null; should hang here to be win compatible\n");
   -- WINE source code


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] LC_* are now wrongly cleared by e

2005-12-03 Thread Ramkumar R
> 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 set it, especially when it forks... well... the
user meant it to be unset, so be it! As you said, E_LANG seems to be a
better idea, but well... if something really wants to know E's
language, it can use the much superior IPC mechanism.

On a related note, should we be using LANGUAGE as an argument to
setlocale, when LANGUAGE can use an extended syntax (colon separated
list of locales) not understood by setlocale? In fact, I think even
your validation function doesn't take the extended syntax into
account. May be we should not be using LANGUAGE at all (gettext anyway
references it if needed, even when only the default locale is set)

Ramkumar

--
WARN_(accel)("msg null; should hang here to be win compatible\n");
   -- WINE source code


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] LC_* are now wrongly cleared by e

2005-12-03 Thread Ramkumar R
> 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 function can only bind one directory at a time.  In
> enlightenment message files may be in any directory in the messages
> path. If we want to set the locale to zh_CN:zh_TW and zh_CN is installed
> in a user path and zh_TW is in a system path there would be no way (that
> I know of) to bind to both paths and get the correct behavior.

Sorry, but since I am new to e-devel, could you please tell me what
was the need to allow arbitrary search paths for messages, rather than
allowing a choice of a single base dir. If there is a genuine need, I
think we should inform the gettext people of the problem. The only
hackish solution I could think of is to generate a symlink directory
tree somewhere in .e at runtime, everytime we set the language,
incorporating all the mo files we gathered from the search path, and
then use it as our base directory.

Is this a problem with E alone? What about third party modules? Should
we be somehow exposing the load path for them as well, so that they
could use the search path as well?

Ramkumar

--
WARN_(accel)("msg null; should hang here to be win compatible\n");
   -- WINE source code


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] LC_* are now wrongly cleared by e

2005-12-04 Thread Ramkumar R
> 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 dirs.

I don't think it is a lot. If LANGUAGE has k entries, we will need
3k+1 inodes (2k+1 for the directory structure, and k for the
symlinks), and I don't see a typical LANGUAGE entry exceeding some 5
languages. (I guess it will be lesser mostly). Add to it, many systems
already don't have inode restrictions (Reiserfs, for example). And if
you are really concerned, we can always optimize for the case when
LANGUAGE has only one entry and do away with this mechanism, so that
if an user has 4 inodes left in his quota, he can change LANGUAGE to a
single entry one... anyway, that is what E offers now.

As I said earlier, this still stays as a *hack*. May be we should tell
this to the gettext people and get the functionality in.

> modules can use gettext DOMAINS to load a different domain for their use, but
> they still suffer fromt he problem of possibly haveing some languages already
> supported by teh system packages, but the user wanting to edxtend language
> support by adding more translations but not having root access.

So, do they currently use E's locale search path? Should we be
exposing a e_intl_get_locale_path(), so that modules can do a
bindtextdomain(MODULENAME, e_intl_get_locale_path()). This may have
even greater significance if we get the symlink system I described...

Ramkumar

--
WARN_(accel)("msg null; should hang here to be win compatible\n");
   -- WINE source code


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Trouble due to sticky windows when using focus_last_focused_per_desktop

2005-12-08 Thread Ramkumar R
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 hence sticky windows get a single
entry wherever they are viewed. Now, if a sticky window has the focus
in some desk x, then it will always be brought to focus whenever a
switch to desk y is made, irrespective of whether it is the last
window to be viewed there, since the non-sticky windows of desk y will
be buried beneath this sticky window. Further, even if a sticky window
is never brought to focus, it will always get the focus if
focus_revert_on_hide_or_close is set, since all non-sticky windows of
desk x are hidden before the switch, ultimately leaving the sticky
window at the top of the stack.

Currently, I have a sticky gkrellm, and focus always goes to it on any
desktop shift, which is highly annoying...

May be we will need a per-desk focus stack or store focus stack
entries as a (desk, window) tuple, so that we can get multiple entries
for sticky windows, one for each desk appearance.

Ramkumar.

--
WARN_(accel)("msg null; should hang here to be win compatible\n");
   -- WINE source code


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] imlib2 loaders location

2006-03-22 Thread Ramkumar R
> 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 issues to the client, whom we
assume is aware of the dangers of allowing an arbitrary path :) So,
IMO, exposing an API is not a bad thing (env vars is a different
issue) if there are use cases for it...

Ramkumar.

--
April 1: This is the day upon which we are reminded of
what we are on the other three hundred and sixty-four.
  -- Mark Twain, "Pudd'nhead Wilson's Calendar"


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Ecore_exe and shell metacharachters

2006-04-05 Thread Ramkumar R
> 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
POSIX shell.

> be a good idea.  Maybe even letting programs choose the shell to use,
> and leave it up to them to detect if the shell exists.  If the program
> asks ecore_exe to use a shell that doesn't exist, then the same thing
> will happen that would normally happen when trying to ecore_exe any
> program that doesn't exist.

I think changing the API to do this would be redundant, and would
unnecessarily complicate things. If the person is really bent on using
csh, he/she could use the command line "exec csh -c 'actual-cmd-line'"
to /bin/sh which ecore_exe uses.

Regards,
Ramkumar.

--
April 1: This is the day upon which we are reminded of
what we are on the other three hundred and sixty-four.
  -- Mark Twain, "Pudd'nhead Wilson's Calendar"


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Desklock triggers crash...

2006-04-12 Thread Ramkumar R
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 exits.

Regards,
Ramkumar.

--
April 1: This is the day upon which we are reminded of
what we are on the other three hundred and sixty-four.
  -- Mark Twain, "Pudd'nhead Wilson's Calendar"


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Desklock triggers crash...

2006-04-13 Thread Ramkumar R
> 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, clock, pager, ibox... use my login password and locked
screen shows on all zones (i have only one neway :) ) i am leaving for
a place with no net conn... i am probably get a backtrace when i get
back tomorrow or the day after...

Ramkumar.

--
April 1: This is the day upon which we are reminded of
what we are on the other three hundred and sixty-four.
  -- Mark Twain, "Pudd'nhead Wilson's Calendar"


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel