Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
57 user(s) are online (48 user(s) are browsing Forums)

Members: 0
Guests: 57

more...
Support us!
Recent OS4 Files
OS4Depot.net



« 1 2 3 4 (5)


Re: VIM the editor
Home away from home
Joined:
2006/12/4 23:15
Posts: 2073
@kas1e

Hmm that's interesting.

the SetProtect() function is called during the filehandle / descriptor close call as far as I recall.

Which files get the wrong protection bits and how are they created / manipulated by the prgram?


_________________
Blender For OS4.x : Blues : Walker Broad
   Report Go to top

Re: VIM the editor
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5192
@broadblues
Quote:

Which files get the wrong protection bits and how are they created / manipulated by the prgram?


It is swap files created by VIM when you editing main file. Swap files start with "." and ends with .swp.

Vim sources pretty big ones, so i can be wrong, but as far as i can see logic for creating/closing of swap files , they just use open()/close() calls.

At least in the https://github.com/vim/vim/blob/master/src/memfile.c

I can see:

Open swap file:

/*
 * Open a swap file for a memfile.
 * The "fname" must be in allocated memory, and is consumed (also when an
 * error occurs).
 */
    
static void
mf_do_open
(
    
memfile_T    *mfp,
    
char_u    *fname,
    
int        flags)        /* flags for open() */
{
#ifdef HAVE_LSTAT
    
stat_T    sb;
#endif

    
mfp->mf_fname fname;

    
/*
     * Get the full path name before the open, because this is
     * not possible after the open on the Amiga.
     * fname cannot be NameBuff, because it must have been allocated.
     */
    
mf_set_ffname(mfp);
#if defined(MSWIN)
    /*
     * A ":!cd e:xxx" may change the directory without us knowing, use the
     * full pathname always.  Careful: This frees fname!
     */
    
mf_fullname(mfp);
#endif

#ifdef HAVE_LSTAT
    /*
     * Extra security check: When creating a swap file it really shouldn't
     * exist yet.  If there is a symbolic link, this is most likely an attack.
     */
    
if ((flags O_CREAT) && mch_lstat((char *)mfp->mf_fname, &sb) >= 0)
    {
    
mfp->mf_fd = -1;
    
emsg(_("E300: Swap file already exists (symlink attack?)"));
    }
    else
#endif
    
{
    
/*
     * try to open the file
     */
    
flags |= O_EXTRA O_NOFOLLOW;
#ifdef MSWIN
    /* Prevent handle inheritance that cause problems with Cscope
     * (swap file may not be deleted if cscope connection was open after
     * the file) */
    
flags |= O_NOINHERIT;
#endif
    
mfp->mf_fd mch_open_rw((char *)mfp->mf_fnameflags);
    }

    
/*
     * If the file cannot be opened, use memory only
     */
    
if (mfp->mf_fd 0)
    {
    
VIM_CLEAR(mfp->mf_fname);
    
VIM_CLEAR(mfp->mf_ffname);
    }
    else
    {
#ifdef HAVE_FD_CLOEXEC
    
int fdflags fcntl(mfp->mf_fdF_GETFD);
    if (
fdflags >= && (fdflags FD_CLOEXEC) == 0)
        (
void)fcntl(mfp->mf_fdF_SETFDfdflags FD_CLOEXEC);
#endif
#if defined(HAVE_SELINUX) || defined(HAVE_SMACK)
    
mch_copy_sec(fnamemfp->mf_fname);
#endif
    
mch_hide(mfp->mf_fname);    /* try setting the 'hidden' flag */
    
}
}


There is used mch_open_rw() for actual opening, and this one is defined in macros.h , like this:

#define mch_open_rw(n, f) mch_open((n), (f), 0)

which in turn defined in the vim.h like this:

# define mch_open(n, m, p) open((n), (m), (p))

Close swap file looks like this:

/*
 * Close the swap file for a memfile.  Used when 'swapfile' is reset.
 */
    
void
mf_close_file
(
    
buf_T    *buf,
    
int        getlines)    /* get all lines into memory? */
{
    
memfile_T    *mfp;
    
linenr_T    lnum;

    
mfp buf->b_ml.ml_mfp;
    if (
mfp == NULL || mfp->mf_fd 0)        /* nothing to close */
    
return;

    if (
getlines)
    {
    
/* get all blocks in memory by accessing all lines (clumsy!) */
    
mf_dont_release TRUE;
    for (
lnum 1lnum <= buf->b_ml.ml_line_count; ++lnum)
        (
void)ml_get_buf(buflnumFALSE);
    
mf_dont_release FALSE;
    
/* TODO: should check if all blocks are really in core */
    
}

    if (
close(mfp->mf_fd) < 0)            /* close the file */
    
emsg(_(e_swapclose));
    
mfp->mf_fd = -1;

    if (
mfp->mf_fname != NULL)
    {
    
mch_remove(mfp->mf_fname);        /* delete the swap file */
    
VIM_CLEAR(mfp->mf_fname);
    
VIM_CLEAR(mfp->mf_ffname);
    }
}


