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.