From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Paths as sequences of path components Date: Mon, 23 May 2011 16:14:19 -0400 Message-ID: <8762p1kwdg.fsf_-_@netris.org> References: <1297784103-18322-1-git-send-email-janneke-list@xs4all.nl> <1297784103-18322-3-git-send-email-janneke-list@xs4all.nl> <87r58gzuoy.fsf@gnu.org> <87vcxsycds.fsf@gnu.org> <87wri7ru80.fsf@netris.org> <87zkn2stsf.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1306181680 25234 80.91.229.12 (23 May 2011 20:14:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 May 2011 20:14:40 +0000 (UTC) Cc: Andy Wingo , Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon May 23 22:14:35 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QObWN-0004oz-Lx for guile-devel@m.gmane.org; Mon, 23 May 2011 22:14:35 +0200 Original-Received: from localhost ([::1]:36460 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QObWN-0003H8-3l for guile-devel@m.gmane.org; Mon, 23 May 2011 16:14:35 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:49908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QObWK-0003Gs-H6 for guile-devel@gnu.org; Mon, 23 May 2011 16:14:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QObWJ-0005je-La for guile-devel@gnu.org; Mon, 23 May 2011 16:14:32 -0400 Original-Received: from world.peace.net ([96.39.62.75]:55650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QObWH-0005j1-4J; Mon, 23 May 2011 16:14:29 -0400 Original-Received: from 209-6-41-222.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.41.222] helo=freedomincluded) by world.peace.net with esmtpa (Exim 4.69) (envelope-from ) id 1QObW9-0001gl-Rg; Mon, 23 May 2011 16:14:21 -0400 Original-Received: from mhw by freedomincluded with local (Exim 4.69) (envelope-from ) id 1QObW8-000372-4A; Mon, 23 May 2011 16:14:20 -0400 In-Reply-To: (Noah Lavine's message of "Tue, 17 May 2011 12:59:16 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12524 Archived-At: Hello all, I really like the basic gist behind Noah's proposal, to allow programs to optionally represent paths (roughly) as sequences of path components. I haven't worked out all the details, and I'm glad to leave that job to someone else, but I do have a few comments to add: First of all, I think that the paths-as-components layer should be _above_ the POSIX-bytestrings-as-SCM-strings layer. In other words, the pathnames-as-components code should represent both complete pathnames and path components as SCM strings. In addition, I hope that the paths-as-components layer will allow code to conveniently manipulate paths while avoiding some of the common security problems that can arise. For example, a web application should be able to easily and safely use a user-supplied string to construct a pathname, without having to search the user-supplied string for things like "../../../../etc/passwd". When constructing paths from components, I think we should prevent a single component from being interpreted by the OS as multiple components. In other words, we should make sure that components do not contain path separators or other characters which are illegal in filenames (e.g. NUL). Either an exception should be thrown or they should be escaped somehow. If escaped, I think the transformation should be bijective. Also, I think there should be a very simple way to exclude "special" path components such as "." from "..", in a platform-neutral way. On the other hand, sometimes you really do need to include "." or ".." in a path, and so it ought to be possible to include them if needed. Apart from this, I wish to raise some questions for which I don't have answers: Should we provide a way to represent paths with multiple consecutive path separators? How should things like drive letters in DOS filenames be handled? How should the distinction between absolute and relative paths be handled? Should our existing POSIX interfaces which accept pathnames be extended to optionally accept these higher-level path objects? Best, Mark