From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v481) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Michael Baldwin To: 9fans@cse.psu.edu Content-Transfer-Encoding: 7bit Message-Id: Subject: [9fans] spaces in filenames Date: Fri, 31 May 2002 23:35:47 -0400 Topicbox-Message-UUID: a3a2b996-eaca-11e9-9e20-41e7f4b1d025 really, what is the big deal with spaces in filenames? yeah, there are some file formats here and there, and some shell files that maybe aren't so careful, so it's not a cakewalk, but it isn't some Big Huge Problem. using shells like rc that manage lists of string works quite well; if you need a list of files use "ls" not "echo"; if you really want to use the output of a command with backquote, set ifs to \t\n. geoff talks about how maddening it is to use filenames with spaces on mac os x. i use mac os x too, and have lots of files with spaces, and i use quotes on the occasion that i refer to them in the shell. i haven't noticed any "problem" that would cause me to go mad, and everything works just fine from the shell and the gui for me. i send spacey filenames to web sites, attach/detach them from mail messages, move them about, and things work. what am i missing? now that i can use spaces, i kinda like using space instead of _ in names -- easier to type and easier to read. why banish the poor lowly space character? so call me a communist for my radical views. the only problem i've had with spaces is getting to spacey files on windows and unix from plan 9 and inferno. i took out the space restriction in inferno and things work swimmingly. yeah, i know there are gotchas here and there, but they really haven't been an issue. i much prefer the ability to manipulate files to the odd gotcha. oh, the non-printable range also includes 7F, so it's really 00-1F and 7F-9F that are restricted. it does seem to be a Good Thing that \t and \n are not allowed, leaving them usable as delimiters. unix lets you create such files, but they definitely seem rare, and it is a bit harder to do from a gui. who cares if they don't work right. but leave poor space alone. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <98980baaa19b1da58bf31a8435a4b978@collyer.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames From: Geoff Collyer MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Fri, 31 May 2002 22:02:33 -0700 Topicbox-Message-UUID: a3a87228-eaca-11e9-9e20-41e7f4b1d025 Okay, you're a communist. ☺ On Unix, part of the problem is scripts that use $* when they should use "$@", but the need to quote file names containing spaces interactively is an on-going nuisance. If you're going to allow spaces, then why not allow tabs? They have traditionally been considered equivalent whitespace, with a few exceptions (e.g., make, tbl). I don't see a compelling reason to allow spaces but not tabs. And if you allow spaces and tabs, why not newline, it's whitespace too. And as long as we're allowing any old character in file names, why not allow slashes in file name components? Sure, we'll have to introduce some ugly hack like having the kernel understand /this\/is\/all\/one\/component, but by now we're not afraid of a little quoting, right? And why discriminate against NUL? Shouldn't one be able to have a file name like 'This is a history of the \0, \\ and \/ characters in computing, © 2002 Peter Pedant<\/a>', where \0 represents a NUL byte? We could also adopt another Mac OS tradition, case-insensitive file names. Pretty soon our file names will be as ungodly a stew as anything ever parsed by MVS or VMS. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sam To: <9fans@cse.psu.edu> Subject: Re: [9fans] spaces in filenames In-Reply-To: <20020601100550.B11922@honk.eecs.harvard.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sat, 1 Jun 2002 09:15:20 -0400 Topicbox-Message-UUID: a3daeb04-eaca-11e9-9e20-41e7f4b1d025 > On Sat, Jun 01, 2002 at 02:55:47PM +0000, Richard Miller wrote: > I got myself into trouble recently by misunderstanding the syntax > of the kfs 'rename' command. If you do something like > > disk/kfscmd 'rename /tmp/xxx /tmp/yyy' > > you end up with a file in /tmp with slashes in its name. Exercise > for the reader: how do you get rid of it? > hmm ... disk/kfscmd 'rename /tmp/\/tmp\/yyy yyy'? From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [9fans] spaces in filenames Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Michael Baldwin To: 9fans@cse.psu.edu Content-Transfer-Encoding: 7bit In-Reply-To: <98980baaa19b1da58bf31a8435a4b978@collyer.net> Message-Id: <48288ED5-7565-11D6-A7FB-000393726A14@orb.sh> Date: Sat, 1 Jun 2002 09:41:31 -0400 Topicbox-Message-UUID: a3ae33ca-eaca-11e9-9e20-41e7f4b1d025 > On Unix, part of the problem is scripts that use $* when they should > use "$@" yeah, so fix them, if it's so easy. are there lots of these around? i haven't noticed. > but the need to quote file names containing spaces interactively is an > on-going nuisance. i guess if you think 'quoting' is a nuisance. yes, you have to quote spaces in shell args. i also have to quote '=' in rc args, and i have to quote ( ) { } * ? and a bunch of other characters. so what? > If you're going to allow spaces, then why not allow tabs? ... why not > newline ... why discriminate against NUL ... because filenames are supposed to be printable "labels" for things. tabs are control characters to adjust the "carriage", like CR and NL are. NUL is a control character. space is just a space, and is thought of as printable. putting spaces in labels is not a radical idea. ever label a paper folder "Mom's recipes"? i don't feel obligated to put an underscore in there instead. and let me tell you, her stuffed peppers are to die for. and i've already said it is very useful to have characters that are guaranteed to be useful as separators. slashes are used for pathname element separation, and for the same reason, it seems a good idea to have a character that always works as an element separator. so stop confusing the issue. i'm talking about space. JUST SPACE. not tab, newline, nul, or slash. i have ALREADY given my reasons for not allowing those (they are non-printable, and it is good to have reliable separators). this is about SPACE ONLY. the only reason you've given to hate spaces is shell sloppiness. we even have the nice new quoted string functions if you want to use them. > We could also adopt another Mac OS tradition, case-insensitive file > names. this is more questionable. but in the case of inferno, which has to live on top of these other systems (windoze does this too), one cannot simply ignore it. "mv A a" on inferno used to delete your poor file "A" instead of move it. oops. and i notice that the shell(s) in mac os x are case-sensitive when using glob matching. > Pretty soon our file names will be as ungodly a stew as anything ever > parsed by MVS or VMS. oh please. allowing the use of space somehow makes filenames a stew? give me a break. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <68ae0f680a3752663a0ced5488e6784d@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames From: "Russ Cox" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sat, 1 Jun 2002 09:46:10 -0400 Topicbox-Message-UUID: a3b82f74-eaca-11e9-9e20-41e7f4b1d025 looks like you pulled in a big one, geoff. where do you get such great lures? From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames From: Richard Miller MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20020601135555.64A7A19A08@mail.cse.psu.edu> Date: Sat, 1 Jun 2002 14:55:47 +0100 Topicbox-Message-UUID: a3c2a5a8-eaca-11e9-9e20-41e7f4b1d025 I got myself into trouble recently by misunderstanding the syntax of the kfs 'rename' command. If you do something like disk/kfscmd 'rename /tmp/xxx /tmp/yyy' you end up with a file in /tmp with slashes in its name. Exercise for the reader: how do you get rid of it? -- Richard From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames From: "Russ Cox" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sat, 1 Jun 2002 10:01:43 -0400 Topicbox-Message-UUID: a3c7f134-eaca-11e9-9e20-41e7f4b1d025 > I got myself into trouble recently by misunderstanding the syntax > of the kfs 'rename' command. If you do something like > > disk/kfscmd 'rename /tmp/xxx /tmp/yyy' > > you end up with a file in /tmp with slashes in its name. Exercise > for the reader: how do you get rid of it? That's one of the first Plan 9 mistakes I ever made. I killed off the partition and started afresh. (Not the right answer.) Anyhow, you didn't misunderstand the syntax. That should have worked. That's how the install moves your old file system into /3e. The case where src and dst are in same directory must use the wrong name. Russ From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 1 Jun 2002 10:05:50 -0400 From: William Josephson To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames Message-ID: <20020601100550.B11922@honk.eecs.harvard.edu> References: <20020601135555.64A7A19A08@mail.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020601135555.64A7A19A08@mail.cse.psu.edu>; from miller@hamnavoe.demon.co.uk on Sat, Jun 01, 2002 at 02:55:47PM +0000 Topicbox-Message-UUID: a3ce0c4a-eaca-11e9-9e20-41e7f4b1d025 On Sat, Jun 01, 2002 at 02:55:47PM +0000, Richard Miller wrote: > I got myself into trouble recently by misunderstanding the syntax > of the kfs 'rename' command. If you do something like > > disk/kfscmd 'rename /tmp/xxx /tmp/yyy' > > you end up with a file in /tmp with slashes in its name. Exercise > for the reader: how do you get rid of it? You should be able to rename it again; maybe you'll need to rename it in to another directory if there is a bug. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <8a720f5eef7f37a0d9efa9773de38bfe@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames From: "Russ Cox" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sat, 1 Jun 2002 10:10:18 -0400 Topicbox-Message-UUID: a3d5a284-eaca-11e9-9e20-41e7f4b1d025 > You should be able to rename it again; maybe you'll need to rename > it in to another directory if there is a bug. BZZT! How do you rename it? When you pass the path to kfs or the kernel, it will tokenize it into 'tmp' 'xxx' 'tmp' 'yyy' instead of 'tmp' 'xxx' '/tmp/yyy' as is necessary. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <098f5dbb6c8eba3b60049b80b4e237d4@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames From: "Russ Cox" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sat, 1 Jun 2002 10:15:35 -0400 Topicbox-Message-UUID: a3e2a574-eaca-11e9-9e20-41e7f4b1d025 > hmm ... disk/kfscmd 'rename /tmp/\/tmp\/yyy yyy'? you expect far too much from kfs. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <62fa56bc4e012eb25c221bdf313644f2@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames From: "Russ Cox" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sat, 1 Jun 2002 10:16:07 -0400 Topicbox-Message-UUID: a3ea4a04-eaca-11e9-9e20-41e7f4b1d025 > Anyhow, you didn't misunderstand the syntax. > That should have worked. That's how the > install moves your old file system into /3e. > The case where src and dst are in same > directory must use the wrong name. I have no idea why this doesn't work. I'm staring at the rename code and it really should work. Unless I misunderstand what nextelem does. You'll note that disk/kfscmd 'rename /tmp/yyy a/b/c/d' correctly diagnoses the fact that there are slashes in the new name. Destinations beginning with / are supposed to do what you expect. I'm leaving for a trip soon, but will be online with reasonable frequency. If someone else wants to add the appropriate print, figure out what's wrong, and send me a fix, I'd be happy to put it in. Russ From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Michael Baldwin To: 9fans@cse.psu.edu Content-Transfer-Encoding: 7bit In-Reply-To: <68ae0f680a3752663a0ced5488e6784d@plan9.bell-labs.com> Message-Id: Subject: [9fans] lures Date: Sat, 1 Jun 2002 10:34:13 -0400 Topicbox-Message-UUID: a3f00f8e-eaca-11e9-9e20-41e7f4b1d025 yeah, that's what i like about geoff. if you can't have animated discussions of such fringe stuff as cursor keys vs. mouse or spaces in filenames on 9fans, then it would be a duller world. From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 1 Jun 2002 10:38:47 -0400 From: William Josephson To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames Message-ID: <20020601103847.A12183@honk.eecs.harvard.edu> References: <8a720f5eef7f37a0d9efa9773de38bfe@plan9.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <8a720f5eef7f37a0d9efa9773de38bfe@plan9.bell-labs.com>; from rsc@plan9.bell-labs.com on Sat, Jun 01, 2002 at 10:10:18AM -0400 Topicbox-Message-UUID: a3fa1416-eaca-11e9-9e20-41e7f4b1d025 On Sat, Jun 01, 2002 at 10:10:18AM -0400, Russ Cox wrote: > > You should be able to rename it again; maybe you'll need to rename > > it in to another directory if there is a bug. > > BZZT! How do you rename it? When you pass > the path to kfs or the kernel, it will tokenize Forgot that kfs will parse the path, too. I can bypass the kernel easily enough: I wrote a stupid 9p shell after I broke some names on the fileserver by untarring something on a 9p2k terminal. Guess it is time to do some hacking... From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames From: Richard Miller MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-vlqwdsqdiivvdjntmbwqevhqoy" Message-Id: <20020601145528.C415D19ADB@mail.cse.psu.edu> Date: Sat, 1 Jun 2002 15:55:20 +0100 Topicbox-Message-UUID: a403a044-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-vlqwdsqdiivvdjntmbwqevhqoy Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > Anyhow, you didn't misunderstand the syntax. > That should have worked. That's how the > install moves your old file system into /3e. Sorry, I should have said: this was on a 3rd edition kfs. -- Richard --upas-vlqwdsqdiivvdjntmbwqevhqoy Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from punt-1.mail.demon.net by mailstore for miller@hamnavoe.demon.co.uk id 1022940142:10:00752:17; Sat, 01 Jun 2002 14:02:22 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-1.mail.demon.net id aa1000678; 1 Jun 2002 14:02 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.23.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 2EB29199BC; Sat, 1 Jun 2002 10:02:09 -0400 (EDT) Delivered-To: 9fans@cse.psu.edu Received: from plan9.cs.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by mail.cse.psu.edu (CSE Mail Server) with SMTP id 8EB0719988 for <9fans@cse.psu.edu>; Sat, 1 Jun 2002 10:01:46 -0400 (EDT) Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Sat Jun 1 10:01:45 EDT 2002 Received: from 141.154.233.68 ([141.154.233.68]) by plan9; Sat Jun 1 10:01:44 EDT 2002 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames From: "Russ Cox" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Sat, 1 Jun 2002 10:01:43 -0400 > I got myself into trouble recently by misunderstanding the syntax > of the kfs 'rename' command. If you do something like > > disk/kfscmd 'rename /tmp/xxx /tmp/yyy' > > you end up with a file in /tmp with slashes in its name. Exercise > for the reader: how do you get rid of it? That's one of the first Plan 9 mistakes I ever made. I killed off the partition and started afresh. (Not the right answer.) Anyhow, you didn't misunderstand the syntax. That should have worked. That's how the install moves your old file system into /3e. The case where src and dst are in same directory must use the wrong name. Russ --upas-vlqwdsqdiivvdjntmbwqevhqoy-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] lures Message-ID: <20020601165932.L29024@cackle.proxima.alt.za> References: <68ae0f680a3752663a0ced5488e6784d@plan9.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from Michael Baldwin on Sat, Jun 01, 2002 at 10:34:13AM -0400 Date: Sat, 1 Jun 2002 16:59:33 +0200 Topicbox-Message-UUID: a409f688-eaca-11e9-9e20-41e7f4b1d025 On Sat, Jun 01, 2002 at 10:34:13AM -0400, Michael Baldwin wrote: > > yeah, that's what i like about geoff. if you can't have animated > discussions of such fringe stuff as cursor keys vs. mouse or spaces in > filenames on 9fans, then it would be a duller world. The clincher is that the space is useful both as a separator of command line arguments and as a joiner of filename "words". Seeing as even Micahel Baldwin does not suggest using spaces as path separators (why not?) I would be tempted to go along with the school of thought that proposes using a teeny dot in filenames. The rationale being that long filenames, GUIs and Internationalisation are all the _new_ rage and may as well be lumped into a single paradigm change. That we should need a keyboard key for the new pseudospace (it was very useful in Wang Word Processors, others may remember it from MultiMate days) in as convenient a position as the present space bar, well, that is a little harder to address. Also, I think it was dhog suggesting proportional spacing fonts in program source (I shudder!) but in my mind a diminutive dot would look nice as a linking space in the proportional space representation of a long file name. Finally, the space as a command line argument separator could be sacrificed, but the result would not be aesthetically pleasing, in my opinion. And the diminutive dot would look wrong in this context, specially if using a proportional font. To give Michael his due, spaces in filenames can no longer be suppressed. But if they become very common, it will become more convenient to use a GUI than command line composition. That will be a sad day. ++L PS: It's tempting to dig up the arguments in favour of Oberon's flat filespace, I wonder how it would be received by the proponents of a namespace _based_ on file paths :-) From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200206011654.RAA24007@cthulhu.dircon.co.uk> Subject: Re: [9fans] spaces in filenames In-Reply-To: from Michael Baldwin at "May 31, 2002 11:35:47 pm" To: 9fans@cse.psu.edu From: Digby Tarvin MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Sat, 1 Jun 2002 17:54:42 +0100 Topicbox-Message-UUID: a40fd422-eaca-11e9-9e20-41e7f4b1d025 I always rather liked the old Unix approach of the Kernel allowing anything for which there was no compelling technical reason to forbid. For file names, that used to be (in the old Bell Labs days) any sequence of up to 14 bytes, excluding '/' and the NULL used as terminator (both in the directory entry and the strings passed in system calls). The subsequent relaxation of the length restriction was certainly a good thing, but otherwise I was quite happy with the status quo. As to to desirability of actually using file names with non-printable characters - that is certainly questionable. I would prefer to have a conservative file nameing scheme used in the 'standard' distribution, refraining from unnecessary use of unprintable ascii in file names. But I would no more have the operating system enforce it than I would have the system dictate what bytes appear in a text file. Most objections to flexible file nameing seem to be the result of syntactic limitations of the shell which make it difficult to remove or rename strangely named files when created accidentaly. It was never difficult to to get rid of them by writing a one line C program. As I recall, Unix 6th edition came with a 'dsw' (Delete from SWitches) command to help remove files with funny names. Perhaps something similar is needed. I do recall once amusing myself as a student arranging to be allocated inode '0407' for a directory so that with appropriate choice of file name I could create a directory which would also be an executable program. The most compelling reason I can think of for disliking artificial restrictions on file names (and also case insensitive file names) is that it is so inconvenient when importing file systems from, or sharing filesystems with, less restrictive operating systems. Admittedly you are stuck either way with differences in file name case sensitivity, but I would rather have the problem of not finding a file because of a case mis-match than over-writing a file due to case insensitivity. Although I could probably come up with a scheme whereby files were stored in a case insensitive way, but directories could be searched with a 'case insensitive' option which would return the first match - as a form of wildcarding. It would then be an application issue weather you were protected from accidentally creating multiple files differing only in case. If your file system was case insensitive, a workaround to simulate case sensitivity would be much more difficult. One final comment - on the OS-9 operating system (not to be confused with with MAC OS-9, which it predates by about 20 years...) there is quite a convenient facility which allows file nameing restrictions to be varied dynamically. The default disallows, for instance, spaces in file names. But as a super user, if I want to unpack a tar file which contains such names, I can temporarily redefine the file name validation parameters, unpack the archive, and then revert to normal conventions. This gives the flexibility without the danger of accidental creation of funny files. Perhaps if this facility were available on a per user basis, then those that know what they are doing could relax restrictions when there was a good reason, and others would be protected from mistakes. Regards, DigbyT > really, what is the big deal with spaces in filenames? yeah, there are > some file formats here and there, and some shell files that maybe aren't > so careful, so it's not a cakewalk, but it isn't some Big Huge Problem. > using shells like rc that manage lists of string works quite well; if > you need a list of files use "ls" not "echo"; if you really want to use > the output of a command with backquote, set ifs to \t\n. > > geoff talks about how maddening it is to use filenames with spaces on > mac os x. i use mac os x too, and have lots of files with spaces, and i > use quotes on the occasion that i refer to them in the shell. i haven't > noticed any "problem" that would cause me to go mad, and everything > works just fine from the shell and the gui for me. i send spacey > filenames to web sites, attach/detach them from mail messages, move them > about, and things work. what am i missing? now that i can use spaces, > i kinda like using space instead of _ in names -- easier to type and > easier to read. why banish the poor lowly space character? so call me > a communist for my radical views. > > the only problem i've had with spaces is getting to spacey files on > windows and unix from plan 9 and inferno. i took out the space > restriction in inferno and things work swimmingly. yeah, i know there > are gotchas here and there, but they really haven't been an issue. i > much prefer the ability to manipulate files to the odd gotcha. > > oh, the non-printable range also includes 7F, so it's really 00-1F and > 7F-9F that are restricted. it does seem to be a Good Thing that \t and > \n are not allowed, leaving them usable as delimiters. unix lets you > create such files, but they definitely seem rare, and it is a bit harder > to do from a gui. who cares if they don't work right. but leave poor > space alone. > -- Digby R. S. Tarvin digbyt@acm.org http://www.cthulhu.dircon.co.uk From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Michael Baldwin To: 9fans@cse.psu.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20020601165932.L29024@cackle.proxima.alt.za> Message-Id: <9C52EA7C-7588-11D6-9E8E-000393726A14@orb.sh> Subject: [9fans] spaces, separators, and utf-8 Date: Sat, 1 Jun 2002 13:54:25 -0400 Topicbox-Message-UUID: a415bc34-eaca-11e9-9e20-41e7f4b1d025 On Saturday, June 1, 2002, at 10:59 , lucio@proxima.alt.za wrote: > The clincher is that the space is useful both as a separator of > command line arguments and as a joiner of filename "words". command line arguments can be trivially quoted. if the issue is possible shell misinterpretation, then we've got a whole slew of allowed chars that are "problems": * ? ; < > [ ] { } ` ' " $ & ^ # = \ |. they are all allowed now, and if i type them at a shell, i've got to quote them. one shell (mash) used : as a special char, and there were and are files with colons in them in the plan 9 distribution. so why does space get all the scorn? > Seeing as even Michael Baldwin does not suggest using spaces as path > separators (why not?) ["even Michael Baldwin" -- are you saying i now have a reputation as a communist?!] we already have a separator (/), no need for another one. or are you asking why not space instead? when i call a file "My Great Novel" it doesn't seem natural to think of space as a path separator. i used Primos eons ago, and they used ">", which is perhaps arguably slightly more intuitive than "/" (or ":" or "\"). i can imagine wanting to put a date in a filename as in 2002/06/01 or use / in other ways in names, but > is harder to imagine. but in the end, you must have a separator, so you just pick a char and say it's the separator. it is /. and you cannot use / otherwise in a path. fine, that's life. and 9P even works when accessing something that doesn't use / because the protocol itself doesn't use / in Twalk. so one can even get to those ugly \ systems from plan 9 (until they do something stupid like put / in a path element). but space as a path separator? yikes, no. but speaking to digy's point, i'm glad that control chars are disallowed. i think it is useful to have a char or two that you know are outside the possible charset for filenames. i'm thinking of \t and \n, which can easily be used in text programs to delimit paths if they don't feel like quoting. and NUL, well let's not get started. does NUL work *anywhere*? can't use it in C strings, can't use it in acme or rio or sam, can't use it in old 9P. curiously enough, 9P2000 can actually transport it. but just say no to NUL. > The rationale being that long filenames, GUIs and Internationalisation > are all the _new_ rage and may as well be lumped into a single > paradigm change. hmm, i thought that internationalization by using utf-8 everywhere (including in pathnames) was pioneered by plan 9 itself. and it is a good idea. mac os x uses utf-8 paths and does ok with utf-8 in terminal windows and mail; what about the other unixoid systems? but are there any systems that handle utf-8 as cleanly as plan 9 yet? i don't know of any. the mac has problems (do ls in a Terminal window, or use TextEdit or [gasp] vi or emacs), and if there is a convenient input method, i haven't found it. now it would be a great thing if this attribute of plan 9 (utf-8 everywhere and it just works, decent C language support, and a goodly-sized unicode font) were put into the commercial OS's out there. hey geoff, can you pull that off at apple? certainly you wouldn't be opposed to *that* crusade?! From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Michael Baldwin To: 9fans@cse.psu.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20020601165932.L29024@cackle.proxima.alt.za> Message-Id: <8DE3E682-7589-11D6-9E8E-000393726A14@orb.sh> Subject: [9fans] long path names Date: Sat, 1 Jun 2002 14:01:10 -0400 Topicbox-Message-UUID: a41c0602-eaca-11e9-9e20-41e7f4b1d025 now that long names are really supported in plan 9, when is the archive format going to be fixed? it still uses the 16-char limit from the ancient days, which even 3rd edition plan 9 could choke on (16 < 28). other systems out there use one of i think 3 different hacks to extend the name limit (ugh). From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <20020601182148.28004.qmail@g.bio.cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces, separators, and utf-8 In-Reply-To: Message from Michael Baldwin of "Sat, 01 Jun 2002 13:54:25 EDT." <9C52EA7C-7588-11D6-9E8E-000393726A14@orb.sh> From: Scott Schwartz Date: Sat, 1 Jun 2002 14:21:47 -0400 Topicbox-Message-UUID: a422525a-eaca-11e9-9e20-41e7f4b1d025 | ... and 9P even works when accessing something | that doesn't use / because the protocol itself doesn't use / in Twalk. | so one can even get to those ugly \ systems from plan 9 (until they do | something stupid like put / in a path element). If open took an array of filenames, you wouldn't need a delimiter in the kernel. On the other hand, if there were system calls that gave more direct access to 9p, you could do it that way. An old thread also argued for that on the grounds of making stacked file servers easier to build. | don't feel like quoting. and NUL, well let's not get started. does NUL | work *anywhere*? It is said to work in TCL, where they use a (technically illegal) utf sequence that translates to 0x0000. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200206012200.SAA26314@math.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces, separators, and utf-8 In-Reply-To: Your message of "Sat, 01 Jun 2002 13:54:25 EDT." <9C52EA7C-7588-11D6-9E8E-000393726A14@orb.sh> From: Dan Cross Date: Sat, 1 Jun 2002 18:00:35 -0400 Topicbox-Message-UUID: a43cb15e-eaca-11e9-9e20-41e7f4b1d025 > ["even Michael Baldwin" -- are you saying i now have a reputation as a > communist?!] Yes. - Dan C. :-) From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: "Russ Cox" To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sat, 1 Jun 2002 18:16:31 -0400 Topicbox-Message-UUID: a448c174-eaca-11e9-9e20-41e7f4b1d025 > Sorry, I should have said: this was on a 3rd edition kfs. The bug is still there in the 4e kfs binary I am running. I am just very confused as to why. Russ From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: "Russ Cox" To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sat, 1 Jun 2002 18:17:09 -0400 Topicbox-Message-UUID: a44e67c8-eaca-11e9-9e20-41e7f4b1d025 > I can bypass the kernel easily enough: man 9pcon From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 1 Jun 2002 18:25:59 -0400 From: William Josephson To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames Message-ID: <20020601182559.E13955@honk.eecs.harvard.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rsc@plan9.bell-labs.com on Sat, Jun 01, 2002 at 06:17:09PM -0400 Topicbox-Message-UUID: a45a03a8-eaca-11e9-9e20-41e7f4b1d025 On Sat, Jun 01, 2002 at 06:17:09PM -0400, Russ Cox wrote: > > I can bypass the kernel easily enough: > > man 9pcon I'm aware of it, but last I checked it didn't compile on FreeBSD :-p From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200206031006.g53A6ZI15198@zamenhof.cs.utwente.nl> To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames In-reply-to: Your message of "Sat, 01 Jun 2002 18:17:09 -0400." References: From: Axel Belinfante Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 3 Jun 2002 12:06:35 +0200 Topicbox-Message-UUID: a4901f06-eaca-11e9-9e20-41e7f4b1d025 > > I can bypass the kernel easily enough: > > man 9pcon cpu% aux/9pcon /srv/dns read9pmsg from server: inappropriate use of fd cpu% What does that error message mean? Did I invoke 9pcon in the wrong way? Axel. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <69f257021c2eeab8640b6a28e36772af@plan9.bell-labs.com> From: presotto@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-hfmsokzytqegxzxyielufbviac" Date: Mon, 3 Jun 2002 08:42:16 -0400 Topicbox-Message-UUID: a4960b50-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-hfmsokzytqegxzxyielufbviac Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit YOu can't read and write from user level a file descriptor that has already been mounted. Otherwise, you could side step authentication to file servers. --upas-hfmsokzytqegxzxyielufbviac Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Jun 3 06:07:16 EDT 2002 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon Jun 3 06:07:15 EDT 2002 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id E1F8819A2C; Mon, 3 Jun 2002 06:07:05 -0400 (EDT) Delivered-To: 9fans@cse.psu.edu Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id DF9BF199E4 for <9fans@cse.psu.edu>; Mon, 3 Jun 2002 06:06:43 -0400 (EDT) Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id MAA22935 for <9fans@cse.psu.edu>; Mon, 3 Jun 2002 12:06:40 +0200 (MET DST) Received: from zamenhof.cs.utwente.nl by zeus.cs.utwente.nl (8.10.2+Sun/csrelay-Sol1.4/RB) id g53A6be25601; Mon, 3 Jun 2002 12:06:38 +0200 (MEST) Received: from localhost (belinfan@localhost) by zamenhof.cs.utwente.nl (8.11.6+Sun/8.10.2) with SMTP id g53A6ZI15198 for <9fans@cse.psu.edu>; Mon, 3 Jun 2002 12:06:35 +0200 (MEST) Message-Id: <200206031006.g53A6ZI15198@zamenhof.cs.utwente.nl> X-Authentication-Warning: zamenhof.cs.utwente.nl: belinfan@localhost didn't use HELO protocol X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #20[UCI] To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in filenames In-reply-to: Your message of "Sat, 01 Jun 2002 18:17:09 -0400." References: From: Axel Belinfante X-Organisation: University of Twente, Department of Computer Science, Formal Methods and Tools Group, PO Box 217, NL-7500 AE Enschede, The Netherlands X-Phone: +31 53 4893774 X-Telefax: +31 53 4893247 X-Face: 3YGZY^_!}k]>-k'9$LK?8GXbi?vs=2v*ut,/8z,z!(QNBk_>~:~"MJ_%i`sLLqGN,DGbkT@ N\jhX/jNLTz2hO_R"*RF(%bRvk+M,iU7SvVJtC*\B6Ud<7~`MGMp7rCI6LVp=%k=HE?-UCV?[p\$R? mI\n2/!#3/wZZsa[m7d;PKWiuH6'~ List-Archive: Date: Mon, 03 Jun 2002 12:06:35 +0200 > > I can bypass the kernel easily enough: > > man 9pcon cpu% aux/9pcon /srv/dns read9pmsg from server: inappropriate use of fd cpu% What does that error message mean? Did I invoke 9pcon in the wrong way? Axel. --upas-hfmsokzytqegxzxyielufbviac-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: smiley@zenzebra.mv.com To: 9fans@9fans.net Date: Tue, 26 Apr 2011 18:08:05 +0000 Message-ID: <86ipu0evi2.fsf@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [9fans] spaces in filenames Topicbox-Message-UUID: d5ee4f58-ead6-11e9-9d60-3106f5b1d025 Hi, >>From time to time, the issue of having spaces in file names seems to come up on this list, mostly in the context of discussions on find, du, Acme, and trfs(4). All the discussions I've found suggest that file names with whitespace in them are *legal* on fossil. I'm running a 9atom 9pcf kernel copied verbatim from the 9atom .iso, on an otherwise stock Plan 9 4e fossil+venti install. However, I can't seem to create files with with spaces in their names. The resulting error string reports invalid characters in the file name. Why doesn't this work? Has the ability to have spaces in file names been removed from fossil? If so, then how is it possible that there are files such as '/n/sources/contrib/steve/file with spaces' hanging around? While I'm perfectly happy using underscores in lieu of spaces in *my* file names, there are a number of APE packages (i.e., fgb/lcms) containing files with spaces in their names. Since those are the names used in replica(1), I'm unable to contrib/install(1) any of these packages. Are there any known fixes or workarounds for this problem? (I doubt trfs(4) would help, because the ape would still be naming the file with spaces, unless specifically modified to match the trfs(4) translation.) What's the theory behind excluding whitespace from filenames? Was it causing too much discussion on the list? ;) Since Plan 9 was a total re-think of Unix, I have to wonder why this problem wasn't fixed. If Plan 9 used 0x00 (NUL) as the record separator (instead of newline), many of these types of problems could be averted. Why don't we? Also, if anyone knows where I can find 9fans archives prior to March 2008, please let me know. The archives I was able to find only go back that far. Also, quanstro, would you whitelist me? I can't seem to get mail to you off-list. Thanks! -- +---------------------------------------------------------------+ |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+ From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <86ipu0evi2.fsf@cmarib.ramside> References: <86ipu0evi2.fsf@cmarib.ramside> From: Rob Pike Date: Tue, 26 Apr 2011 11:42:49 -0700 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] spaces in filenames Topicbox-Message-UUID: d5f4f182-ead6-11e9-9d60-3106f5b1d025 Sometime around, maybe, 2000, I flipped the bit in the frogs table so spaces were legal in file names, for two reasons: we were seeing spaces in file names from remote systems and seemed simpler to accept them than to remap them, and I wanted to know how it would affect things. Not all software has caught up, I suspect. It's only been a decade. -rob From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 26 Apr 2011 14:43:00 -0400 To: 9fans@9fans.net Message-ID: <95260b7e190c22af011c28169a4b2c38@brasstown.quanstro.net> In-Reply-To: <86ipu0evi2.fsf@cmarib.ramside> References: <86ipu0evi2.fsf@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] spaces in filenames Topicbox-Message-UUID: d60c9990-ead6-11e9-9d60-3106f5b1d025 > From time to time, the issue of having spaces in file names seems to > come up on this list, mostly in the context of discussions on find, > du, Acme, and trfs(4). All the discussions I've found suggest that > file names with whitespace in them are *legal* on fossil. I'm running > a 9atom 9pcf kernel copied verbatim from the 9atom .iso, on an > otherwise stock Plan 9 4e fossil+venti install. However, I can't seem > to create files with with spaces in their names. The resulting error > string reports invalid characters in the file name. Why doesn't this > work? Has the ability to have spaces in file names been removed from > fossil? If so, then how is it possible that there are files such as > '/n/sources/contrib/steve/file with spaces' hanging around? this is all my fault. ken fs doesn't allow spaces in file names, and neither does kfs. since many scripts tend to do the wrong thing with such file names, i thought it would be a lot easier to just disallow them, and deal with any problems that come up at file creation time, instead of when you're running a script that's mysteriously failing. the sources version of fossil does allow spaces in filenames. > While I'm perfectly happy using underscores in lieu of spaces in *my* > file names, there are a number of APE packages (i.e., fgb/lcms) > containing files with spaces in their names. Since those are the > names used in replica(1), I'm unable to contrib/install(1) any of > these packages. Are there any known fixes or workarounds for this > problem? (I doubt trfs(4) would help, because the ape would still be > naming the file with spaces, unless specifically modified to match the > trfs(4) translation.) i have never run into this. my preferred solution would be to fix the contrib packages, but that's not my call. sorry for the inconvienece. > Also, if anyone knows where I can find 9fans archives prior to March > 2008, please let me know. The archives I was able to find only go > back that far. http://9fans.net/archive > Also, quanstro, would you whitelist me? I can't seem to get mail to > you off-list. Thanks! done. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 26 Apr 2011 14:44:05 -0400 To: 9fans@9fans.net Message-ID: <7f1a4725c490e4083afaa3534390121d@brasstown.quanstro.net> In-Reply-To: References: <86ipu0evi2.fsf@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] spaces in filenames Topicbox-Message-UUID: d5fbad9c-ead6-11e9-9d60-3106f5b1d025 > > Not all software has caught up, I suspect. It's only been a decade. > my software hasn't. i'm just a philistine. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 From: dexen deVries To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Date: Tue, 26 Apr 2011 20:52:36 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.39-rc4-l33+; KDE/4.5.5; x86_64; ; ) References: <86ipu0evi2.fsf@cmarib.ramside> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104262052.36817.dexen.devries@gmail.com> Subject: Re: [9fans] spaces in filenames Topicbox-Message-UUID: d61689e6-ead6-11e9-9d60-3106f5b1d025 On Tuesday 26 of April 2011 20:42:49 Rob Pike wrote: > Sometime around, maybe, 2000, I flipped the bit in the frogs table so > spaces were legal in file names, for two reasons: we were seeing > spaces in file names from remote systems and seemed simpler to accept > them than to remap them, and I wanted to know how it would affect > things. > > Not all software has caught up, I suspect. It's only been a decade. on the topic, is acme still your favorite editor, Rob? asking, cause it is mine, and about the only thing i miss in it is sensible support for whitespace in pathnames. i'm using the p9p version, btw. -- dexen deVries ``One can't proceed from the informal to the formal by formal means.'' From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <201104262052.36817.dexen.devries@gmail.com> References: <86ipu0evi2.fsf@cmarib.ramside> <201104262052.36817.dexen.devries@gmail.com> From: Rob Pike Date: Tue, 26 Apr 2011 12:31:17 -0700 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] spaces in filenames Topicbox-Message-UUID: d61f400e-ead6-11e9-9d60-3106f5b1d025 I still use acme. My solution for spaces in file names is to avoid them. That might not work for everyone. -rob From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <86ipu0evi2.fsf@cmarib.ramside> <201104262052.36817.dexen.devries@gmail.com> Date: Tue, 26 Apr 2011 12:35:14 -0700 Message-ID: From: Paul Lalonde To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=90e6ba613b7057852004a1d76c16 Subject: Re: [9fans] spaces in filenames Topicbox-Message-UUID: d624f940-ead6-11e9-9d60-3106f5b1d025 --90e6ba613b7057852004a1d76c16 Content-Type: text/plain; charset=ISO-8859-1 I mostly run acme from inferno (acme-SAC), and live with trfs to take care of my windows and mac paths. My linux paths are much better behaved, and so I run from p9p there. Paul On Tue, Apr 26, 2011 at 12:31 PM, Rob Pike wrote: > I still use acme. My solution for spaces in file names is to avoid > them. That might not work for everyone. > > -rob > > -- I'm migrating my email. plalonde@telus.net will soon be disconnected. Please use paul.a.lalonde@gmail.com from now on. --90e6ba613b7057852004a1d76c16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I mostly run acme from inferno (acme-SAC), and live with trfs to take care = of my windows and mac paths. =A0My linux paths are much better behaved, and= so I run from p9p there.

