Solaris

The question being asked in the Solaris forum, /tmp standard permissions are protecting files created by someone to be altered by someone else, at least if the owner doesn't create world writable files (or if both users belong to the same group and the file is group writable).
"drwxrwxrwt" permissions for /tmp and /var/tmp is quite standard on Unix & Linux distributions nowadays.

And, as I said, on a Solaris systems with normal permissions on /tmp, if I run wisecracker's script creating /tmp/ECHO and /tmp/PRINTF with my default umask and then you run wisecracker's script:
What am I missing??? Why are you arguing that wisecracker's code provides a reasonable approach to solve the OP's problem? Given that any other user on the system can prevent you from creating an executable file in /tmp to be run by your script (just by running the same script with no malice intended), why do you think /tmp is an appropriate directory in which to install utilities (or files containing the paths of utilities) for use by any script that you want to run?

Why? If you know the location of the utility you want to run on the OS you're running on, just use it directly instead of dealing with the O&M of keeping copies of something that the OS provides.

Agreed. Avoid "proprietary" extensions - and GNUisms are no different than the extensions to standard protocols that Microsoft provides.

---------- Post updated at 10:10 AM ---------- Previous update was at 10:02 AM ----------

But that doesn't prevent someone from prepositioning malicious code in /tmp if they know you're going to run "/tmp/PRINTF".

I don't see the point of any complex workaround. Utilities behave differently on different flavors of Unix. You know what flavor you're running on, you know which utility you want run. The only way to deal with it is - get this - deal with it.

Deal with it directly and in ONE place - the script you're writing. Put in if/else or case statements for each OS flavor you support. Add comments to explain WHY you're using each utility from that location, because a few months or years from now, you won't remember. If you have a set of scripts, all of them can source ONE common script to set envvals for utilities.

Don't copy OS-provided binaries to custom locations - who's going to maintain that when the OS is updated?

Keep it simple - and in ONE place - or you won't be able to keep it working.

GNU is free, accurately documents which flags are extensions and which aren't, and does a good and pretty complete job of implementing standard features, so it's quite different from that sprawling monopoly. Some GNU extensions are just closing gaping holes which most UNIX suffers badly from -- like date math!

The real problem is that other UNIX cannot use these ideas to improve itself due to copyleft, so these improved features will never be anything but GNU Their hope, of course, was to entice people to switch to GNU by offering these feature improvements. In that way you could say they are similar I suppose, but I still see a difference between forcing someone into perpetual incompatibility and offering someone features they need. Oh well.

But this is besides the point... grep -q is POSIX. Maybe newer POSIX than some systems offer by default, but POSIX.

The grep -q option has been in POSIX since the first POSIX Shell and Utilities standard was adopted by IEEE in 1992. Any system with utilities conforming to any version of the Shell and Utilities volume of the POSIX standards for the last 22 years is required to support the -q option.

Not at all. Wisecracker's suggestion has several flaws and is obviously using a broken approach in the first place.
I was just commenting on your second statement "it is easy for them to replace the utilities you thought you had specified with other utilities of their choosing." In the general case, it is hopefully not easy or even possible for other users to modify or replace files you have previously created in /tmp. Many utilities and applications routinely create and use files in /tmp with no particular security risks. As I wrote and you later mentioned too, it is however possible to anticipate and create files with the same name in the first place but this is a case that can be easily detected by a robust script.
I believe it is not necessarily inappropriate. There are a couple of advantages to use /tmp (or better /var/tmp if persistance is required) to store files and commands. As a matter of fact, I have been doing this on hundreds of machines for several decades without any major issue (outside the scripts being removed by erroneous cleaning procedures). Of course, some measures should be taken to avoid the race condition and other risks but if done properly, there are no fundamental issues.

---------- Post updated at 15:52 ---------- Previous update was at 13:29 ----------

I'm afraid this is incorrect. GNU which itself started by reimplementing commands and APIs found in proprietary Unix OSes doesn't forbid itself to reimplement GNUisms on non GPL code. What is forbidden by the GPL license is to reuse code, not ideas.
For example the -iname option has been added to the supported ones with the Solaris 11 standard find utility, same for the compression options like -z and -j with Solaris tar.

Crikey, apologies, I have opened up a real hornets nest here.
I did quote 'absolutely global' not locally global, that is, storing inside one's $HOME drawer somewhere.
I use /tmp (C:\Windows\Temp, T:, etc depending on the platform) always when showing ideas and developing stuff.
Where else is universally common that usually has R/W(/X) access?