[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+qPFcLsZ8iEBxRrWYj82aEcKzeNYv7_kqMrjRnOROrgmkSupA@mail.gmail.com>
Date: Wed, 17 May 2017 16:07:21 +0000
From: mzpqnxow <musl@...qnxow.com>
To: musl@...ts.openwall.com
Subject: Re: Question about setting argv[0] when manually using dynamic linker
BTW, the shell built-in "exec" has -a which can be used to set argv[0]
Again though, I'm not entire sure I understand your use, so ignore this if
it's irrelevant :>
On Wed, May 17, 2017 at 07:00 mzpqnxow <musl@...qnxow.com> wrote:
> Is there any reason you want to avoid simply statically linking the
> program(s) so that it needs no libc or other shared objects at all?
>
> Or did I misunderstand what you're trying to do?
>
> On Wed, May 17, 2017 at 05:05 <u-uy74@...ey.se> wrote:
>
>> On Tue, May 16, 2017 at 08:38:56PM -0400, John Regan wrote:
>> > Hi there - I was wondering if it's possible to somehow set argv[0] when
>> > calling the dynamic linker to load a program.
>> ...
>> > I'd like to retain whatever was actually typed on the command line (in
>> this
>> > case, set argv[0] to "app"), since many apps look at argv[0] to change
>> > behavior, ie - gzip vs gunzip.
>> >
>> > I tried seeing if there was some switch I could pass to the linker, etc
>> -
>> > as far as I can tell, there's no easy way to do this.
>>
>> Set argv[0] to whatever you need when you exec*() the dynamic loader,
>> which is straightforward with a binary wrapper (not with a shell).
>>
>> A binary wrapper also adds less overhead then going through a shell.
>>
>> There is imho hardly any incentive to put such functionalty into the
>> loader. I say this even though we are dependent here on such tricks,
>> to work around programs which insist on guessing things when not asked to.
>>
>> Regards,
>> Rune
>>
>>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
