source bash config from perl code

[Oleg Goldshmidt]

Tzafrir Cohen <tzafrir at cohens.org.il> writes:

> Having to export what you explicitly set is a strange habbit for a
> configuration format.

Why? Doesn't your ~/.bash_profile export what it needs to?

>> #!/bin/bash
>> 
>> function die() {
>
> Nit #1: you can get rid of 'function' and save a whole word while making
> the script more portable.

It is explicitly a bash script, and "function" adds to
readability. It's a question of style. Where you seem to be very
focused on tiny savings, I care much more about people who'll read the
code than the machine that will execute it.

>>     echo "$2" > /dev/stderr
>
> What's wrong with >&2  #?

Nothing, but /dev/stderr is more readable - see above.

> Nit #3: 'source is bashism (or csh-ism). Use '.' and save extra 5
> characters :-)

See above.

>> # now run the rest of the command line
>> 
>> $@
>
> Nit #4: "$@"

Think again: what if the command line contains quoted strings? You
might argue (having certain use cases in mind) that "$@" is preferable
- the point is that they are not equivalent.

>> Note that a command line that refers to environment variables will
>> expand them before the $environment is sourced.
>
> $@ is expanded after reading the configuration. But why should it matter
> (unless you use very dirty tricks) ?

No need for dirty tricks. The case I had in mind is something like

$ withenv config.env echo $PATH

- if config.env sets PATH it won't be picked up as the shell expands
$PATH in the command line before withenv is called. 

-- 
Oleg Goldshmidt | pub at goldshmidt.org