From: Andy Wingo <wingo@pobox.com>
To: ludo@gnu.org (Ludovic Courtès)
Cc: Eli Barzilay <eli@barzilay.org>, guile-devel@gnu.org
Subject: Re: [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names.
Date: Tue, 03 May 2011 09:44:10 +0200 [thread overview]
Message-ID: <m3zkn4rzxx.fsf@unquote.localdomain> (raw)
In-Reply-To: <87vcxsycds.fsf@gnu.org> ("Ludovic Courtès"'s message of "Tue, 03 May 2011 00:18:55 +0200")
On Tue 03 May 2011 00:18, ludo@gnu.org (Ludovic Courtès) writes:
>> I still think that we need at least the ability to pass a bytevector as
>> a path name, on GNU systems; and that if we can do so, then any routine
>> that needs to deal with a path name would then need to deal in byte
>> vectors in addition to strings, and at that point perhaps it is indeed
>> useful to have a path library.
>
> To accommodate various file name encodings, right? Then yes.
That's the crazy thing: file names on GNU aren't in any encoding! They
are byte strings that may or may not decode to a string, given some
encoding. Granted, they're mostly UTF-8 these days, but users have the
darndest files...
> I think GLib and the like expect UTF-8 as the file name encoding and
> complain otherwise, so UTF-8 might be a better default than locale
> encoding (and it’s certainly wiser to be locale-independent.)
It's more complicated than that. Here's the old interface that they
used, which attempted to treat paths as utf-8:
http://developer.gnome.org/glib/unstable/glib-Character-Set-Conversion.html
(search for "file name encoding")
The new API is abstract, so it allows operations like "get-display-name"
and "get-bytes":
http://developer.gnome.org/gio/2.28/GFile.html (search for "encoding"
in that page)
"All GFiles have a basename (get with g_file_get_basename()). These
names are byte strings that are used to identify the file on the
filesystem (relative to its parent directory) and there is no
guarantees that they have any particular charset encoding or even make
any sense at all. If you want to use filenames in a user interface you
should use the display name that you can get by requesting the
G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME attribute with
g_file_query_info(). This is guaranteed to be in utf8 and can be used
in a user interface. But always store the real basename or the GFile
to use to actually access the file, because there is no way to go from
a display name to the actual name."
> So volumes matter in the file name canonicalization of the .go cache
> right?
>
> Couldn’t we mimic /cygdrive/c, etc.?
Is that what cygwin does? We certainly could, yes; though for the
purposes of joining the cache dir to an absolute filename, I guess we
could simply change c:/foo to /c/foo... Hum!
Andy
--
http://wingolog.org/
next prev parent reply other threads:[~2011-05-03 7:44 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-15 15:34 mingw runtime patches Jan Nieuwenhuizen
2011-02-15 15:34 ` [PATCH 1/5] [mingw]: Add implementation of canonicalize_file_name Jan Nieuwenhuizen
2011-04-29 16:33 ` Andy Wingo
2011-05-20 13:56 ` Jan Nieuwenhuizen
2011-05-20 14:54 ` Andy Wingo
2011-02-15 15:35 ` [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names Jan Nieuwenhuizen
2011-04-29 17:16 ` Andy Wingo
2011-04-29 17:30 ` Noah Lavine
2011-05-01 11:30 ` Andy Wingo
2011-05-01 19:23 ` Noah Lavine
2011-05-01 21:12 ` Andy Wingo
2011-05-01 21:48 ` Mark H Weaver
2011-05-02 7:45 ` Andy Wingo
2011-05-02 20:58 ` Ludovic Courtès
2011-05-02 21:58 ` Andy Wingo
2011-05-02 22:18 ` Ludovic Courtès
2011-05-03 7:44 ` Andy Wingo [this message]
2011-05-03 8:38 ` Ludovic Courtès
2011-05-04 3:59 ` Mark H Weaver
2011-05-04 4:13 ` Noah Lavine
2011-05-04 9:24 ` Ludovic Courtès
2011-05-17 16:59 ` Noah Lavine
2011-05-17 19:26 ` Mark H Weaver
2011-05-17 20:03 ` Mark H Weaver
2011-05-23 19:42 ` Filenames and other POSIX byte strings as SCM strings without loss Mark H Weaver
2011-07-01 10:51 ` Andy Wingo
2011-05-23 20:14 ` Paths as sequences of path components Mark H Weaver
2011-05-24 10:51 ` Hans Aberg
2011-11-23 22:15 ` Andy Wingo
2011-11-25 2:51 ` Mark H Weaver
2011-06-16 22:29 ` [PATCH 2/5] [mingw]: Have compiled-file-name produce valid names Andy Wingo
2011-05-02 23:16 ` Eli Barzilay
2011-05-20 13:47 ` Jan Nieuwenhuizen
2011-05-20 14:01 ` Andy Wingo
2011-06-30 14:11 ` Andy Wingo
2011-02-15 15:35 ` [PATCH 3/5] [mingw]: Do not export opendir, readdir etc., as dirents differ Jan Nieuwenhuizen
2011-05-01 11:37 ` Andy Wingo
2011-05-20 13:57 ` Jan Nieuwenhuizen
2011-06-16 22:22 ` Andy Wingo
2011-02-15 15:35 ` [PATCH 4/5] [mingw]: Delete existing target file before attempting rename Jan Nieuwenhuizen
2011-05-01 11:40 ` Andy Wingo
2011-05-20 14:05 ` Jan Nieuwenhuizen
2011-06-16 21:45 ` Andy Wingo
2011-02-15 15:35 ` [PATCH 5/5] [mingw]: Use $LOCALAPPDATA as a possible root for cachedir Jan Nieuwenhuizen
2011-05-01 11:42 ` Andy Wingo
2011-05-20 14:03 ` Jan Nieuwenhuizen
2011-06-16 22:02 ` Andy Wingo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3zkn4rzxx.fsf@unquote.localdomain \
--to=wingo@pobox.com \
--cc=eli@barzilay.org \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).