Loading ...
Sorry, an error occurred while loading the content.

why does vim change the file type?

Expand Messages
  • Dave Fortin
    Hello, I work at a manufacturing company in New Hampshire. My Job is to write vectorscript code to automate the design of swimming pool liners and covers. I
    Message 1 of 5 , Jun 3, 2003
    • 0 Attachment
      Hello,
      I work at a manufacturing company in New Hampshire. My Job is to write vectorscript code to automate the design of swimming pool liners and covers. I just started here less than a year ago and I've been introduced to the world of Macs. Always being a Solaris/Linux user I've grown very attached to vim. I slowly got myself setup with VIM on OS 9 and found it definitely more tedious then on a unix based OS. Finally I convinced my boss to get me a new Mac with OS X (10.2.6) and I feel write back at home. Actually I feel like I've moved into a better place. Any who, the automated system I'm working with is using MiniCad 6.0.4 which will only run on OS9. Eventually we want to get into Vectorworks 10 but this is besides the point. In order to run minicad 6.0.4 I must open the classic environment, which is not a problem. Of course being a vim nut I do all of my developing in VIM and love to be in the terminal. However the problem is when I open an OS 9 textfile with vim and then edit and save it, I seem to loose carbonization(?) and minicad 6.0.4 won't allow me to open that file unless I reopen the file in an OS9 hex editor and save it. I don't have to make any changes in the editor, I just save it so, I think, the file will get re-carbonized or something. I'm wondering if there is something I can set in VIM to preserve the file attributes so that I don't have to do this tedious opening and closing of the file multiple times before I use it. I know that If I open and make changes to a file in BBEdit that I don't need to do the hex edit thing. Any guesses or reasoning behind this?

      Thanks,
      David Fortin.
    • Bodhi
      This has nothing to do with carbonization , rather it has a bit to do with resource forks. Unless I have missed something fairly obvious, the command line
      Message 2 of 5 , Jun 4, 2003
      • 0 Attachment
        This has nothing to do with "carbonization", rather it has a bit to do
        with resource forks.

        Unless I have missed something fairly obvious, the command line version
        of Vim doesn't write resource forks. Mac OS 9 apps often require at
        least the existence of resource forks, if not specific content in the
        resource fork. In Mac OS X resource forks are supported by the Finder
        and most file systems, but are not required partially because UNIX apps
        in general usually don't expect them or know how to deal with them. I
        think that the official line that I read on the developer site was
        something like "don't rely on them but it is nice to put them in for
        backwards compatibility," which would seem to make sense in your
        situation.

        Options you have:
        -File a bug with the good folks doing Vim development and ask them to
        at least handle them gracefully if they are there. Having not done any
        research into the issue and just reading your email, it appears that
        there was a resource fork before you began editing it with Vim but when
        Vim saved the file it didn't save the existing resource fork. Perhaps
        the UNIX Vim source should check if it is Mac OS X and if the file has
        an existing resource fork make sure they save it. If someone wants to
        do this I can probably dig up what to call to do this - I would guess
        it is in CoreFoundation. (Sure there are things in Carbon, but who
        wants to link against that if they don't have to - esp in the UNIX
        version.)
        -Until then try the SetFile command line utility. It is installed with
        the Mac OS X Developer Tools in the /Developer/Tools directory. You
        could probably rig an alias so that you just say "make9Openable" and it
        runs SetFile with the appropriate arguments. Off the top of my head I
        don't know what the appropriate arguments are but I would try setting
        the -c and -d options. It probably doesn't matter what you set them to,
        it is probably just their existence that matters. See the SetFile
        manual page for examples (man SetFile in Terminal). That man page won't
        be there unless you have the Dev Tools and I think the Dev
        Documentation package installed.

        Hope that helps somewhat.

        On Tuesday, June 3, 2003, at 11:52, Dave Fortin wrote:

        > Hello,
        > I work at a manufacturing company in New Hampshire. My Job is to
        > write vectorscript code to automate the design of swimming pool liners
        > and covers. I just started here less than a year ago and I've been
        > introduced to the world of Macs. Always being a Solaris/Linux user
        > I've grown very attached to vim. I slowly got myself setup with VIM
        > on OS 9 and found it definitely more tedious then on a unix based OS.
        > Finally I convinced my boss to get me a new Mac with OS X (10.2.6) and
        > I feel write back at home. Actually I feel like I've moved into a
        > better place. Any who, the automated system I'm working with is using
        > MiniCad 6.0.4 which will only run on OS9. Eventually we want to get
        > into Vectorworks 10 but this is besides the point. In order to run
        > minicad 6.0.4 I must open the classic environment, which is not a
        > problem. Of course being a vim nut I do all of my developing in VIM
        > and love to be in the terminal. However the problem is when I open an
        > OS 9 textfile with vim and then edit and save it, I seem to loose
        > carbonization(?) and minicad 6.0.4 won't allow me to open that file
        > unless I reopen the file in an OS9 hex editor and save it. I don't
        > have to make any changes in the editor, I just save it so, I think,
        > the file will get re-carbonized or something. I'm wondering if there
        > is something I can set in VIM to preserve the file attributes so that
        > I don't have to do this tedious opening and closing of the file
        > multiple times before I use it. I know that If I open and make
        > changes to a file in BBEdit that I don't need to do the hex edit
        > thing. Any guesses or reasoning behind this?
        >
        > Thanks,
        > David Fortin.
        >
        >

        bodhi
      • Benji Fisher
        ... Perhaps the second item from the FAQ at http://macvim.swdev.org/OSX/#FAQ will help here. (I think the same advice applies for any version of vim and Mac
        Message 3 of 5 , Jun 4, 2003
        • 0 Attachment
          Bodhi wrote:
          > This has nothing to do with "carbonization", rather it has a bit to do
          > with resource forks.
          >
          > Unless I have missed something fairly obvious, the command line version
          > of Vim doesn't write resource forks. Mac OS 9 apps often require at
          > least the existence of resource forks, if not specific content in the
          > resource fork. In Mac OS X resource forks are supported by the Finder
          > and most file systems, but are not required partially because UNIX apps
          > in general usually don't expect them or know how to deal with them. I
          > think that the official line that I read on the developer site was
          > something like "don't rely on them but it is nice to put them in for
          > backwards compatibility," which would seem to make sense in your situation.
          >
          > Options you have:
          > -File a bug with the good folks doing Vim development and ask them to at
          > least handle them gracefully if they are there. Having not done any
          > research into the issue and just reading your email, it appears that
          > there was a resource fork before you began editing it with Vim but when
          > Vim saved the file it didn't save the existing resource fork. Perhaps
          > the UNIX Vim source should check if it is Mac OS X and if the file has
          > an existing resource fork make sure they save it. If someone wants to do
          > this I can probably dig up what to call to do this - I would guess it is
          > in CoreFoundation. (Sure there are things in Carbon, but who wants to
          > link against that if they don't have to - esp in the UNIX version.)
          > -Until then try the SetFile command line utility. It is installed with
          > the Mac OS X Developer Tools in the /Developer/Tools directory. You
          > could probably rig an alias so that you just say "make9Openable" and it
          > runs SetFile with the appropriate arguments. Off the top of my head I
          > don't know what the appropriate arguments are but I would try setting
          > the -c and -d options. It probably doesn't matter what you set them to,
          > it is probably just their existence that matters. See the SetFile manual
          > page for examples (man SetFile in Terminal). That man page won't be
          > there unless you have the Dev Tools and I think the Dev Documentation
          > package installed.
          >
          > Hope that helps somewhat.

          Perhaps the second item from the FAQ at
          http://macvim.swdev.org/OSX/#FAQ
          will help here. (I think the same advice applies for any version of vim and Mac
          OS.)

          # How can I keep file creators and other meta data when I save a file with vim?
          If you

          :set backupcopy=yes

          then you can edit files with Vim without changing their creator codes, so that
          opening them from the Finder will still launch the application that created
          them. New files that you write with Vim will still get Vim's creator code. For
          details, read

          :help 'backupcopy'

          HTH --Benji Fisher
        • Eugene Lee
          ... Correct. However, regarding the subject, the Mac file type information is stored in the file TYPE field of the HFS+ structure, and not in the resource
          Message 4 of 5 , Jun 4, 2003
          • 0 Attachment
            On Wed, Jun 04, 2003 at 11:20:35AM -0400, Benji Fisher wrote:
            :
            : Bodhi wrote:
            : >
            : >This has nothing to do with "carbonization", rather it has a bit to do
            : >with resource forks.
            : >
            : >Unless I have missed something fairly obvious, the command line version
            : >of Vim doesn't write resource forks.

            Correct. However, regarding the subject, the Mac file type information
            is stored in the file TYPE field of the HFS+ structure, and not in the
            resource fork.

            : Perhaps the second item from the FAQ at
            :
            : http://macvim.swdev.org/OSX/#FAQ
            :
            : will help here. (I think the same advice applies for any version of
            : vim and Mac OS.)

            Sounds like a winner to me. :-)


            --
            Eugene Lee
          • Dany St-Amant
            ... This problem should not be seen on the MACOS_CLASSIC version (even the carbonized one). I created a generic function mch_copy_file_attribute() [which is
            Message 5 of 5 , Jun 4, 2003
            • 0 Attachment
              Le mercredi, 4 jun 2003, à 12:38 Canada/Eastern, Eugene Lee a écrit :

              > On Wed, Jun 04, 2003 at 11:20:35AM -0400, Benji Fisher wrote:
              > :
              > : Bodhi wrote:
              > : >
              > : >This has nothing to do with "carbonization", rather it has a bit to
              > do
              > : >with resource forks.
              > : >
              > : >Unless I have missed something fairly obvious, the command line
              > version
              > : >of Vim doesn't write resource forks.
              >
              > Correct. However, regarding the subject, the Mac file type information
              > is stored in the file TYPE field of the HFS+ structure, and not in the
              > resource fork.

              This problem should not be seen on the MACOS_CLASSIC version (even
              the carbonized one). I created a generic function
              mch_copy_file_attribute()
              [which is now also used by the Windows version] to copy the resource
              fork
              and finder attribute from the original file. In don't remember why I
              remove
              the called from the MACOS_X version, but I'll take a look at it on the
              weekend.
              As for the plain UNIX version or X (as in Motif, Athena, ...), I don't
              know if there's
              some HFS function within Darwin which can be used.

              > : Perhaps the second item from the FAQ at
              > :
              > : http://macvim.swdev.org/OSX/#FAQ
              > :
              > : will help here. (I think the same advice applies for any version of
              > : vim and Mac OS.)
              >
              > Sounds like a winner to me. :-)

              Dany
            Your message has been successfully submitted and would be delivered to recipients shortly.