unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Marko Rauhamaa <marko@pacujo.net>
To: Chris Vine <chris@cvine.freeserve.co.uk>
Cc: guile-user@gnu.org
Subject: Re: Running script from directory with UTF-8 characters
Date: Tue, 22 Dec 2015 17:55:58 +0200	[thread overview]
Message-ID: <87bn9ieaup.fsf@elektro.pacujo.net> (raw)
In-Reply-To: <20151222142125.17ba7368@bother.homenet> (Chris Vine's message of "Tue, 22 Dec 2015 14:21:25 +0000")

Chris Vine <chris@cvine.freeserve.co.uk>:

> On Tue, 22 Dec 2015 03:14:18 +0200
> Marko Rauhamaa <marko@pacujo.net> wrote:
>> For example,
>> 
>>     scheme@(guile-user)> (opendir ".")
>>     $1 = #<directory stream f7ffa0>
>>     [...]
>>     scheme@(guile-user)> (readdir $1)
>>     $4 = "?9t\x1b["
>>     scheme@(guile-user)> (open-file $4 "r")
>>     ERROR: In procedure open-file:
>>     ERROR: In procedure open-file: No such file or directory:
>> "?9t\x1b["
>
> You can set the locale in the REPL, if that is where you are working
> from (as in your example), and then UTF-8 pathnames will work fine.

You misunderstood me. The problem is that Guile cannot deal with
non-UTF-8 pathnames in a UTF-8 locale. IOW, Linux pathnames are *not*
strings. They are bytevectors. Guile 1.x (as well as Python 2.x) was
fine bytevector pathnames, but Guile 2.x (as well as Python 3.x) wants
to pretend filenames are strings. That leads to trouble, potentially
even to security vulnerabilities.

A very typical case is a tarball that contains, say, Latin-1 filenames.
If you should expand the tarball in a UTF-8 environment, Guile wouldn't
be able to deal with the situation.


Marko



  reply	other threads:[~2015-12-22 15:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-21 21:09 Running script from directory with UTF-8 characters Vicente Vera
2015-12-21 23:19 ` Marko Rauhamaa
2015-12-22  0:34   ` Chris Vine
2015-12-22  1:14     ` Marko Rauhamaa
2015-12-22 14:21       ` Chris Vine
2015-12-22 15:55         ` Marko Rauhamaa [this message]
2015-12-22 20:12           ` Chris Vine
2015-12-22 20:36             ` Marko Rauhamaa
2015-12-22 20:59               ` Eli Zaretskii
2015-12-22 21:39                 ` Marko Rauhamaa
2015-12-23 18:28                   ` Eli Zaretskii
2015-12-23 19:18                     ` Marko Rauhamaa
2015-12-23 19:33                       ` Eli Zaretskii
2015-12-23 21:15                         ` Marko Rauhamaa
2015-12-23 21:53                         ` David Kastrup
2015-12-23 22:20                           ` Marko Rauhamaa
2015-12-23 22:25                             ` David Kastrup
2015-12-24 16:13                   ` Barry Schwartz
2015-12-22 14:32   ` Vicente Vera
2015-12-22 15:56     ` Marko Rauhamaa
2015-12-26  1:57       ` Vicente Vera

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=87bn9ieaup.fsf@elektro.pacujo.net \
    --to=marko@pacujo.net \
    --cc=chris@cvine.freeserve.co.uk \
    --cc=guile-user@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).