From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Re: [babel] How to kill two birds with one stone? Date: Fri, 25 Feb 2011 17:44:43 -0500 Message-ID: <4851.1298673883@alphaville.usa.hp.com> References: <808vxv23j2.fsf@missioncriticalit.com> <80mxm9yulk.fsf@missioncriticalit.com> <87sjvj6oul.fsf@gmail.com> <80y654nq9a.fsf@somewhere.org> Reply-To: nicholas.dokos@hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=55322 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pt6P4-00049F-Ot for emacs-orgmode@gnu.org; Fri, 25 Feb 2011 17:44:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pt6Oz-0004H5-B3 for emacs-orgmode@gnu.org; Fri, 25 Feb 2011 17:44:50 -0500 Received: from g6t0185.atlanta.hp.com ([15.193.32.62]:16988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pt6Oz-0004Gz-7F for emacs-orgmode@gnu.org; Fri, 25 Feb 2011 17:44:45 -0500 In-Reply-To: Message from =?us-ascii?Q?=3D=3Futf-8=3FQ=3FS=3DC3=3DA9bastie?= =?us-ascii?Q?n=5FVauban=3F=3D?= of "Fri\, 25 Feb 2011 15\:27\:29 +0100." <80y654nq9a.fsf@somewhere.org> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FS=3DC3=3DA9bastien=5FVauban=3F=3D?= Cc: nicholas.dokos@hp.com, emacs-orgmode@gnu.org S=C3=A9bastien Vauban wrote: > ...=20 > * List all files in dir (version of Seb) >=20 > My code was a bit more complex... because I need to be able to correctly = take > care of filenames containing spaces inside them (I'm on Windows, I never = do > such a thing, but there are well spaces on the files I wanna graph). >=20 > #+srcname: graph-files-seb > #+begin_src sh :results vector :var dir=3Dgraph-dir > find $dir -type f -print |\ > while read -r name > do > echo "\"${name##*/}\"" > done > #+end_src >=20 > #+results: graph-files-seb > | dan | | > | eric | | > | other | | > | "seb | vauban" | >=20 I suspect that this is a losing battle: spaces in filenames are legal, they are common on Windows systems, but they are a PITA. The main reason is that a *lot* of tools (particularly Unix tools of a certain age) assume that spaces in filenames will not occur and break in mysterious and unexpected ways when presented with a directory structure that contains such. There are various workarounds (the most important of which, practically spe= aking, is the idiom find ... -print0 | xargs -0 .... which causes ``find'' to use a null byte as a separator and ``xargs'' to search for same in order to split the list into its constituent components - null bytes being illegal in filenames), and there is a long, fairly exhaustive discusssion of such matters in David Wheeler's enlightening essay: http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html but none of these would help in this case, because the culprit here turns out to be org-table-convert-region: ,---- | org-table-convert-region is an interactive Lisp function in | `org-table.el'. |=20 | (org-table-convert-region BEG0 END0 &optional SEPARATOR) |=20 | Convert region to a table. | The region goes from BEG0 to END0, but these borders will be moved | slightly, to make sure a beginning of line in the first line is included. |=20 | SEPARATOR specifies the field separator in the lines. It can have the | following values: |=20 | '(4) Use the comma as a field separator | '(16) Use a TAB as field separator | integer When a number, use that many spaces as field separator | nil When nil, the command tries to be smart and figure out the | separator in the following way: | - when each line contains a TAB, assume TAB-separated material | - when each line contains a comma, assume CSV material | - else, assume one or more SPACE characters as separator. |=20 `---- It is called with a nil separator so it uses its "smart" mode and counts one or more whitespace characters as the separator (I wonder what would happen with a filename that contains a comma :-) In any case, the region has the filenames one per line, so if org-table-convert-region could parse a newline-separated list (and if there was a way to specify the newline separator from higher levels) everything would be hunky dory; there might be a way to specify the separator using dynamic scoping, but org-table-convert-region would require some changes to take advantage of it. Nick