Re: Bug#852451: ITP: rname -- invoke a program under a different name

[Christian Seiler <christian@iwakd.de>]

On 01/24/2017 04:19 PM, Peter Pentchev wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Peter Pentchev <roam@ringlet.net>
> 
> * Package name    : rname
>   Version         : 1.0.2
>   Upstream Author : Peter Pentchev <roam@ringlet.net>
> * URL             : https://devel.ringlet.net/sysutils/rname/
> * License         : BSD-2-clause
>   Programming Lang: C
>   Description     : invoke a program under a different name
> 
> The rname utility invokes a specified program, passing a different name
> instead of the name of the program executable.  This could be useful in
> a number of cases, both during software development, testing, and in
> production use.  There are many programs that do different things based
> on what name they have been invoked under; the rname utility avoids
> the need to e.g. create ephemeral symlinks to run these programs in
> some conditions when they have not been completely installed.
> 
> I originally wrote this tool in 2000 and I'm resurrecting it now for
> the purpose of writing unit and integration tests for just such
> a multifaceted program.

This is definitely useful (I've needed this myself at multiple times),
but wouldn't it be better if this were part of coreutils or util-linux
or something similar?

Because say if I wanted to use that functionality in a package of mine
(for unit tests or similar), I'd probably not want to depend on a tiny
package just for this, especially since there are ways of doing the
very same thing with packages that are installed on most systems:

/bin/bash -c "exec -a $argv0 $progname $args"
perl -e 'exec {shift} @ARGV' $progname $argv0 $args
python3 -c 'import os, sys; os.execvp(sys.argv[1], sys.argv[2:])' \
    $progname $argv0 $args

(The shell needs to be bash, mksh, zsh or similar to work; dash and
others don't support -a for exec.)

I would prefer a standalone program for this of course, but the pain
of the other solutions is not large enough for me that the trade-off
in depending on something non-standard makes sense to me.

Of course that's just my personal assessment, YMMV, and I'm not
opposed to you packaging this (what you provide is definitely useful),
but maybe this email gives you some food for thought about how to
best provide this functionality.

Regards,
Christian