chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH 3/4] Remove ##sys#expand-home-path.


From: Mario Domenech Goulart
Subject: Re: [Chicken-hackers] [PATCH 3/4] Remove ##sys#expand-home-path.
Date: Mon, 18 Mar 2013 10:33:49 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Hi,

On Mon, 18 Mar 2013 14:30:13 +0000 Alaric Snell-Pym <address@hidden> wrote:

> On 03/16/2013 05:18 PM, Florian Zumbiehl wrote:
>>
>>> having a "clean file-system API", whatever that means.
>>
>> I think primarily that you can read a directory and use the filenames you
>> get back for opening the files in that directory rather than being
>> surprised with some other file or an exception? Or not re-expanding command
>> line arguments that the shell has already expanded?
>
> Indeed. It's hard to define "clean", but I'm pretty sure that requiring
> extra string manipulation on the paths the filesystem API returns you
> before you can feed them back into it is definitely "unclean" :-)
>
> Now, we might say that chicken pathnames have $/~ expansion as part of
> their semantics, in which case DIRECTORY should be changed to return
> pathnames with leading $/~ escaped, and any other places where Chicken
> Pathnames interface with System Pathnames in the FFI likewise changed to
> apply an appropriate conversion. But I think that would be more work,
> and still trip people up on account of chicken pathnames still being
> strings, so there being no reliable way to automatically convert or warn
> if the wrong kind is used in the wrong place or whatever. Just code that
> seems to work, but breaks strangely in strange situations.

Excuse my sincerity, but I think we should just remove all the
expansions that the port/file operations currently do and let code that
rely on them break.

I doubt code that rely on those expansions handle cases that may trigger
injection of unexpected paths, so they are inherently broken anyway.

Making robust software in shell scripting languages is hard, and one of
the reasons it is hard is that shells perform a lot of "convenient"
operations behind our back.  They may be convenient for interactive use,
indeed, but for programs they usually imply handling corner cases that
the programmer ends up forgetting, leading to bugs that are hard to
reproduce, find and fix.


Best wishes.
Mario
-- 
http://parenteses.org/mario



reply via email to

[Prev in Thread] Current Thread [Next in Thread]