In article ,
Tom Ivar Helbekkmo wrote:
Oh, come on!
First, we hear that UNIX can't hack spaces in file names. Then we're
told that UNIX can't hack USENET articles posted by people with angle
brackets in their name. Now we hear that UNIX can't hack file names
with parentheses in them.
No -- what I am saying is that these names are problems to the
*shell* -- the command-line interpreter, which makes it awkward to
*type* such filenames. (Some newer shells, such as zsh and tcsh at
least, have a shortcut to deal with that with an already-existing
filename -- a side effect of filename completion.)
1) '(' starts a subshell -- what follows it is run as a command
in a separate subshell, up to the corresponding closing ')'
2) ' ' (spaces) in filenames are a problem to the normal unix
shells because the *shell* takes spaces as delimiters between
arguments in the command line. (tabs and newlines are also
similar delimiters).
3) '' (and for that matter '' are problems because they are used for
I/O redirection. '' means "take input from the file whose
name follows". '' means "write output to the file whose name
follows. "" means append output to the tail of the existing
file whose name follow.
All can be dealt with on the command line by prepending a '\' to
each such offending character -- saying "I know that this
character is special to you, shell, but just for the moment
please treat it as a plain character." Or -- the entire line
can be enclosed in quotes - double quotes '"' or single quotes
"'" -- though the effect of these differs somewhat if (for
example) there are '$' in the line -- as this introduces a shell
variable name unless similarly escaped. This does not happen
inside single quotes, but does inside double quotes.
There are quite a few other characters which, while legal in
filenames, have special meaning to the various shells.
Sometimes, only in particular locations, other times anywhere.
Among those, aside from the ones already mentioned, are '~',
'#', '^', '&', '*' '[', ']', '{', '}', '|' and '?'. I wont'
bother to list the various things these do in the different
shells, as I am bound to miss some. :-) Also, each of the quote
marks: ( ', ", and ` ) have their own functions, and are thus
bad things to put in filenames.
Even '-' at the *beginning* of a filename can create problems,
if you don't know how to work around it. Try this following
sequence from the shell (any shell) -- *not* from a GUI, which
works around the shell special characters by not using the
shell:
cd /tmp
touch -junque
rm -junque
:-)
Yes -- I know of several ways to remove it -- but for a
first-time user, it can be a real problem. The first time I
encountered it (before some shells put in an alternative way to
deal with it) I wound up writing and compiling a tiny program to
delete a specific file name. :-)
Note that to put '\' in a filename, it, also, must be "escaped"
with a '\', so:
jim\beam
would show up as:
jimbeam
But:
jim\\beam
would create a file named:
jim\beam.
Sometimes, in shell scripts, you are subjected to more than one
pass of shell processing, so you would have to double them yet
again, using
jim\\\\beam
to create the file name from within a script which had to be
read into a shell and then executed.
All of this is completely untrue. It may be that there is some
specific software, running under some UNIX or other, that has problems
like this, but then that software is buggy, and should be fixed.
You are trying to tell me that the original Bourne shell
(/bin/sh), and all subsequent ones that I have encountered, are buggy?
The shells *are* the user interface of unix.
The
only character you can't have in a UNIX file name is the forward slash
('/'), because it's used as a directory separator.
There is one other forbidden character -- the NULL character
(ASCII code '0'). This is used to flag end-of-string in many places in
unix -- including in filenames.
And actually, there *is* one way to put '/' in a filename on
unix -- at least on Sun servers running NFS (Networked File System),
offering file systems to the Macintosh. I was a system administrator on
such a network before I retired, and the only way to deal with these
from the unix side was to edit the raw directory to change the
characters, and *then* rename or remove the file. However, NFS somehow
manages to bypass the unix filename syntax checking.
The funny name
with the graphical arrow in it was completely legal, as well, and
should pose no problem to any properly working news or email software.
Note that many unix newsreaders are descendants of rn (trn and
my current strn as prime examples). rn (and descendants) uses shell
scripts to accomplish many things -- including saving articles --
normally by appending them to a file named for the newsgroup. I make a
practice to save articles which I have read in this way.
Unfortunately, when the shell script sees characters like '(',
')', '', '', or similar (in this case in either the "From: " or
"Reply-To: " headers -- even though it is not creating a file name from
them, it *is* checking them -- it attempts to use normal shell syntax
rules on them -- and barfs. I have encountered this many times (and
mentioned it in the newsgroup when I have encountered it). As a
work-around, since I run my own news server, I go into the file in the
news spool, and edit the offending characters to avoid the problem.
Yes -- from within a compiled program (including a
fully-compiled newsreader), you can create almost any filename. But the
various shells, because of their flexibility, have special meanings
assigned to many characters.
However, if you want to be sure you use file names portable to
anything, stick to file names of maximum eight characters picked from
the letters A-Z and digits 0-9, then a single period ('.'), then a
maximum of three characters picked from the same set. These file
names will be MS-DOS compatible, and will also work on anything else
that's less than about 30 years old. :-)
30 years? Let's see -- I have still some SSB DOS-68 manuals
from about 1978 (it is not yet 2008, is it?) which are not 8.3
filenames, but rather 6.3. No, I don't expect to use these for
newsreading, or for much of anything serious, these days. I'm not
really sure whether CP/M was 8.3 or 6.3 in its filenames, as I have
never run it at home.
Enjoy,
DoN.
--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. |
http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---