I think it is worth investigating using C or something for wrappers, as
wrappers on macOS can't be used in shebangs. Wrapped ruby executables have
to be unwrapped to use.
Would using C solve your problems as well?
On Mon, May 22, 2017 at 11:00 AM Freddy Rietdijk
wrote:
> The problem with such an
>
> The problem with such an environment variable is that it's inherited by
> child
> processes, who might get confused. (E.g. some code might run both in a
> wrapped
> and unwrapped context, so it wouldn't be able to rely on $NIX_PROGRAM_NAME
> unambiguously.)
In the case of Python we might be a
Hi,
On 05/19/2017 01:35 PM, Freddy Rietdijk wrote:
> Therefore, I propose we set an environment variable `NIX_PROGRAM_NAME` that
> the
> scripts check for. To prevent creating yet another `wrapProgram` variant I
> propose we extend `wrapProgram` to always set this variable.
The problem with suc
If a Python script is run, then `sys.argv[0]` is set to the script name (or
path, depending on platform). Some scripts use this name or path to start a
new instance of itself. Unfortunately, exec -a doesn't set `sys.argv[0]`.
Therefore, when running a wrapped Python script, `sys.argv[0]` points not
Hi Freddy,
Can you expand a bit on why this is a problem? If a program is executed
using python I would expect this to be reflected in the process name. Argv0
would contain a path to python and argv1 the path to the script.
Cheers,
z
On Fri, 19 May 2017, 12:35 Freddy Rietdijk, wrote:
> Hi,
>
>
