Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!decwrl!ucbvax!info-vax
From: jon@CIT-VAX.ARPA (Jonathan P. Leech)
Newsgroups: mod.computers.vax
Subject: DEC/Shell wildcard expansion
Message-ID: <8511262204.AA07892@cit-vax.ARPA>
Date: Tue, 26-Nov-85 17:04:30 EST
Article-I.D.: cit-vax.8511262204.AA07892
Posted: Tue Nov 26 17:04:30 1985
Date-Received: Wed, 27-Nov-85 22:27:35 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 35
Approved: info-vax@sri-kl.arpa


	We just got DEC/Shell V  1.0.  I  find	that  when  the  shell
expands wildcards, it includes version numbers, i.e.

	echo *.c

might generate

	all.c.3 backup.c.2 ...

if a 'tar' file is generated with something like

	tar cvf foo.tar *.c

the version numbers are included in  the  tar  file.  If  it  is  then
extracted on a Unix system, I get (unsurprisingly) files named

	all.c.3
	backup.c.2

which is  NOT  desirable.  Does  anyone  know  a  way  to  defeat  the
version-number expansion of the shell? I realize that at worst I could
write a program and do something like

	tar cvf foo.tar `fixnames *.c`

but there seems to be a (very small) limit on the  length  of  strings
generated through the backquoting mechanism. Also, I find that the 'r'
option to  tar	(used  to  update  an  archive)  frequently  generates
'directory checksum errors' which makes it difficult  to  construct  a
tar file in several passes.

	Thanks,
	Jon Leech (jon@cit-vax.arpa)
	__@/