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

Re: $VIM and $PATH on Mac OS X

Expand Messages
  • Dany St-Amant
    ... #$&@# of Mail.App, just did a by error over the DRAFT copy of this reply... and I cannot find it anymore. Rewriting from scratch. Applications
    Message 1 of 9 , Nov 9, 2001
    • 0 Attachment
      Le Vendredi 9 novembre 2001, à 03:55 , Benji Fisher a écrit :

      > I am thinking more in terms of how to write an installation script
      > when I package gvim 6.0 (Carbon) for distribution. (Not this week, it
      > seems; maybe next week.) If I cannot figure out how to compile in a
      > reasonable value for $VIM, I may modify the system files to set it.
      > Then, maybe, the system vimrc file can do something like
      >
      > :let $PATH = system("printenv PATH")
      >
      > (I tried that: it works, except that I have to strip the EOL character
      > returned by system().)

      #$&@# of Mail.App, just did a <DELETE> by error over the DRAFT copy
      of this reply... and I cannot find it anymore. Rewriting from scratch.

      Applications under MacOS X inherit the environment of their invoker,
      so if you change PATH of VIM in Terminal.app and then do
      "open Vim.app", you'll use those new PATH and VIM.

      Vim on MacOS X is defaulting $VIM to the executable path. To use
      a hardcoded path you'll have to undefine USE_EXE_PATH
      and maybe change the wrap the use of exe_name in os_mac.c
      with a #ifdef USE_EXE_PATH.

      By grep-ping and find-ing around as a root, I finally figure out
      how to define change the environment that any Application
      will use when launch from anywhere.

      In your home directory, create a directory .MacOSX and create
      an environment.plist file. I just minimally tested this with a dummy
      user id. When changing PATH you have to be careful has it will be used
      as is, so you have to add you own bin directory $HOME/bin.

      <?xml version="1.0" encoding="UTF-8"?>
      <!DOCTYPE plist SYSTEM
      "file://localhost/System/Library/DTDs/PropertyList.dtd">
      <plist version="0.9">
      <dict>
      <key>VIM</key>
      <string>/Users/dstamant/</string>
      <key>PATH</key>
      <string>/usr/X11R6/bin</string>
      </dict>
      </plist>
    • Benji Fisher
      ... Yes, I have several complaints with Mail.app. I would install Pine or mutt, if I could figure out how to get mail sent to a Terminal-based application. I
      Message 2 of 9 , Nov 10, 2001
      • 0 Attachment
        On Friday, November 9, 2001, at 10:18 PM, Dany St-Amant wrote:

        > #$&@# of Mail.App, just did a <DELETE> by error over the DRAFT copy
        > of this reply... and I cannot find it anymore. Rewriting from scratch.

        Yes, I have several complaints with Mail.app. I would install Pine
        or mutt, if I could figure out how to get mail sent to a Terminal-based
        application. I did solve one problem: if you send a patch in the body of
        an e-mail, I can save the mail in rtf (having no other choice), open it in
        TextEdit, change it to plain text using the Format menu, and save it in a
        usable way.

        > Applications under MacOS X inherit the environment of their invoker,
        > so if you change PATH of VIM in Terminal.app and then do
        > "open Vim.app", you'll use those new PATH and VIM.

        This works, but I want to compile, package, and distribute a version
        that can be placed in the Applications/
        directory. Opening from Terminal.app is not the way to go.

        > Vim on MacOS X is defaulting $VIM to the executable path. To use
        > a hardcoded path you'll have to undefine USE_EXE_PATH
        > and maybe change the wrap the use of exe_name in os_mac.c
        > with a #ifdef USE_EXE_PATH.

        Can you be more explicit? Where is USE_EXE_PATH defined? I could
        not find it, even using grep. Since I define OS_X_UNIX, isn't os_mac.c
        skipped? I really think that hard-coding $VIM is the best alternative, if
        Vim.app is going to go in the Applications/ directory (I mean folder).

        > By grep-ping and find-ing around as a root, I finally figure out
        > how to define change the environment that any Application
        > will use when launch from anywhere.
        >
        > In your home directory, create a directory .MacOSX and create
        > an environment.plist file. I just minimally tested this with a dummy
        > user id. When changing PATH you have to be careful has it will be used
        > as is, so you have to add you own bin directory $HOME/bin.
        >
        > <?xml version="1.0" encoding="UTF-8"?>
        > <!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.
        > dtd">
        > <plist version="0.9">
        > <dict>
        > <key>VIM</key>
        > <string>/Users/dstamant/</string>
        > <key>PATH</key>
        > <string>/usr/X11R6/bin</string>
        > </dict>
        > </plist>
        >
        OK, this works. I still prefer a hard-coded value for $VIM. Once I
        have $VIM set, I can install a system vimrc file: I tried

        echo system("source /private/etc/csh.login; printenv PATH")

        and got the right answer, so I can set $PATH from within vim. (BTW, this
        line shows that the @* register is working!)

        I am beginning to think that ProjectBuilder ignores the makefiles.
        Is that right? Either way, what is the recommended way to enable/disable
        features? I guess I can either edit feature.h or define macros (-DSTUFF)
        in ProjectBuilder. Is there a way to compile with +perl?

        --Benji Fisher
      • Benji Fisher
        ... Yes, I have several complaints with Mail.app. I would install Pine or mutt, if I could figure out how to get mail sent to a Terminal-based application. I
        Message 3 of 9 , Nov 10, 2001
        • 0 Attachment
          On Friday, November 9, 2001, at 10:18 PM, Dany St-Amant wrote:

          > #$&@# of Mail.App, just did a <DELETE> by error over the DRAFT copy
          > of this reply... and I cannot find it anymore. Rewriting from scratch.

          Yes, I have several complaints with Mail.app. I would install Pine
          or mutt, if I could figure out how to get mail sent to a Terminal-based
          application. I did solve one problem: if you send a patch in the body of
          an e-mail, I can save the mail in rtf (having no other choice), open it in
          TextEdit, change it to plain text using the Format menu, and save it in a
          usable way.

          > Applications under MacOS X inherit the environment of their invoker,
          > so if you change PATH of VIM in Terminal.app and then do
          > "open Vim.app", you'll use those new PATH and VIM.

          This works, but I want to compile, package, and distribute a version
          that can be placed in the Applications/
          directory. Opening from Terminal.app is not the way to go.

          > Vim on MacOS X is defaulting $VIM to the executable path. To use
          > a hardcoded path you'll have to undefine USE_EXE_PATH
          > and maybe change the wrap the use of exe_name in os_mac.c
          > with a #ifdef USE_EXE_PATH.

          Can you be more explicit? Where is USE_EXE_PATH defined? I could
          not find it, even using grep. Since I define OS_X_UNIX, isn't os_mac.c
          skipped? I really think that hard-coding $VIM is the best alternative, if
          Vim.app is going to go in the Applications/ directory (I mean folder).

          > By grep-ping and find-ing around as a root, I finally figure out
          > how to define change the environment that any Application
          > will use when launch from anywhere.
          >
          > In your home directory, create a directory .MacOSX and create
          > an environment.plist file. I just minimally tested this with a dummy
          > user id. When changing PATH you have to be careful has it will be used
          > as is, so you have to add you own bin directory $HOME/bin.
          >
          > <?xml version="1.0" encoding="UTF-8"?>
          > <!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.
          > dtd">
          > <plist version="0.9">
          > <dict>
          > <key>VIM</key>
          > <string>/Users/dstamant/</string>
          > <key>PATH</key>
          > <string>/usr/X11R6/bin</string>
          > </dict>
          > </plist>
          >
          OK, this works. I still prefer a hard-coded value for $VIM. Once I
          have $VIM set, I can install a system vimrc file: I tried

          echo system("source /private/etc/csh.login; printenv PATH")

          and got the right answer, so I can set $PATH from within vim. (BTW, this
          line shows that the @* register is working!)

          I am beginning to think that ProjectBuilder ignores the makefiles.
          Is that right? Either way, what is the recommended way to enable/disable
          features? I guess I can either edit feature.h or define macros (-DSTUFF)
          in ProjectBuilder. Is there a way to compile with +perl?

          --Benji Fisher
        • Dany St-Amant
          ... Doh!. I should have type USE_EXE_NAME and gui_mac.c. The check #ifdef is already there. If Vim is place inside a folder inside the Application folder, the
          Message 4 of 9 , Nov 12, 2001
          • 0 Attachment
            Le Dimanche 11 novembre 2001, à 12:30 , Benji Fisher a écrit :

            > On Friday, November 9, 2001, at 10:18 PM, Dany St-Amant wrote:
            >
            >> Applications under MacOS X inherit the environment of their invoker,
            >> so if you change PATH of VIM in Terminal.app and then do
            >> "open Vim.app", you'll use those new PATH and VIM.
            >
            > This works, but I want to compile, package, and distribute a
            > version that can be placed in the Applications/
            > directory. Opening from Terminal.app is not the way to go.
            >
            >> Vim on MacOS X is defaulting $VIM to the executable path. To use
            >> a hardcoded path you'll have to undefine USE_EXE_PATH
            >> and maybe change the wrap the use of exe_name in os_mac.c
            >> with a #ifdef USE_EXE_PATH.
            >
            > Can you be more explicit? Where is USE_EXE_PATH defined? I could
            > not find it, even using grep. Since I define OS_X_UNIX, isn't os_mac.c
            > skipped? I really think that hard-coding $VIM is the best alternative,
            > if Vim.app is going to go in the Applications/ directory (I mean
            > folder).

            Doh!. I should have type USE_EXE_NAME and gui_mac.c. The check #ifdef is
            already there. If Vim is place inside a folder inside the Application
            folder, the
            current auto-detect should, but won't be nice. In misc1.c, function
            'expand_env'
            we could try to avoid the removal of VIm.app by not calling (unless
            build is
            present)

            pend = remove_tail_with_ext(p, pend, (char_u *)".app");

            Or we could add back the Vim.app (should use the original name removed)
            in the
            function vim_version_dir. This could allow us to put the $VIMRUNTIME
            inside
            VIm.app (which I think is the way recommended by Apple, one big fat
            application
            folder)

            > [...]
            > I am beginning to think that ProjectBuilder ignores the
            > makefiles. Is that right? Either way, what is the recommended way to
            > enable/disable features? I guess I can either edit feature.h or define
            > macros (-DSTUFF) in ProjectBuilder. Is there a way to compile with
            > +perl?

            The os_mac.pbproj is by itself a makefile. Since there's a empty
            auto/config.h supplied
            in the distribution it should not be hard to try to get Project Builder
            to use it as a template.
            But it will require a lot of #ifdef in os_mac.h and gui_mac.h (I didn't
            got ride of os_mac.h for -DMACOS_X.. Another problem (as shown by
            os_macosx.c) is that I haven't yet found
            a way to conditionally compile a file without the use of a wrapper.

            Dany, currently looking at:
            -providing a Console/Carbon combo (works somehow but strangely)
            -how easy to get a Cocoa version (seems easier that I originally though,
            but no time)
            -how to get ./configure to go Carbon (I'm having headaches)
            -fixing small issues
            -can't remember what else
          Your message has been successfully submitted and would be delivered to recipients shortly.