On Sat, Aug 17, 2013 at 01:46:16PM +0200, Andreas Gregor Frank wrote: > same reason for me: some object-oriented shell ( > http://oobash.sourceforge.net/)
We're both running commands in the form 'object.method ...', and it works very naturally on the shell using the command-not-found hook. The problem comes when, e.g., the object is incrementally built up using tab completion so that it contains slashes, and the hook won't fire. > > "But given that the first entry on a command line pretty much has to be > a command, I'm not sure it makes sense to invoke file_not_found_handle()" > > I think you are right. On the other hand, there'd be no confusion if the handler was named to match the error message , so maybe no_such_file_or_directory_handler() could work. Still, it might be simpler to fix the current behavior. > But then we go in circles...: > http://gnu-bash.2382.n7.nabble.com/command-not-found-handle-not-called-if-command-includes-a-slash-tp7118.html > > @all: If there is a reason for not fixing this 'bug', i would like to hear. I suspect the reason may just be disinterest, and no one has made any noise about the issue. Object oriented shell is perhaps an arcane area, but I find it quite useful, and have several different systems running using it. My scheme relies on following search paths to resolve executables, and could likely largely be implemented by setting PATH dynamically according to $object, followed by exec $method. Most object oriented shell schemes that I've found and looked at are based on using the innards of shell programming, some using functions, some using arrays, some using variables, namespaces in variable name prefixes, etc. Using these systems often requires significant buy-in to the scheme, e.g., having to follow some discipline to make everything work. My interest is in trying to minimize the machinery needed to make it happen, and trying to keep necessary conventions that have to be followed to a minimum. That's the goal anyway. Methods are any ordinary executables, executed in the context of the object (the handler cd's to the object directory). The current machinery for my scheme is mostly one executable, the handler or executive, really just yet another command line interpreter or shell. The main convention is that symlinks named ^ are needed to identify the type of objects. The ^ link in a directory object resolves via the handler to a directory with methods, i.e., a bin or lib directory, which can also have a ^ link, and so on, effectively building up PATH. I have to avoid going on and on about this. I have a github project for it, but have not updated the documentation for quite a while, https://github.com/kirv/thinobject I'm not sure where an appropriate place to discuss the general topic would be, but at least the subject topic seems appropriate for bash-bug, whether as a bug or feature request. Ken