🚀 go-pugleaf

haiying@cs.mcgill.ca (Haiying ZHANG) writes:


>   I came across this bug a while ago. This has to do with using wild
>card in file names with unix2dos/dos2unix.

>   If you use a wild card in the file name, be it a single * or a ?
>embedded in a pattern, these two handy utilities will wipe out your
>entire current directory with the exception of the first file. It will
>set all the rest of the file to size 0. 

>   Although the man page does mention anything about wild card in
>filename making one believe that it is not supported, it should not in
>any case cause serious damaging to your files. While I am at it, these
>two programs look like a recompile of its DOS version. It should have
>provided more - options such as -Rfp etc. as in cp. 


First, what system are you running on?  Second, what are you trying to do?
On a Sun system the dos2unix command is designed to operate on ONE file only,
sending the output to the second file specification.  The wild cards are
expanded by the shell, and all the program sees is a long list of filenames.

It appears that you may be using it improperly.


JB
-- 
Jonathan Bayer		Intelligent Software Products, Inc.
(908) 248-1853		37 Winthrop Rd. 
jbayer@ispi.COM		Edison, NJ   08817

In article <1992Dec12.224109.15621@cs.mcgill.ca> haiying@cs.mcgill.ca (Haiying ZHANG) writes:
=
=   I came across this bug a while ago. This has to do with using wild
=card in file names with unix2dos/dos2unix.

Where did you find these utilities?

jbayer@ispi.COM (Jonathan Bayer) writes:

> haiying@cs.mcgill.ca (Haiying ZHANG) writes:
> 
> >   I came across this bug a while ago. This has to do with using wild
> >card in file names with unix2dos/dos2unix.
> 
> >   If you use a wild card in the file name, be it a single * or a ?
> >embedded in a pattern, these two handy utilities will wipe out your
> >entire current directory with the exception of the first file. It will
> >set all the rest of the file to size 0. 
> 
> >   Although the man page does mention anything about wild card in
> >filename making one believe that it is not supported, it should not in
> >any case cause serious damaging to your files. While I am at it, these
> >two programs look like a recompile of its DOS version. It should have
> >provided more - options such as -Rfp etc. as in cp. 
> 
> First, what system are you running on?

A student of mine had the same problems on a SPARCstation with SunOS 4.1.2

>                                         second, what are you trying to do?
> On a Sun system the dos2unix command is designed to operate on ONE file only,
> sending the output to the second file specification.  The wild cards are
> expanded by the shell, and all the program sees is a long list of filenames.
> 
> It appears that you may be using it improperly.

This explains what dos2unix does, but not WHY it has such strange behaviour.
Using software improperly MUST NOT lead to such damaging results. Beware
of such bad software engineering!

At least unix2dos/dos2unix has to check that it is invoked with exactly two
arguments, first of which is the input filename and the second one the output
filename, not a directory name.  Better still, unix2dos/dos2unix should behave
similar to mv/cp and allow an arbitrary number of files when the last argument
is a directory name.

Reinhard

-- 
Reinhard Zierke                   Universitaet Hamburg, FB Informatik
zierke@informatik.uni-hamburg.de  Vogt-Koelln-Strasse 30, D-2000 Hamburg 54
                                  Tel.: (040) 54715-295   Fax: -206

jbayer@ispi.COM (Jonathan Bayer) writes:

>haiying@cs.mcgill.ca (Haiying ZHANG) writes:


>>   I came across this bug a while ago. This has to do with using wild
>>card in file names with unix2dos/dos2unix.

>>   If you use a wild card in the file name, be it a single * or a ?
>>embedded in a pattern, these two handy utilities will wipe out your
>>entire current directory with the exception of the first file. It will
>>set all the rest of the file to size 0. 

>>   Although the man page does mention anything about wild card in
>>filename making one believe that it is not supported, it should not in
>>any case cause serious damaging to your files. While I am at it, these
>>two programs look like a recompile of its DOS version. It should have
>>provided more - options such as -Rfp etc. as in cp. 


