On 7/1/20 6:24 AM, Robert Elz wrote: > Date: Wed, 01 Jul 2020 00:43:14 +0300 > From: Dmitry Alexandrov <d...@gnui.org> > Message-ID: <tuysgrgt....@gnui.org> > > | > If you need to ensure a disk executable is used, > | Of course. Why "command" otherwise? > > That doesn't actually work, "command" can run built-ins, there is > actually no method (not even via use of "env") which guarantees > execution of an executable from an external file, other than by > using the complete path name (containing at least one '/') of the > desired file.
Indeed -- that's why I specifically used the bashism $(type -P ...) as type -P forces the printing of an external file executable. Regarding use of env, I presume you're referring to the busybox behavior here, where busybox's builtin env applet will still execute other builtin applets. That's the only case I'm aware of that will not guarantee execution of an executable from an external file -- so shouldn't env be safe to use as such, if you know: a) your interpreter is bash rather than /bin/sh, b) the external disk executable "env" is not a symlink to busybox -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
