Complex path related issue

Vim writes back the edited file into the first directory in

Fri, 03 Dec 2010 15:12:04 +0100

Vim writes back the edited file into the first directory in the complex path. For example: TITAN2_ZAY $ cre/dir <.testdir.test_1> TITAN2_ZAY $ cre/dir <.testdir.test_2> TITAN2_ZAY $ cre/dir <.testdir.test_3> TITAN2_ZAY $ sh def USRDSK: TITAN2_ZAY $ def /nolog testdir USRDSK:,USRDSK:,USRDSK: TITAN2_ZAY $ sh log testdir "TESTDIR" = "USRDSK:" (LNM$PROCESS_TABLE) = "USRDSK:" = "USRDSK:" Create a file in the last directory of the complex path. TITAN2_ZAY $ dir testdir Directory USRDSK: TESTFILE.TXT;1 1 3-DEC-2010 15:03:25.38 Total of 1 file, 1 block. TITAN2_ZAY $ dir testdir:TESTFILE.TXT Directory USRDSK: TESTFILE.TXT;1 1 3-DEC-2010 15:03:25.38 Total of 1 file, 1 block. Edit file testdir:TESTFILE.TXT and save. The result is that Vim writes to the first directory of the complex path and not to the directory where the original file is found. TITAN2_ZAY $ dir testdir:TESTFILE.TXT Directory USRDSK: TESTFILE.TXT;1 1 3-DEC-2010 15:05:16.83 Total of 1 file, 1 block. Directory USRDSK: TESTFILE.TXT;1 1 3-DEC-2010 15:03:25.38 Total of 1 file, 1 block. Grand total of 2 directories, 2 files, 2 blocks. TITAN2_ZAY $ diff USRDSK:TESTFILE.TXT USRDSK:TESTFILE.TXT ************ File USRDSK:TESTFILE.TXT;1 1 111 ****** File USRDSK:TESTFILE.TXT;1 1 222111 ************ Number of difference sections found: 1 Number of difference records found: 1 DIFFERENCES /IGNORE=()/MERGED=1- USRDSK:TESTFILE.TXT;1- USRDSK:TESTFILE.TXT;1

This is really an issue; I will try to describe how I am dea

Mon, 06 Dec 2010 16:24:39 +0100

This is really an issue; I will try to describe how I am dealing with it: The natural workaround (from my point of view) was to introduce a BufReadPre auto-command, which would expand the path: 1) :edit testdir:TESTFILE.TXT 2) the BufReadPre autocommand kicks in, notices that the filename uses a rooted logical name, and instead of opening testdir:TESTFILE.TXT it translates the logical and opens USRDSK:TESTFILE.TXT 3) the write then behaves as expected Alas, this is not possible. An autocommand is not allowed (by vim) to change the name of the file to be opened (security reasons). --- Since the approach above did not work, I am now dealing with this with a BufRead (i.e. BufReadPost) autocommand: if has('vms') autocmd BufRead,BufWritePost * nested call ReopenFileIfNecessary() endif 1) :edit testdir:TESTFILE.TXT 2) vim opens testdir:TESTFILE.TXT 3) as a post-read action, vim calls ReopenFileIfNecessary(), which detects that a rooted logical (testdir) is used in the name, calls system("write sys$output f$search(\"testdir:TESTFILE.TXT\")") to translate this to USRDSK:TESTFILE.TXT and then opens this file immediately. The user doesn't even notice that testdir:TESTFILE.TXT was ever opened (the file only flashes there for a split second). However, it is really opened, and it stays in history. That is ugly: suppose I am past step 3, so I am editing file USRDSK:TESTFILE.TXT, and want to use Ctrl-O to go back to where I was in step 1. When I press Ctrl-O, I go back one step in history, i.e. to testdir:TESTFILE.TXT, at which point ReopenFileIfNecessary() is called and I "slide" back to step 3. (2Ctrl-O solves this, of course.) Additionally, it is ugly because I am not really opening testdir:TESTFILE.TXT as requested. --- Is the desired behaviour clear? If I edit testdir:TESTFILE.TXT (suppose the name of the file stays the same, i.e. I do NOT reopen the file using the physical path), is it clear that using :write should write a new version of the file in TEST_3?

I suppose the solution could be one of (or a combination of)

Wed, 29 Dec 2010 08:25:58 +0100

I suppose the solution could be one of (or a combination of) the following: ---------- 1) Opening the file It should be configurable whether, when editing testdir:TESTFILE.TXT, the file is opened as testdir:TESTFILE.TXT or as USRDSK:TESTFILE.TXT I personally would configure this to be always the latter (physical path), but perhaps someone would go for the former. Perhaps this should be a VMS-only feature of vim. It should also be possible to change this setting per file. For example, I may want to open all files using the physical path, except of FOO.TXT, where I want to use the logical path. I should be able to define an autocommand (BufReadPre FOO.TXT) that switches the setting to "logical" when opening FOO.TXT. (As described in comment #2, vim does not allow a BufReadPre autocommand to change the name of the file to be edited. I think that is a good security policy, and can be retained. This setting allows one kind of hole into this policy, but the hole is very reasonable and limited, so it should not present a security problem.) ---------- 2) Writing the file Again, it should be configurable, when the file is opened as testdir:TESTFILE.TXT i.e. using a logical path, how the writing behaves. I see 2 options: a) Copy to the first path to which testdir translates. As Zoltan described, this is how vim behaves currently. I think this is not functionally wrong, strictly speaking, but it can be annoying/surprising. In fact, this is similar to using VMS copy: when TESTFILE.TXT only exists in TEST_3, and we execute $ copy testdir:TESTFILE.TXT testdir:TESTFILE.TXT the file is copied to TEST_1. b) Copy over the current file. I suppose this is what Zoltan wants. The file should be replaced in TEST_3. Again, this should be configurable as a setting (perhaps global), but modifiable with an autocommand (per file). c) Copy over the first testdir:TESTFILE.TXT (?!). This is something to consider. For example, TESTFILE.TXT only exists in TEST_3. Zoltan opens it in vim. In the meantime, someone creates TESTFILE.TXT in TEST_2. Is there any case when Zoltan may want to replace the file in TEST_2? Perhaps not. If not, we should not consider c) an option. In the very least, we must consider this scenario in b): the implementation of b) cannot be simply to find the first occurrence of testdir:TESTFILE.TXT and replace it. It is wrong to assume that the first testdir:TESTFILE.TXT found when writing is the same as the first testdir:TESTFILE.TXT found when opening. Note: at work, we use multi-translation logicals like testdir. The first translation refers to a user directory, the latter to a system directory. (Is this common elsewhere?) The system directory is not writable. Thus, to continue the example above, if my setting was to use b)-style writing (replace the file), and I edit and write a file in the system directory, the write will fail. But this can be solved by the user: - detect that the file is opened read-only -> change to a) or - try writing b)-style, try/catch e45 or e212 -> change to a)