Re: Loop in vi
As I probably did not make clear in my last reply, I have no love for the
/bin/vi script. It was "demanded" by users who "needed" to be able to type
'vi' during the install and have an editor come up.
I have always viewed this as a cluge and a bad hack, but have seen no way
to get out of it.
Ideally the script should be removed as soon as there is a valid version
of vi on the system. I would use update alternatives, but can't figure out
how to get the vi-style rc file into the command line.
Your hack on the original hack has given me an idea.
First, my problem with your patch: If I understand the logic correctly,
you check to see if the file pointed to by the call is the same as the
file in /usr/bin/vi. If they are the same the fall back is ae in vi mode.
On a system where /usr is a link to /, what happens to the file /bin/vi
when the link /usr/bin/vi is created by the installation of a real vi?
If I type /usr/bin/vi I expect to get the real vi (only getting ae in vi
mode when I enter vi or /bin/vi, and no other vi is installed). If the
script executes (and I don't see how it will) then I will get ae in vi
mode, which is not what is expected.
Unless the HURD is doing something spectacularly different with its file
system, I expect it to behave much the way a Linux file system will. If I
link /usr to /, I effectively link /usr/bin to /bin, and any file I then
copy to /usr/bin will appear in the directory /bin as well. If I copy a
file into /usr/bin that already exists in /bin, the already existing file
is replaced by the newly copied file, and will appear in both /usr/bin and
/bin from then on. As a result, I don't see the problem you seem to think
exists with the /bin/vi script, as it will be replaced with an
update-alternatives link in /usr/bin/vi once the first vi package is
instlled.
Have I missed something here?
As for the way your patch may help remove the script, it made me realize
that if the script can tell that there is a "real" vi installed then it
could remove itself. Under the conditions that /usr is not linked to / the
current script can to that, and will be modified to slit its own throat
when such conditions are found.
At this point, I don't understand the problem or your solution well enough
to trust it to work. I am more than ready to apply any patches that will
resolve this ugly hack of /bin/vi, but, having been backed into this
currently ugly corner by other requests for repair, I am unwilling to move
into another, possibly tighter corner, as a means of "fixing" things.
Help me understand what the "right thing" is, and I am more than willing
to oblige.
Waiting is,
On 15 Apr 1999, Gordon Matzigkeit wrote:
> >>>>> Dale Scheetz writes:
>
> DS> Linking /usr to / is a broken idea.
>
> I'm not going to waste much time arguing for or against the relative
> brokenness of this idea. Likewise, I'm not going to waste much time
> arguing for or against the relative brokenness of having a wrapper
> script that incurs a performance impact on my non-symlinked system
> every time I run vi just because /bin appears in my PATH before
> /usr/bin.
>
> I believe that the /bin/vi wrapper is useful because it saves users
> who accidentally break their vi installation (or are installing their
> system), and don't have an emacs, so I'm willing to accept the cost.
> I believe that the /usr to / link is useful because it saves me having
> to type 4 characters once in a while, and so I'm willing to accept the
> cost.
>
> Assuming that you are determined to have a vi wrapper script that is
> located /bin, and assuming that I am determined to symlink /usr to /,
> I've attached a solution that should make us all relatively happy.
>
> I'm not entirely happy with the performance of my fix, though. You
> can judge for yourself by my profiling (after changing every `exec' to
> `: exec' in both scripts):
>
> trick:~$ time perl -e 'for ($i = 0; $i < 100; $i ++) { 1; }'
>
> real 0m0.022s
> user 0m0.020s
> sys 0m0.010s
> trick:~$ time perl -e 'for ($i = 0; $i < 100; $i ++) { system "./vi.orig"; }'
>
> real 0m2.543s
> user 0m1.600s
> sys 0m0.950s
> trick:~$ time perl -e 'for ($i = 0; $i < 100; $i ++) { system "./vi"; }'
>
> real 0m8.163s
> user 0m4.980s
> sys 0m3.080s
> trick:~$
>
> By my count, that's 0.02521 seconds for the original, and 0.08141
> seconds for my solution. Would my changes make /bin/vi a bottleneck?
> ;)
>
> Anyway, if any other aspect of my solution doesn't make you happy,
> please let me know.
>
> DS> In addition, /bin/vi is a script, installed in the root.bin of
> DS> the rescue floppy so that the vi command will provide an editor
> DS> during base installation. As soon as one of the "real" vi's gets
> DS> installed (on a system with /usr linked to /) the script will be
> DS> overwritten by the new symlink for update-alternatives that the
> DS> various vi use.
>
> Exactly... the problem is limited in scope, and so I don't want to
> spend much more time working on it. It was a tiny problem for me,
> I've attached a tiny fix for it, and now I'm asking you to graciously
> consider spending a tiny bit of time incorporating my fix into your
> package.
>
> If you do, I will be a tiny bit happier, and there will be a tiny bit
> more peace among fellow Debian developers. :)
>
> Thanks Dale,
>
> --
> 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/)
>
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Reply to: