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

Re: $VIM and $PATH on Mac OS X

Expand Messages
  • Bob Ippolito
    Well, it s not a bad habit if you re administering a system for a bunch of people to use.. but generally, your own ~/.cshrc is a better idea =)
    Message 1 of 9 , Nov 9, 2001
    • 0 Attachment
      Well, it's not a bad habit if you're administering a system for a bunch
      of people to use.. but generally, your own ~/.cshrc is a better idea =)

      On Friday, November 9, 2001, at 01:44 PM, david craig wrote:

      >
      >> There's also the possibility of modifying systemwide flies in
      >> /private/etc ...
      >
      > Oooh, bad habit. As bob said, create your own ~/.cshrc.
      >
      > David Craig
      >
      >
      > <http://www.panix.com/~dac/>
      >
    • Benji Fisher
      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
      Message 2 of 9 , Nov 9, 2001
      • 0 Attachment
        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().)

        --Benji Fisher

        Bob Ippolito wrote:
        >
        > Well, it's not a bad habit if you're administering a system for a bunch
        > of people to use.. but generally, your own ~/.cshrc is a better idea =)
        >
        > On Friday, November 9, 2001, at 01:44 PM, david craig wrote:
        >
        > >
        > >> There's also the possibility of modifying systemwide flies in
        > >> /private/etc ...
        > >
        > > Oooh, bad habit. As bob said, create your own ~/.cshrc.
        > >
        > > David Craig
        > >
        > >
        > > <http://www.panix.com/~dac/>
      • 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 3 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 4 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 5 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 6 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.