Path: utzoo!utgpu!cs.utexas.edu!usc!julius.cs.uiuc.edu!psuvax1!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: alt.sources.d
Subject: Re: NON-SOURCE POSTINGS CONSIDERED HARMFUL!
Message-ID: <13437:Jan2823:24:2991@kramden.acf.nyu.edu>
Date: 28 Jan 91 23:24:29 GMT
References: <1991Jan26.091846.25944@convex.com> <1943:Jan2619:34:3591@kramden.acf.nyu.edu> <2856@charon.cwi.nl>
Organization: IR
Lines: 80

In article <2856@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
> Dan moves on to another field giving a script
> that gives all duplicate executables in your path; it does not look at the
> arguments you give.

Right. I started this subthread as a separate followup to Tom's first
article. This has very little to do with the ``which'' thread (except
that I don't think the function of ``which'' should be copied into a
million separate scripts). The latter thread is also under a different
subject line.

> I have a few complaints

Duly noted.

> In article <1943:Jan2619:34:3591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> > for i in `ls -ilFL $dirs |
> Complaint 1:  ls complains about non existing directories that I have in my
> path.

Good point. Your change helps portability.

>  >                            rev |
> Complaint 2: some of the (UNIX) systems I have access to tell me:
> 	rev not found.

Yes, so? When I try to run Tom's script, most of the UNIX systems I have
access to tell me: perl not found. A few of the features he used didn't
work the same in earlier versions of perl. All this means is that he
requires your system to have a certain level of support. The same is
true of my script.

> What do I do now?  Write a csh alias to do rev?

You can work front-to-back on the lines if you want; sort and sed don't
mind. To run this version, you have to, e.g., pick up the rev source and
compile it---just as you need to compile perl if you don't have that.

>  > | sed -n -e 's/ .*//' -e 's/^\*//p' |
> Complaint 3: Mmm.  What with a filename that ends in an asterisk?

Already noted, several times.

> And
> files with embedded blanks?

There is no proper way to handle them, because of Tom's stilted output
format. You might as well say that find is buggy because there's no way
to separate filenames with null rather than newline. Sure, that leads to
security holes; find still works.

>  >   echo -n "$i: "
> Complaint 4:  On some (UNIX) systems this will not echo what you want.

Same response as for rev; this is not a reasonable complaint. To port
the program to those systems, you can use echo ... | tr -d '\012' if you
want.

>  >   echo ''
> Why those quotes?

Figure it out yourself.

> Score: 8 lines of code, 3 correct.

Be serious. The code does what it's meant to do in the situation I wrote
it for. It is so short that it is trivial to port to any system. The
same isn't true of Tom's maintenance mess.

Sure, there are lots of limitations: if two different files on different
devices have the same inode and appear with the same name in your path,
then they won't be reported. Do I care? Sure, enough to mention this
caveat in the documentation if I wrote a man page. That doesn't make the
code incorrect.

Exercise for the reader: Find three more portability problems and five
more minor caveats. Yes, they exist. Will this stop people from using
the script if they just want to find repeated executables in path? No.

---Dan