Paul

On Tue, Apr 26, 2011 at 12:31 PM, Rob Pike <robpike@gmail.com> wrote:
I still use acme. =A0My solution for spaces in file names is to avoid
them. =A0That might not work for everyone.

-rob




--
I'm mig= rating my email. =A0plalonde@telus.net will soon be disconnected. =A0Please use paul.a.lalonde@gmail.co= m from now on.


--90e6ba613b7057852004a1d76c16-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: smiley@zenzebra.mv.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <86ipu0evi2.fsf@cmarib.ramside> <95260b7e190c22af011c28169a4b2c38@brasstown.quanstro.net> Date: Wed, 27 Apr 2011 02:30:54 +0000 In-Reply-To: <95260b7e190c22af011c28169a4b2c38@brasstown.quanstro.net> (erik quanstrom's message of "Tue, 26 Apr 2011 14:43:00 -0400") Message-ID: <86oc3sv31d.fsf@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [9fans] spaces in filenames Topicbox-Message-UUID: d62b27ca-ead6-11e9-9d60-3106f5b1d025 erik quanstrom writes: > the sources version of fossil does allow spaces in filenames. I'm hypothesizing that my version of fossil isn't allowing spaces in file names because the version compiled into the '#//boot/boot/fossil' in the 9atom 9pcf kernel from the 9atom .iso doesn't allow spaces. Would that hypothesis be correct? (Which would bring me to my next question: how to recompile the 9atom kernel, with _tracein and _traceout undefined in the final link and all, but that's a topic for a different thread.) > i have never run into this. my preferred solution would be to fix > the contrib packages, but that's not my call. :( It's not mine, either. > http://9fans.net/archive Yes, I found that. However, if there's an API for downloading them, it's not obvious. Short of spidering 9fans.net, is there a place to get them? -- +---------------------------------------------------------------+ |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+ From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 26 Apr 2011 22:39:12 -0400 To: 9fans@9fans.net Message-ID: <1fda448af4d14fd45e11fc96eb572eef@ladd.quanstro.net> In-Reply-To: <86oc3sv31d.fsf@cmarib.ramside> References: <86ipu0evi2.fsf@cmarib.ramside> <95260b7e190c22af011c28169a4b2c38@brasstown.quanstro.net> <86oc3sv31d.fsf@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] spaces in filenames Topicbox-Message-UUID: d6332ca4-ead6-11e9-9d60-3106f5b1d025 On Tue Apr 26 22:34:26 EDT 2011, smiley@zenzebra.mv.com wrote: > erik quanstrom writes: > > > the sources version of fossil does allow spaces in filenames. > > I'm hypothesizing that my version of fossil isn't allowing spaces in > file names because the version compiled into the '#//boot/boot/fossil' > in the 9atom 9pcf kernel from the 9atom .iso doesn't allow spaces. > Would that hypothesis be correct? (Which would bring me to my next > question: how to recompile the 9atom kernel, with _tracein and _traceout > undefined in the final link and all, but that's a topic for a different > thread.) i hope to clean all this junk up in my infinite spare time. sorry. rebuild libc after adding this, or remove the flags section from your /sys/src/9/pc/9pcf*. ; cat /sys/src/libc//386/trace.s TEXT _tracein(SB), 1, $0 CMPL traceactive(SB), $0 JEQ inotready MOVL 16(SP),AX PUSHL AX MOVL 16(SP),AX PUSHL AX MOVL 16(SP),AX PUSHL AX MOVL 16(SP),AX PUSHL AX MOVL 16(SP),AX PUSHL AX CALL tracein(SB) POPL AX POPL AX POPL AX POPL AX POPL AX inotready: RET TEXT _traceout(SB), 1, $0 CMPL traceactive(SB), $0 JEQ notready PUSHL AX MOVL 4(SP),AX PUSHL AX CALL traceout(SB) POPL AX POPL AX notready: RET - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 27 Apr 2011 14:10:41 +0100 From: Digby Tarvin To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20110427131041.GA21774@skaro.cthulhu.dircon.co.uk> References: <86ipu0evi2.fsf@cmarib.ramside> <201104262052.36817.dexen.devries@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: [9fans] spaces in filenames Topicbox-Message-UUID: d63d28da-ead6-11e9-9d60-3106f5b1d025 I was always happy with the traditional Unix approach - Kernel allows anything unless there is a good reason not to (ie no NULL or '/'). Anything else is an application problem that usually required some ingenuity if you really wanted to break convention. But then, I have never been a big fan of spaces in filenames so varying levels of support in userland was not a big concern. I can remember amusing myself once as an undergraduate, deleting and creating files till I got the right inode numbers to allow a judicious choice of binary file names to result in a directory that was a valid executable a.out image. DigbyT -- Digby R. S. Tarvin digbyt(at)digbyt.com http://www.digbyt.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 27 Apr 2011 09:16:36 -0400 To: digbyt@acm.org, 9fans@9fans.net Message-ID: <80660070788d5c9db6af9f2881e5444d@ladd.quanstro.net> In-Reply-To: <20110427131041.GA21774@skaro.cthulhu.dircon.co.uk> References: <86ipu0evi2.fsf@cmarib.ramside> <201104262052.36817.dexen.devries@gmail.com> <20110427131041.GA21774@skaro.cthulhu.dircon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] spaces in filenames Topicbox-Message-UUID: d648c726-ead6-11e9-9d60-3106f5b1d025 On Wed Apr 27 09:12:15 EDT 2011, digbyt@acm.org wrote: > I was always happy with the traditional Unix approach - Kernel allows > anything unless there is a good reason not to (ie no NULL or '/'). > Anything else is an application problem that usually required > some ingenuity if you really wanted to break convention. port/chan.c:/^char isfrog - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <0bc37e9990e3c3ebde8276275a170a88@quintile.net> From: "Steve Simon" Date: Wed, 27 Apr 2011 14:21:04 +0100 To: digbyt@acm.org, 9fans@9fans.net In-Reply-To: <20110427131041.GA21774@skaro.cthulhu.dircon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] spaces in filenames Topicbox-Message-UUID: d64283ac-ead6-11e9-9d60-3106f5b1d025 > I can remember amusing myself once as an undergraduate, deleting and > creating files till I got the right inode numbers to allow a judicious > choice of binary file names to result in a directory that was a > valid executable a.out image. Wonderful! This made me laugh loud enough to make everyone in the office turn round. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <0bc37e9990e3c3ebde8276275a170a88@quintile.net> References: <20110427131041.GA21774@skaro.cthulhu.dircon.co.uk> <0bc37e9990e3c3ebde8276275a170a88@quintile.net> Date: Thu, 28 Apr 2011 11:58:01 +0200 Message-ID: From: "Peter A. Cejchan" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cd4889ebff66904a1f79744 Subject: Re: [9fans] spaces in filenames Topicbox-Message-UUID: d740da4c-ead6-11e9-9d60-3106f5b1d025 --000e0cd4889ebff66904a1f79744 Content-Type: text/plain; charset=UTF-8 spaces in filenames.. does not it break the rules?? Who actually needs them?? ++pac --000e0cd4889ebff66904a1f79744 Content-Type: text/html; charset=UTF-8 spaces in filenames.. does not it break the rules?? Who actually needs them??

++pac

--000e0cd4889ebff66904a1f79744--