Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!ncar!elroy.jpl.nasa.gov!lll-winken!quintro!bep From: bep@quintro.uucp (Bryan Province) Newsgroups: comp.sys.apollo Subject: Re: Peculiar behaviour of "ls //" Message-ID: <1991Jan30.035438.2312@quintro.uucp> Date: 30 Jan 91 03:54:38 GMT References: <4f7aa1e7.20b6d@apollo.HP.COM> Distribution: comp Organization: none Lines: 41 In article <4f7aa1e7.20b6d@apollo.HP.COM> vinoski@apollo.HP.COM (Stephen Vinoski) writes: >In article jnp@tnds05.tele.nokia.fi (J|rgen N|rgaard) writes: >>What happens is that a command like, say, "ls //" takes rather long time to >>complete whereas "time ls //" is very fast. >> >>First "ls //": >> bash# date; ls // ; date >> Mon Jan 28 14:34:55 EET 1991 >> .bash_history* .emacs* andromeda/ dionysos/ kronos/ >> .bash_login* afrodite/ atlas/ kirke/ mjolner/ >> Mon Jan 28 14:39:18 EET 1991 >> bash# >> >> >>That is 5 minutes to complete "ls" (amazing indeed !) >> >>Next "time ls //": >> bash# time ls // >> .bash_history .emacs andromeda dionysos kronos >> .bash_login afrodite atlas kirke mjolner >> 0.5 real 0.0 user 0.1 sys >> bash# > >It looks like your "ls" is an alias for "ls -F" which results in a stat() for >every entry to be listed. When you run it via the "time" command, the alias is >not used. > >-steve As a side point, I don't think that the "//" is the proper place to store files such as .emacs, .bash_login, and .bash_history. I always thought of this directory as being reserved for storing the cataloged names of nodes in the network. You might try removing these files and see what happens although I don't think that's why it takes so long to do an ls -F. You might also try the following command: time ls -F // to see if it also takes 5 minutes. -- --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- Bryan Province -Glenayre Corp., Quincy, IL- quintro!bep@lll-winken.llnl.gov "I tried putting instant coffee in the microwave, I almost went back in time." - Steven Wright