[X-Unix] Weird tcsh vs bash behavior

[James Bucanek]

Kirk McElhearn wrote on Thursday, February 19, 2004:

>When using tcsh, you can do the following:
>
>% ls -al */rsrc 
>
>When in a directory, to find if there are any resource forks. The result
>looks like this:
>
>-rw-rw-r--  1 root  admin      11644 26 Nov 20:44 Classic Support UI/rsrc
>-rw-rw-r--  1 root  admin      14477 26 Nov 20:44 Classic Support/rsrc
>-rw-r--r--  1 root  unknown        0  4 Feb 16:05 Classic Update
>Log.txt/rsrc
>-rw-rw-r--  1 root  admin     789387 26 Nov 20:44 Classic/rsrc
>-rw-rw-rw-  1 kirk  unknown        0  8 Feb  2003 Clipboard/rsrc
>
>But running the same command while in bash doesn't work - is there something
>I'm missing? Does bash not see the /rsrc files? Or is it something to do
>with the way it globs?

It's not the way the shells glob.  It's probably the way in which they try to resolve the resulting paths.

The magic '/rsrc' isn't really a file -- at least it doesn't have a traditional entry in the UNIX directory structure.  It's a "synthetic" file who's parent "directory" is the file that contains the resource data.  Note that you can also use the synthetic naming convention '<filename>/..namedfork/rsrc'.

So, let's take the example "*/rsrc".  If the shell reads the current directory and matches all the entries it can find against '*' (both files and directories), then systematically tests each possible <filename>/rsrc using stat(), or some similar call, then it will find all of the synthetic */rsrc files in the directory.

However, if a shell tries to be "smart" it might first exam the type of each entry that matches the '*'.  As it examines each match, it's going to see that they are all files, so it could safely eliminate it as a potential match because files aren't directories, and therefor can't contain children.

I suspect that tcsh is blindly trying each <filename>/rsrc to see if it exists, and bash is looking at <filename>, sees that it's a file, and skips it.

______________________________________________________
James Bucanek       <mailto:privatereply at gloaming.com>