Finding all applications


(Jim Menard) #1

Chris Gehlker gehlker@fastq.com writes:

In trying to add drag and drop scripting to RubyStudio and the first task is
to simply make a set of all the applications on the local volumes. I’ve
fallen into some gnarlyesque Carbon code. Before I proceed further down this
thorny path, is there some simple unix way of doing this. Any pointers
appreciated.

I’m away from my MacOS X box, but have you tried this?

find / -type d -name '*.app'

(Wrap that in a Ruby system() command, of course.)

Jim

···


Jim Menard, jimm@io.com, http://www.io.com/~jimm/
“Any sufficiently complicated C or Fortran program contains an ad hoc
informally-specified bug-ridden slow implementation of half of Common Lisp.”
– Greenspun’s Tenth Rule of Programming


(SER) #2

Jim Menard wrote:

In trying to add drag and drop scripting to RubyStudio and the first task
is to simply make a set of all the applications on the local volumes.
I’ve fallen into some gnarlyesque Carbon code. Before I proceed further
down this thorny path, is there some simple unix way of doing this. Any
pointers appreciated.

find / -type d -name ‘*.app’

Or, if you want to use Ruby:

ruby -r find -e ‘Find.find("/"){|f| puts f if f[/.app$/]}’

···

… “It isn’t pre-marital sex if you don’t get married”
<|> – anon
/|\
/|


(Nobuyoshi Nakada) #3

Hi,

···

At Sun, 2 Jun 2002 03:08:12 +0900, Sean Russell wrote:

find / -type d -name '*.app'

Or, if you want to use Ruby:

ruby -r find -e ‘Find.find("/"){|f| puts f if f[/.app$/]}’

Or,

ruby -r find -e ‘Dir.glob("/**/*.app") {|f| puts f}’


Nobu Nakada


(Chris Gehlker) #4

Thanks, Jim, Shawn and nobu for replying. All of your suggestions work. They
are all so slow though. I guess when man find says “find recursively
descends the directory tree for each file listed…” I’m supposed to take
that literally. I was hoping that find would be smart enough to just search
the catalog.

···

On 6/1/02 11:33 AM, "nobu.nokada@softhome.net" nobu.nokada@softhome.net wrote:

Hi,

At Sun, 2 Jun 2002 03:08:12 +0900, > Sean Russell wrote:

find / -type d -name '*.app'

Or, if you want to use Ruby:

ruby -r find -e ‘Find.find("/"){|f| puts f if f[/.app$/]}’

Or,

ruby -r find -e ‘Dir.glob("/**/*.app") {|f| puts f}’


The secret of life is honesty and fair dealing. If you can fake that,
you’ve got it made. -Groucho Marx


(Michael Campbell) #5

ruby -r find -e ‘Find.find("/"){|f| puts f if f[/.app$/]}’

Or,

ruby -r find -e ‘Dir.glob("/**/*.app") {|f| puts f}’

Thanks, Jim, Shawn and nobu for replying. All of your suggestions work. They
are all so slow though. I guess when man find says “find recursively
descends the directory tree for each file listed…” I’m supposed to take
that literally. I was hoping that find would be smart enough to just search
the catalog.

Catalog?


(SER) #6

Chris Gehlker wrote:

Thanks, Jim, Shawn and nobu for replying. All of your suggestions work.
They are all so slow though. I guess when man find says “find recursively
descends the directory tree for each file listed…” I’m supposed to take
that literally. I was hoping that find would be smart enough to just
search the catalog.

Chris,

Does OS/X come with the slocate package? If it does, you can use the
’locate’ command:

    locate \*.app

This is much faster than find or the Ruby alternatives.

— SER


(Chris Gehlker) #7

That is probably Mac speak. I know Windows used to call it a FAT but I think
it’s called something else in NTFS. I have no idea what the generic term is
for “The database that maps inodes to the directory hierarchy. The thing
that gets updated when the user executes mv.” Among Mac programmers that
thing has been called the “catalog tree” or “catalog” forever, while the
corresponding database that maps inodes to disk sectors is called the
"extents tree."

