vim is compiled without python support
i compile vim from source on a daily basis, lately i encounter an issue, when
vim is not compiled with python support.
$ vim --version
...
+python/dyn
+python3/dyn
...
The build process i follow, is this one
https://github.com/Valloric/YouCompleteMe/wiki/Building-Vim-from-source
i do set python configuration directory for both (python2.7 and python) like so:
$ ./configure --with-features=huge \
--enable-multibyte \
--enable-rubyinterp \
--enable-pythoninterp\
--with-python-config-dir=/usr/lib/python2.7/config-i386-linux-gnu
\
--enable-python3interp \
--with-python3-config-dir=/usr/lib/python3.5/config-3.5m-i386-linux-gnu
\
--enable-perlinterp \
--enable-luainterp \
--enable-gui=gtk2 \
--enable-cscope \
--prefix=/usr
i'am using linux, python-dev and python3-dev are installed,
:echo has('python') return 0
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Extremely slow when using relativenumber & syntax highlighting
On an unrelated note, you may want to consider setting synmaxcol to a reasonable value as that can drastically improve performance if you regularly deal with very long lines (with syntax highlighting enabled for the current buffer). ~Adam~ -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Add Apache's ProxyPassMatch keyword to apache.vim
Thanks, will do. Adam On Tue, Feb 25, 2014 at 5:09 AM, Bram Moolenaar wrote: > > Adam Matan wrote: > > > Apache's ProxyPassMatch directive > > (http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassmatch) > > is not recognised as a keyword in vim. > > I've added the directive to apache's syntax file and attached the > > diff. It is my first contribution to vim, so please let me know if the > > diff format is correct. > > The maintainer for that file is in the header. Please send the patch to > him. > > -- > ARTHUR:I command you as King of the Britons to stand aside! > BLACK KNIGHT: I move for no man. > The Quest for the Holy Grail (Monty > Python) > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net > \\\ > ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/\\\ > \\\ an exciting new programming language -- http://www.Zimbu.org > /// > \\\help me help AIDS victims -- http://ICCF-Holland.org > /// > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Add Apache's ProxyPassMatch keyword to apache.vim
Hi, Apache's ProxyPassMatch directive (http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassmatch) is not recognised as a keyword in vim. I've added the directive to apache's syntax file and attached the diff. It is my first contribution to vim, so please let me know if the diff format is correct. Best, Adam Matan Problem:Vim Apache syntax lacks the ProxyPassMatch keyword Solution: Add ProxyPassMatch to apache.vim Files: vim/runtime/syntax/apache.vim --- a/runtime/syntax/apache.vim Mon Feb 24 03:32:00 2014 +0100 +++ b/runtime/syntax/apache.vim Mon Feb 24 11:29:09 2014 +0200 @@ -157,7 +157,7 @@ syn keyword apacheDeclaration PerlFreshRestart PerlSendHeader syn keyword apacheDeclaration php_value php_flag php_admin_value php_admin_flag syn match apacheSection "<\/\=\(Proxy\|ProxyMatch\)[^>]*>" contains=apacheAnything -syn keyword apacheDeclaration AllowCONNECT NoProxy ProxyBadHeader ProxyBlock ProxyDomain ProxyErrorOverride ProxyIOBufferSize ProxyMaxForwards ProxyPass ProxyPassReverse ProxyPassReverseCookieDomain ProxyPassReverseCookiePath ProxyPreserveHost ProxyReceiveBufferSize ProxyRemote ProxyRemoteMatch ProxyRequests ProxyTimeout ProxyVia +syn keyword apacheDeclaration AllowCONNECT NoProxy ProxyBadHeader ProxyBlock ProxyDomain ProxyErrorOverride ProxyIOBufferSize ProxyMaxForwards ProxyPass ProxyPassMatch ProxyPassReverse ProxyPassReverseCookieDomain ProxyPassReverseCookiePath ProxyPreserveHost ProxyReceiveBufferSize ProxyRemote ProxyRemoteMatch ProxyRequests ProxyTimeout ProxyVia syn keyword apacheDeclaration RewriteBase RewriteCond RewriteEngine RewriteLock RewriteLog RewriteLogLevel RewriteMap RewriteOptions RewriteRule syn keyword apacheOption inherit syn keyword apacheDeclaration BrowserMatch BrowserMatchNoCase SetEnvIf SetEnvIfNoCase -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. diff -r 10d35c8b50e3 runtime/syntax/apache.vim --- a/runtime/syntax/apache.vim Mon Feb 24 03:32:00 2014 +0100 +++ b/runtime/syntax/apache.vim Mon Feb 24 11:32:28 2014 +0200 @@ -157,7 +157,7 @@ syn keyword apacheDeclaration PerlFreshRestart PerlSendHeader syn keyword apacheDeclaration php_value php_flag php_admin_value php_admin_flag syn match apacheSection "<\/\=\(Proxy\|ProxyMatch\)[^>]*>" contains=apacheAnything -syn keyword apacheDeclaration AllowCONNECT NoProxy ProxyBadHeader ProxyBlock ProxyDomain ProxyErrorOverride ProxyIOBufferSize ProxyMaxForwards ProxyPass ProxyPassReverse ProxyPassReverseCookieDomain ProxyPassReverseCookiePath ProxyPreserveHost ProxyReceiveBufferSize ProxyRemote ProxyRemoteMatch ProxyRequests ProxyTimeout ProxyVia +syn keyword apacheDeclaration AllowCONNECT NoProxy ProxyBadHeader ProxyBlock ProxyDomain ProxyErrorOverride ProxyIOBufferSize ProxyMaxForwards ProxyPass ProxyPassMatch ProxyPassReverse ProxyPassReverseCookieDomain ProxyPassReverseCookiePath ProxyPreserveHost ProxyReceiveBufferSize ProxyRemote ProxyRemoteMatch ProxyRequests ProxyTimeout ProxyVia syn keyword apacheDeclaration RewriteBase RewriteCond RewriteEngine RewriteLock RewriteLog RewriteLogLevel RewriteMap RewriteOptions RewriteRule syn keyword apacheOption inherit syn keyword apacheDeclaration BrowserMatch BrowserMatchNoCase SetEnvIf SetEnvIfNoCase <>
Re: [RFC] Revision of Objective-C Syntax
On 24 January 2014 13:53, Adam Sharp wrote: > I'm fairly new to vim so I'm prepared to concede I may have stuffed something > up—just wanted to report that I downloaded the latest version from this > thread and added it to ~/.vim/autoload/ [...] So it turns it I was doing it wrong: after moving the file into ~/.vim/syntax and running it through dos2unix, it started working. No more red braces. If I do find any issues, is this still the right place to report them? –Adam -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [RFC] Revision of Objective-C Syntax
On Sunday, 9 June 2013 23:39:53 UTC+10, Kazunobu Kuriyama wrote:
> Attached is the latest draft of syntax/objc.vim, in which the bug, kindly
> reported by Christian Wellenbrock, is fixed:
>
> On Jun 5, 2013, at 3:41 AM, Christian Wellenbrock wrote:
> >
>
> > Yes the update fixed the problems. You saved it with Windows line endings
> > again though. While we're at it, there are still red braces in other
> > methods (that are red with the current syntax file as well). See the
> > screenshot [1] of the code [2]. Maybe you can fix those too?
>
> >
>
> > [1] http://i.imgur.com/kYXunaD.png
>
> > [2]
> > https://github.com/AFNetworking/AFNetworking/blob/master/AFNetworking/AFURLConnectionOperation.m#L198-L207
>
> Now, all the reported bugs have been fixed.
I'm fairly new to vim so I'm prepared to concede I may have stuffed something
up—just wanted to report that I downloaded the latest version from this thread
and added it to ~/.vim/autoload/, but I still seem get red braces for blocks
passed to functions, e.g.:
dispatch_async(queue, ^{
// code
});
or in a Kiwi spec:
describe(@"testing", ^{
it(@"is awesome", ^{
// ...
});
});
Am I missing something?
Thanks,
Adam
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Markdown syntax script using the new conceal feature
Awesome, Peter! Did this ever make it upstream? I've been a big fan of conceal with other languages (HTML, LaTeX), it would be great to get this patched into Vim proper. -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Race condition..., once again
Adam Osuchowski wrote:
> fd = open("file");
> read(fd, buffer, size);
> close(fd);
> copy("file", "file~");
> [...here user edits file...]
> fd = open("file.tmp", O_WRONLY|O_CREAT|O_TRUNC);
> write(fd, "new content of file");
> close(fd);
> chmod("file.swp", mode);
> chown("file.swp", owner, group);
> [...if need be, setting other parameters like ACLs...]
> rename("file.swp", "file");
Sure, it's my mistake, it should be file.tmp not file.swp:
fd = open("file");
read(fd, buffer, size);
close(fd);
copy("file", "file~");
[...here user edits file...]
fd = open("file.tmp", O_WRONLY|O_CREAT|O_TRUNC);
write(fd, "new content of file");
close(fd);
chmod("file.tmp", mode);
chown("file.tmp", owner, group);
[...if need be, setting other parameters like ACLs...]
rename("file.tmp", "file");
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Re: Race condition..., once again
Bram Moolenaar wrote:
> > rename() would behave identically and moreover would be atomic.
>
> It appears you don't have 'backupcopy' set, as was recommended in the
> thread you quote.
I thought about rename temporary file to target one and backupcopy doesn't
change it. Below, strace of command with backupcopy set:
17518 execve("/usr/bin/vim", ["vim", "+set backupcopy=yes", "testfile"], [/* 49
vars */]) = 0
[...]
17518 open("testfile", O_WRONLY|O_CREAT|O_TRUNC, 0600) = 3
17518 write(3, "test test test something else\n"..., 30) = 30
17518 fsync(3) = 0
17518 close(3) = 0
17518 chmod("testfile", 0100600)= 0
As you can see, vim opens edited file with O_TRUNC, so it is truncated
for non-zero time. No matter what I set, backupcopy=yes or backupcopy=no,
above mentioned fragment is exactly the same. backupcopy has influence
only on creating another inode or writing to the same one:
> > So, I have a little request to developers. Please, read it again and try
> > to understand me. Atomic rename() is better solution. It's not so stupid
> > as it may appear at first look and shouldn't break to much. :-)
>
> I'm afraid that it will break much. Especially when not on a Unix
> system.
I thought only about unix. I don't know how vim behave on other systems,
but on unix it could behave better. I don't want you to change it on all
systems (because I am aware that something may be broken because of that),
but only on unix (in principle on POSIX).
> The problem is that using rename() is not atomic, because we need two
> of them.
One rename() is always atomic and changing from temporary file to target
file should be atomic, what I expect vim to do:
rename("test.tmp", "test");
Of course, ale the process of saving file (preparing temporary files,
making backup file, cleaning up, etc.) can't be atomic, but exchanging
target (edited) file could be atomic by means of rename().
> And the procedure to write a new file and then rename
> again has the problem that the inode changes, which is bad for hard
> links and complex ACL.
I wrote about hard links, and I agree that rename() may break it.
Files with number of hard links greater then one should be treated
individually.
As to ACLs, if vim can change standard unix mode, owner and group (e.g.
with backupcopy=no), why it couldn't change POSIX extended attributes,
ACLs, etc.?
> The only solution is overwriting the file. Currently it's first made
> empty. It would be possible to first write the new contents and then
> truncate to remove any remaining old text. But that's worse: halfway
> writing you have an inconsistent file, at some place it switches from
> the new text to the old text. I rather have a truncated file, that's
> less problematic.
>
> In case we rename the file to make a backup, it would be possible to
> first write the new file and then use two rename calls to swap the old
> and new files. Again, if another process is using the file, it will
> suddenly see different text. And on Unix, if the file was opened by
> another process, it will keep on using the old version. This only
> solves a few very specific situations.
I don't expect vim to rename edited file to backup file. Rather, it should
be copied. All the operations would be done on temporary file and during
saving, temporary file should be filled with new content, set with right
permissions, ACLs, owner, group, etc. and finally, should be atomically
renamed to target file. From another process point of view (which only
read this file), its contents changes atomically and there is no time
when file was broken, truncated or half written. In meta-code it could
look like this:
fd = open("file");
read(fd, buffer, size);
close(fd);
copy("file", "file~");
[...here user edits file...]
fd = open("file.tmp", O_WRONLY|O_CREAT|O_TRUNC);
write(fd, "new content of file");
close(fd);
chmod("file.swp", mode);
chown("file.swp", owner, group);
[...if need be, setting other parameters like ACLs...]
rename("file.swp", "file");
Of course, file content and inode attributes could be changed between
reading it's content and final rename(), but this situation is not resolvable
on standard POSIX file system semantic. However, this behaviour secures
other processes, which only read (not write), against incorrect content.
Regards.
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Race condition..., once again
Some time ago I wrote here about race condition during file saving (http://groups.google.com/group/vim_dev/tree/browse_frm/month/2009-01/0049693b73a6a1e6). Some of you didn't share my opinion about this problem and said "File systems is not databases with ACID properties". Ok, I agree and know it is rather POSIX semantic's fault. But my case has come back to me. In that thread, I suggested that rename() syscall should improve bahaviour beacuse of atomical nature of this syscall. One of argument against using rename() was that it would break hard and soft links. In soft links case, I can't imagine how rename() could break it. If process atomically exchange file which is pointed to by symlink, nothing will break down. Even, if it is chain of symlinks. In hard links case, really there is a problem, and this case should be treated individually (fortunately, hardlinks are rather relatively rare case). But in other cases, rename() should be safe. Furthermore, even now, vim changes inode of edited file: # ls -li testfile 2955134269 -rw--- 1 root root 15 Jan 25 22:44 testfile # vim testfile [...edit file here...] # ls -li testfile 2955134271 -rw--- 1 root root 20 Jan 25 22:44 testfile rename() would behave identically and moreover would be atomic. So, I have a little request to developers. Please, read it again and try to understand me. Atomic rename() is better solution. It's not so stupid as it may appear at first look and shouldn't break to much. :-) Regards. -- You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php
stop directory bug in findfile()
I think there's a bug in the stop-directory behavior of
findfile()/finddir(). Everything after the last slash in the stop
directory is ignored. For example:
:echo findfile('foo.txt', '/tmp/vim/a/b/c/d;/tmp/vim/a/b')
/tmp/vim/a/foo.txt
:echo findfile('foo.txt', '/tmp/vim/a/b/c/d;/tmp/vim/a/b/')
I think the problem is in ff_path_in_stoplist(),
on line 5307 of src/misc2.c:
if (fnamecmp(stopdirs_v[i], path) == 0)
It looks like this should be:
if (fnamencmp(stopdirs_v[i], path, path_len) == 0)
--
Adam Simpkins
simpk...@facebook.com
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Tabbing in VisVim
Hi all, I just put together a small patch to add tab support to VisVim. Enjoy! -- Adam Slater --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- VisVim.diff Description: Binary data
One more thought about vim race condition during file saving
Did you think about use leases to exclusively lock file during save? I mean fcntl() with F_SETLEASE. It acquires mandatory lock and doesn't break hard links, which you afraid of. Processes which try to read file during saving are blocked on open() until lease is removed, so it doesn't change behaviour from other processes' point of view. On the other hand, it is not possible to obtain write lease on file already opened by another process, and in such a situation (which IMHO shouldn't happen often with files which are edited by hand) vim should retry acquiring lease after short sleep or fallback to current behaviour. This method was originally developed for use in samba, but it is available in Linux kernel since 2002 (or even earlier), so it could be said that it is standard. Certainly, it is Linux specific feature, but if it is available, why shouldn't it be used. Any pros or cons? Regards. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Race condition during file saving
Charles E. Campbell, Jr. wrote: > Likely areas for problems like this concern cooperative editing (ie. > multiple people editing the same file) and editing log files (or other > files which are potentially being written to by some other program). > Vim isn't designed for cooperative editing; I seem to recall it being on > a wishlist, though. Editing log files is problematic because they > generally aren't using mandatory file locking. I didn't tell about multiple people editing the same file or editing log files. I told about _ONE_ person editing file which could be read by another process at the same time. Isn't vim designed for it too? Don't think so. > To avoid the need for cooperative editing, use cvs/git/etc and use separate > copies and repositories. And keep all /etc files in cvs repo? It's only pinning the blame on another application (cvs, in this case). --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Race condition during file saving
Nikolai Weibull wrote: > Either way, I really don't think we have a problem to fix. So what is your advice? Ignore it? It's very comfortable to call flows features, we have perfect situation and don't need to worry about consequences. > If you're writing to a file that another program critically needs > /that's/ your problem. Configuration file, for example, is critically for almost every daemon. Do you think that it is only my problem? No, it is very real scenario which could happen to everyone who use vim. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Race condition during file saving
Nikolai Weibull wrote: > I haven't really understood what the problem is (I don't believe that > there actually is one), There is a non-zero time period between open file and write complete content. Because vim truncate file while opening (O_TRUNC), another process which would like to read it can hit in the moment when file will be empty. > but would opening the file exclusively solve the problem? Do you mean O_EXCL flag to open syscall? It doesn't protect against such a situation. It only guarantee that file doesn't exist prior to call open in atomic manner. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Race condition during file saving
Bram Moolenaar wrote:
> That's all taken care of when 'backupcopy' is "auto". If you want the
> original file to always exist set 'backupcopy' to "yes". Saving files
> will be slower then, since Vim needs to both write a copy and write the
> actual file.
Not quite. Of course, with 'backupcopy' set to "yes", there are not
moment when another process find file missing, but still file may be empty
or not completely written:
open("testfile", O_WRONLY|O_CREAT|O_TRUNC, 0600) = 3
write(3, "test test test\n"..., 15) = 15
fsync(3) = 0
close(3) = 0
> Since you are overwriting the file there always is a moment it's empty.
Unless use of rename() syscall, which replace it atomically (with exact
to hard link cases).
I know, that these problems result from flawed POSIX file system syscalls
behaviour, but IMHO it may be made better than it is done now.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Race condition during file saving
Matt Wozniski wrote: > rename(2) doesn't do everything needed. Right, but current behaviour is even worse. We can't protect if somebody create file while vim saves it due to system limitations, but we can protect against completely lack of file or situation when it is partially written. > rename() would break the link, which probably isn't what you want an > editor to do... Right, but definitely there are fewer multi hard linked files than singles. Again, we can't protect against such situation because of POSIX syscalls nature, so maybe vim should identify if there is hard link and unless, it will do atomic file replacement. I know, there is another race condition (between stat() and rename()) but it is more unlikely case. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Race condition during file saving
Tony Mechelynck wrote: > I don't know. There're only one keyboard and one display on this > machine, and I try to avoid having several programs modify a single file > simultaneously outside each other's knowledge. The rare case is > /var/spool/mail/root which is appended to by my cron jobs, and truncated > by SeaMonkey after "downloading" the mail to its own mailbox in its > profile. Vim doesn't intervene there. > > Vim will try to detect when its editfile has been modified by another > program, but it is not meant to be used in an environment where anything > can be modified simultaneously by any number of actors. If something > goes wrong, you can try to |recover|. Cases like mbox files are not so rare. There are many examples of simultaneously access to single file, but problem exists even without concurrent modification. A simple example: editing config file for some daemon. When vim truncates this file and program read it at the same time (because, for example, it will be restarted by cron, other administrator or even by itself) it will be problematic situation. The same matter is if a program will be run from cron or other program (for example, procmail from sendmail). Recover option in vim does not help here. Do you suggest turn off all processes during editing config files? Vim is used on multiuser and multiprocess systems, so limiting the working users or simultaneously processes to single one is misunderstanding. Why do you disrespect problem, especially if there is solution in the form of proper use of rename(2) syscall, which I mentioned about? --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Race condition during file saving
Tony Mechelynck wrote:
> See
> :help backup
> :help 'backup'
> :help 'writebackup'
> :help 'backupcopy'
> :help timestamp
I try different settings of this variables and there was always the same
situation:
open("testfile", O_WRONLY|O_CREAT|O_TRUNC, 0600) = 3
write(3, "test test test\n"..., 15) = 15
So, still there are points in time when file could be empty (after opening
with O_TRUNC) or partially written (between multiple write syscalls).
Could you give me a concrete example of values of these settings, which
could prevent such situations?
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Race condition during file saving
There is a race condition in vim 7.2 (and probably in earlier too) on POSIX
platforms. Below, there is fragment of strace output related to this problem.
stat64("testfile~", 0xbfc35dbc) = -1 ENOENT (No such file or directory)
stat64("testfile", {st_mode=S_IFREG|0600, st_size=12, ...}) = 0
unlink("testfile~") = -1 ENOENT (No such file or directory)
rename("testfile", "testfile~") = 0
open("testfile", O_WRONLY|O_CREAT|O_TRUNC, 0600) = 3
write(3, "test test test\n"..., 15) = 15
fsync(3)= 0
stat64("testfile", {st_mode=S_IFREG|0600, st_size=15, ...}) = 0
stat64("testfile", {st_mode=S_IFREG|0600, st_size=15, ...}) = 0
close(3)= 0
Problematic situation take place during file saving between rename and open,
open and write as well as write and close syscalls. There are points at
which another process attempting to access file may run into trouble.
There is, for example, possibility to:
- if application, which expects existence of file, would try to open it
between vim rename and open syscalls, it will fail due to lack of this
file,
- if other process creates file with the same name between vim rename and
open syscalls, it will be overriden by vim (it works with symlinks too,
so it can be used by attacker to damage other files),
- if application will read file while vim will write to it, the contents
may be badly read due to temporarily partially record.
Vim rather should create new, its own, temporary file with unique name,
write content, close it and then, atomically rename it to original name.
Regards.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Vim 7.2a in CVS
On Thu, Jun 26, 2008 at 12:05:04AM +0200, Bram Moolenaar wrote: > > you'll get a tar.gz matching a particular commit or a tag (yellow > > boxes, useful to track releases/milestones), or even experimental > > branches (in green) without ever had to install git, it even works > > with internet explorer... > > Getting a tar.gz archive is not the same as running "cvs update". Same > for using wget. One can always download the archives if you are willing > to start from scratch. Using git that way is not an improvement. I see git has a feature called cvsserver (git help cvsserver), should be helpful if you decide to switch to git. -- http://www.mysza.eu.org/ | Everybody needs someone sure, someone true, PLD Linux developer| Everybody needs some solid rock, I know I do. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim 7.2a in CVS
On Wed, Jun 25, 2008 at 05:54:36PM +0100, Mike Williams wrote: > > Can someone use Git without installing any software? If yes, then we > > might be able to replace other methods. If no, then lots of people will > > prefer to stay with what they already have installed. > > Windows users wanting to use Git for things other than getting snapshots > (e.g. patch development) it can be a pain - they need to install and set > up Cygwin. Last time I looked Windows support was the neglected child > for various philosophical and technical reasons. Using Git will raise > the barrier for Windows users. There's msysgit (http://code.google.com/p/msysgit/) which provides git (and git-gui) for Windows environment and does not depend on cygwin. I use it from time to time and am quite happy with it. -- http://www.mysza.eu.org/ | Everybody needs someone sure, someone true, PLD Linux developer| Everybody needs some solid rock, I know I do. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Cannot connect to ftp.vim.org or ftp.nluug.nl
On Fri, Feb 22, 2008 at 10:31 PM, Tony Mechelynck <[EMAIL PROTECTED]> wrote: > Can anyone check me? At the moment, trying to connect by FTP or rsync to > ftp.vim.org or ftp.nluug.nl doesn't succeed for me (i.e., times out). I'm seeing the same as well. Cheers Adam --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Athena GUI problem: menus
On 20/11/2007, Derek <[EMAIL PROTECTED]> wrote: > > Vim 7.1.157 built on FreeBSD 8.0 with Athena GUI has a menu problem. > Any menu only displays the first 2 items, although very rarely one can > get vim to display the whole menu. I haven't the faintest idea of > where to start looking for the problem. Building vim with Motif or > GTK2 has no problem with the menus. FreeBSD 8.0? 7.0 isn't out of beta yet! Cheers Adam --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Announcing Eeedit - Vim plug-in for Eclipse.
On Wed, Aug 29, 2007 at 01:37:08AM +1000, David Terei wrote: > This project is in its very early stages, so far Vim functions pretty much > as an external editor (although there's more then this going on behind the > scenes). You can however if you're lucky enough to be on Linux and using a > GTK2 build of Vim embed it into Eclipse. There is a patch under review by > Bram for enabling support for this under Windows. Hi. I tried to use this plugin, but what I get is externally launched vim (not embedded into eclipse), with an unhandled exception being thrown: - Trying to start vim Server started and listening Started vim Connection established AUTH changeme 0:version=0 "2.4" 0:startupDone=0 Exception in thread "Thread-2" java.lang.NullPointerException at org.eeedit.vimplugin.VimConnection$6.handleEvent(VimConnection.java:217) at org.eeedit.vimplugin.VimConnection.run(VimConnection.java:119) at java.lang.Thread.run(Thread.java:619) dispose() close( true ); - This is a `huge' gtk2 vim 7.0.241, built with +netbeans_ing feature enabled. I am using eclipse-3.2.2 here. Best regards, Adam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "vim_dev" group. To post to this group, send email to vim_dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/vim_dev?hl=en -~--~~~~--~~--~--~---
