An early addition to thinobject was support for some command line utilities as methods, operating on the thinobject store (directory). These are defined in the thinob.sh shell interface, and do actually call the system or shell command of the same name, either directly (inline) or via exec.
find, however, has an annoying message that appears in some of my test cases, when a loop or cycle of symbolic links is encountered. It turns out (per the find manpage on debian) that this message is issued in compliance with POSIX, and there seems to be no way to "cleanly" turn it off or otherwise supress it specifically.
The message is probably quite useful and meaningful, but I'm guessing it's not really needed or pertinent in this case. I don't recall the details, but I think those cyclic infinite loops arise naturally from trying to define thinobject classes in a hierarchy. The workaround, which I've used, is to (drum roll...) not do that, i.e., don't create them in a hierarchy but in some sort of parallel arrangement; but that leads to classnames which imply other superclasses in the name. It's awkward.
The problem with the cycle thing is really find's problem, and it is able to deal with it safely -- i.e., it isn't even a problem! Well, it won't crash the computer (apparently, 'cause I've tried it plenty) anyway, and seems harmless.
I guess the issue might be shown as:
A is a subclass of B
B is a subclass of C
C is a subclass of A
Is that it? That definitely looks bad, and I'm not sure why this would be useful, but it, or something like it, is. Find's solution is to simply detect the loop, report it, and move on. My thinobject system has to traverse those links as well when it goes searching for methods, but the same simple "trick" is used: if the directory has already been visited, then move along, nothing to see here.
The bottom line of all this is that I added 2>/dev/null to the find commands executed from the find method. There's an exception: if --debug and --verbose are used (as options to thinob.sh), then standard error is left along, and should appear as normal. But by default, that annoying message is supressed.
ALONG WITH ANY OTHER ERROR MESSAGE FROM FIND...
Definitely more of a shotgun filter than a finely targeted one. If important error/warming messages are going to be missed, this is probably not a good thing to be doing, but I'm not aware of any in particular.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An early addition to thinobject was support for some command line utilities as methods, operating on the thinobject store (directory). These are defined in the thinob.sh shell interface, and do actually call the system or shell command of the same name, either directly (inline) or via exec.
find, however, has an annoying message that appears in some of my test cases, when a loop or cycle of symbolic links is encountered. It turns out (per the find manpage on debian) that this message is issued in compliance with POSIX, and there seems to be no way to "cleanly" turn it off or otherwise supress it specifically.
The message is probably quite useful and meaningful, but I'm guessing it's not really needed or pertinent in this case. I don't recall the details, but I think those cyclic infinite loops arise naturally from trying to define thinobject classes in a hierarchy. The workaround, which I've used, is to (drum roll...) not do that, i.e., don't create them in a hierarchy but in some sort of parallel arrangement; but that leads to classnames which imply other superclasses in the name. It's awkward.
The problem with the cycle thing is really find's problem, and it is able to deal with it safely -- i.e., it isn't even a problem! Well, it won't crash the computer (apparently, 'cause I've tried it plenty) anyway, and seems harmless.
I guess the issue might be shown as:
A is a subclass of B
B is a subclass of C
C is a subclass of A
Is that it? That definitely looks bad, and I'm not sure why this would be useful, but it, or something like it, is. Find's solution is to simply detect the loop, report it, and move on. My thinobject system has to traverse those links as well when it goes searching for methods, but the same simple "trick" is used: if the directory has already been visited, then move along, nothing to see here.
The bottom line of all this is that I added 2>/dev/null to the find commands executed from the find method. There's an exception: if --debug and --verbose are used (as options to thinob.sh), then standard error is left along, and should appear as normal. But by default, that annoying message is supressed.
ALONG WITH ANY OTHER ERROR MESSAGE FROM FIND...
Definitely more of a shotgun filter than a finely targeted one. If important error/warming messages are going to be missed, this is probably not a good thing to be doing, but I'm not aware of any in particular.