In article ,
Tom Ivar Helbekkmo wrote:
(DoN. Nichols) writes:
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.
That an application that uses the shell has to be conscious of the
special meanings of various characters, and quote things in a safe
manner, is not a problem. Applications handle that. If they don't,
they're buggy.
It was written back when people only put *real* addresses and
*real* usernames into "From: " and "Reply-To: " headers. Things have
changed. There was no need to quote the strings then. (I'm not really
sure *why* it even scans those headers prior to saving an article, but
it does.
[shell 101 snipped]
[ ... ]
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.
Of course that's not what I'm saying. Neither /bin/sh nor the other
shells have problems with the fact that all characters except the
slash are legal. Neither do well-written applications. Applications
that have problems with this are buggy.
Note that this application was written *before* the days of munged
addresses. Note also, that the "From: " and "Reply-To: " headers often
have double quotes already around the "Real-Name" field, and that ''
and '' are *already* present in the address field, which the script is
trying to parse. At the time the program was written, there was no
reason to believe that people would start putting those characters into
the "Real-name" fields of those headers. (It is an application which I
have been running for quite a few years, and which had no problems until
the days of munged addresses -- thanks to spammers.
There is one other forbidden character -- the NULL character
Of course -- but I didn't want to start discussing inode internals... ;-)
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.
Now *there* is an example of a buggy application.
I agree absolutely -- but which is the buggy one, the Mac,
which was using a character which was perfectly reasonable in its own
filesystems, or the Sun (SunOs 4.1.3 at that time) NFS, which didn't
syntax check a file name which it was in no position to correct in any
case?. But what is the NFS to translate that character to so
it can be safely saved -- a sequence perhaps? And what sequence can
safely be assumed to *never* be used in the file names, so it can be
translated back to the '/' when the file is served to a Mac -- and
*only* to a Mac?
Note that the Mac could easily access and rename the files, and
the problems only came when scanning through the directory with shell
scripts, looking for various problems -- or when trying to clean out the
directory, because the user had left the lab, or was being moved to a
different server. (Obviously, re-newfs'ing the disk would have gotten
rid of it -- but even clri had problems left when fsck choked on the
filename in trying to clean up afer the clri.
My *own* preference would have been to deny that character to Mac
users saving on NFS-mounted drives -- but I did not have (and do not
have) the source that the servers were using. They must have been
hooking rather deeply into the kernel to do that, I think.
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.
Do you know of any news groups that have magic characters in their
names? I don't.
Nor do I. The problem is not the newsgroup names, but the
presented *user*-names -- which are under the control of the users on
many different OS's. I've just checked the shell script in question.
It is the one used to save the article in "mbox" format. It is short,
mostly comments. The arguments which it receives a
================================================== ====================
# Arguments:
# 1 Full name of article (%A)
# 2 Public news spool directory (%P)
# 3 Directory of current newsgroup (%c)
# 4 Article number (%a)
# 5 Where in article to start (%B)
# 6 Newsgroup name (%C)
# 7 Save destination (%b)
# 8 First line of message, normally From...
================================================== ====================
and after a sanity check to make sure that it running under /bin/sh, it
does this:
( echo "$8"
if test "$5" = 0 -a ! "$4" = 0 ; then
echo "Article: $4 of $6"
fi
tail +$5c $1 | sed "s/^[Ff]rom /& /"
echo ""
echo "" ) $7
to convert the syntax to that appropriate for a mbox (unix mailbox)
file. I don't think that any of the arguments are the problem -- it is
the file itself (the standard unix news spool format) which is the
problem -- and it is no longer standards compliant if it has '' ( or
'(' ) in the real-name field.
I guess that I could re-write it in C and do my own sanity
checking, but it seems a shame to replace such a tiny shell script with
something much larger.
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.
If rn actually shoves this stuff to the shell without proper quoting,
then rn is buggy. I'm almost tempted to put a ";halt" into my "From:"
field just for kicks... ;-)
How many systems will you break with that?
...which reminds me of a funny one-line .signature I saw once:
SCRIPT Language="Javascript"window.close()/SCRIPT
A nice way to make sure that the article is only read by those
with text-only newsreaders -- or at least those others which have had
javascript turned off. :-)
Note that rn was originally written (IIRC) by Larry Wall -- the
author/originator of perl, among other useful things.
Enjoy,
DoN.
P.S. I suspect that everybody else is bored to death with this, so
perhaps we should drop it.
--
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 ---