megabyte@chinet.UUCP (Mark E. Sunderlin) (02/18/86)
Ok, here is my question to the net. Why does ls -C Sometimes NOT print across the screen? Most of the time when I enter a ls -C I get a nice diretory like: News fvps.c h19 mbox vps.c But some times a directory will list one per line on me. What does ls make this decision on? I have seen this behavior on both at&t 3b2 machines and on Tandy 6000 machines. (sys V on one Xenix 3 on the latter) Any thoughts??? -- _________________________________________________________________________ UUCP: (1) seismo!dolqci!irsdcp!scsnet!sunder Mark E. Sunderlin (2) ihnp4!chinet!megabyte aka Dr. Megabyte CIS: 74026,3235 (202) 634-2529 Quote: "No matter where you go, There you are" (9-4 EST) Mail: IRS 1111 Constitution Ave. NW PM:S:D:NO Washington, DC 20224
cdl@mplvax.ARPA (Carl Lowenstein) (02/20/86)
In article <337@chinet.UUCP> megabyte@chinet.UUCP (Mark E. Sunderlin) writes: >Ok, here is my question to the net. Why does ls -C Sometimes >NOT print across the screen? >But some times a directory will list one per line on me. What does >ls make this decision on? I have seen this behavior on both at&t 3b2 >machines and on Tandy 6000 machines. (sys V on one Xenix 3 on the latter) This seems to be the now-famous SysV 14-character filename bug. Directories have exactly 14 bytes allocated for the file name, so a full-length name can't have a null terminator. When ls(1) tries to compute the number of columns to use for the -C option it gets some ridiculously long length for one of the file names, and gives up and uses a single column. -- carl lowenstein marine physical lab u.c. san diego {ihnp4|decvax|akgua|dcdwest|ucbvax} !sdcsvax!mplvax!cdl
carl@bdaemon.UUCP (carl) (02/21/86)
> Ok, here is my question to the net. Why does ls -C Sometimes > NOT print across the screen? Most of the time when I enter > a ls -C I get a nice diretory like: > News fvps.c h19 mbox vps.c > But some times a directory will list one per line on me. What does > ls make this decision on? I have seen this behavior on both at&t 3b2 > machines and on Tandy 6000 machines. (sys V on one Xenix 3 on the latter) > Any thoughts??? etc., etc. This bug is known to the people at the AT&T hot-line and happens when any file name is 14 characters long. When it will be fixed?????????
kimcm@olamb.UUCP (Kim Chr. Madsen) (02/21/86)
[come on ye little faithfull friends -- and eat me !] > Ok, here is my question to the net. Why does ls -C Sometimes > NOT print across the screen? Most of the time when I enter > a ls -C I get a nice diretory like: > News fvps.c h19 mbox vps.c > But some times a directory will list one per line on me. What does > ls make this decision on? I have seen this behavior on both at&t 3b2 > machines and on Tandy 6000 machines. (sys V on one Xenix 3 on the latter) > Any thoughts??? Well on the 3b2 the answer is: If a filename in the directory is exactly 16 characters long the colomnized version of ls will fail. A kludge to handle this is to pipe `ls' though `pr -4' to get a four colomn output... Kim Chr. Madsen AmbraSoft A/S kimcm@olamb.uucp
jso@edison.UUCP (John Owens) (02/21/86)
> Why does ls -C Sometimes NOT print across the screen? > [...] What does > ls make this decision on? I have seen this behavior on both at&t 3b2 > machines and on Tandy 6000 machines. (sys V on one Xenix 3 on the latter) > Any thoughts??? Check what's in your PATH ("echo $PATH"). Look in each of those directories for the "ls" command. Chances are you have more than one.... Often "/bin/ls" is an old V7-like ls command, which always lists one per line, while another ls, earlier in your path, has the -C option. Does this "sometimes" happen when your current directory is /bin? -- John Owens edison!jso%virginia@CSNet-Relay.ARPA General Electric Company Phone: (804) 978-5726 Factory Automation Products Division Compuserve: 76317,2354 houxm!burl!icase!uvacs ...!{ decvax!mcnc!ncsu!uvacs }!edison!jso gatech!allegra!uvacs
wcs@ho95e.UUCP (x0705) (02/22/86)
In article <365@bdaemon.UUCP> carl@bdaemon.UUCP writes: >> Ok, here is my question to the net. Why does ls -C Sometimes >> NOT print across the screen? .... >> ls make this decision on? I have seen this behavior on both at&t 3b2 >> machines and on Tandy 6000 machines. (sys V on one Xenix 3 on the latter) > >This bug is known to the people at the AT&T hot-line and happens when any >file name is 14 characters long. When it will be fixed????????? For that matter, when did it get broken? My 3B2 running System V (R2?) has this bug, but my 3B20 and VAXen running System V and VR2 don't. -- # Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
sean@ukma.UUCP (Sean Casey) (02/23/86)
In article <337@chinet.UUCP> megabyte@chinet.UUCP (Mark E. Sunderlin) writes: >Ok, here is my question to the net. Why does ls -C Sometimes >NOT print across the screen? Most of the time when I enter >a ls -C I get a nice diretory like: >News fvps.c h19 mbox vps.c >But some times a directory will list one per line on me. What does >ls make this decision on? I have seen this behavior on both at&t 3b2 >machines and on Tandy 6000 machines. (sys V on one Xenix 3 on the latter) >Any thoughts??? The problem is an oversight in the design. The structure that the file name is being read into is exactly large enough to hold the file name and no more (14 chars). If the filename is less than 14 characters long, there is a null terminator. If the file name is exactly 14 characters long (the maximum), there is no null terminator because there is no room for one. This causes problems when ls attempts to determine how many columns it can put on the screen. Since the filename isn't null terminated, when ls does a strlen() to see how long the filename is, it not only looks at the 14 characters of the filename, but at any junk after that until it happens to hits a null. Thus, when you have a filename of 14 characters, ls incorrectly thinks that you have a VERY long filename. It divides the screen width by the width of the largest file to determine how many columns can go on the screen. Since you now have a BIG filename, it goes "gee, I can only put one column of files on the screen". The easiest fix is to make sure that no filename is ever regarded as being longer than the longest you're allowed to have. Context diff follows: -------- CUT HERE -------- CUT HERE -------- *** ls.c.old Sat Feb 22 21:12:36 1986 --- ls.c Sat Feb 22 21:13:05 1986 *************** *** 616,621 continue; if (Cflg || mflg) { width = strlen(dentry.d_name); if (width > filewidth) filewidth = width; } --- 616,632 ----- continue; if (Cflg || mflg) { width = strlen(dentry.d_name); + + /* CHANGE [10-Feb-86 sean@ukma] ls -C fix + * + * If a file name is the maximum size (DIRSIZ), then dentry.d_name will + * not have a null terminator. This causes width to be set too high and + * the files will print in reduced columns. The fix is to check the width + * and set it to DIRSIZ if it exceeds DIRSIZ. + */ + if (width > DIRSIZ) + width = DIRSIZ; + if (width > filewidth) filewidth = width; } -------- CUT HERE -------- CUT HERE -------- What I don't understand is that later on in the program, they force a null into the filename at the proper point so that it can be printed out. It seems to me that if whoever wrote it did this then they would also see the need for the null here. Sean -- ------------------------------------------------------------------------------- Sean Casey UUCP: sean@ukma.uucp CSNET: sean@uky.csnet University of Kentucky ARPA: ukma!sean@anl-mcs.arpa Lexington, Kentucky BITNET: sean@ukma.bitnet "Remember, no matter where you go, there you are." - BB
guy@sun.uucp (Guy Harris) (02/23/86)
> > Ok, here is my question to the net. Why does ls -C Sometimes > > NOT print across the screen?... > > This bug is known to the people at the AT&T hot-line and happens when any > file name is 14 characters long. When it will be fixed????????? It'll probably get fixed when they get around to adopting the 4.2BSD *cum* IEEE P1003 directory reading library, since that library always null-terminates file names. (Yet another argument in favor of that library, as if there weren't enough good reasons to use it anyway.) -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa (yes, really)
rich@rexago1.UUCP (K. Richard Magill) (02/25/86)
>In article <337@chinet.UUCP> megabyte@chinet.UUCP (Mark E. Sunderlin) writes: >>Why does ls -C Sometimes NOT print across the screen? I met this bug long ago. I presume that because the fix is so easy & the red tape so difficult it may be a long time before we see a 'fishal solution. I would have posted diffs myself but I figured that anyone with source would find & fix the bug so quickly... I have 3b2/300 ls corrected and with the 4.2 style -x default & single column if (!isatty()). I am willing to share uuencoded COFF. MAIL ME. Should interest dictate, I shall post to mod.sources. xoxorich. K. Richard Magill
jel@uel (J. Eli Lamb ) (03/16/86)
> > Ok, here is my question to the net. Why does ls -C Sometimes > > NOT print across the screen?... > > This bug is known to the people at the AT&T hot-line and happens when any > file name is 14 characters long. When it will be fixed????????? This problem was fixed in the latest release from AT&T, the UNIX System V Release 2.1 Source Code for AT&T 3B2 Computers and has been available since December 1985. === J. Eli Lamb {mcvax!ukc!}uel!jel Technical Support Manager UNIX Europe Limited, phone: +44 1 785-6972 27A Carlton Drive, fax: +44 1 785-6916 London SW15 2BS, UK telex: 914054 UNIXTM G