>First, what system are you running on?  Second, what are you trying to do?
>On a Sun system the dos2unix command is designed to operate on ONE file only,
>sending the output to the second file specification.  The wild cards are
>expanded by the shell, and all the program sees is a long list of filenames.


Running dos2unix with wildcards is incorrect, but it still shouldn't
destroy all of the other files.  Having seen the source for dos2unix,
what it does (at least on the Sun version) is

    for each argument
      if it's an option
	process it
      else
	if it's the first time we've seen a filename
	  open it for reading
	else
	  open it for writing


This is definitely a bug - it will process the first file on the
command line, with output going into the last file, and truncate the
others to zero length.  I ended up writing a script to process
multiple files, which is appended below in a shar archive with a
manual page.  The script should be installed as dos2unixdir, with
a link to it called unix2dosdir.


--------------------------------------------------------------------------------
#	This is a shell archive.
#	Remove everything above and including the cut line.
#	Then run the rest of the file through sh.
#----cut here-----cut here-----cut here-----cut here-----
#!/bin/sh
# shar:	Shell Archiver
#	Run the following text with /bin/sh to create:
#	dos2unixdir.1
#	dos2unixdir
# This archive created: Wed Dec 16 09:20:28 1992
cat << \SHAR_EOF > dos2unixdir.1
.TH  "DOS2UNIXDIR" "1L" "14th November 1991" "uk.ac.ed.ee"  "LOCAL commands"
.SH NAME
dos2unixdir
.sp 1
unix2dosdir \- run conversion programs on directory trees.
.SH SYNOPSIS
\fBdos2unixdir\fP \fI[-v] input-dir [output-dir]\fP
.br
\fBunix2dosdir\fP \fI[-v] input-dir [output-dir]\fP
.SH DESCRIPTION
\fBDos2unixdir\fP copies the directory tree rooted at \fIinput-dir\fP
to \fIoutput-dir\fP,
running the command \fIdos2unix -ascii -7\fP on each one.
If \fIoutput-dir\fP is not given the files will be converted in place.
The \fI-v\fP option makes \fBdos2unixdir\fP print the name of each file
as it converts it.
.PP
\fBUnix2dosdir\fP is identical to \fBdos2unixdir\fP,
except that it runs \fIunix2dos -ascii -7\fP on the files.
.SH NOTES
If \fIoutput-dir\fP is not empty the converter will only be run on files 
that have been copied from \fIinput-dir\fP.
To convert all of the files in a directory run \fBdos2unixdir\fP with one
directory argument.
.SH AUTHOR
support@uk.ac.ed.ee : MFG
SHAR_EOF
cat << \SHAR_EOF > dos2unixdir
#!/bin/sh

# A function to make a directory hierarchy - mostly taken from X11 mkdirhier
mkdirhier ()
{
	parts=`echo $1 | sed 's/\(.\)\/\(.\)/\1 \2/g`

	path=""
	for d in $parts
	do
		if [ "$path" = "" ]
		then
			dir=$d
		else
			dir=$path/$d
		fi

		if [ ! -d $dir ]
		then
			[ "$verbose" = "yes" ] && echo "Making $dir" 
			mkdir $dir
		fi

		path=$dir
	done
}


verbose=no
progname=`expr $0 : '.*/\(.*\)'`
conv_options="-ascii -7"
if [ "$progname" = "dos2unixdir" ]
then
	conv=dos2unix
elif [ "$progname" = "unix2dosdir" ]
then
	conv=unix2dos
else
	echo "Conversion program started with name $progname"
	echo "I only understand being started as dos2unixdir or unix2dosdir"
	exit 1
fi

if [ "$1" = "-v" ]
then
	verbose=yes
	shift
fi
topindir=$1
topoutdir=$2

if [ ! -d $topindir ]
then
	echo "$0: $topindir - not a directory or doesn't exist"
	exit 1
fi