I would like to know the generic names for these things, assuming there are
generic names.

···

On 6/1/02 5:20 PM, “Mike Campbell” michael_s_campbell@yahoo.com wrote:

ruby -r find -e ‘Find.find("/"){|f| puts f if f[/.app$/]}’

Or,

ruby -r find -e ‘Dir.glob("/**/*.app") {|f| puts f}’

Thanks, Jim, Shawn and nobu for replying. All of your suggestions work. They
are all so slow though. I guess when man find says “find recursively
descends the directory tree for each file listed…” I’m supposed to take
that literally. I was hoping that find would be smart enough to just search
the catalog.

Catalog?


Tact is the ability to describe others as they see themselves. -Abraham
Lincoln, 16th president of the U.S (1809-1865)


(Dossy) #8

Did Mac (HFS I’m assuming) index the filesystem and allow searching
of the index (I think BeOS had this functionality)?

In FAT, NTFS and most Unix filesystems, there’s no indexing so to
locate objects you have to traverse the whole filesystem.

– Dossy

···

On 2002.06.02, Chris Gehlker gehlker@fastq.com wrote:

On 6/1/02 5:20 PM, “Mike Campbell” michael_s_campbell@yahoo.com wrote:

ruby -r find -e ‘Find.find("/"){|f| puts f if f[/.app$/]}’

Or,

ruby -r find -e ‘Dir.glob("/**/*.app") {|f| puts f}’

Thanks, Jim, Shawn and nobu for replying. All of your suggestions work. They
are all so slow though. I guess when man find says “find recursively
descends the directory tree for each file listed…” I’m supposed to take
that literally. I was hoping that find would be smart enough to just search
the catalog.

Catalog?

That is probably Mac speak. I know Windows used to call it a FAT but I think
it’s called something else in NTFS. I have no idea what the generic term is
for “The database that maps inodes to the directory hierarchy. The thing
that gets updated when the user executes mv.” Among Mac programmers that
thing has been called the “catalog tree” or “catalog” forever, while the
corresponding database that maps inodes to disk sectors is called the
"extents tree."

I would like to know the generic names for these things, assuming there are
generic names.


Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)


(Nobuyoshi Nakada) #9

Hi,

···

At Sun, 2 Jun 2002 11:07:54 +0900, Chris Gehlker wrote:

That is probably Mac speak. I know Windows used to call it a FAT but I think
it’s called something else in NTFS. I have no idea what the generic term is
for “The database that maps inodes to the directory hierarchy. The thing
that gets updated when the user executes mv.” Among Mac programmers that
thing has been called the “catalog tree” or “catalog” forever, while the
corresponding database that maps inodes to disk sectors is called the
"extents tree."

Perhaps, you may want to access Deskop Database' or something (I don't remember correctly), however, it's not a filesystem feature butFinder’ applications database. If so, you need
`Inside Macintosh’ or similar first.


Nobu Nakada


(Chris Gehlker) #10

Did Mac (HFS I’m assuming) index the filesystem and allow searching
of the index (I think BeOS had this functionality)?

Basically yes. There is API for treating the filesystem as a database.
Sherlock exposes this API to the user but any app can use it as well.

In FAT, NTFS and most Unix filesystems, there’s no indexing so to
locate objects you have to traverse the whole filesystem.

Maybe that explains why I kept losing files on my PC. If there wasn’t really
anything in the filesystem itself that kept track of where a file was in the
directory hierarchy. This information must have been in the registry?

I guess efs doesn’t really have anything like that either, now that you
mention it. From a given file of directory you can trace up the file
hierarchy because you have that information encoded in it’s full path name
but you can’t search down the hierarchy without using the expensive method
that find is using. I remember that efs didn’t have aliases and symlinks
aren’t the same thing.

I expect to be able to search a 50 gig HD in milliseconds for queries like
"show me all the documents originally created with application X" or “show
me all the programs that the current user has permission to execute”. I’ve
done this kind of thing before and had those results. Unfortunately, the
techniques didn’t stick in my head that well and the API changed a little
for OSX so I’m going to have to modify my old code.

NTFS, according to people who should know, really does have all the
capabilities built in. Their simply aren’t any applications that use them
including WinXP itself.

···

On 6/1/02 7:44 PM, “Dossy” dossy@panoptic.com wrote:

Conversation, n. A fair for the display of the minor mental commodities,
each exhibitor being too intent upon the arrangement of his own wares to
observe those of his neighbor. -Ambrose Bierce


(Chris Gehlker) #11

Thanks nobu but I have enough documentation to do it. I was just looking for
any easier way that writing a bunch of plain old C.

···

On 6/1/02 8:59 PM, "nobu.nokada@softhome.net" nobu.nokada@softhome.net wrote:

Perhaps, you may want to access Deskop Database' or something (I don't remember correctly), however, it's not a filesystem feature butFinder’ applications database. If so, you need
`Inside Macintosh’ or similar first.


