Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #30607 > unrolled thread

Re: parse an environment file

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: parse an environment file Chris Angelico <rosuav@gmail.com> - 2012-10-02 00:41 +1000
    Re: parse an environment file 88888 Dihedral <dihedral88888@googlemail.com> - 2012-10-01 08:29 -0700
    Re: parse an environment file 88888 Dihedral <dihedral88888@googlemail.com> - 2012-10-01 08:29 -0700

#30607 — Re: parse an environment file

On Tue, Oct 2, 2012 at 12:37 AM, Jason Friedman <jason@powerpull.net> wrote:
>> Is there a reason to use that format, rather than using Python
>> notation? I've at times made config files that simply get imported.
>> Instead of a dictionary, you'd have a module object:
>>
>>
>> # config.py
>> VAR1='foo'
>> VAR2='bar'
>> VAR3=VAR1+VAR2
>>
> There is a reason:  /path/to/export_file exists for Bash scripts, too,
> and I do not think I could get Bash to read config.py in the format
> stated above.  I want to maintain only one file.

(Responding on-list and hoping it was merely oversight that had that
email come to me personally)

Ah, fair enough. Well, since you're using the full range of bash
functionality, the only viable way to parse it is with bash itself.
I'd recommend going with the version you have above:

> * * * * * . /path/to/export_file && /path/to/script.py

Under what circumstances is this not an option? That'd be the next
thing to consider.

Alternatively, you may want to consider making your own config file
format. If you consciously restrict yourself to a severe subset of
bash functionality, you could easily parse it in Python - for
instance, always look for "export %s=%s" with simple strings for the
variable name and value.

ChrisA

[toc] | [next] | [standalone]

#30609

On Monday, October 1, 2012 10:42:02 PM UTC+8, Chris Angelico wrote:
> On Tue, Oct 2, 2012 at 12:37 AM, Jason Friedman <jason@powerpull.net> wrote:
> 
> >> Is there a reason to use that format, rather than using Python
> 
> >> notation? I've at times made config files that simply get imported.
> 
> >> Instead of a dictionary, you'd have a module object:
> 
> >>
> 
> >>
> 
> >> # config.py
> 
> >> VAR1='foo'
> 
> >> VAR2='bar'
> 
> >> VAR3=VAR1+VAR2
> 
> >>
> 
> > There is a reason:  /path/to/export_file exists for Bash scripts, too,
> 
> > and I do not think I could get Bash to read config.py in the format
> 
> > stated above.  I want to maintain only one file.
> 
> 
> 
> (Responding on-list and hoping it was merely oversight that had that
> 
> email come to me personally)
> 
> 
> 
> Ah, fair enough. Well, since you're using the full range of bash
> 
> functionality, the only viable way to parse it is with bash itself.
> 
> I'd recommend going with the version you have above:
> 
> 
> 
> > * * * * * . /path/to/export_file && /path/to/script.py
> 
> 
> 
> Under what circumstances is this not an option? That'd be the next
> 
> thing to consider.
> 
> 
> 
> Alternatively, you may want to consider making your own config file
> 
> format. If you consciously restrict yourself to a severe subset of
> 
> bash functionality, you could easily parse it in Python - for
> 
> instance, always look for "export %s=%s" with simple strings for the
> 
> variable name and value.
> 
> 
> 
> ChrisA

I think one can ues some decorators to wrap OS  or platform 
dependent functions.

I am sure someone did that long time ago as the iron python
wrapped dot-net.

[toc] | [prev] | [next] | [standalone]

#30611

On Monday, October 1, 2012 10:42:02 PM UTC+8, Chris Angelico wrote:
> On Tue, Oct 2, 2012 at 12:37 AM, Jason Friedman <jason@powerpull.net> wrote:
> 
> >> Is there a reason to use that format, rather than using Python
> 
> >> notation? I've at times made config files that simply get imported.
> 
> >> Instead of a dictionary, you'd have a module object:
> 
> >>
> 
> >>
> 
> >> # config.py
> 
> >> VAR1='foo'
> 
> >> VAR2='bar'
> 
> >> VAR3=VAR1+VAR2
> 
> >>
> 
> > There is a reason:  /path/to/export_file exists for Bash scripts, too,
> 
> > and I do not think I could get Bash to read config.py in the format
> 
> > stated above.  I want to maintain only one file.
> 
> 
> 
> (Responding on-list and hoping it was merely oversight that had that
> 
> email come to me personally)
> 
> 
> 
> Ah, fair enough. Well, since you're using the full range of bash
> 
> functionality, the only viable way to parse it is with bash itself.
> 
> I'd recommend going with the version you have above:
> 
> 
> 
> > * * * * * . /path/to/export_file && /path/to/script.py
> 
> 
> 
> Under what circumstances is this not an option? That'd be the next
> 
> thing to consider.
> 
> 
> 
> Alternatively, you may want to consider making your own config file
> 
> format. If you consciously restrict yourself to a severe subset of
> 
> bash functionality, you could easily parse it in Python - for
> 
> instance, always look for "export %s=%s" with simple strings for the
> 
> variable name and value.
> 
> 
> 
> ChrisA

I think one can ues some decorators to wrap OS  or platform 
dependent functions.

I am sure someone did that long time ago as the iron python
wrapped dot-net.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web