# If the input directory is a symbolic link (e.g. ~/floppy) find won't
# follow it. Find doesn't have an option to make it follow symbolic
# links so the following hack is necessary.
[ -h $topindir ] && topindir="$topindir/."

if [ $# -eq 1 ]
then
	for infile in `find $topindir -type f -print`
	do
		[ "$verbose" = "yes" ] && echo $infile
		$conv $conv_options $infile $infile
	done
elif [ $# -eq 2 ]
then
	if [ ! -d $topoutdir ]
	then
		echo "$0: $topoutdir - not a directory or doesn't exist"
		exit 1
	fi

	for infile in `find $topindir -type f -print`
	do
		reloutfile=`expr $infile : "$topindir/\(.*\)"`
		reloutdir=`dirname $reloutfile`
		outdir=$topoutdir/$reloutdir
		baseoutfile=`basename $infile`
		outfile=$outdir/$baseoutfile
		[ ! -d $outdir ] && mkdirhier $outdir
		[ "$verbose" = "yes" ] && echo $outfile
		$conv $conv_options $infile $outfile
	done
else
	echo "usage: $0 [-v] input-directory [output-directory]"
	exit 1
fi
SHAR_EOF
#	End of shell archive
exit 0

--------------------------------------------------------------------------------
-- 
Michael Gordon - mfg@castle.ed.ac.uk OR ee.ed.ac.uk
Computing Officer, EE Dept, Edinburgh University
It's not an optical illusion, it just looks like one

In article <zierke.724493009@rzdspc24> zierke@rzdspc24.informatik.uni-hamburg.de (Reinhard Zierke) writes:
> This explains what dos2unix does, but not WHY it has such strange behaviour.
> Using software improperly MUST NOT lead to such damaging results. Beware
> of such bad software engineering!

Agreed. NO program on UNIX should EVER use the

	command inputfile [outputfile]

syntax. It's dangerous, counterintuitive (you can't use it as a filter), and
inflexible. Indent does the same thing, which is why I have indent in a script
that does "indent -st" here.

If the command *requires* an outputfile (mv, cp, ln) it needs to do sanity
checks, and accept multiple input files. The output file should NEVER be
optional in this case:

	command inputfile outputfile
	command inputfile... outputdir

If you NEED an optional output file, and for some reason redirects don't
work, then flag it:

	command file... [-o outputfile]

I don't know what dos2unix and unix2dos do, but they should be using one
of these alternatives.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

In article <id.87XV.OQH@ferranti.com>, peter@ferranti.com (peter da silva) says:
>
>Agreed. NO program on UNIX should EVER use the
>
>        command inputfile [outputfile]
>
>syntax. It's dangerous, counterintuitive (you can't use it as a filter), and
>inflexible. Indent does the same thing, which is why I have indent in a script
>that does "indent -st" here.

And don't forget "uniq"; it hasn't even a flag... :-(

Does anyone actually USE the behaviour of such programs?
(I mean: specifying the outputfile as an optional second argument)
Will there a lot of scripts be broken when you change this stupid
syntax?
--
Paul Bijnens             -- MS-DOS is the world's most widespread virus.
Linguistics dept., K. University Leuven, Belgium
Polleke@cc1.kuleuven.ac.be

In <BzBF6H.3Au@mccc.edu> pjh@mccc.edu (Pete Holsberg) writes:

>In article <1992Dec12.224109.15621@cs.mcgill.ca> haiying@cs.mcgill.ca (Haiying ZHANG) writes:
>=
>=   I came across this bug a while ago. This has to do with using wild
>=card in file names with unix2dos/dos2unix.

>Where did you find these utilities?
I didn't have these utilities long ago (They came with the last update
though), so I wrote a couple of shell scripts that do the same thing.  Let
me know if you are interested.

-- 
INTERNET:  ray@Celestial.COM   Ray A. Jones; Celestial Software
UUCP:   ...!thebes!camco!ray   6641 East Mercer Way
             uunet!camco!ray   Mercer Island, WA 98040; (206) 947-5591
The probability of one or more spelling errors in this missive approaches