War is God’s way of teaching Americans geography.
-Ambrose Bierce, writer(1842-1914)


(Tobi Reif) #12

Dossy wrote:

In FAT, NTFS and most Unix filesystems, there’s no indexing so to
locate objects you have to traverse the whole filesystem.

I’m new to nx, but
http://cm.bell-labs.com/7thEdMan/v7vol2a.pdf
says
"IV. IMPLEMENTATION OF THE FILE SYSTEM
As mentioned in Section 3.2 above, a directory entry contains only a
name for the associated file and a pointer to the file itself. This
pointer is an integer called the i-number (for index number) of the
file. When the file is accessed, its i-number is used as an index into a
system table (the i-list )" …

is this what he wants, the i-list?

… “stored in a known part of the device on which the directory
resides. The entry found thereby (the file’s i-node )
contains the description of the file:
i the user and group-ID of its owner
ii its protection bits
iii the physical disk or tape addresses for the file contents
iv its size
v time of creation, last use, and last modification
vi the number of links to the file, that is, the number of times it
appears in a directory
vii a code indicating whether the file is a directory, an ordinary
file, or a special file.”

Tobi

···


http://www.pinkjuice.com/


(Rick Bradley) #13

I expect to be able to search a 50 gig HD in milliseconds for queries like
"show me all the documents originally created with application X" or “show
me all the programs that the current user has permission to execute”.

In the Unix world in general (which OSX is now a part of), there’s
historically been no metadata for determining sytematically the creator
of a file [0]. Some suffixes are helpful in determining the format of a
file but this says little about the creating application [1], much less
a preferred reader [2].

That aside most legacy nx filesystems don’t provide even the basic
sorts of indices you’re looking for. Simple userland add-ons like
locate/findb provide quick name-based searching. There are, however, a
large number of filesystems available (something one doesn’t tend to see
in the Windows world, but hopefully will see more of in the OSX world)
on various nx platforms. I seem to recall some fs-as-db filesystems
getting some news recently in the nx world. Perhaps that’s worth a
look.

[0] the “magic number” applies in many cases, but in many others
it doesn’t and there’s no forcing a developer to use that
mechanism
[1] e.g., an .html file generally contains HTML, but its creator
could be any text manipulator from cat(1) to Lyx
[2] off the top of my head I know that Mozilla, NS4.72, Konqueror,
Opera, w3m, lynx, links, and emacs-www are installed on my (FreeBSD)
system, and all of those browsers get use (by me) from time to time.

Rick

···


http://www.rickbradley.com MUPRN: 894 (75F/78F)
> type. Fair warning. A
random email haiku | grill’s a grill, as long as there
> is some heat in it.


(Nobuyoshi Nakada) #14

Hi,

···

At Sun, 2 Jun 2002 16:34:22 +0900, Tobias Reif wrote:

is this what he wants, the i-list?

I-nodes don’t have the names and no portable way to access
i-node lists directly. If it were possible, unprivileged users
should be denied, since it means to voilates file permissions.

