Re: du

[prev] [thread] [next] [lurker] [Date index for 2005/09/30]

From: Luke Kanies
Subject: Re: du
Date: 19:36 on 30 Sep 2005
On Fri, 30 Sep 2005, Earle Martin wrote:

> On Thu, Sep 29, 2005 at 07:20:25PM -0400, Dave Vandervies wrote:
> > Keep in mind that "." is a file/directory starting with a '.' in your
> > home directory.
>
> Why? What use is it? I never use it. Well, unless you count using it to
> invoke programs. Is it a symlink? My shell's highlighting doesn't think so;
> it's in the blue that claims it's a directory. So when I do invoke programs,
> I have to go through this invisible yes-it's-a-directory-no-it's-a-symlink
> to do it, which is retarded. No, I can't suggest something better. I reserve
> the right to call things retarded, KTHX, HAND.

They're hard links (you'll have to look that one up).  A little known
aspect of the output of ls -al is that it lists the number of hard links
to a file, and directories (almost) always have >=2, because one is the
hard link from the parent directory to the inode, and the other is the
hard link in the directory to itself.  Incidentally, adding a
subdirectory also automatically adds another hardlink to the parent
directory, because of '..'.  Go ahead, see for yourself:

    luke@culain(0) $ mkdir /tmp/links
    luke@culain(0) $ ls -ald /tmp/links
    drwxr-xr-x  2 luke luke 48 Sep 30 13:29 /tmp/links
    luke@culain(0) $ mkdir /tmp/links/sub
    luke@culain(0) $ ls -ald /tmp/links
    drwxr-xr-x  3 luke luke 72 Sep 30 13:29 /tmp/links

Notice the '2' in the second column becomes a '3' upon creation of the
subdirectory.  That's because the subdir links back to the parent dir.
(Yes, I often ask questions related to this when I am interviewing
sysadmins -- I expect people to actually understand filesystems.)

I use '.' all the time, though, and would often be quite lost without it
(although it could be argued that most of those problems stem from
stupid or unclear tools).  For instance:

    rsync -a /somedir/. /otherdir/.

If I don't specify the '.', then I might (or might not) get
/otherdir/somedir, which is definitely not what I want.  Each tool that
does recursive copies seems to arbitrarily decide whether to create a
new dir or operate in the old dir.  I recently had some stupid problems
where I would copy a directory (/etc/apache) somewhere as myself, it
would fail on one directory, so then I would sudo cp it, and it would
get copied into a subdir:

    luke@culain(0) $ cp -R /etc/apache2/ /tmp/apache2
    cp: cannot access `/etc/apache2/auth': Permission denied
    luke@culain(1) $ ls -ald /tmp/apache2/apache2
    ls: /tmp/apache2/apache2: No such file or directory
    luke@culain(1) $ sudo cp -R /etc/apache2/ /tmp/apache2
    luke@culain(0) $ ls -ald /tmp/apache2/apache2
    drwxr-xr-x  15 root root 616 Sep 30 13:22 /tmp/apache2/apache2

Yes, that's right, cp behaves completely differently if the directory
you're copying into already exists.

'.' is useful for cases like this, because you can specify exactly what
you want to copy and where:

    luke@culain(0) $ cp -R /etc/apache2/ /tmp/apache2
    cp: cannot access `/etc/apache2/auth': Permission denied
    luke@culain(1) $ ls -ald /tmp/apache2/apache2
    ls: /tmp/apache2/apache2: No such file or directory
    luke@culain(1) $ sudo cp -R /etc/apache2/. /tmp/apache2/.
    luke@culain(0) $ ls -ald /tmp/apache2/apache2
    ls: /tmp/apache2/apache2: No such file or directory

> And then there's "..", which is more of the same. When I do "cd .." I'm
> actually changing directory /into/ a directory, which means I should be going
> /down/ the directory tree. And yet the net effect is that I move up. Call me
> a stupid-head if you like, but that is not intuitive.

I'm not in complete disagreement with you, but both the '.' and '..' are
made for the filesystem, not so much for you.  Without these hard links,
the system itself could not operate.  This is why they're hidden --
they're not something humans are supposed to deal with.  Would you have
preferred that they actually be hidden, so that you could not see them?
I wouldn't.

> On a side note, since both start with a ".", that means they should be hidden.
> Yet for some reason scads of applications display both "." and ".." in "open
> file" dialog boxes. What the fuck is the point of giving me something I can
> double-click on and does nothing at all?

Yeah, that's pretty stupid.  File dialogs should never show that crap.

> > Do you really want to see all the stuff that starts with '.' every time
> > you use *?  Isn't avoiding that the whole point of the .name convention?
>
> Yes, I do; I expect * to match everything. I had always been under the
> impression that the output from 'ls' was not the same as an explicit 'ls *'.
> Evidently it's not; I can add it, bash, or both to my list of retarded
> software.

Well, 'ls -d' is the same as 'ls -d *', but 'ls *' will list
subdirectories, which is quite different.  I assume you meant it would
match the same file list, though, which is the case.

'ls -d *' behaves identically to 'ls -d' behaves identically to
'ls -d ./*', and if you want all files then use 'ls -a'.  Without '-a',
you won't get dot-files, which makes it behave as though you had matched
'*'.

-- 
Between two evils, I always pick the one I never tried before.  -- Mae West
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://config.sage.org

There's stuff above here

Generated at 16:00 on 04 Oct 2005 by mariachi 0.52