dougm@pnet51.orb.mn.org (Doug Mcintyre) (09/08/89)
stowekeller@pro-carolina.cts.com (Stowe Keller) writes: >re: allowing lowercase-period = space chr in ProDOS filenames > > I can think of a good reason not to allow spaces in ProDOS filenames: >it would screw up all the existing command line shells for ProDOS which use >the space chr as a delimiter between multiple filenames, option switches, etc. > > Stowe > >------------------------------------------------------------------------ >Stowe Keller Author of ProDOS8 LIST utility >CompuServe: 71540,725 GEnie: SKELLER BIX: stowekeller >UUCP: [ sdcsvax nosc ] !crash!pro-carolina!stowekeller >ARPA: crash!pro-carolina!stowekeller@nosc.mil >INET: stowekeller@pro-carolina.cts.com I wrote a reply to the originaly poster with something like that.. You can do it, but people would be confused with it.. Suppose you have three files with the names.. one two one two And then you type 'compress one two'. This will compress files one and two, to compress file one two, you'd have to type 'compress "one two"', and that would probably confuse many a people. Especially since no other OS that works with a command shell has spaces in files names (ie. messy-dos & Unix.. ) I could be wrong about messy-dos, since I've never used it.. UUCP: {rosevax, crash}!orbit!pnet51!dougm Compuserve: 70611,2215 ARPA: crash!orbit!pnet51!dougm@nosc.mil ALPE: DougMac INET: dougm@pnet51.cts.com GENIE: D.MCINTYRE1
fadden@cory.Berkeley.EDU (Andy McFadden) (09/09/89)
In article <991@orbit.UUCP> dougm@pnet51.orb.mn.org (Doug Mcintyre) writes: [snip] > Especially since no other OS that works with a >command shell has spaces in files names (ie. messy-dos & Unix.. ) I could be >wrong about messy-dos, since I've never used it.. You are right about MS-DOS, but wrong about UNIX. Try the line % touch "foo bar" under BSD... >UUCP: {rosevax, crash}!orbit!pnet51!dougm Compuserve: 70611,2215 -- fadden@cory.berkeley.edu (Andy McFadden) ...!ucbvax!cory!fadden
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/09/89)
In article <991@orbit.UUCP> dougm@pnet51.orb.mn.org (Doug Mcintyre) writes: >probably confuse many a people. Especially since no other OS that works with a >command shell has spaces in files names (ie. messy-dos & Unix.. ) I could be >wrong about messy-dos, since I've never used it.. You're definitely wrong about UNIX. It allows spaces in file names. And you're right about it confusing many people..
dlyons@Apple.COM (David Lyons) (09/09/89)
In article <991@orbit.UUCP> dougm@pnet51.orb.mn.org (Doug Mcintyre) writes: >[...] Especially since no other OS that works with a >command shell has spaces in files names (ie. messy-dos & Unix.. ) [...] Gee...what about HFS and AppleShare? (Have you ever used MPW?) For that matter, what about Apple II DOS 3.3? No problem there--it simply uses commas (rather than blanks) as separators. Actually, I'm on a Unix machine right now. I never tried putting a blank in a filename before, but I just did: works great! (mkdir 'x y', for example.) >UUCP: {rosevax, crash}!orbit!pnet51!dougm Compuserve: 70611,2215 >ARPA: crash!orbit!pnet51!dougm@nosc.mil ALPE: DougMac >INET: dougm@pnet51.cts.com GENIE: D.MCINTYRE1 -- --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
lmb7421@ultb.UUCP (L.M. Barstow) (09/12/89)
In article <991@orbit.UUCP> dougm@pnet51.orb.mn.org (Doug Mcintyre) writes: >stowekeller@pro-carolina.cts.com (Stowe Keller) writes: >>re: allowing lowercase-period = space chr in ProDOS filenames >Especially since no other OS that works with a >command shell has spaces in files names (ie. messy-dos & Unix.. ) I could be >wrong about messy-dos, since I've never used it.. Wrong...Unix *does* allow the use of a space character (and *any* other character as well...the literal, '\', can precede any character which the command shell might mistake for another purpose...therefore, '\ ' can specify a space (and '\\' a backslash, and '\0' a NULl character) Command shells could be fixed slightly to comply with this standard... (they have to be changed anyway to accomodate lower-case...) Les Barstow (back at school) -- Les Barstow |Bitnet: LMB7421@RITVAX "What about the R.O.U.S's?" |UUCP: ...rutgers!rochester!ritcv!ultb!lmb7421 "The Rodents Of Unusual Size? |ARPA: lmb7421@ultb.isc.rit.edu I don't believe they exist!" - Buttercup and Wesley, _The Princess Bride_
fadden@cory.Berkeley.EDU (Andy McFadden) (09/13/89)
In article <1227@ultb.UUCP> lmb7421@ultb.UUCP (L.M. Barstow) writes: >In article <991@orbit.UUCP> dougm@pnet51.orb.mn.org (Doug Mcintyre) writes: > >Wrong...Unix *does* allow the use of a space character (and *any* other >character as well...the literal, '\', can precede any character which Try that with a '/'... the local Apollo cluster uses (I think) a double slash to indicate a specific machine; that has the nasty affect of breaking some programs... I didn't really appreciate APW until I used MS-DOS command.com for a while. Ack. I think that the added complexity of some shell meta-characters would do APW some good, though. >Les Barstow (back at school) -- fadden@cory.berkeley.edu (Andy McFadden) ...!ucbvax!cory!fadden
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/13/89)
In article <1227@ultb.UUCP> lmb7421@ultb.UUCP (L.M. Barstow) writes: >Wrong...Unix *does* allow the use of a space character (and *any* other >character as well...the literal, '\', can precede any character which >the command shell might mistake for another purpose... We're not talking about how to type things at a shell, but about what filenames are permitted in the file system itself. On UNIX, any characters not including "/" and the null byte are allowed in directory entries, up to the maximum supported length (14 on older systems). UNIX files themselves need not have directory entries (i.e. names), although they most often do. The reason "/" is excluded is that the file system code interprets it as a path segment delimiter. The null byte is excluded because of the general UNIX/C convention for representing character strings.