cdl@mplvax.UUCP (Carl Lowenstein) (03/29/85)
References:
I have a mere binary-licensed 3b2, so I can't investigate this
any further myself, but:
ls(1) has two options to produce multi-column output,
-C for sorted down the columns
-x for sorted across the rows
if *any* file in a directory has a full-length (14-char) name,
then these options fail, and a single-column output results.
Any hints or workarounds would be welcome.
--
carl lowenstein marine physical lab u.c. san diego
{ihnp4|decvax|akgua|dcdwest|ucbvax} !sdcsvax!mplvax!cdlnetnews@wnuxb.UUCP (Heiby) (03/31/85)
I discovered this bug several weeks ago. The appropriate reports have
been made and it should be fixed in a (near) future release. In the
mean time, a work-around is to use "ls -C *" instead of "ls -C". It
seems to do the multi-column thing if all the files are specified
explicitly. Wierd.
--
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL (CU-D21)alan@drivax.UUCP (Alan Fargusson) (04/03/85)
> ls(1) has two options to produce multi-column output, > -C for sorted down the columns > -x for sorted across the rows > > if *any* file in a directory has a full-length (14-char) name, > then these options fail, and a single-column output results. I thought I would try out 14 character names with ls on System V/iAPX286 and The result on the 286 was 2 column output, while the VAX produced 5 column output. In looking at the source I found that the directory structure is declared as follows: struct { short inode; char name[14]; } directory; Or something like that. The problem is that strlen(3) is called with the name as an argument. When the name is 14 characters long, strlen falls off the end of the name, and returns a large number. By dumb luck the VAX has a null after the name. The VME/10s around here do not have the version of ls with the -C and -x flags. I can't think of any way around this problem without fixing the source, since a null has to be added to the end of the name for strlen to work. -- Alan Fargusson. { ihnp4, sftig, amdahl, ucscc, ucbvax!unisoft }!drivax!alan
mp@allegra.UUCP (Mark Plotnick) (04/06/85)
Well, the problem is that in the readdir() routine, the code is doing strlen(dentry.d_name), and d_name isn't null-terminated if it's 14 characters long (I think strlen returns 44 or so). Now if you have a binary distribution, all is not lost; since dentry is the only automatic variable in the readdir() routine, you can increase your chances of finding a null at the end of the structure by increasing the amount of automatic space the routine allocates. I changed the .s file and assembled it and this works until you start asking ls to list more than one directory at a time. *** old Fri Apr 5 17:41:31 1985 --- new Fri Apr 5 17:42:33 1985 *************** *** 1,6 readdir() 8080112e: 10 47 SAVE %r7 ! 80801130: 9c 10 4c ADDW2 &0x10,%sp 80801133: a0 5a PUSHW 0(%ap) 80801135: a0 4f c5 14 88 80 PUSHW &0x808814c5 8080113b: 2c cc f8 7f a8 44 80 80 CALL 0xf8(%sp),$0x808044a8 --- 1,6 ----- readdir() 8080112e: 10 47 SAVE %r7 ! 80801130: 9c 14 4c ADDW2 &0x14,%sp 80801133: a0 5a PUSHW 0(%ap) 80801135: a0 4f c5 14 88 80 PUSHW &0x808814c5 8080113b: 2c cc f8 7f a8 44 80 80 CALL 0xf8(%sp),$0x808044a8 Lacking adb (they don't offer it on 3b's) and sufficient knowledge about the COFF, I can't offer a sure-fire way to patch the binary, though. Mark Plotnick allegra!mp
guy@sun.uucp (Guy Harris) (04/11/85)
> Well, the problem is that in the readdir() routine, the code is doing > strlen(dentry.d_name), and d_name isn't null-terminated if it's 14 > characters long (I think strlen returns 44 or so). This is the second S5R2 bug that is fixed "for free" if you convert to the Berkeley "directory library". The library provides directory entries with null-terminated names, fixing this bug; the previous bug was a shell problem caused, if I remember correctly, by testing whether the result of an "open" of a directory was > 0 rather than whether it was >= 0. I've converted lots of S5R2 programs to use the library; it's very easy. I'd vote for putting it into 1) the /usr/group standard, 2) the System V Interface Definition (which currently, bless its soul, does *not* commit to what directories look like when you open them), and therefore 3) System V. Guy Harris sun!guy
fred@mot.UUCP (Fred Christiansen) (04/11/85)
> > ls(1) has two options to produce multi-column output, > > -C for sorted down the columns > > -x for sorted across the rows > > > > if *any* file in a directory has a full-length (14-char) name, > > then these options fail, and a single-column output results. > > I thought I would try out 14 character names with ls(1) on System V/iAPX286 > and the result on the 286 was 2 column output, while the VAX produced 5 > column output. > The problem is that strlen(3) is called with > the name as an argument. When the name is 14 characters long, strlen > falls off the end of the name, and returns a large number. By dumb > luck the VAX has a null after the name. The VME/10s around here do not > have the version of ls with the -C and -x flags. > Alan Fargusson (drivax!alan) A look at the code suggests that "fall[ing] off the end of the name" is indeed what happens, except for the "serendipity" when a null happens to be following ... or is there more? I created several files in a row with 14-char names on a VME/10 running Sys V R2. "od -cx ." indicates they were consecutive with no nulls following. Yet, with either -C or -x options for ls(1), the output was five column. Hmm. -- << Generic disclaimer >> Fred Christiansen, Motorola Microsystems, Tempe {ihnp4,allegra}!sftig!mot!fred {ihnp4,seismo}!ut-sally!oakhill!mot!fred {ihnp4,amdahl}!drivax!mot!fred
jsdy@hadron.UUCP (Joseph S. D. Yao) (04/11/85)
> mean time, a work-around is to use "ls -C *" instead of "ls -C". It
Suggest 'ls -Cd *' would do what you want. I've made the other
mistake too often.
Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}todd@bu-cs.UUCP (Todd Cooper) (04/13/85)
> > Well, the problem is that in the readdir() routine, the code is doing > > strlen(dentry.d_name), and d_name isn't null-terminated if it's 14 > > characters long (I think strlen returns 44 or so). > > This is the second S5R2 bug that is fixed "for free" if you convert > to the Berkeley "directory library". The library provides directory > entries with null-terminated names, fixing this bug; the previous bug > was a shell problem caused, if I remember correctly, by testing whether > the result of an "open" of a directory was > 0 rather than whether it > was >= 0. > > I've converted lots of S5R2 programs to use the library; it's very easy. > I'd vote for putting it into 1) the /usr/group standard, 2) the System V > Interface Definition (which currently, bless its soul, does *not* commit > to what directories look like when you open them), and therefore 3) > System V. > > Guy Harris > sun!guy > > The SYSTEM V we are working with on the 3b5 also has the same bug -- yech --- I made the same fix. In fact we are running less than RELEASE 2 --- they have not released release 2 for our system.? en fact, I have taken their ls (release 1.3) and converted it so that if DOES multiple cols. Why didn't they also make it so that the multiple cols come "magically" when you are using a tty as stdout like berkely --- also they do not print a '?' when the a character in a file name is unprintable ala Berkely. -- --------------------------- Todd Cooper (617) 424-9018 UUCP: ...!harvard!bu-cs!todd ARPA: todd%bu-cs.csnet@csnet-relay.arpa USNail: 13 Marlborough St. #1, Boston, MA 02116
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (04/14/85)
> > This is the second S5R2 bug that is fixed "for free" if you convert > > to the Berkeley "directory library". The library provides directory > > entries with null-terminated names, fixing this bug; the previous bug > > was a shell problem caused, if I remember correctly, by testing whether > > the result of an "open" of a directory was > 0 rather than whether it > > was >= 0. > > > > I've converted lots of S5R2 programs to use the library; it's very easy. > > I'd vote for putting it into 1) the /usr/group standard, 2) the System V > > Interface Definition (which currently, bless its soul, does *not* commit > > to what directories look like when you open them), and therefore 3) > > System V. I second the motion! Benefits include: (1) Easier coding (2) Cleaner coding (3) Portable coding (4) Faster operation due to buffering Of course virtually ALL the UNIX System V Release 2 utilities have been so converted in the BRL UNIX System V emulation for 4.2BSD (out of necessity). If AT&T wants `em they can have `em. I also previously posted a UNIX System V edition of the directory access library routines. They should be added to the standard C library!
greg@ncr-tp.UUCP (Greg Noel) (04/16/85)
In article <2116@sun.uucp> guy@sun.uucp (Guy Harris) writes: >I've converted lots of S5R2 programs to use the [dir] library.... >I'd vote for putting it into 1) the /usr/group standard, 2) the System V >Interface Definition (which currently, bless its soul, does *not* commit >to what directories look like when you open them), and therefore 3) >System V. I'll second that (although I doubt that I'll be second). After all, libld was added to standardize the interface to load modules; why not a standard interface to directories? -- -- Greg Noel, NCR Torrey Pines Greg@ncr-tp.UUCP or Greg@nosc.ARPA