Does the shell built-in "exec" -a app1 /bah/dynamic-loader.so /path/to/app1" work or it has the same problem with argv[0] getting reset? On Wed, May 17, 2017 at 15:16 John Regan wrote: > > On Wed, May 17, 2017 at 2:07 PM, wrote: > >> On Wed, May 17, 2017 at 12:24:28PM -0400, Rich Felker 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. >> >> > > >>> 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. >> >> > > >>> Rune >> >> > a completely reasonable and recommended way for deploying dynamic >> > linked apps in a self-contained way that doesn't depend on musl libc >> > on the host. Unfortunately there's no way to set argv[0] like you want >> >> We do deploy dynamic linked apps without any dependencies on the libraries >> on the host. It works just fine with musl-as-it-is, including the >> questionably designed applications like busybox and gcc who >> analyze argv[0]. >> >> > at this time. Perhaps adding an option like --argv0=foo would be >> > appropriate. >> >> What would be the justification for adding the supporting code (to every >> instance of the dynamic loader)? >> >> It looks like --argv0=foo is meant to overcome a specific limitation in >> bourne shell, in a specific context where the task can be solved easily >> and generally better without involving the bourne shell in the first hand. >> >> I would like to see an example of a situation where a wrapper in C (or >> any language allowing setting of argv[0]) is less appropriate? >> >> If one really has a reason to express the wrapper in sh, a one-liner in >> C and an extra exec from the shell (much cheaper than starting the >> shell itself was) is sufficient to make it work. >> >> Rune >> >> Hi Rune - would you mind sharing some tips on doing that? > > I wrote and compiled a short program that just dumps the elements in argv, > then a wrapper program that figures out the needed paths for libc, real > binary, etc, but it seems like argv[0] gets reset by the dynamic loader. > > I'm calling execve with the path to the libc.so, and argv is somenthing > like: > > argv[0] - desired process name > argv[1] - full path to the real binary > argv[2...] arguments > > The 'real' binary is loaded and ran, but winds up printing out: > > argv[0] - full path to the real binary > argv[1...] arguments >