And also, an executable file is marked by an executable bit,

not by its suffix under normal unixen.


Nobu Nakada


(SER) #15

Chris Gehlker wrote:

I guess efs doesn’t really have anything like that either, now that you
mention it. From a given file of directory you can trace up the file
hierarchy because you have that information encoded in it’s full path name
but you can’t search down the hierarchy without using the expensive method
that find is using. I remember that efs didn’t have aliases and symlinks
aren’t the same thing.

I want to caveat my earlier message about slocate. It does build this
index, but it is particular to Linux installations. I mean, I’m sure that
you could easily compile and install it on any nx-ish OS, but you won’t
find it there commonly, so it probably won’t be of any use to you.

A further speedbump:

All of this talk about i-nodes and filesystems illustrates the fact that
there isn’t a portable way to do what you want, because there are at least
three /commonly/ used filesystems on Linux, another three for the rest of
the Unix world, and probably yet another three for the other common OSes.
This isn’t counting network FSes.

Basically yes. There is API for treating the filesystem as a database.
Sherlock exposes this API to the user but any app can use it as well.

And OS/X doesn’t provide a command-line interface to this API?

By the way, I’m curious: I was a long-time NeXTSTEP user. Under NeXTSTEP,
‘find / -name *.app’ wouldn’t do what you wanted it to. Not all
applications under NeXT were packaged as 'app’s; for example, you’d miss
all of the applications in /bin. Are /all/ executables suffixed by 'app’
in OS/X? If not, you’d need something else from find, probably:

    find / -type f -perm +1

which, even then, probably wouldn’t work, because people aren’t careful
about their permissions. A short search on my machine turned up a bunch of
QT header files :-/

It occurs to me as I’m writing this that it might be possible for Ruby to
use the /fastest/ underlying search mechanism. Something like:

class Locate
METHODS = [ ‘linux’, ‘macos’, ‘windows’ ]

def initialize
  METHODS.each do | platform, method |
    if RUBY_PLATFORM =~ /#{platform}/i
      instance_eval "alias :locate #{method}"
      break
    end
  end
  instance_eval "alias :locate :find" unless defined? locate
end

def linux(*args, &block)
  `locate #{args.to_s}`.split("\n").each(&block)
end

def macos(*args, &block)
   `clisherloc #{args.to_s}`.split("\n").each(&block)
end

#...

end


(Tobi Reif) #16

Hi,

is this what he wants, the i-list?

I-nodes don’t have the names and no portable way to access
i-node lists directly. If it were possible, unprivileged users
should be denied, since it means to voilates file permissions.

You’re right. But he could search it as root?

And also, an executable file is marked by an executable bit,

not by its suffix under normal unixen.

Sure. But doesn’t the i-list say if a file is executable?
(“ii its protection bits”)

Well, anyways, if you say there’s no portable way to access i-node lists
directly …

Tobi

···

nobu.nokada@softhome.net wrote:


http://www.pinkjuice.com/


(Albert) #17

Based on this thread, I just installed slocate. There is an option that
tells it to parse the /etc/updatedb.conf. I can’t find any docs that
describe what /etc/updatedb.conf might contain. Any clues?

···


Quantum Mechanics: The dreams stuff is made of


(Chris Gehlker) #18

Chris Gehlker wrote:

I want to caveat my earlier message about slocate. It does build this
index, but it is particular to Linux installations. I mean, I’m sure that
you could easily compile and install it on any nx-ish OS, but you won’t
find it there commonly, so it probably won’t be of any use to you.

Thanks for all the suggestions, Sean. Mac OS does provide BSD locate but
it’s broken. The problem is that crontabs is set up by default to update the
data base at some weird time like 1:00 am on Monday mornings. Power
management is set up to have the Mac asleep then. So the cron task never
actually runs. I bet 80% of the Mac users never notice this because they
have Sherlock right in the dock so they don’t investigate locate.

A further speedbump:

All of this talk about i-nodes and filesystems illustrates the fact that
there isn’t a portable way to do what you want, because there are at least
three /commonly/ used filesystems on Linux, another three for the rest of
the Unix world, and probably yet another three for the other common OSes.
This isn’t counting network FSes.

I agree. I really don’t need it to be portable though.

Basically yes. There is API for treating the filesystem as a database.
Sherlock exposes this API to the user but any app can use it as well.

And OS/X doesn’t provide a command-line interface to this API?

I don’t think so. I stumbled over a few command line tools that aren’t in
the man pages anywhere but I searched the documentation and couldn’t find
anything like this.

By the way, I’m curious: I was a long-time NeXTSTEP user. Under NeXTSTEP,
‘find / -name *.app’ wouldn’t do what you wanted it to. Not all
applications under NeXT were packaged as 'app’s; for example, you’d miss
all of the applications in /bin. Are /all/ executables suffixed by 'app’
in OS/X? If not, you’d need something else from find, probably:

I just did a cd into /Applications and then an ls. Only about half the
applications had a .app suffix. Nothing in /bin did.

  find / -type f -perm +1

That won’t work here. It barfs on the +.

···

On 6/2/02 7:29 AM, “Sean Russell” ser@germane-software.com wrote:

In the midst of great joy, do not promise anyone anything. In the midst of
great anger, do not answer anyone’s letter. -Chinese proverb


(Chris Gehlker) #19

I expect to be able to search a 50 gig HD in milliseconds for queries like
"show me all the documents originally created with application X" or “show
me all the programs that the current user has permission to execute”.

In the Unix world in general (which OSX is now a part of), there’s
historically been no metadata for determining sytematically the creator
of a file [0]. Some suffixes are helpful in determining the format of a
file but this says little about the creating application [1], much less
a preferred reader [2].

Ah, I didn’t mean to imply that I could find all the files created by any
given application now. Given a file it’s pretty easy to determine the
preferred reader for the current user in OSX because you can look in
Users//Library/Preferences. I haven’t quite figured out howto
determine the username of the person who launched RubyStudio though. And the
converse, given application X, what are the members of the set of local
files for which it is the preferred reader, is something I just don¹t know
how to address programmatically. The question must have come up before
though.

That aside most legacy nx filesystems don’t provide even the basic
sorts of indices you’re looking for. Simple userland add-ons like
locate/findb provide quick name-based searching. There are, however, a
large number of filesystems available (something one doesn’t tend to see
in the Windows world, but hopefully will see more of in the OSX world)
on various nx platforms. I seem to recall some fs-as-db filesystems
getting some news recently in the nx world. Perhaps that’s worth a
look.

[0] the “magic number” applies in many cases, but in many others
it doesn’t and there’s no forcing a developer to use that
mechanism
[1] e.g., an .html file generally contains HTML, but its creator
could be any text manipulator from cat(1) to Lyx
[2] off the top of my head I know that Mozilla, NS4.72, Konqueror,
Opera, w3m, lynx, links, and emacs-www are installed on my (FreeBSD)
system, and all of those browsers get use (by me) from time to time.

So what happens when you double click an html file. KDE must do something.

···

On 6/1/02 10:19 PM, “Rick Bradley” rick@rickbradley.com wrote:


Cogito Ergo Spud. - I think therefore I yam.


(Nobuyoshi Nakada) #20

Hi,

is this what he wants, the i-list?

I-nodes don’t have the names and no portable way to access
i-node lists directly. If it were possible, unprivileged users
should be denied, since it means to voilates file permissions.

You’re right. But he could search it as root?

Maybe.

And also, an executable file is marked by an executable bit,

not by its suffix under normal unixen.

Sure. But doesn’t the i-list say if a file is executable?
(“ii its protection bits”)

According to [ruby-talk:41558], Mac OS X seems to use suffixes
to say executable.

···

At Sun, 2 Jun 2002 17:50:32 +0900, Tobias Reif wrote:


Nobu Nakada