To me the issue is a very very simple.
How to alter the environment before executing a GUI program.
The requirement is do it in per-user, per-app basis.
Currently there are two working solutions:
1. Use env FOO=bar /path/to/real/program
2. Use /path/to/wrapper.sh
( The script contains export FOO=b
On Thu, Dec 26, 2013 at 8:09 PM, Kevin Krammer wrote:
> If wine cannot accept the prefix as a command line argument, then this should
> use a script that adjusts the environment accordingly before calling the
> binary.
>
> I just don't see how adding an addtional key would make people who prefer
>
> A danger in customizing shell-level commands is that shell-scripts can
> become hard to debug remotely and hard to share.
True. But you can even customize /bin/sh on Debian/Ubuntu.
> I'm personally in favour of keeping xdg-open and not making a grab for
> "open", because it helps people remembe
On Sun, Dec 22, 2013 at 4:23 AM, Matthias Klumpp wrote:
> Btw, I don't find "I like open better" a good justification for
> dropping it from kbd - you are asking essentially for an API break
> which has unforseen consequences if we just swap some binary names on
> shell, especially with shell-scri
Bug filed for Debian's kbd package:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732796
For some reason I forgot to include a title...
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Hi, List:
I admittedly like the usage of "open" command in OS X (maybe Haiku also).
As far as I know, neither POSIX nor LSB mentions open(1) at all. It is
not a goal for toybox project either:
http://www.landley.net/toybox/status.html
In other words, it is not a standard and no one uses it.
The
