Default config file location

Is there a “better” way to specify a default config file location than
this?

File.expand_path('~') + "/#{filename}"

On Sat, 18 Jun 2011, Chad P. wrote:

Is there a “better” way to specify a default config file location than
this?

File.expand_path(’~’) + “/#{filename}”

Depending on the shell, ‘~’ may not be defined. $HOME is a better
choice
generally.

Matt

On 6/17/2011 14:45, Matthew K. Williams wrote:

On Sat, 18 Jun 2011, Chad P. wrote:

Is there a “better” way to specify a default config file location than
this?

File.expand_path(’~’) + “/#{filename}”

Depending on the shell, ‘~’ may not be defined. $HOME is a better
choice generally.

According to the documentation for File.expand_path, all that is
required is that $HOME is set correctly. It doesn’t apparently use the
shell to figure this out. Chad’s method even works on Windows. :slight_smile:

I might simplify this just a tiny bit though:

File.expand_path("~/#{filename}")

-Jeremy

On Jun 17, 2011, at 3:49 PM, Jeremy B. wrote:

According to the documentation for File.expand_path, all that is
required is that $HOME is set correctly. It doesn’t apparently use the
shell to figure this out. Chad’s method even works on Windows. :slight_smile:

I might simplify this just a tiny bit though:

File.expand_path(“~/#{filename}”)

I use File.join for such situations due to separator differences. Is
this
unnecessary for some reason?

Michael E.
[email protected]
http://carboni.ca/

On Sat, Jun 18, 2011 at 04:45:56AM +0900, Matthew K. Williams wrote:

On Sat, 18 Jun 2011, Chad P. wrote:

Is there a “better” way to specify a default config file location than
this?

File.expand_path(’~’) + “/#{filename}”

Depending on the shell, ‘~’ may not be defined. $HOME is a better
choice generally.

I take it you mean the above should be changed to this:

ENV['HOME'] + "/#{filename}"

Is that what you mean?

You make a good point about tilde expansion. Thank you.

On Sat, 18 Jun 2011, Jeremy B. wrote:

According to the documentation for File.expand_path, all that is
required is that $HOME is set correctly. It doesn’t apparently use the
shell to figure this out. Chad’s method even works on Windows. :slight_smile:

Thanks for that; I’ll have to remember it!

Matt

On Sat, Jun 18, 2011 at 04:49:24AM +0900, Jeremy B. wrote:

According to the documentation for File.expand_path, all that is
required is that $HOME is set correctly. It doesn’t apparently use the
shell to figure this out. Chad’s method even works on Windows. :slight_smile:

Do you know whether that’s consistent across Ruby implementations (e.g,
Rubinius and JRuby)? I imagine it is for Rubinius, at least, given the
project’s focus on API consistency. . . .

On Sat, 18 Jun 2011, Chad P. wrote:

choice generally.

According to the documentation for File.expand_path, all that is
required is that $HOME is set correctly. It doesn’t apparently use the
shell to figure this out. Chad’s method even works on Windows. :slight_smile:

Do you know whether that’s consistent across Ruby implementations (e.g,
Rubinius and JRuby)? I imagine it is for Rubinius, at least, given the
project’s focus on API consistency. . . .

It works on jruby (I checked 1.6.0)

Matt

On Friday, June 17, 2011 02:52:53 PM Michael E. wrote:

unnecessary for some reason?
I use File.join also – well, actually, I look for opportunities to use
the
Pathname library instead. But on modern Windows, forward slashes work,
too.

I had to explain this to people writing a Java program in which they
hardcoded
backslashes. Java’s File library is a lot like Ruby’s Pathname library,
and
you have to create a File object eventually anyway, but even if you
ignore all
that, forward slashes work fine!

On Friday, June 17, 2011 02:53:23 PM Chad P. wrote:

I take it you mean the above should be changed to this:

ENV['HOME'] + "/#{filename}"

Is that what you mean?

As people have pointed out, File.expand_path probably works.
I do find this a bit cleaner, though:

File.join(ENV[‘HOME’], filename)

On 6/17/2011 14:52, Michael E. wrote:

I use File.join for such situations due to separator differences. Is this
unnecessary for some reason?

Ruby always uses ‘/’ with File.join wherever I’ve tested it, even on
Windows. Fortunately, Windows will also accept that separator, and Ruby
on Windows will work with either just like other Windows applications.
However, it’s possible that one day Ruby will be ported to an OS that
doesn’t support it. Using File.join or something equivalent (see below)
should pretty much guarantee that your script won’t trip over that
problem.

I actually had the very problem you’re concerned about in a large Perl
framework years ago that had to run on Windows, Unix, and MacOS 9. For
those too young to remember, MacOS 9 used ‘:’ for the file separator
character, among other path-related differences. Since then, I tend to
use methods like File.join for long-lived or important projects.

The only real problem at the moment in Ruby is displaying Ruby-style
paths to a Windows user. Since they’re used to seeing the ‘’
separator, many may not understand the ‘/’ or at least be uncomfortable
using it. In such cases where you need to show a path that was
generated internally to a user, it might be a good idea to use a
platform-aware filter to make the path more presentable/palatable.

BTW, another way to handle this separator issue is to use the Pathname
class from the pathname library for all your paths:

require ‘pathname’
puts (Pathname.new(’~’) + filename).expand_path

-Jeremy

On Sat, Jun 18, 2011 at 07:29:58AM +0900, David M. wrote:

I take it you mean the above should be changed to this:

ENV['HOME'] + "/#{filename}"

Is that what you mean?

As people have pointed out, File.expand_path probably works.

Yeah – I started composing this before the other emails started showing
up in my inbox.

I do find this a bit cleaner, though:

File.join(ENV[‘HOME’], filename)

As do I, now that I’ve had time to think about it.

Chad P.:

Is there a “better” way to specify
a default config file location than this?

File.expand_path(‘~’) + “/#{filename}”

Depending on how ‘good’ you want to be with regards to
modern systems adhering to the FreeDesktop standard¹. :slight_smile:

The last time I needed to take care of this (YAML ‘database’
with signatures for signore, a signature randomiser) I settled on

(ENV[‘XDG_DATA_HOME’] or File.expand_path ‘~/.local/share’) +
‘/signore/signatures.yml’

– so for a config file I’d go with

(ENV[‘XDG_CONFIG_HOME’] or File.expand_path ‘~/.config’) +
“/#{appname}/#{configfilename}”

¹ http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

— Piotr S.

We tried that One Encoding To Rule Them All in Java, and it was
a failure. We tried it again with a different encoding in Java 5,
and it was a failure. We tried it in .NET, and it was a failure. The
Python community is currently in the process of realizing it was a
failure.
Five years of work on PHP 6 were completely destroyed because of this.
(At
least they realized it before releasing it into the wild.)
[Jörg W Mittag,
ruby-talk]

On Fri, Jun 17, 2011 at 2:56 PM, Chad P. [email protected] wrote:

Do you know whether that’s consistent across Ruby implementations (e.g,
Rubinius and JRuby)? I imagine it is for Rubinius, at least, given the
project’s focus on API consistency. . . .

JRuby has a focus on API consistency as well.

  • Charlie

On Sat, Jun 18, 2011 at 10:26 PM, Piotr S.
[email protected] wrote:

Depending on how good you want to be with regards to
modern systems adhering to the FreeDesktop standard. :slight_smile:

The last time I needed to take care of this (YAML database
with signatures for signore, a signature randomiser) I settled on

That’s for X Windows environments, like KDE or GNOME.

For all others, the FHS applies:
http://refspecs.linuxfoundation.org/fhs.shtml

In a nutshell: Configuration and user data go into “.#{appname}”.


Phillip G.

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibnitz

On Jun 18, 5:49pm, Phillip G. [email protected]
wrote:

That’s for X Windows environments, like KDE or GNOME.
The base directory standard does not limit it’s use to X windows
environments. That’s just how it originated. Any app can make use of
it.

One of the aims of freedesktop.org is “Integrate desktop-specific
standards into broader standards efforts”.

For all others, the FHS applies:FHS Referenced Specifications

In a nutshell: Configuration and user data go into “.#{appname}”.

The XDG base directory standard has a few advantages --first and
foremost (IMHO) it helps unclutter the home directory.