Related is #50798 which I just filed
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50789 This is a similar issue in
the executable path picked up by a program (finding the -real one) and using
that for writing a .desktop file.
Not sure if there is anything more general to do here, other than ha
Attila Lendvai schreef op wo 08-09-2021 om 09:20 [+]:
> thanks for the ideas Maxime!
>
>
> > You could patch trezor-agent with something like
> >
> > Python syntax might be incorrect
> >
> >
> > if sys.argv[0] == ".trezor-gpg'
> > sys.argv[0] = "trezor-gpg"
thanks for the ideas Maxime!
> You could patch trezor-agent with something like
>
> Python syntax might be incorrect
>
>
> if sys.argv[0] == ".trezor-gpg'
> sys.argv[0] = "trezor-gpg"
> device_name = os.path.basename(sys.argv[0]).rsplit('-',1)[0]
>
> Would that wo
Hi,
Attila Lendvai schreef op di 07-09-2021 om 18:52 [+]:
> pardon me for reviving a years old discussion, but i'm facing the same
> problem once again.
>
> i have updated trezor support, and i wanted to test generating a new gpg key:
>
> $ trezor-gpg init "foobar "
>
> leading to: OSError
pardon me for reviving a years old discussion, but i'm facing the same problem
once again.
i have updated trezor support, and i wanted to test generating a new gpg key:
$ trezor-gpg init "foobar "
leading to: OSError: Cannot find '.trezor-gpg-gpg-agent' in $PATH
upstream relies on sys.argv[0]
Ricardo Wurmus writes:
> Ricardo Wurmus writes:
>
>> I wonder if there’s a way to have a script header that starts out as a
>> shell script and then calls itself again but skipping over the header,
>> thus calling the original script.
>>
>> Take this Python script as an example:
>>
>> --8<-
Ricardo Wurmus writes:
> For binaries (like emacs) we’d still create shell wrappers where needed,
> because it’s harder to do this natively.
You could link in a constructor function to replace a wrapper that just
sets the environment, couldn't you? I've done that at times and it
allows you to r
Hi!
Hartmut Goebel skribis:
> answering on a mail which Ricardo CCed to me and which did not make it
> to the list yet. Thus I full-quote.
>
> Am 04.11.2017 um 23:30 schrieb Ricardo Wurmus:
>> How about this:
>>
>> --8<---cut here---start->8---
>> #!/home/reka
Hi,
Ricado proposed a new and better solution already. Nevertheless I want
to comment on this proposal, sint it includes a pitfall and would not work:
Am 03.11.2017 um 22:17 schrieb Ricardo Wurmus:
> exec /home/rekado/.guix-profile/bin/python
> <(/run/current-system/profile/bin/tail -n +4 "$0")
Hi,
answering on a mail which Ricardo CCed to me and which did not make it
to the list yet. Thus I full-quote.
Am 04.11.2017 um 23:30 schrieb Ricardo Wurmus:
> How about this:
>
> --8<---cut here---start->8---
> #!/home/rekado/.guix-profile/bin/guile --no-auto-
Christopher Baines writes:
> However, I think that the file wrapping approach has advantages for
> visibility. Maybe it could be tweaked to keep ensure the wrapper script
> has the same name as the script its wrapping, e.g. when wrapping foo,
> replace foo with a bash script, and move the real s
On Fri, 3 Nov 2017 18:54:16 +
Christopher Baines wrote:
> However, I think that the file wrapping approach has advantages for
> visibility. Maybe it could be tweaked to keep ensure the wrapper script
> has the same name as the script its wrapping, e.g. when wrapping foo,
> replace foo with a
Hallo Ricardo,
Am 02.11.2017 um 22:31 schrieb Ricardo Wurmus:
> This made me wonder if we could avoid shell wrappers in more cases.
This is an interesting challenge :-)
> If
> the target script is a Python script we could set the environment
> variables right after the Python shebang with Python
Christopher Baines writes:
> However, I think that the file wrapping approach has advantages for
> visibility. Maybe it could be tweaked to keep ensure the wrapper script
> has the same name as the script its wrapping, e.g. when wrapping foo,
> replace foo with a bash script, and move the real scr
On Thu, 02 Nov 2017 22:31:16 +0100
Ricardo Wurmus wrote:
> Hi Guix,
>
> the environment activation feature of our “conda” package currently
> fails. This is because the “deactivate” shell script is wrapped in
> another shell script. This leads to the actual shell script to be
> called “.deacti
15 matches
Mail list logo
