Linux/Unix naming conventions...

[jc at trillian.mit.edu (John Chambers,,,781-647-1813)]

Seth Gordon <sgordon at kenan.COM> writes:

	"John Chambers wrote:

	> The only characters that have special meaning
	> to the Unix file system are slash and null.

	Not to disagree, but to supplement: some utilities assume, by default, that file
	names don't have any spaces in them.  (For example, they will interpret a group of
	words separated by spaces as a group of filenames.)  Therefore, creating files
	with embedded spaces is Generally Not Done, although it's technically possible,
	and there are ways to coerce the rest of Unix into treating them properly.

Indeed.  With the shells, of course, all it takes is a pair of quotes
to protect blanks and other significant characters. But some programs
don't have a way of quoting file names, so in general it's better  to
avoid  things like spaces, tabs, newlines, parens, and other kinds of
punctuation in file names, unless you have a good reason to use them.
This  isn't  because  Unix itself has a problem with it; it's because
programmers write programs that have  restrictions  on  what  strings
they will accept as file names.

OTOH, I worked on a project some years  back  in  which,  after  much
beating  of our heads against a wall, we learned that the reason that
our little program couldn't download files to  a  particular  machine
(which shall remain nameless to protect the guilty) was that it would
only accept files if their names started with  a  ^X  (Ctrl-X)  char.
This  struck  us  as particularly idiotic, but once we learned it, it
wasn't a real problem.  We modified the downloader to only send files
whose  names started with ^X, and to insert a ^X if there wasn't one,
for typing convenience.  The program that  created  the  downloadable
files  was  told  to insert the ^X at the start of the name, and that
was an effective type flag for files  destined  for  that  particular
machine.   We  were duly impressed by the fact that the Unix software
wasn't at all bothered by this "funny" character in file names. Since
ls  showed  the  name  with  the "^X" digraph, and the shells weren't
bothered by it, everything worked just fine.

I've recently had some dealings with remote Macintosh files.  The Mac
file  system routinely uses spaces inside file names.  Other than the
need to quote the file names in  shell  commands, this really  hasn't
caused any problems.  All the "standard" Unix commands seem to accept
such names without complaining.  Apache converts spaces to %20 in its
directory  listings,  and  does  the  reverse conversion for incoming
URLs. And so on.  A much larger problem is Apple's use of nonstandard
line  separators,  which makes the ascii-based stdio library routines
not very useful.  (This was one of the reasons that perl has a way to
specify input line separators.)

Both of these are examples of Unix being able to handle the file name
conventions  of another system.  But this is definitely a property of
"Unix" itself, i.e., the kernel and its file system.  Many Unix  apps
(including the shells) implement much stricter file-name conventions.
And there's often not a lot of consistency in how this is done.

One of the standard pranks to pull on new Unix users is to  create  a
file in their home directory whose name consists solely of a space or
tab (or hyphen or backspace or Ctrl-X), and challenge them to  delete
it.  This is a useful educational tool ...

The original question was from a newcomer to Unix, wondering how this
is  all  handled on Unix systems.  One thing that such people need to
learn is that there's a significant distinction between "Unix" (which
has  very  few rules about file names or formats) and "Unix programs"
(which can and do deal with all  sorts  of  strange  file  names  and
formats).   This is an intentional part of the Unix design, is one of
Unix's major strengths, and is  one  of  the  reasons  that  Unix  is
so widely used.  But it can lead to confusion at times.


--
Modern GUIs are very well designed, for people with three hands. The
real problem has been how slow customers have been to make necessary
hardware upgrades to meet the requirements of the software.
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).