Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Tue, 12 May 2009, Aaron Schaefer wrote: > This will mean that all plugin packages will have to be rebuilt for > each minor Vim release? Is that how other distro's handle it? Seems a > bit odd... Minor releases don't happend more than once a year. It's not that much of a biggie. Honestly, I on't know how big the impact is when vim has to look up files in two pathes over one. Users did complain about it that's for sure. -T
Re: [arch-general] New vi/vim/gvim in testing requires intervention
Since I can't reply to the dev mailing list thread: On Tue, May 12, 2009 at 8:25 AM, Dan McGee wrote: > On Tue, May 12, 2009 at 2:19 AM, Tobias Kieslich wrote: >> On Tue, 12 May 2009, Magnus Therning wrote: >> That means all plugins need to be rebuild and some users that set fixed >> pathes in .vimrc will have to adjust. > > Looks like we have a new rebuild list then: > > $ pacman -Sqs vim- ... This will mean that all plugin packages will have to be rebuilt for each minor Vim release? Is that how other distro's handle it? Seems a bit odd... -- Aaron "ElasticDog" Schaefer
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Tue, May 12, 2009 at 2:19 AM, Tobias Kieslich wrote: > On Tue, 12 May 2009, Magnus Therning wrote: And a quick guess, it looks like the new vim package puts its colors here: /usr/share/vim/vim72/colors/ Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath? >> >> Looking at other distros it seems using /usr/share/vim/vimX is the place >> for system-wide configurations. Not saying that's right or wrong. > > Well, I tied up quite a few requests into the new vim packages. Becuase > we serve the runtime files with one package(vim) and have other > packages(gvim) depend on it, I used to set the runtime path explicitely. > Users told me that causes vim to search always in two pathes(the > explicite one AND the default one). Hence I started toi stick with the > default path, which is /usr/share/vim/vimxy. > > That means all plugins need to be rebuild and some users that set fixed > pathes in .vimrc will have to adjust. Looks like we have a new rebuild list then: $ pacman -Sqs vim- gvim vim-a vim-bufexplorer vim-buftabs vim-colorsamplerpack vim-doxygentoolkit vim-guicolorscheme vim-matchit vim-minibufexpl vim-omnicppcomplete vim-project vim-taglist vim-vcscommand vim-workspace vim-pastie vim-rails vim-supertab vim-surround vim-timestamp vimpager Why the heck gvim and vimpager showed up in there I'm not sure, but the above plugin packages probably all use the default location. We should additionally make sure they depend on 'vim' and not 'vi', as I rebuilt two or three plugins already that made the assumption they were one and the same. -Dan
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Mon, May 11, 2009 at 08:50:02PM -0500, Dan McGee wrote: > > And a quick guess, it looks like the new vim package puts its colors here: > > /usr/share/vim/vim72/colors/ > > > > Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath? > > Addendum: *any* plugins installed do not work, not just colors or > anything else. vim-bufexplorer is broken; vim-taglist is broken, etc. > Add this line to ~/.vimrc: set runtimepath+=/usr/share/vim In the default vim configuration the main directory for runtime files is the one where vim installs its files, /usr/share/vim/vim72 in the new package, /usr/share/vim/ before the split vi/vim/gvim. See the help for :runtimepath, $VIMRUNTIME and $VIM. The plugins packages need a repackaging. There is already a bug report http://bugs.archlinux.org/task/14626.
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Tue, 12 May 2009, Magnus Therning wrote: >>> And a quick guess, it looks like the new vim package puts its colors here: >>> /usr/share/vim/vim72/colors/ >>> >>> Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath? > > Looking at other distros it seems using /usr/share/vim/vimX is the place > for system-wide configurations. Not saying that's right or wrong. Well, I tied up quite a few requests into the new vim packages. Becuase we serve the runtime files with one package(vim) and have other packages(gvim) depend on it, I used to set the runtime path explicitely. Users told me that causes vim to search always in two pathes(the explicite one AND the default one). Hence I started toi stick with the default path, which is /usr/share/vim/vimxy. That means all plugins need to be rebuild and some users that set fixed pathes in .vimrc will have to adjust. -T
Re: [arch-general] New vi/vim/gvim in testing requires intervention
Dan McGee wrote:
On Mon, May 11, 2009 at 8:40 PM, Dan McGee wrote:
On Tue, May 5, 2009 at 2:22 AM, Tobias Kieslich wrote:
Hi,
Finally, the new vi* packages are up. There will be a little migration
pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}"
before you run "sudo pacman -Syu"
Any ideas?
dmc...@galway ~
$ vim .vimrc
Error detected while processing /home/dmcgee/.vimrc:
line 64:
E185: Cannot find color scheme inkpot
Press ENTER or type command to continue
dmc...@galway ~
$ locate inkpot
/usr/share/vim/colors/inkpot.vim
For reference, here is some of my .vimrc:
" GUI/NONGUI SETTINGS "
if has("gui_running")
if has("gui_gtk2")
set guifont=DejaVu\ Sans\ Mono\ 12
endif
colorscheme desert
set columns=80 lines=40
else
colorscheme inkpot
endif
And a quick guess, it looks like the new vim package puts its colors here:
/usr/share/vim/vim72/colors/
Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath?
Looking at other distros it seems using /usr/share/vim/vimX is the place for
system-wide configurations. Not saying that's right or wrong.
/M
--
Magnus Therning(OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Mon, May 11, 2009 at 8:40 PM, Dan McGee wrote:
> On Tue, May 5, 2009 at 2:22 AM, Tobias Kieslich wrote:
>> Hi,
>>
>> Finally, the new vi* packages are up. There will be a little migration
>> pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}"
>> before you run "sudo pacman -Syu"
>
> Any ideas?
>
> dmc...@galway ~
> $ vim .vimrc
> Error detected while processing /home/dmcgee/.vimrc:
> line 64:
> E185: Cannot find color scheme inkpot
> Press ENTER or type command to continue
>
> dmc...@galway ~
> $ locate inkpot
> /usr/share/vim/colors/inkpot.vim
>
> For reference, here is some of my .vimrc:
>
> " GUI/NONGUI SETTINGS "
> if has("gui_running")
> if has("gui_gtk2")
> set guifont=DejaVu\ Sans\ Mono\ 12
> endif
> colorscheme desert
> set columns=80 lines=40
> else
> colorscheme inkpot
> endif
>
>
> And a quick guess, it looks like the new vim package puts its colors here:
> /usr/share/vim/vim72/colors/
>
> Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath?
Addendum: *any* plugins installed do not work, not just colors or
anything else. vim-bufexplorer is broken; vim-taglist is broken, etc.
This is going to leave a lot of people with a crippled setup if we
start moving the default paths around like this. This should not move
out of [testing] until this is resolved in some way.
-Dan
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Tue, May 5, 2009 at 2:22 AM, Tobias Kieslich wrote:
> Hi,
>
> Finally, the new vi* packages are up. There will be a little migration
> pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}"
> before you run "sudo pacman -Syu"
Any ideas?
dmc...@galway ~
$ vim .vimrc
Error detected while processing /home/dmcgee/.vimrc:
line 64:
E185: Cannot find color scheme inkpot
Press ENTER or type command to continue
dmc...@galway ~
$ locate inkpot
/usr/share/vim/colors/inkpot.vim
For reference, here is some of my .vimrc:
" GUI/NONGUI SETTINGS "
if has("gui_running")
if has("gui_gtk2")
set guifont=DejaVu\ Sans\ Mono\ 12
endif
colorscheme desert
set columns=80 lines=40
else
colorscheme inkpot
endif
And a quick guess, it looks like the new vim package puts its colors here:
/usr/share/vim/vim72/colors/
Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath?
-Dan
Re: [arch-general] New vi/vim/gvim in testing requires intervention
Kessia 'even' Pinheiro wrote: Hi all, Tobias, i`m without a machine, so, i can`t check the vim version. Did you compile new vim with witch version of ruby? It will be with ruby-1.8 because 1.9 is not in the repos yet... I am waiting for the vi(m)'s to move out of [testing] before I do the ruby update. Allan
Re: [arch-general] New vi/vim/gvim in testing requires intervention
Hi all, Tobias, i`m without a machine, so, i can`t check the vim version. Did you compile new vim with witch version of ruby? On Sat, May 9, 2009 at 10:24 AM, Thomas Bohn wrote: > On 2009-05-05 00:22 -0700, Tobias Kieslich wrote: > > > Finally, the new vi* packages are up. > > One more question about the vim package. Why is /usr/bin/vim a symlink > to /usr/bin/vim-normal? > > Thomas > -- Kessia Pinheiro Computer Science Student - Brazil, UFBa Linux System Administrator Arch Linux Trusted User Linux User #389695 http://even.archlinux-br.org --- X Fórum Internacional Software Livre - fisl10 24 a 27 de junho de 2009 PUCRS - Porto Alegre - Brasil
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On 2009-05-05 00:22 -0700, Tobias Kieslich wrote: > Finally, the new vi* packages are up. One more question about the vim package. Why is /usr/bin/vim a symlink to /usr/bin/vim-normal? Thomas
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Wed, 2009-05-06 at 15:40 -0500, Aaron Griffin wrote: > On Wed, May 6, 2009 at 3:15 PM, Pierre Chapuis wrote: > > Le Wed, 6 May 2009 14:53:43 -0500, > > Aaron Griffin a écrit : > > > >> Might be worth seeing if we can find a patch to fix the crash at least. > > > > Patching might be a good idea, but if you just patch the crash I think it > > will still be even more dangerous to put this version of vi in core because > > of the behavior described by André Ramaciotti. > > > > If any user whose language is not English writes a comment at the top of a > > config file (say rc.conf or /etc/sudoers if he runs visudo) and saves it, > > this config file will be emptied and he won't know it. Guess what will > > happen when he tries to reboot. > > > > There is a simple, easy to use and mostly bug-free editor in core, it's > > nano. Why the need for another one? > > Not everyone likes or prefers nano. More to the point - a working vi > is required to be POSIX compliant (or maybe it's SUSv3) As for the working vi, we have two options: - disable widechar support - check debian sid for patches, they have some patches that cope with broken widechar support
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Wed, May 6, 2009 at 3:15 PM, Pierre Chapuis wrote: > Le Wed, 6 May 2009 14:53:43 -0500, > Aaron Griffin a écrit : > >> Might be worth seeing if we can find a patch to fix the crash at least. > > Patching might be a good idea, but if you just patch the crash I think it > will still be even more dangerous to put this version of vi in core because > of the behavior described by André Ramaciotti. > > If any user whose language is not English writes a comment at the top of a > config file (say rc.conf or /etc/sudoers if he runs visudo) and saves it, > this config file will be emptied and he won't know it. Guess what will happen > when he tries to reboot. > > There is a simple, easy to use and mostly bug-free editor in core, it's nano. > Why the need for another one? Not everyone likes or prefers nano. More to the point - a working vi is required to be POSIX compliant (or maybe it's SUSv3)
Re: [arch-general] New vi/vim/gvim in testing requires intervention
Le Wed, 6 May 2009 14:53:43 -0500, Aaron Griffin a écrit : > Might be worth seeing if we can find a patch to fix the crash at least. Patching might be a good idea, but if you just patch the crash I think it will still be even more dangerous to put this version of vi in core because of the behavior described by André Ramaciotti. If any user whose language is not English writes a comment at the top of a config file (say rc.conf or /etc/sudoers if he runs visudo) and saves it, this config file will be emptied and he won't know it. Guess what will happen when he tries to reboot. There is a simple, easy to use and mostly bug-free editor in core, it's nano. Why the need for another one? -- Pierre 'catwell' Chapuis
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Wed, May 6, 2009 at 2:30 PM, André Ramaciotti wrote: > At least here, vi can open non-ASCII files, but as I said previously, > it won't show the lines with non-ASCII characters. The worst thing is > if you try to save this file, vi will save it only up to the first > line with a non-ASCII character: > > $ cat test.txt > This line is fine > mas essa não (but this one isn't) > neither is this one. > > Then open it with vi and try to save it. > > $ cat test.txt > This line is fine > > and that's all. > > Vi does crash, but only when I type a non-ASCII character. Might be worth seeing if we can find a patch to fix the crash at least.
Re: [arch-general] New vi/vim/gvim in testing requires intervention
At least here, vi can open non-ASCII files, but as I said previously,
it won't show the lines with non-ASCII characters. The worst thing is
if you try to save this file, vi will save it only up to the first
line with a non-ASCII character:
$ cat test.txt
This line is fine
mas essa não (but this one isn't)
neither is this one.
Then open it with vi and try to save it.
$ cat test.txt
This line is fine
and that's all.
Vi does crash, but only when I type a non-ASCII character.
On Wed, May 6, 2009 at 4:15 PM, Aaron Griffin wrote:
> 2009/5/6 Frédéric Perrin :
>> I have a system whose users' real names can't be written in ASCII, and
>> this being the 21st century, not the 70's, I have the real name (with
>> accents) in the GECOS field in /etc/passwd. Not being a vi{,m} user, I
>> just have whatever the default package for vi is installed.
>
> $ grep http /etc/passwd | cut -d: -f5
>
> $ usermod -c éøß http
> $ grep http /etc/passwd | cut -d: -f5
> éøß
>
> Editing the passwd file by hand seems a little odd to me.
>
> Still, if vi crashes when opening a non ASCII file, that's another story
>
Re: [arch-general] New vi/vim/gvim in testing requires intervention
2009/5/6 Frédéric Perrin :
> I have a system whose users' real names can't be written in ASCII, and
> this being the 21st century, not the 70's, I have the real name (with
> accents) in the GECOS field in /etc/passwd. Not being a vi{,m} user, I
> just have whatever the default package for vi is installed.
$ grep http /etc/passwd | cut -d: -f5
$ usermod -c éøß http
$ grep http /etc/passwd | cut -d: -f5
éøß
Editing the passwd file by hand seems a little odd to me.
Still, if vi crashes when opening a non ASCII file, that's another story
Re: [arch-general] New vi/vim/gvim in testing requires intervention
Hi, that can be done, sure, however I don't like the idea of having an extra package conflict with a core one. We could name the package nvi, call the binaries nvi and provide a symlink that gets replace on installing vim but all this symlinking stuff has proved itself to be error prone. - T Quoting Aaron Griffin : On Tue, May 5, 2009 at 12:49 PM, Thomas Bohn wrote: On 2009-05-05 19:20 +0200, tob...@justdreams.de wrote: the current vi package is actually nvi, the purpose of that was to have a smaller package for core that also would not stall any updates of vim/gvim while vi sits in testing. I know that. That is why I'm asking. Either nvi or Vim. Both makes it complex. Th vim package is not uglier then it used to be before, Actually, I don't see a big problem with vim having provides/conflicts with vi, so that it will completely supplant it. That way we also cover the users who USE and EXPECT 'vim' but still type 'vi' (sigh)
Re: [arch-general] New vi/vim/gvim in testing requires intervention
Le Mercredi 6 à 13:07, Jan de Groot a écrit :
> On Wed, 2009-05-06 at 07:54 -0300, André Ramaciotti wrote:
>> Just a question about this new vi package. Am I the only one having
>> problems when openning UTF-8 files? I can't even type words with
>> diacritics or vi will abort. For example, try to create a file with
>> the following and then open it with the new vi package:
>>
>> This line will render fine
>> Mas essa aqui não ("but this one won't" in Portuguese).
>
> [...]
>
> If you want support for non-ASCII charsets and other things offered by
> vim, just install vim.
I have a system whose users' real names can't be written in ASCII, and
this being the 21st century, not the 70's, I have the real name (with
accents) in the GECOS field in /etc/passwd. Not being a vi{,m} user, I
just have whatever the default package for vi is installed.
Then for whatever reason, /etc/passwd is b0rked, and I have to boot into
single usermode to repair that, and all I can use is vi. vi crashes when
I open /etc/passwd. Now what ? Or, $config_file has comments in my native
language, and vi crashes when I open it.
FreeBSD's vi (actually nvi) can't manage non-ASCII characters, but at
least it doesn't crash.
(Actually :
1. I'm an emacs user, so I would use emacs ;-p ;
2. cut -d: -f -4,6- < /etc/passwd > /etc/passwd.no-real)
--
Fred
Re: [arch-general] New vi/vim/gvim in testing requires intervention
> cover the users who USE and EXPECT 'vim' but still type 'vi' (sigh) couldn't we suggest them to make an alias ?
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Tue, May 5, 2009 at 12:49 PM, Thomas Bohn wrote: > On 2009-05-05 19:20 +0200, tob...@justdreams.de wrote: > >> the current vi package is actually nvi, the purpose of that was to have a >> smaller package for core that also would not stall any updates of >> vim/gvim while vi sits in testing. > > I know that. That is why I'm asking. Either nvi or Vim. Both makes it > complex. > >> Th vim package is not uglier then it used to be before, Actually, I don't see a big problem with vim having provides/conflicts with vi, so that it will completely supplant it. That way we also cover the users who USE and EXPECT 'vim' but still type 'vi' (sigh)
Re: [arch-general] New vi/vim/gvim in testing requires intervention
I was thinking more about the installation/recuperation process than
the daily usage, because it's not always possible to install vim in
such cases. That's why I was questioning only vi being in [core],
though having vim in [core] would add lots of dependencies, so I guess
it's better the way it is. Especially if other distros are using the
same vi package, and still there is nano.
On Wed, May 6, 2009 at 8:07 AM, Jan de Groot wrote:
> On Wed, 2009-05-06 at 07:54 -0300, André Ramaciotti wrote:
>> Hi,
>>
>> Just a question about this new vi package. Am I the only one having
>> problems when openning UTF-8 files? I can't even type words with
>> diacritics or vi will abort. For example, try to create a file with
>> the following and then open it with the new vi package:
>>
>> This line will render fine
>> Mas essa aqui não ("but this one won't" in Portuguese).
>>
>> I know that config files from Arch don't have diacritics, but I don't
>> think that putting this vi package in core will be a good idea.
>>
>> (The new vim package is working fine, though.)
>
> vi is just a bare editor which has its limits. One of them is not being
> able to use the cursor keys while you're in insert mode for example.
> This issue is known on many platforms: other linux distributions,
> FreeBSD, OpenBSD, etc. They all have nvi or some other vi clone in the
> base system.
> If you want support for non-ASCII charsets and other things offered by
> vim, just install vim.
>
>
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Wed, 2009-05-06 at 07:54 -0300, André Ramaciotti wrote:
> Hi,
>
> Just a question about this new vi package. Am I the only one having
> problems when openning UTF-8 files? I can't even type words with
> diacritics or vi will abort. For example, try to create a file with
> the following and then open it with the new vi package:
>
> This line will render fine
> Mas essa aqui não ("but this one won't" in Portuguese).
>
> I know that config files from Arch don't have diacritics, but I don't
> think that putting this vi package in core will be a good idea.
>
> (The new vim package is working fine, though.)
vi is just a bare editor which has its limits. One of them is not being
able to use the cursor keys while you're in insert mode for example.
This issue is known on many platforms: other linux distributions,
FreeBSD, OpenBSD, etc. They all have nvi or some other vi clone in the
base system.
If you want support for non-ASCII charsets and other things offered by
vim, just install vim.
Re: [arch-general] New vi/vim/gvim in testing requires intervention
Hi,
Just a question about this new vi package. Am I the only one having
problems when openning UTF-8 files? I can't even type words with
diacritics or vi will abort. For example, try to create a file with
the following and then open it with the new vi package:
This line will render fine
Mas essa aqui não ("but this one won't" in Portuguese).
I know that config files from Arch don't have diacritics, but I don't
think that putting this vi package in core will be a good idea.
(The new vim package is working fine, though.)
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Tue, May 5, 2009 at 12:20 PM, wrote: > the current vi package is actually nvi, the purpose of that was to have a > smaller package for core that also would not stall any updates of vim/gvim > while vi sits in testing. > > Th vim package is not uglier then it used to be before, actually it's less > complex now because I don['t have to cater towards three different package > from the same source that all depend on each otherl. It's down to two > packages now vim and gvim :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: vim-bufexplorer: requires vi>=7.0 Can you rebuild anything that depends on the vi version please? This looks like it really should depend on vim. -Dan
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On 2009-05-05 19:20 +0200, tob...@justdreams.de wrote: > the current vi package is actually nvi, the purpose of that was to have a > smaller package for core that also would not stall any updates of > vim/gvim while vi sits in testing. I know that. That is why I'm asking. Either nvi or Vim. Both makes it complex. > Th vim package is not uglier then it used to be before, Well before was extremely ugly with this three different packages and a Vim wich didn't react like one, at least until someone found out that it needed .virc. Thomas
Re: [arch-general] New vi/vim/gvim in testing requires intervention
the current vi package is actually nvi, the purpose of that was to have a smaller package for core that also would not stall any updates of vim/gvim while vi sits in testing. Th vim package is not uglier then it used to be before, actually it's less complex now because I don['t have to cater towards three different package from the same source that all depend on each otherl. It's down to two packages now vim and gvim -T Quoting Thomas Bohn : On 2009-05-05 00:22 -0700, Tobias Kieslich wrote: Finally, the new vi* packages are up. Why not letting Vim replace nvi entirely, the Vim package looks kinda ugly now. Thomas
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On 2009-05-05 00:22 -0700, Tobias Kieslich wrote: > Finally, the new vi* packages are up. Why not letting Vim replace nvi entirely, the Vim package looks kinda ugly now. Thomas
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Tue, 05 May 2009, bs wrote:
>
> hello,
> as a linux newbie i am a little confused about the "sudo rm
> /usr/bin/{view/rview}" command. typing it with the "{}"s does not
> work, file or directory not found. am i supposed to delete
> /usr/bin/view (which is a link)? i am probably missing something very
> obvious, but before i mess up my system i rather ask.
Hi,
yeah as the others pointed out, that was a typo on my part, sorry.
And of cause Jan beat me with shorten it up even further :P
I'll go and fix the news.
-T
Re: [arch-general] New vi/vim/gvim in testing requires intervention
Yay, thanks.
-AT
On Tue, May 5, 2009 at 9:18 AM, Magnus Therning wrote:
> On Tue, May 5, 2009 at 2:11 PM, bs wrote:
>> On Tue, May 5, 2009 at 9:22 AM, Tobias Kieslich wrote:
>>> Hi,
>>>
>>> Finally, the new vi* packages are up. There will be a little migration
>>> pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}"
>>> before you run "sudo pacman -Syu"
>>>
>>>-T
>>>
>>
>> hello,
>> as a linux newbie i am a little confused about the "sudo rm
>> /usr/bin/{view/rview}" command. typing it with the "{}"s does not
>> work, file or directory not found. am i supposed to delete
>> /usr/bin/view (which is a link)? i am probably missing something very
>> obvious, but before i mess up my system i rather ask.
>
> I think it would have been better to write in proper shell syntax,
> which would be "sudo rm /usr/bin/{view,rview}". The equivalent
> command, without the {} is "sudo rm /usr/bin/view /usr/bin/rview", by
> using the {} you let the shell do the expansion, and you save a few
> keystrokes. :-)
>
> /M
>
> --
> Magnus Therning(OpenPGP: 0xAB4DFBA4)
> magnus＠therning．org Jabber: magnus＠therning．org
> http://therning.org/magnus identi.ca|twitter: magthe
>
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Tue, May 5, 2009 at 2:11 PM, bs wrote:
> On Tue, May 5, 2009 at 9:22 AM, Tobias Kieslich wrote:
>> Hi,
>>
>> Finally, the new vi* packages are up. There will be a little migration
>> pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}"
>> before you run "sudo pacman -Syu"
>>
>> -T
>>
>
> hello,
> as a linux newbie i am a little confused about the "sudo rm
> /usr/bin/{view/rview}" command. typing it with the "{}"s does not
> work, file or directory not found. am i supposed to delete
> /usr/bin/view (which is a link)? i am probably missing something very
> obvious, but before i mess up my system i rather ask.
I think it would have been better to write in proper shell syntax,
which would be "sudo rm /usr/bin/{view,rview}". The equivalent
command, without the {} is "sudo rm /usr/bin/view /usr/bin/rview", by
using the {} you let the shell do the expansion, and you save a few
keystrokes. :-)
/M
--
Magnus Therning(OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Tue, 2009-05-05 at 15:11 +0200, bs wrote:
> On Tue, May 5, 2009 at 9:22 AM, Tobias Kieslich wrote:
> > Hi,
> >
> > Finally, the new vi* packages are up. There will be a little migration
> > pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}"
> > before you run "sudo pacman -Syu"
> >
> >-T
> >
>
> hello,
> as a linux newbie i am a little confused about the "sudo rm
> /usr/bin/{view/rview}" command. typing it with the "{}"s does not
> work, file or directory not found. am i supposed to delete
> /usr/bin/view (which is a link)? i am probably missing something very
> obvious, but before i mess up my system i rather ask.
It shouldn't be {view/rview}, but {view,rview} or even {r,}view.
Re: [arch-general] New vi/vim/gvim in testing requires intervention
On Tue, May 5, 2009 at 9:22 AM, Tobias Kieslich wrote:
> Hi,
>
> Finally, the new vi* packages are up. There will be a little migration
> pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}"
> before you run "sudo pacman -Syu"
>
> -T
>
hello,
as a linux newbie i am a little confused about the "sudo rm
/usr/bin/{view/rview}" command. typing it with the "{}"s does not
work, file or directory not found. am i supposed to delete
/usr/bin/view (which is a link)? i am probably missing something very
obvious, but before i mess up my system i rather ask.
[arch-general] New vi/vim/gvim in testing requires intervention
Hi,
Finally, the new vi* packages are up. There will be a little migration
pain. For optimal results, I recommend to "sudo rm /usr/bin/{view/rview}"
before you run "sudo pacman -Syu"
-T
