Subject: Re: Option to make cpp(1) not accept named pipes or devices as
To: Christos Zoulas <christos@zoulas.com>
From: Jim Wise <jwise@draga.com>
List: tech-toolchain
Date: 11/29/2004 17:36:44
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 29 Nov 2004, Christos Zoulas wrote:
>>My main concern is that this will be most often used by programs
>>exec'ing cpp, and not all of them will be smart about allowing arguments
>>to be part of ${CPP}, so an environment variable provides a saner way to
>>modify cpp's behavior when called from an already-existing binary or
>>script.
>>
>>There's also the concern that if users decide to use a non-basesrc cpp
>>(as _many_ users do via pkgsrc/lang/gcc34), a new command line option
>>will cause cpp to fail outright, while a new environment variable will
>>not.
>
>The problem with the environment variable approach is that there is no
>user feedback if the variable did something or not. With a flag the program
>can exit with a usage message indicating to the caller that this option
>is not supported.
This is true -- on the other hand, in the case of a binary (such as
calendar) compiled to use a new flag, the user will know that the
requested behavior was not provided, but will be unable to get the
binary to work, short of recompiling or of writing a wrapper script for
cpp which strips off the offending argument.
Not sure which is a more compelling argument...
- --
Jim Wise
jwise@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
iD8DBQFBq6SDpRpI6SYACmIRAlyFAKC5utV++cX3X6+FV7zlFBOn+UfAUgCeNZqL
WU8S1STKXv/+JabpejCPfE4=
=XIrh
-----END PGP SIGNATURE-----