🚀 go-pugleaf

>Why whould a script care.

Because the script might be a wrapper script around an application -
let's give the application the hypothetical name "Frame Maker" - that
finds out the architecture for the machine, and runs the appropriate
binary, because the hypothetical vendor of this application - let's give
them the hypothetical name "Frame Technology" - apparently wants to have
shared versions of the non-architecture-dependent files, and separate
directories for the architecture-dependent files.

And yes, I *did* get bitten by that when I tried firing Frame up on a
Solaris 2.x machine here; the obvious fix, of using "uname -p", isn't
guaranteed to allow the same binary to be used on, for example,
386-based and 486-based boxes.

If you don't think Frame is doing the right thing, try convincing *them*
of that - and, if you don't succeed, consider that having "uname -b"
might be better than forcing Frame to have to recognize that "i80386"
and "i80486" and "iPentium" and... are really equivalent for its
purposes.

And also consider that Frame might not be the *only* application that
does this....

>The Generic ABI lists all the commands an
>ABI conforming script may call. If a script is attempting to perform
>different functions based on architecture type then by definition "sort of"
>the script is non ABI conforming.

So?  Who cares?  What's the *cost* of putting in a "get the architecture
name" option into "uname"?

>Now this doesn't address the real world problem of having servers
>export a tree which contains binaries for a bunch of different machines,
>but some view this as an admin problem not an ABI problem.

And some don't.