The machine stack and the C language

W

Walter Roberson

But the only reason to
execute "/bin/true --version" with the expectation of having it do
nothing is deliberate conformance testing. There's no real-world
reason to give it an argument at all.

Real life example:

Portable(-ish) Makefiles with a step that would normally be
ar -t (topological sort on the archive contents) but that step
is unneeded or unimplemented on some architectures. The usual
solution is to parameterize the program name as a variable in
the makefile, and for those architectures that do not need or
support the step, use /bin/true or ':' (colon) as the program name,
taking advantage of the fact that arguments will be ignored but
the step will be considered to succeed.
 
K

Keith Thompson

Real life example:

Portable(-ish) Makefiles with a step that would normally be
ar -t (topological sort on the archive contents) but that step
is unneeded or unimplemented on some architectures. The usual
solution is to parameterize the program name as a variable in
the makefile, and for those architectures that do not need or
support the step, use /bin/true or ':' (colon) as the program name,
taking advantage of the fact that arguments will be ignored but
the step will be considered to succeed.

It's even conceivable that the Makefile might want to invoke
"ar --version", so information about the tools used is recorded in the
output log (if the Makefile assumes that ar accepts the "--version"
option). Invoking "true --version" instead isn't likely to kill
anything, but it could cause some confusion.

If you assume an error "can't happen", stop a moment and consider that
computers are capable of making mistakes that would never occur to a
human, and of making them at an incredible rate. Think about this
before deciding that using an identifier with a leading underscore, or
adding a non-standard declaration to a standard header, or ignoring
the possibility that malloc() could fail, can't possibly cause any
problems in the Real World. The C standard doesn't mention Murphy's
Law, but it still applies.

<EVEN_FURTHER_OT>
More recent versions of the GNU "true" command apparently ignore
POSIXLY_CORRECT.
</EVEN_FURTHER_OT>
 
H

Harald van Dijk

But the only reason to execute
"/bin/true --version" with the expectation of having it do nothing is
deliberate conformance testing. There's no real-world reason to give it
an argument at all.

In addition to the example Walter Roberson gave, true and : are sometimes
used as
true ${VAR=value}
to give VAR a value if it's unset. Most shells don't have a built-in
operator to give a variable a default value and then do nothing with it.

Thankfully, most shells implement these utilities as a built-in, which
avoids the problem.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top