>>>>> Dale Scheetz writes: DS> As a result, I don't see the problem you seem to think exists DS> with the /bin/vi script, as it will be replaced with an DS> update-alternatives link in /usr/bin/vi once the first vi package DS> is instlled. DS> Have I missed something here? You've missed the fact that no self-respecting GNU/Hurd user would *ever* install vi. Just kidding. ;) Actually, the real reason is that users try typing `vi' while they're installing their Debian GNU/Hurd system, just like with Debian GNU/Linux. They expect to get an editor, not `file not found', and *definitely* not an infinite loop. At that point they have to guess at what the editor could possibly be called: `ae' isn't exactly the first attempt I'd make... I'd probably try using sed first. The reason I'm spending time trying to fix this infinite loop is the same reason the /bin/vi script exists in the first place: people want to use vi, but they can't because it isn't actually installed. DS> As for the way your patch may help remove the script, it made me DS> realize that if the script can tell that there is a "real" vi DS> installed then it could remove itself. Isn't there a way that you can make update-alternatives think that /bin/ae is just an alternative for /usr/bin/vi? If it's done in the postinstall script, then everything will work. DS> Under the conditions that /usr is not linked to / the current DS> script can to that, and will be modified to slit its own throat DS> when such conditions are found. Can you post your new implementation, so I can understand its implications? DS> At this point, I don't understand the problem or your solution DS> well enough to trust it to work. I am more than ready to apply DS> any patches that will resolve this ugly hack of /bin/vi, but, DS> having been backed into this currently ugly corner by other DS> requests for repair, I am unwilling to move into another, DS> possibly tighter corner, as a means of "fixing" things. I agree. We're actually talking about slightly different problems. All I'm interested in is finding a way so that your wrapper script never calls itself recursively. That really has nothing to do with the problem you tried to solve with it in the first place. I've attached a simpler implementation. Let me know what you think. [BTW, all the cosmetic changes I made were just so that the wrapper is portable to other systems. `test ...' is just a more portable synonym for `[ ... ]'.] DS> Help me understand what the "right thing" is, and I am more than DS> willing to oblige. Thanks, that's all I really wanted to know. We'll definitely be able to do Right Thing, with a little effort. -- Gordon Matzigkeit <gord@fig.org> //\ I'm a FIG (http://www.fig.org/) Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
Attachment:
vi
Description: Binary data