From: ludo@gnu.org (Ludovic Courtès)
To: Eli Zaretskii <eliz@gnu.org>
Cc: guile-devel@gnu.org
Subject: Re: Windows file name separators
Date: Mon, 30 Jun 2014 13:15:44 +0200 [thread overview]
Message-ID: <87ioni1wdb.fsf@gnu.org> (raw)
In-Reply-To: <83egyw21qd.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 10 Jun 2014 19:00:58 +0300")
Eli Zaretskii <eliz@gnu.org> skribis:
>> From: ludo@gnu.org (Ludovic Courtès)
>> Date: Mon, 09 Jun 2014 21:42:36 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> skribis:
>>
>> > 3. load.test fails:
>> >
>> > FAIL: load.test: search-path for "foo.scm" yields "dir1/foo.scm"
>> >
>> > (The messages are misleading: "yields" should be "should yield".)
>> >
>> > The test fails because:
>> >
>> > . it compares file names with equal?, which fails when Windows
>> > file names with mixed forward and backslashes are used, and/or
>> > when the files differ but for letter case
>> >
>> > . the expected result uses a relative file name of temp-dir, while
>> > search-path returns absolute file names
>> >
>> > Fixed by using "/" to create a file name from its parts in load.c:
>> >
>> > --- libguile/load.c~ 2014-02-28 23:01:27 +0200
>> > +++ libguile/load.c 2014-06-08 13:27:24 +0300
>> > @@ -452,11 +452,15 @@ scm_c_string_has_an_ext (char *str, size
>> > return 0;
>> > }
>> >
>> > +#if 0
>> > #ifdef __MINGW32__
>> > #define FILE_NAME_SEPARATOR_STRING "\\"
>> > #else
>> > #define FILE_NAME_SEPARATOR_STRING "/"
>> > #endif
>> > +#else
>> > +#define FILE_NAME_SEPARATOR_STRING "/"
>> > +#endif
>> >
>> > static int
>> > is_file_name_separator (SCM c)
>> >
>> > I don't see any reasons to use the backslashes when constructing
>> > Windows file names. Unless someone can tell why using backslashes
>> > is a good idea, I propose to remove the Windows setting of
>> > FILE_NAME_SEPARATOR_STRING.
>>
>> I’m confused: this was added in 4bab7f01 precisely to support MinGW or
>> Windows. Similarly, boot-9.scm has ‘file-name-separator-string’ and
>> related stuff. This was the result of the discussion at
>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10474#89>.
>
> Sorry, that's my fault: I didn't explain the problem in enough detail.
>
> There's nothing wrong with the 4bab7f01 commit per se (and you will
> see that its only part that I changed is the definition of
> FILE_NAME_SEPARATOR_STRING for MinGW). The problem is not in that
> commit, it is elsewhere: in Scheme code, in this case in the test
> suite, that compares file names as simple strings. Such comparisons
> fail if the file names differ by the style of directory separators:
> one uses forward slashes, the other backslashes, or some mix thereof.
>
> Now, FILE_NAME_SEPARATOR_STRING is used only for constructing file
> names from their parts. It is not used for testing a particular
> file-name character for being a directory separator. Therefore, we
> can discard the separate definition of FILE_NAME_SEPARATOR_STRING for
> Windows, and use "/" on all platforms. This makes the problem of
> comparing file names easier, and in particular lets Guile pass
> load.test. But it doesn't solve the problem entirely.
OK. This and your other message clarify things, thanks.
> To solve this problem completely, we need a function that
> canonicalizes a file name wrt directory separators -- converts all
> backslashes to forward slashes. Does Guile have such a function?
My understanding of your other message is that you now advocate trying
hard to stick to slashes instead of backslashes, in which case a file
name canonicalization function is practically unnecessary, right?
Thanks,
Ludo’.
next prev parent reply other threads:[~2014-06-30 11:15 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-08 15:04 MinGW issues in Guile 2.0.11 Eli Zaretskii
2014-06-09 15:47 ` Eli Zaretskii
2014-06-09 18:01 ` Mark H Weaver
2014-06-09 18:25 ` Eli Zaretskii
2014-06-09 19:30 ` MinGW vs. setlocale Ludovic Courtès
2014-06-10 16:17 ` Eli Zaretskii
2014-06-11 13:13 ` Ludovic Courtès
2014-06-11 15:33 ` Eli Zaretskii
2014-06-12 8:39 ` Ludovic Courtès
2014-06-12 18:18 ` Eli Zaretskii
2014-06-15 17:23 ` Eli Zaretskii
2014-06-21 11:17 ` Eli Zaretskii
2014-06-21 15:02 ` Ludovic Courtès
2014-06-21 15:11 ` Eli Zaretskii
2014-06-21 21:23 ` Ludovic Courtès
2014-06-22 16:13 ` Eli Zaretskii
2014-06-19 4:53 ` Doug Evans
2014-06-19 8:16 ` Ludovic Courtès
2014-06-09 19:32 ` MinGW vs. c-api.test Ludovic Courtès
2014-06-10 9:05 ` Neil Jerram
2014-06-10 11:42 ` Ludovic Courtès
2014-06-10 15:32 ` Eli Zaretskii
2014-06-10 15:56 ` David Kastrup
2014-06-10 18:00 ` Eli Zaretskii
2014-06-11 0:36 ` dsmich
2014-06-11 2:52 ` Eli Zaretskii
2014-06-10 11:44 ` Ludovic Courtès
2014-06-10 15:39 ` Eli Zaretskii
2014-06-11 12:37 ` Ludovic Courtès
2014-06-11 15:08 ` Eli Zaretskii
2014-06-12 8:29 ` Ludovic Courtès
2014-06-12 17:16 ` Eli Zaretskii
2014-06-12 19:48 ` Ludovic Courtès
2014-06-12 19:59 ` Eli Zaretskii
2014-06-12 21:20 ` Ludovic Courtès
2014-06-13 9:15 ` Neil Jerram
2014-06-13 16:04 ` Ludovic Courtès
2014-06-13 16:19 ` Eli Zaretskii
2014-06-13 16:26 ` Neil Jerram
2014-06-13 16:31 ` Mike Gerwitz
2014-06-13 18:09 ` Eli Zaretskii
2014-06-09 19:42 ` Windows file name separators Ludovic Courtès
2014-06-10 16:00 ` Eli Zaretskii
2014-06-30 11:15 ` Ludovic Courtès [this message]
2014-06-30 14:56 ` Eli Zaretskii
2014-07-01 9:36 ` Ludovic Courtès
2014-07-01 15:30 ` Eli Zaretskii
2014-07-01 15:38 ` Ludovic Courtès
2014-07-02 16:04 ` Eli Zaretskii
2014-07-02 20:56 ` Ludovic Courtès
2014-07-02 20:57 ` Ludovic Courtès
2014-07-03 15:10 ` Eli Zaretskii
2014-07-03 17:11 ` Ludovic Courtès
2014-07-03 18:09 ` Eli Zaretskii
2014-07-07 20:53 ` Mark H Weaver
2014-07-08 2:37 ` Eli Zaretskii
2014-07-02 16:13 ` Fix 'dirname' and 'basename' on MS-Windows Eli Zaretskii
2014-07-09 14:22 ` Ludovic Courtès
2014-07-09 14:53 ` Eli Zaretskii
2014-07-02 16:16 ` Provide reasonable stack limit " Eli Zaretskii
2014-07-02 21:02 ` Ludovic Courtès
2014-07-03 16:28 ` Eli Zaretskii
2014-07-02 16:30 ` Bug in scm_getaffinity Eli Zaretskii
2014-07-02 21:04 ` Ludovic Courtès
2014-07-03 16:31 ` Eli Zaretskii
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=87ioni1wdb.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=eliz@gnu.org \
--cc=guile-devel@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).