phil@utecfa.UUCP (Philip Poulos) (04/16/84)
Now that I know we are not the only ones to have this "feature" of ex/vi
I should point out the obvious problems.
BUG: Any vi command will be executed as soon as you run ex/vi on a file
that contains a string that matches the following conditions
- the string starts with "vi:" or "ex:"
- the string ends with ":"
- the string appears in the first 5 or last 5 lines of the file
EXAMPLE: As seen in my original mail the string vi:q!: results in quitting
the editor, before you even get in.
vi:!rm *: Will remove all your files while you are waiting for the
vi prompt.
There are, of course, better examples... picture the super user
editting a source file from the net that has vi:!rm -rf /: hidden
in the file, or perhaps vi:!kill 1: The list is endless.
I found this by accident (what else is in vi?)
We have a login name in the password file
that ends with "vi", so the string "vi:encryptedstuff:" caused ex to
burp mildly. Further investigation led to the discovery of the bug.
So everybody that has this ex/vi version (4.2 bsd, maybe others) you better
fix it fast. Otherwise you leave yourself open to an attack of KILLER MAIL.
FIX:
in ex/ex_io.c 2 pieces of code should be removed.
1: remove the routine checkmodeline(), it starts at line ~850
2: In rop2() remove the call to checkmodeline()
the entire for loop should go, it looks like
for(a=first; a<=lost; a++) {
if(a == first+5 && last-first >10)
a = last - 4;
getline(*a);
checkmodeline(linebuf);
}
Phil (I'll try vi next year) Poulosmark@cbosgd.UUCP (Mark Horton) (04/17/84)
Why do you assume this is a bug? It was put in as a feature at the request of some users, so that vi "set" commands could automatically be run when certain files are entered. EMACS has a similar feature. The only problems are (1) it isn't documented (an oversight on my part), and (2) you seem to have found a security problem. It would indeed be possible to take the feature out (and since most of you didn't know it was there, you'd never notice that it was gone), but it makes more sense to set a flag while checkmodeline is in operation, and refuse to do any ! or sh commands with this flag set. The mode line feature was put into vi version 3.7, and is still in, so it's in 4.2BSD and System V.
jpl@allegra.UUCP (John P. Linderman) (04/18/84)
Things are even worse than Philip Poulos let on. Here is the routine he
suggested removing (a suggestion I am implementing as fast as `make' can run):
checkmodeline(line)
char *line;
{
char *beg, *end;
char cmdbuf[1024];
char *index(), *rindex();
beg = index(line, ':');
if (beg == NULL)
return;
if (beg[-2] != 'e' && beg[-2] != 'v') return;
if (beg[-1] != 'x' && beg[-1] != 'i') return;
strncpy(cmdbuf, beg+1, sizeof cmdbuf);
end = rindex(cmdbuf, ':');
if (end == NULL)
return;
*end = 0;
globp = cmdbuf;
commands(1, 1);
}
Because of the way it checks for "ex:" or "vi:", it will also accept
"ei:" or "vx:". Because of the way it fails to check that the ':'
is at least 2 characters into the line, it might also accept "x:",
"i:" or just ":", depending on the state of the chars in front of
the linebuf array. If you are willing to live with this "feature",
you probably won't care about accepting bogus keywords, but you can
sleep a little easier if you do something like
if ((beg == NULL) || (beg < (line + 2)))
return;
if (strncmp(beg-2, "ex", 2) && strncmp(beg-2, "vi", 2))
return;
John P. Linderman Department of Fun Software allegra!jplprabhaka@ucbvax.UUCP (Aloke Prabhakar) (04/18/84)
Sorry guys, you really cannot call that a bug. It is a documented *feature*. (really) There are people here who actually use it. If your afraid of booby-traps, there`s always cat/more. Aloke Prabhakar wouldnt-it-be-funny: ...moskvax!kremvax!mcvax!decvax!ucbvax!prabhaka USENET: ...ucbvax!prabhaka ARPANET: prabhaka%ucbarpa@Berkeley
scw@cepu.UUCP (04/18/84)
This bug doesn't seem to be in the 2.8 BSD version of ex/vi (version 2.13).
--
Stephen C. Woods (VA Wadsworth Med Ctr./UCLA Dept. of Neurology)
uucp: { {ihnp4, uiucdcs}!bradley, hao, trwrb, sdcsvax!bmcg}!cepu!scw
ARPA: cepu!scw@ucla-locus location: N 34 06'37" W 118 25'43"alan@allegra.UUCP (Alan S. Driscoll) (04/18/84)
> ... it makes more sense to set a flag while checkmodeline is in > operation, and refuse to do any ! or sh commands with this flag > set. Ah, the Berkeley mentality at work! How do you fix a misfeature? By throwing another feature on top of it, of course... -- Alan S. Driscoll AT&T Bell Laboratories
jdb@mordor.UUCP (04/18/84)
I'm not convinced that this "feature" is necessary (or even desirable).
If it is going to be implemented anyway then please make it optional.
Here's my proposal:
A "set" option ("modeline", "ml") would be used to enable processing
of the "vi:" or "ex:" information. The default would be "nomodeline".
Users who wanted this feature could put the appropriate "set" command
into their ".exrc" files (or EXINIT environment variables).
I, for one, do not want this "feature"; however, at least one local
user does. I plan to fix "vi" to work as described above.
--
John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
MILNET: jdb@mordor.ARPA [jdb@s1-c] (415) 422-0758
UUCP: ...!ucbvax!dual!mordor!jdb ...!decvax!decwrl!mordor!jdbrcd@opus.UUCP (Dick Dunn) (04/18/84)
Mark Horton, on "vi" taking commands from its input file: >Why do you assume this is a bug? It was put in as a feature at the >request of some users, so that vi "set" commands could automatically >be run when certain files are entered... I suspect that if response in unix-wizards is any indication, there are more people who think that this is bad than people who want it. The slip in not documenting it means that many users may have not had a chance to express opinions about it--until now, with many of them (myself included) becoming paranoid about using "vi". There is a fairly basic principle about text editors being ignored in this feature: A text editor is a tool for manipulating text files. The fewer assumptions the editor makes about its data, the more general its applicability. We mostly accept the idea that editors work with ASCII and are therefore somewhat ungracious in handling characters with the top bit set (but please, that's a different discussion), and we tend to expect line boundaries now and then (another different discussion), BUT most of the text we manipulate satisfies these conditions. If you put editor commands in the file to be edited, you've said that the file is, in part, not data but a command script for the editor. What other programs can process that file? They have to understand or ignore the editor commands. You've got a fundamentally different type of file if it has editor commands embedded. Moreover, consider what happens if you get a gonzo command string in a file that you were editing! Now you've got to figure out what happened and use ANOTHER EDITOR to fix the mess. If you MUST spend still more of our dwindling memory (and no, it's NOT all virtual anyway) on such a feature, isolate it somehow so that the general users of vi don't have to worry about stepping in it every time they edit a file. For example, invoke the editor with a different name (as in the e/ex dodge) or add a flag to the command line; just don't make it the default. -- ...Are you making this up as you go along? Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303) 444-5710 x3086
rjhurdal@watmath.UUCP (David Canzi) (04/18/84)
Yes, you can call it a feature if you want, since it was obviously deliberately put there. But, if the first five or the last five lines of /etc/passwd contain a userid or encrypted password ending in "vi", "ex", "vx", or "ei", then using "vipw" becomes a risky business. This feature is a trap waiting to spring on the unwary, and such features are unwelcome in any programming language, operating system, or text editor. It obviously serves a purpose, but some safer way ought to be found to accomplish this purpose.
chris@umcp-cs.UUCP (04/19/84)
It's obviously a ``feature'' (after all, how could it be an accident?).
I just think that there's got to be a better way. I kinda like Emacs's
auto-execute myself, though it would be a bit hard to define how that
should work in vi. Perhaps (in a .exrc):
autoexecute *.nr { set ignorecase nowrapscan }
autoexecute *.sh { <whatever> }
(Of course there would be a nice cryptic version: "ae *.nr {se ic nows}"!)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relaysmk@axiom.UUCP (Steven M. Kramer) (04/19/84)
I would hope that the checklinemode flag would be off by default
and only activated thru EXINIT or .exrc. It's a scary default option.
So all you 4.2 sites out there, quickly type `halt' and bring up 4.1
again. If you think I'm serious, I'm not. Rather, I'm ...
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP)
linus!axiom!smk@mitre-bedford (MIL)thomson@uthub.UUCP (Brian Thomson) (04/19/84)
Okay, it should be classified as a bad idea rather than a bug, since
it was deliberate. There appears to be another questionable feature
in vi 3.7, and I quote from /usr/src/ucb/ex/ex.news:
If there is a file .exrc in the current directory, it will be
sourced when you enter vi, after your EXINIT or ~/.exrc.
I can see users leaving .exrc files in every directory they can write,
hoping that the superuser will trip over one someday. We may can
this bad idea as well.
--
Brian Thomson, CSRG Univ. of Toronto
{linus,ihnp4,uw-beaver,floyd,utzoo}!utcsrgv!uthub!thomsonchenr@tilt.UUCP (Raymond Chen ) (04/20/84)
<wheeee.... isn't this fun>
I don't know about people out there, but on the 4.2 system I can get
to, there is file in the ex/ directory called ex.new (or ex.news) that
*does* contain a report on the "feature" as well as other changes made
in between versions 3.7 and 3.6. Of course, I don't know if that
comes with to you without source license, but I suspect that it would.
Agreed, it's not the best place to put documentation, since nobody but
us ex hackers even look in the directory, but it's there.
--
From the Random Fingers of --
Ray Chen
{allegra | ihnp4 | mhuxi}!princeton!down!tilt!chenr
"It's amazing what a thousand monkeys and a few typewriters can accomplish..."richard@sequent.UUCP (04/20/84)
Maybe it would be enlightening to hear if someone in netland has ever used this "bug"/"feature' in any sense. I admit it might come in handy, but can't imagine where... ___________________________________________________________________________ The preceding should not to be construed as the statement or opinion of the employers or associates of the author. It is solely the belief... from the confused and bleeding fingertips of ...!sequent!richard
guido@mcvax.UUCP (04/20/84)
It was very honorable of Mark Horton to admit his "guilt"; but I'm not convinced by His reply. >Why do you assume this is a bug? It was put in as a feature [...]. At most I'd call it a quick hack, especially given the bad quality of the code (pointed out by another unix-wizard) and the absence of documentation. >EMACS has a similar feature. No it hasn't. There is no way to specify IN THE FILE you are editing that certain Emacs commands must be performed. You specify this in the set-up file by binding commands to certain filenames. (At least that's the situation in Gosling's Emacs.) This way it is only you who decides what's be done (if you trust Emacs itself). >[...] you seem to have found a security problem. I can't believe you didn't think of that when you invented it. Enough flaming; the gentleman who proposed to have a flag "modeline" which turns the feature on (default off) has my warm approval. -- Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam guido @ mcvax
simpers@ucbvax.UUCP (Scott Simpers) (04/22/84)
(1) vi/ex reading commands from its source files. I reluctantly have to agree that this is a bad idea. I can see where it would be very useful, but I think the dangers outway the advantages. (2) vi/ex reading .exrc from current directory and home directory: This one IS a good idea. It can take the place of some of the things that (1) was supposed to do. Different types of files often require different configurations. For example, 'autoindent' is very useful when writing a program, but a pain in the rear when typing text. I like the idea of vi being automatically reconfigured for these different tasks. Scott ...!ucbvax!simpers
alan@allegra.UUCP (Alan S. Driscoll) (04/22/84)
> (1) vi/ex reading commands from its source files. I reluctantly have to > agree that this is a bad idea. I can see where it would be very > useful, but I think the dangers outway the advantages. > (2) vi/ex reading .exrc from current directory and home directory: > This one IS a good idea. It can take the place of some of the > things that (1) was supposed to do. Different types of files > often require different configurations. For example, > 'autoindent' is very useful when writing a program, but a pain in > the rear when typing text. I like the idea of vi being > automatically reconfigured for these different tasks. What if you have different sorts of files in the same directory? Don't you really want your editor's configuration determined by the extension of the file you're editing? That way, you get autoindent on '.c' files, etc. Gosling's Emacs has such a facility. -- Alan S. Driscoll AT&T Bell Laboratories
agb@ucbvax.UUCP (Alexander G. Burchell) (04/23/84)
The gentleman asked if anyone had ever used this feature (YES! It is a feature, by definition if for no other reason). I certainly have; I used to use it every day. Vis: ; Random lisp program ; vi: set lisp : (defun foo (bar) (baz (bletch etc))) or: .\" Random nroff file .\" vi: se noai : BTW, my EXINIT is "set ai sm sw=8 terse report=1", and I find autoindent to be not useful while writing text... I agree that there should be a "modeline" option, default unset. But there *is* a better solution, which I employ now. Use EMACS. -- Alexander Burchell [agb@ucbarpa] [ucbvax!agb]
ka@hou3c.UUCP (Kenneth Almquist) (04/23/84)
For the record, some EMACS's (including Warren Mongomery's EMACS but not Goslings EMACS) will allow you to specify a list of editing modes within a file. However, this feature only sets modes so it doesn't pose a security problem. My own belief is that setting modes from the file extension (as Gos- ling's EMACS allows you to do) is a better approach. Kenneth Almquist
ka@hou3c.UUCP (Kenneth Almquist) (04/23/84)
For the record, some EMACS's (including Warren Mongomery's EMACS but not Goslings EMACS) will allow you to specify a list of editing modes within a file. However, this feature does not allow you to execute an arbitrary command so it doesn't pose a security problem. My own belief is that setting modes from the file name extension (as Gosling's EMACS allows you to do) is a better approach. Kenneth Almquist
hans@log-hb.UUCP (Hans Albertsson) (04/26/84)
[] I really think both ways should coexist, that is, set modes according to filename patterns ( not just extensions ) or according to textual commands within the file itself. The version of EMACS that I've been involved in myself deliberately allows both, as does T20-EMACS. ...decvax!mcvax!enea!log-hb!hans Hans Albertsson.
crl@pur-phy.UUCP (Charles LaBrec) (04/26/84)
The two "features" added to vi/ex sounds like an attempt to give it a limited flavor of EMACS "modes"--something that all of us EMACS users know and love. Charles LaBrec UUCP: pur-ee!Physics:crl, purdue!Physics:crl INTERNET: crl @ pur-phy.UUCP
tim@unc.UUCP (Tim Maroney) (04/30/84)
One tolerable solution would be to have a toggle option that activates/deactivates the mode line scanning. The default should probably be "off". Another solution would be to look, not in the file itself, but in a file consisting completely of vi commands. Conceptually, there would be some function modefile such that if modefile(filename) = modfilename, modfilename is the name of a file which is read in (like a .exrc file) when the editor is called on filename. If modfilename is not found, then nothing is read, of course. One good modefile would be simply to prepend a period. -- Tim Maroney, The Censored Hacker mcnc!unc!tim (USENET), tim.unc@csnet-relay (ARPA) All opinions expressed herein are completely my own, so don't go assuming that anyone else at UNC feels the same way.
gbergman@ucbtopaz.CC.Berkeley.ARPA (05/01/84)
Subject: "MAJOR BUG" (vi modeline) -- a safe & powerful alternative
Newsgroups: net.unix-wizards,net.bugs
Convenient though it may be to have a command executed
automatically on entering a file with the editor, it is still
more useful to be able to keep command lines in the
file and execute any of them ad lib.
Given a line of the file, the way to execute it as a bottom-line
command is to yank it to a named buffer, e.g.
"ayy
and then give the bottom-line command that executes the contents of
that buffer, in this case
:@a
I have an item in my EXINIT that makes the single keystroke
control-O do this for me. I will give it twice below, once exactly
as it appears in my EXINIT, and once with the two control-characters
shown explicitly as ^+Letter, for those of you seeing this through
``more'' etc.:
map "ayy:@a
explicitly: map ^O "ayy:@a^M
In addition to allowing you to keep commands in files for repeated
use, it makes it possible to carefully edit a command before executing
it, make a modification if the first version did not do what you meant
it to, etc.. It was actually for such editing capability that I set it
up, and the practice of storing commands for reuse developed after.
The above mapped key can be preceded by a count. E.g. 3^O will
execute the next three lines as bottom-line commands.
Let me note a couple of limitations:
In a bank of commands so executed together, e.g. by 3^O, none
except the last may be a ``global'':
g/pattern/command
If a global appears in nonfinal position, all commands after it are
ignored. (This seems to be a general bug of vi; the same thing happens
if one gives on the bottom-line of vi the command
:source filename
and the file contains a global in nonfinal position. Only in ex mode
does the command :source behave properly. Modeline also seems to
be confused by global commands, by the way.) On the other
hand, I regularly execute banks of many mappings together with no
trouble, as well as things like:
10,-w !nroff|col|lpr -h
x
or
-r !date
+,$-w !mail NAME
Banks of several substitute commands sometimes give trouble; messages
like ``extra characters after substitute command''.
Also note that since we are in vi, not ex, the ex commands i, a,
and c cannot be used. (However, in place of a one can use, say
s/$/^Mline1^Mline2^Metc./
with ^M's entered as ^V-carriage-return, and similar
substitutes for the others, if the resulting command isn't too long.)
Commands executed in this way (in fact, any commands
given by mappings, @x macros, etc.) cannot execute a ``yank'' (or a
deletion to a named buffer) after any operation that changes the
file. (According to Mark Horton, there is good reason for this if the
yank is to the ``nameless'' buffer; the fact that it affects yanks to
named buffers as well is a bug.) This behavior is somewhat capricious:
I have written one command involving such a yank that works OK for no
reason I understand, and another that does something totally
unrelated to what it ought to.
Sometimes an ``undo'' following a command undoes both it and
some preceding commands!
To avoid accidentally executing a command with serious consequences
(e.g. mailing a half-written letter, which I once did) one can write in
such commands preceded by the escape character ", e.g.
"+,$-w !mail NAME
and delete the " only when ready to use.
Despite its minor drawbacks, this trick has totally transformed
the use of the editor for me! I would be very interested in other
people's reactions.
I have some similar tricks for executing file-lines in
ex mode instead of vi mode (mainly developed when I was on a PDP
and didn't have a version 3.7 editor with its @-macro facility).
I occasionally use them when I want to execute something with
successive global commands; I'll give details if anyone is interested.
They're clumsier than the technique described above; I'd be
interested if one of you could come up with a version that wasn't.
(Those of you here at Berkeley may have seen a version of this
message on msgs, with ^A in place of ^O. I switched to ^O
because of ^A's interfering with function keys on some terminals.
And those of you at UCLA may have seen a version of my Berkeley message,
edited by David Cantor, who silently replaced my ^A with \, and changed
the mapping so that it would delete the original command line, both of
which changes I disagree with, especially the latter.)
I will mention, finally, that I have a large file of editor
bugs, as well as suggestions for possible improvements in the editor,
interspersed with comments and rejoinders by Mark Horton. If
anyone would like a copy, I will send it.
George M. Bergmangbergman@ucbtopaz.UUCP (05/01/84)
Subject: "MAJOR BUG" (vi modeline) -- a safe & powerful alternative
Newsgroups: net.unix-wizards,net.bugs
Convenient though it may be to have a command executed
automatically on entering a file with the editor, it is still
more useful to be able to keep command lines in the
file and execute any of them ad lib.
Given a line of the file, the way to execute it as a bottom-line
command is to yank it to a named buffer, e.g.
"ayy
and then give the bottom-line command that executes the contents of
that buffer, in this case
:@a
I have an item in my EXINIT that makes the single keystroke
control-O do this for me. I will give it twice below, once exactly
as it appears in my EXINIT, and once with the two control-characters
shown explicitly as ^+Letter, for those of you seeing this through
``more'' etc.:
map "ayy:@a
explicitly: map ^O "ayy:@a^M
In addition to allowing you to keep commands in files for repeated
use, it makes it possible to carefully edit a command before executing
it, make a modification if the first version did not do what you meant
it to, etc.. It was actually for such editing capability that I set it
up, and the practice of storing commands for reuse developed after.
The above mapped key can be preceded by a count. E.g. 3^O will
execute the next three lines as bottom-line commands.
Let me note a couple of limitations:
In a bank of commands so executed together, e.g. by 3^O, none
except the last may be a ``global'':
g/pattern/command
If a global appears in nonfinal position, all commands after it are
ignored. (This seems to be a general bug of vi; the same thing happens
if one gives on the bottom-line of vi the command
:source filename
and the file contains a global in nonfinal position. Only in ex mode
does the command :source behave properly. Modeline also seems to
be confused by global commands, by the way.) On the other
hand, I regularly execute banks of many mappings together with no
trouble, as well as things like:
10,-w !nroff|col|lpr -h
x
or
-r !date
+,$-w !mail NAME
Banks of several substitute commands sometimes give trouble; messages
like ``extra characters after substitute command''.
Also note that since we are in vi, not ex, the ex commands i, a,
and c cannot be used. (However, in place of a one can use, say
s/$/^Mline1^Mline2^Metc./
with ^M's entered as ^V-carriage-return, and similar
substitutes for the others, if the resulting command isn't too long.)
Commands executed in this way (in fact, any commands
given by mappings, @x macros, etc.) cannot execute a ``yank'' (or a
deletion to a named buffer) after any operation that changes the
file. (According to Mark Horton, there is good reason for this if the
yank is to the ``nameless'' buffer; the fact that it affects yanks to
named buffers as well is a bug.) This behavior is somewhat capricious:
I have written one command involving such a yank that works OK for no
reason I understand, and another that does something totally
unrelated to what it ought to.
Sometimes an ``undo'' following a command undoes both it and
some preceding commands!
To avoid accidentally executing a command with serious consequences
(e.g. mailing a half-written letter, which I once did) one can write in
such commands preceded by the escape character ", e.g.
"+,$-w !mail NAME
and delete the " only when ready to use.
Despite its minor drawbacks, this trick has totally transformed
the use of the editor for me! I would be very interested in other
people's reactions.
I have some similar tricks for executing file-lines in
ex mode instead of vi mode (mainly developed when I was on a PDP
and didn't have a version 3.7 editor with its @-macro facility).
I occasionally use them when I want to execute something with
successive global commands; I'll give details if anyone is intere 0843
From: n44a!wjh12!genrad!decvax!cca!z
Newsgroups: net.bugs.4bsd
Title: Re: Bug in tset(1) - (nf)
Article-I.D.: cca.388
Posted: Tue May 1 08:59:06 1984
References: <3192@fortune.UUCP>
Yes, this is a problem. Aside from the fact that it is only logical
that a tab from the end of a line behave like every other tab (i.e,
advance no more than eight spaces), all terminals that I have seen with
hardwired tab stops do behave this way. Furthermore, even those
terminals with user settable tab stops have a tab set in the first
column and every eight columns thereafter when they are initialized.
If the tab stops set by tset are different from default tab settings and
those on terminals with hardwired tab stops, then it becomes impossible
for programs to reliably know exactly where a terminal's tab stops are.
Steve Zimmerman
decvax!cca!zchris@umcp-cs.UUCP (05/03/84)
There are a number of bugs (and potential bugs, for anyone making
changes) in ex/vi due to ``11 squishing'' (reusing buffers all over
the place). If you decide to experiment with macros, named buffers,
yanking, and undoing, test it out in a "junk file" first!
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandmark@elsie.UUCP (05/10/84)
<> Instead of hacking up vi, or creating various alias that toggle .exrc files, Why not write your own version of vi for each directory where you want to do some editing. That is, write a shell script named vi! Here's one I'm using for a paper I'm working on (^[ == CTRL V ESC; ^letter == CTRL V CTRL letter): #! /bin/sh EXINIT='set terse shell=/bin/csh sw=4 wm=4 aw |map! #1 ^V |map! ^[Ow ^[>>$a|m ap #1 :w^M:n^M|map #2 :n^M| map #3 :ta |map ^[Oq Gi/\<^[A\>^["zdd@z|map ^[Or 1G! Gvispell^M' export EXINIT exec /usr/local/vi $@ Note that the EXINIT variable needs be a single line (escaped newlines don't seem to work with sh variables; they do with csh but startup is slower). I've split the line to let it transmit here. Also this won't work if you want different options for different files in the same directory, but I find it useful. -- Mark J. Miller NIH/NCI/DCE/LEC UUCP: decvax!harpo!seismo!rlgvax!cvl!elsie!mark Phone: (301) 496-5688