Below is an excerpt of a listing of my $HOME/News directory.

total 206
-rw-r--r--  1 tbetz           0 Dec  3  1988 .comsignature
drwxr-xr-x 11 tbetz         176 Oct 18  1988 alt/
-rw-r--r--  1 tbetz       12756 Jun 14 06:49 applied.gw   <-----
-rw-r--r--  1 tbetz       64775 Jun 14 06:48 applied.gw   <-----
drwxr-xr-x  5 tbetz          80 Sep 24  1988 ca/

You will note that there are two files with identical names.

I can view them using 'more' and they are indeed two different
files.  I haven't done anything else with them yet (I'll 'cat'
them to another file if I can) but I can't figure out how this
can happen.

Ideas?

I swear that, other than shortening it, I have not modified this
listing in any way.
--

  MY CURRENT FAVORITE ADVERTISING LINES:     |Tom Betz
    "Look what they done to old Duke...      |ZCNY, Yonkers, NY 10701-2509
       next year I'm growing corn."          |UUCP: tb...@dasys1.UUCP or

Tom Betz asked about a problem he has, where it seems that two of his
files have the exact same name.  Since this is a situation that's easy
to get into, but much harder to solve unless you know how, and since
it can quickly lead to lost data, here's a somewhat verbose explanation:

The problem is that one of your two files has a name that contains a
non-printing character.  This happens now and then...  Here's an `ls
-la` of a directory I just created to illustrate it:

% ls -la
total 8
drwxr-xr-x   2 tih      users         80 Jun 15 17:41 .
drwxr-xr-x   3 tih      users        704 Jun 15 17:41 ..
-rw-r--r--   1 tih      users         21 Jun 15 17:40 Testfile
-rw-r--r--   1 tih      users         42 Jun 15 17:41 Testfile
%

And here's the `od -c .` output showing what the directory entry
actually contains (this is a System V directory, yours will look
different if you're running BSD Unix):

% od -c .
0000000 223   &   .  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000020 270 017   .   .  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000040 236   <   T   e   s   t   f   i   l   e  \0  \0  \0  \0  \0  \0
0000060   b   B   T   e   s   t   f   i   l   e 004  \0  \0  \0  \0  \0
%

Notice the byte with the value 004 (or Ctrl-D) there?  One file is
actually named "Testfile", while the other one is called "Testfile^D"!
This might happen, in some applications, if you start to type a
filename, and then accidentally hit a non-printing character while
doing it.  (I did it by going into an editor, reading in Testfile, and
then specifying Testfile^D when I wrote it back out.)

To fix this one, without losing either file, I would do:

% ls
Testfile
Testfile
% mv Testfile File.1
% ls
File.1
Testfile
% mv Testfile* File.2
% ls
File.1
File.2
%

The trick is to be able to catch the file with the unknown character
in it alone -- and I did it by first moving the file that had the
correct name (since I specified it as it looked).  After that, I could
use a wildcard to match the remaining file (thus not having to type
the unknown character), and everything is now OK!

-tih
--
Tom Ivar Helbekkmo, NHH, Bergen, Norway.  Telephone: +47-5-959205
t...@barsoom.nhh.no, thelb...@norunit.bitnet, edb_...@debet.nhh.no

You must have a non-printable control character in one of the names.

Try:
/bin/ls | cat -v

This will display the control character that ls is hiding from you.
Berkeley's ls (/usr/ucb/ls) will print a '?' for the control character.

I believe "l -b" will also show you the strange char.

--
Daiv Stoner                  +===============================================+
aindi...@osiris.cso.uiuc.edu | I work for the Gov't.  If I want your opinion |
oin...@ria-emh1.army.mil     | I'll ask you to fill out the necessary forms. |
Disclaimer:  The Dept. of    +===============================================+
Defense doesn't even know what it's doing, let alone what I'm doing.

This won't work if the extra characters are spaces which is probably the case.
Use 'od -a' as the pipe instead of the 'cat -v' option.
  ls | od -a
--
Edgar Holmann                       UUCP:   decwrl!nova!ed...@uunet.uu.net
ed...@Neon.stanford.edu             BITNET: edgar%Neon.stanford.edu@stanford

This won't work if the extra characters are spaces which is probably the case.
Use 'od -a' as the pipe instead of the 'cat -v' option.
  ls | od -a
--
Edgar Holmann                       UUCP:   decwrl!nova!ed...@uunet.uu.net
ed...@Neon.stanford.edu             BITNET: edgar%Neon.stanford.edu@stanford

This won't work if the extra characters are spaces which is probably the case.
Use 'od -a' as the pipe instead of the 'cat -v' option.
  ls | od -a
--
Edgar Holmann                       UUCP:   decwrl!nova!ed...@uunet.uu.net
ed...@Neon.stanford.edu             BITNET: edgar%Neon.stanford.edu@stanford

From article <1990Jun15.090604.21...@dasys1.uucp>, by tb...@dasys1.uucp (Tom Betz):
Run your ls output through od of use ls -lb to check for any
invisable (but present) characters in the filenames.
Are you sure that vi didn't warn about non-ascii characters
in your ls file?

-
Ronald Pikkert                 E-mail: ron...@atcmp.nl
@ AT Computing b.v.            Tel:    080 - 566880
Toernooiveld
6525 ED  Nijmegen

Tom, have you considered the possibility that one or both of those
filenames consider a non-printing character?

Try 'hd', 'od', or 'vis' on $HOME/News, and then tell us if they're still
twins or not.
--
Jean-Pierre Radley                                                 jpr@jpradley
New York, NY                                          72160.1...@compuserve.com

No.  I'll bet you that they have different names and that the portion of
one of the name is not printable or overwritten.  For example any of the
following names will appear the same way:

        "applied.gw"
        "ax\bpplied.gw"       (\b is a backspace)
        "applied.gw "   (note space at end of name)

So do an od -bc of . (the directory) to see the different names.

--
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170

This is part of "Frequently Asked Questions."  Anyway, do:

1: ls -i app
        and note inumbers of the files in question.

2: find . -inum xxx -exec mv {} new_name ";"
        where xxx is  the inumber of one of the offenders and new_name
        whatever is appropriate.

NOTE: The option "inum" is not documented anywhere but does exist with every
version of find I have ever used, beginning with Version 7.

Actually, it is documented in 4BSD, and systems that picked up the
documentation of "-inum" from there, including System V Release 4.

Mea culpa!  Indeed, 'inum' is documented in my V7 manual, but in no other
version of my manuals from either BTL (Release 3 and Release 5, later to
become System III and System V) or more recently from AT&T (e.g. SVR3).

Sorry about that - Carl

It is documented in the Ninth Edition Programmer's Manual Volume 1.

Shock horror!!  System V.2.2 `man find' documents it too!?!

Boyd Roberts                    b...@necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''