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

Re: $VIM and $PATH on Mac OS X

Expand Messages
  • david craig
    ... Oooh, bad habit. As bob said, create your own ~/.cshrc. David Craig
    Message 1 of 9 , Nov 9, 2001
    • 0 Attachment
      > 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/>
    • 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 2 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 3 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 4 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 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
            • 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 6 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 7 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.