A new low in cheap tools?

Spearfox,

*Please* change your "realname" portion of your "From: " and "Reply-To: " headers. The presence of the '

Definitely no parenthesis. I did a project a few years back - an automated daily running process, the final part of which involved shipping a few thousand files from an NT box over to a unix box after local processing. Someone had decided that the naming convention made sense if it involved parenthesis. Until it was discovered that unix interpreted the file name as some kind of a function call...

Mickey

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.

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. The only character you can't have in a UNIX file name is the forward slash ('/'), because it's used as a directory separator. 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.

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. :-)

-tih

There are a lot of temptations in the HF catalog. Of course, the particular item may be a bargain in that it's poor quality, but is still inexpensive for what it is. Best example: the famous 4 1/2" grinder. Or the item may be just be a POS that's overpriced at any price. Or anywhere in between.

I've taken the chance and gotten stuff that's all over this "dimension". Sometimes I knew from what I'd heard here. Most of the time I wish that I'd heard about it here. So here is what I have to say about some of the things that I've gotten at HF.

The Bargains (well worth the money):

- the 4 1/2" angle grinder ($12)

- the compact bench bender ($50)

- 6" digital calipers ($20)

- 440/880# electric hoist ($75)

- 1/2" air impact wrench ($20)

- air sheet metal shears ($40)

- 10" carbide circular saw blade ($15)

- nitrile gloves ($7)

- air impact hammer set ($10)

- 40 pc socket set ($2!! - I know, this should be in the POS category, but it hangs out in the car for when I need to take something apart at the dump and then it's worth it)

- free shipping ($30, $40, or $50 order, depending on current promotion)

Satisfied, but nothing to gloat about:

- a couple of Pittsburgh socket sets

- 6 & 11" swivel pad vise-grip knockoff's (11" is really useful)

- 15' ratchet tie-down

The POS's:

- air sheet metal nibbler (the "tooth" broke 1st time I used it)

- laser level (divergent beam)

- air line couplers (leak)

- acid brushes (skimpy on bristles)

- membership in the Inside Track Club (I saved enough on the hoist to pay for this, otherwise it's not worth it)

Well, now that I'm itemized my HF buys, I guess that I've been more satisfied that I thought I was. Where's that latest catalog?

Hope this helps, Bob

I forgot the main qualification to my ratings. It's the standard "I use this stuff only in a hobby context. It's value in professional/commercial setting may be entirely different."

Bob

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) '' are problems because they are used for I/O redirection. '' 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.

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.

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.

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.

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.

Yup. I remember not all that long ago in the bad old days of DOS that the GIS company I was working for received a floppy with some client data on it. It was for a *COMmunity* project, so they had named it "COM1", which DOS cheerfully allowed them to do. Of course, allowing them to delete or rename COM1 was another matter. Had to go in with a hex disk editor and change it to another name.

8.3. My system had 8" drives and I punched extra holes in the envelopes of the single sided disks to be able to use them as double sided - 'flippy' disks - common practice among the budget minded hobbiests in those days. (A mere ~20 years ago)

Mickey

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.

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.

Of course -- but I didn't want to start discussing inode internals... ;-)

Now *there* is an example of a buggy application.

Do you know of any news groups that have magic characters in their names? I don't.

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... ;-)

...which reminds me of a funny one-line .signature I saw once:

window.close()

-tih

The easy answer...get Windows :^)

Tim

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. [ ... ]

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 '' 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.

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.

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 are:

====================================================================== # 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 'field just for kicks... ;-)

How many systems will you break with that?

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.

No thank you. I know how to make unix do what I want -- and it doesn't keep changing under me every couple of years. Windows, I do not trust with *anything* which comes from the outside, like e-mail, or web pages.

The latest CERT (Computer Emergency Response Team) advisory (about two or three days ago) about Windows was for a hole in the very software library which checks for security authentication. *Not* a good recommendation. :-)

DoN.

Rather, there was less focus on such things: the Internet was about cooperation and common good, and nobody did anything wrong on purpose.

Hardly any. Yours, if you run rn with privileges, and attempt to save an article of mine. Maybe ";rm -rf ~;" would be a better string? ;-)

It ensures the article won't be read with broken readers. This trick depends on the reading program interpreting HTML in a body of text that isn't specified to be an HTML document. Thus, it won't do anything at all to software that works properly.

Agreed.

-tih

I've been using Win98SE for the last bunch of years with zero (0) troubles. Nothing has "changed under me".

I've heard of some pretty common holes in Linux too, the only difference here is that 1. it's nowhere near as popular, and 2. there are many versions of *nix. So there's just no point it targetting it!

Tim

-- "I have misplaced my pants." - Homer Simpson | Electronics, - - - - - - - - - - - - - - - - - - - - - - -+ Metalcasting and Games: