I have been tidying up and generalising some of the linux poplog
installation mechanisms, including the install_package script,
now documented here
http://www.cs.bham.ac.uk/research/poplog/tools/install_package/
and also updating the list of changes and bugfixes over the last few
years here
http://www.cs.bham.ac.uk/research/poplog/bugfixes/BUGREPORTS
This reminded me of an old problem. For some time I have been aware that
invoking
$popcom/make_indexes
can cause problems in some contexts. In a message broadcast two years
ago I suggested that this was due to the make_indexes program not
detecting loops in a directory tree where symbolic links are used.
I therefore proposed a change which would detect loops.
However, I have now found that the problem is worse than that.
If any link in the poplog tree (including the local directory) points
outside of the tree to a large file structure (as happens here in
Birmingham), then the program goes on exploring the whole tree. In this
case the process needs to be stopped long before a loop is encountered.
There is not an easy work-around, because the make_indexes library uses
the '/.../' option to tell sys_file_match to expand to any depth in its
search for directories to index (e.g. with names like 'help', 'teach'
'lib' etc.)
It is possible to give make_indexes a list of blocking path names
to prevent it examining directories whose path names start with
a blocker. But it does that only AFTER the name has been returned
by sys_file_match.
So the repeater produced by sys_file_match can go on indefinitely
producing longer and longer path names that are to be rejected.
A possible fix:
It should be possible to alter sys_file_match so that it can be
given an optional extra argument which is a list of blocker
strings and blocker predicates (pop11 procedures which return a
boolean when applied to a string).
Then if a path name starts with one of the blocker strings or if one of
the predicates returns true when applied to a path name, then the path
name is discarded and sys_file_match produces no new paths based on it.
For instance make_indexes could be told to ignore any path containing
'/local/'.
This change to sys_file_match would be useful in other contexts besides
the make_indexes library.
Doing this would be a good exercise for someone who understands pop11
(including perhaps the process mechanism, which is used by
sys_file_match).
I suspect that once the location in sys_file_match is found the fix will
take a few minutes' work at most. Testing it and altering the
documentation will take longer!
Any takers? I have too many other things to do just now, though I may
work on it later.
(A generalisation of this would be to allow a blocker procedure to
return an alternative path in some cases. This would allow pop11 to
support a type of 'symbolic' link that does not depend on unix symbolic
links.)
Aaron
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
|