environment variables for ghc

[Tomasz Zielonka]

On Wed, Mar 09, 2005 at 10:27:28AM -0800, Frederik Eaton wrote:
> On Wed, Mar 09, 2005 at 07:03:38PM +0100, Tomasz Zielonka wrote:
> > 
> > I was complaing (only to myself) that rsync doesn't allow to put some
> > common options in ~/.rsyncrc or an environment variable. Then I simply
> > added an alias in my .bash_profile:
> > 
> >     alias rsync='rsync -v --progress'
> > 
> > Unfortunately, this is still something that developers would like to
> > know when facing a bug report :)
> 
> Right. Well, to get it to work from makefiles etc., I'd need to create
> a script in my path, something like
> 
> #!/bin/sh
> ghc -i$HSPATH -package-conf $HSPKGCONF "$@"
> 
> And I'd call it ghc. The thing is, I'm arguing that enough people
> would do this that we should standardize on the environment variable
> names. Plus, yeah, as you point out, I could just as well forget to
> mention in a bug report that 'ghc' is my own special script.

Why not simply do:

#!/bin/bash
/usr/.../ghc $GHCOPTS "$@"

?

I am still not convinced that it is a good idea to add such
functionality to GHC. Do you want to persuade developers of
every program you use to add similar feature?

For the simple case of providing the same options everytime
shell script wrappers and aliases are the way to go.

There are more complicated case which justify extending a program in
such way. For example, it is common that VCS's (like CVS, subversion
and darcs) have a single executable with many sub-commands. You them in
this way:

    $ cvs get ...
    $ cvs update ...
    $ cvs status ...

You may want to provide different default options for different
sub-commands. Possible to do with a shell script, but much, much more
difficult. That's why at least darcs has a mechanism for setting default
options for different sub-commands (~/.darcs/defaults or
_darcs/prefs/defaults in a repo).

Best regards
Tomasz