Re: Feature suggestion: env --nopath

[Simon Tatham]

Simon Tatham <anakin@pobox.com> wrote:
> I think it would be useful if 'env' had an option which would cause it
> to treat its COMMAND argument as _necessarily_ a pathname to an
> executable file, rather than the usual semantics of considering it to be
> either that or a command to search for on PATH.

Rob Landley wrote:
> When you care about that you do ./filename and the ./ is an explicit
> path meaning "in the current directory".

But the COMMAND might not _be_ in the current directory. The feature I'm
suggesting would be usable if COMMAND is _either_ of a cwd-relative path
_or_ an absolute path.

Prefixing "./" makes a cwd-relative path work fine, as you say. But it
causes an absolute path to _stop_ working. Consider the commands

  env --nopath foo
  env --nopath bar/foo
  env --nopath /opt/quux/bin/foo

If one replaces the nonexistent "env --nopath" with a prefix "./" as you
suggest, then we get

  ./foo
  ./bar/foo
  .//opt/quux/bin/foo

The first of those works, as you say. The second also works (but is
unnecessary, since "bar/foo" by itself would also have been fine -
that's the easiest case of all). But the third one is _broken_ by the
prefixed "./", because the // is treated the same as a single /, so this
becomes an exec of ./opt/quux/bin/foo, i.e. the absolute path has turned
into a multi-step path relative to my cwd, not my root. Most likely
nothing is there; there's an outside chance that there is and it's the
wrong thing.

To use the "./" strategy, one must first examine the input pathname, and
only prefix "./" if it doesn't begin with a "/". So the alternative to
env --nopath is to do some string processing in the calling tool, along
the lines of

  case "$path" in /*);; *) path="./$path"; esac
  env "$path" args args args

which is cumbersome enough - especially if you have to quote that in
turn to get it through some secondary syntax like Makefile - that
perhaps you see why I'm suggesting it would be useful to have a
ready-made tool for the job instead?

> This is not env-specific.

Of course that's true. I could write a separate tool called 'execv' in
under ten lines of C that would do the thing I want, and chain it with
env if I also wanted any of env's existing features. (Except that if it
isn't already available in /usr/bin or somewhere, the Makefile or
whatever has the same bootstrap problem again with building and running
that. To be useful this tool needs to be available on PATH already.)

But I thought it might fit well into env's existing collection of
non-environment-related options for customising the execution of another
process.

Cheers,
Simon

-- 
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
 print("".join([chr(32+3*((k>>x)&1))for x in range(79)])) # <anakin@pobox.com>