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-----