and then mch_remove() it's just :

#define mch_remove(x) remove((const char *) x)


I do not know when bits exactly gots cleared.. Visually on closing : so i tried to comment out all "close" functions in that memfile.c which i link above and while when exit from VIM bits still cleared, when i operate with tabs , and close tabs (without exit from Vim), then bits start to be _not_ cleared.

Probabaly when VIM exit fully its doing something else, not only those "close" functions from memfile.c, but at least that commenting out those close functison make closing of tab in VIM not clear the bits , mean that its indeed related to close() things too.


Edited by kas1e on 2019/5/8 12:16:28
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: VIM the editor
Just popping in
Joined:
2017/5/18 10:12
From Audruicq, France
Posts: 28
Thank you for your work!

I modified the script by adding a assign to runtime like this
'assign >nil: vim: runtime'

Regards,

   Report Go to top

Re: VIM the editor
Not too shy to talk
Joined:
2008/3/15 2:00
From Alberta, Canada
Posts: 292
@kas1e
@sTix

Very nice indeed. I downloaded today to try her out.

Thanks to all involved with this project.

redfox

   Report Go to top

Re: VIM the editor
Just popping in
Joined:
2006/11/30 11:59
Posts: 19
@redfox

I've started to migrate the whole thing to GitHub. There's still some work left on the installer to make it work on all platforms but building it should work.

It would be great if there are people interested in becoming a collaborator / creating pull requests.

https://github.com/sodero/MUI-Vim

   Report Go to top

Re: VIM the editor
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5192
@sTix
Are you sure we need installers at all ? Classic "unpack&run" was always better, and all choice can be done from makefiles when pack lha ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: VIM the editor
Just popping in
Joined:
2006/11/30 11:59
Posts: 19
@kas1e

I think it's nice to have an installer. It makes it possible for the user to do choices after build time, choosing toolbar themes for example, handling .vimrc, perhaps installing plugins and so on. It also makes it possible to create a single archive for all platforms, without the user having to manually pick binaries.

Of course it's not strictly necessary, it's still possible to do an "unpack and run" installation for users who wish to do so. And I kind of like writing installers anyway ;)

   Report Go to top

Re: VIM the editor
Site Builder
Joined:
2006/12/2 23:57
From Athens
Posts: 467
Maybe a configuration app would be better for that. Think about it. The user makes a default installation really fast, and there is a configuration application that helps him enable/disable things through a GUI. This can be independent project as well.

   Report Go to top

Re: VIM the editor
Not too shy to talk
Joined:
2006/11/27 22:28
From Germany
Posts: 296
@kas1e

Quote:
@sTix Are you sure we need installers at all ? Classic "unpack&run" was always better, and all choice can be done from makefiles when pack lha ?


no installer please. unpack + copy folder to any destination.
what currently is not ok is the required assign. this needs to be removed. special assigns for applications should be forbidden.

regards...
michael

_________________
Michael Merkel
(Michael.Merkel@gmx.net Home)
Member of Amiga-Freunde Pfalz, OS4 Welt
   Report Go to top

Re: VIM the editor
Just can't stay away
Joined:
2009/5/1 17:57
From Czech Republic
Posts: 1024
@MichaelMerkel

Quote:
what currently is not ok is the required assign. this needs to be removed. special assigns for applications should be forbidden.

Yes, a special assign is rarely needed, PROGDIR: should cover it nicely for the majority of applications.

_________________
Smoke me a kipper, I'll be back for breakfast!

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
   Report Go to top

Re: VIM the editor
Just popping in
Joined:
2006/11/30 11:59
Posts: 19
@trixie

Indeed, it's just that "VIM:" is used by the part of Vim that I haven't touched (and have been for many many years) and I try to do as little patching as possible.

About the installer; like I said, having an installer doesn't make it impossible to not use it.

   Report Go to top

Re: VIM the editor
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5192
@sTix

With current installer there still will be problems for at least icons, which renamed with underscore at end, so unpack and run will fail a bit.

Anyway, if you doest mind, i can handle amigaos4 version easy, where we will have no installer at all (as seems everyone prefer it that way, and mason icons are default). For morphos and aros it can be used as before, so all happy. What you think ?

Also we can made ticket on github about "get rid of vim assign and replace all on progdir where need it". If you think is worth of :)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: VIM the editor
Just popping in
Joined:
2006/11/30 11:59
Posts: 19
@walkero

I'm not to keen on writing an application like that. The possible number of options would be infinite. This is Vim ;)

   Report Go to top

Re: VIM the editor
Just popping in
Joined:
2006/11/30 11:59
Posts: 19
@kas1e

Yes, it won't work as it is now. You could create an OS4 build target if you'd like to handle the OS4 icon / toolbar at build time.

Regarding "unpack and run": Does lha on OS4 handle symlinks? I might be doing something wrong here, but creating symlinks like evim -> vim (to start vim in simplified mode) doesn't seem to work on MorphOS.

What is the value of PROGDIR: when using symlinks?

   Report Go to top


« 1 2 3 4 (5)



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project