[plt-scheme] v299: process* file args, paths, strings, and byte-strings

Actually, a file with a name that is impossible to express in the
current locale isn't all that uncommon. Take Israeli Windows XP users,
because it is a good example. Many users here have their locale set to
Hebrew. However, if one of them downloads a file, say, with the name
Ce-dossier-est-en-français, or Este-archivo-ser-en-Español, the ç or ñ
would stay there, and be impossible to express. But, there is a far
more common problem: many users in Israel have their locale set to
English (US) (because that's the default) but still use Hebrew in many
of their file names. This causes all of the Hebrew files to be
impossible to express.

ifconfig nslookup

On Tue, 19 Oct 2004 21:55:27 -0400, John Clements
<clements at brinckerhoff.org> wrote:
> 
> On Oct 19, 2004, at 9:02 PM, Matthew Flatt wrote:
> >
> > `path->string' should be right. Under Unix and Mac OS X, `process*'
> > will convert its arguments to bytes using the current locale's
> > encoding, and `path->string' converts the path to a string using the
> > current locale's encoding, so they're consistent.
> >
> > It's possible to have a path that can't be expressed in the locale's
> > encoding. In that case, though, you wouldn't be able to type the
> > corresponding command in your shell (er, assuming that your shell uses
> > the locale encoding, which it probably does).
> 
> This came up for me, too.
> 
> IIUC, MzScheme should 'know' when it gets a path that can't be
> expressed in the locale's encoding, right?  So it should be possible to
> have a 'path->string/conservative' that signals an error if the path
> can't be expressed as a string?
> 
> I admit that this is a peculiar corner case, but it _would_ seem
> possible to have two independent file-system entities (A & B, say)
> whose paths mapped to the same string, a string that is interpreted by
> a string-expecting system call to refer to B.  So references to A would
> wind up (in system call) affecting B instead. Is my reading correct?
> 
> john
> 
> 
>