On 2/19/04 4:57 PM, "James Bucanek" <subscriber at gloaming.com> wrote: >> 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. Well, that makes sense, sort of... I do understand that it's more the weirdness of HFS+ and resource forks than the actual file system though. So, to sum up, bash can't do what tcsh can do here. Kirk My latest book: How to Do Everything with Mac OS X Panther http://www.mcelhearn.com/htde.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . kirk at mcelhearn.com | http://www.mcelhearn.com . . . . . . . . Kirk McElhearn | Chemin de la Lauze | 05600 Guillestre | France . .