From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: A few issues with thumbs.el Date: Thu, 26 May 2005 20:22:35 +0200 Message-ID: References: <87br6zuerw.fsf-monnier+emacs@gnu.org> <87u0kqrsur.fsf-monnier+emacs@gnu.org> <87vf56q6fk.fsf-monnier+emacs@gnu.org> Reply-To: Juanma Barranquero NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1117131889 7907 80.91.229.2 (26 May 2005 18:24:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 26 May 2005 18:24:49 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 26 20:24:47 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DbN14-0002fy-Rl for ged-emacs-devel@m.gmane.org; Thu, 26 May 2005 20:23:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DbN5C-0007dX-1b for ged-emacs-devel@m.gmane.org; Thu, 26 May 2005 14:27:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DbN4g-0007ZP-K1 for emacs-devel@gnu.org; Thu, 26 May 2005 14:27:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DbN4c-0007Wm-Kt for emacs-devel@gnu.org; Thu, 26 May 2005 14:27:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DbN4c-0007W5-1r for emacs-devel@gnu.org; Thu, 26 May 2005 14:27:14 -0400 Original-Received: from [64.233.184.198] (helo=wproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DbN0o-0007Lf-55 for emacs-devel@gnu.org; Thu, 26 May 2005 14:23:18 -0400 Original-Received: by wproxy.gmail.com with SMTP id 50so730905wri for ; Thu, 26 May 2005 11:22:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hdrZkosgPMb+NtNc10zxE/mbkMamiDfZtelOokQKf7en+pUcjMgCrq0xsqaT4BMMPw0kwZw6by5HZ3mt13nen8hW+51aa0Ns2YkLp/0DimnhfXKcUCGF5r4OwSASajfqTQMP607AHDVnR4m3Zpj7G9KreDlGqbLOoPOSX0XM+/w= Original-Received: by 10.54.23.26 with SMTP id 26mr1102585wrw; Thu, 26 May 2005 11:22:35 -0700 (PDT) Original-Received: by 10.54.82.6 with HTTP; Thu, 26 May 2005 11:22:35 -0700 (PDT) Original-To: emacs-devel@gnu.org In-Reply-To: <87vf56q6fk.fsf-monnier+emacs@gnu.org> Content-Disposition: inline X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:37722 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37722 > Oh, right. So the docstring should be fixed to make it clear that the > argument should be an *absolute* file name. Uh? convert-standard-filename works right with non-absolute paths: (convert-standard-filename "file/test:.dat") =3D> "file\\test!.dat" It just handles an initial "X:" differently (on Windows): (convert-standard-filename "c:file/test:.dat") =3D> "c:file\\test!.dat" I see nothing wrong with convert-standard-filename or its docstring. AFAICS, the problem is that convert-standard-filename is intended to transform a filename into another filename, suitable for the current filesystem. But what you're trying in the code you proposed is using convert-standard-filename to build the *name* part of a filename. There's nothing anywhere that guarantees that a filename (with path etc) is a valid name for a file. In MS-DOS/Windows you've got the ":", in VMS the brackets, etc. When you concatenate thumbs-thumbsdir with the output of convert-standard-filename, the result can perfectly be a non-valid filename. So you'll have to use convert-standard-filename, and then filter its output to remove potentially dangerous characters, or, as I did in my example, use convert-standard-filename as the last pass: (convert-standard-filename (concat thumbs-thumbsdir "/" (subst-char-in-string [etc...]) I don't think the trouble is worth the tiny benefit that the filename of the cached thumbnail is user-friendly on debugging. If someone has to debug it he can modify thumbs-thumbname easily enough. --=20 /L/e/k/t/u