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

Re: $VIM and $PATH on Mac OS X

Expand Messages
  • Bob Ippolito
    in OS X, just make the file ~/.cshrc -- it gets executed each time a shell is opened. I don t believe one is created by default, but I know from experience
    Message 1 of 9 , Nov 8, 2001
    • 0 Attachment
      in OS X, just make the file ~/.cshrc -- it gets executed each time a
      shell is opened. I don't believe one is created by default, but I know
      from experience that it gets executed.

      There's also the possibility of modifying systemwide flies in
      /private/etc ...
      ls /private/etc/csh.*
      /private/etc/csh.cshrc /private/etc/csh.login /private/etc/csh.logout

      -bob

      On Thursday, November 8, 2001, at 04:33 PM, Benji Fisher wrote:

      > With a little help from the vim users' list, I figured out (at
      > least part of the reason) why some commands do not work from the Carbon
      > version of vim that I compiled: the commands I want (such as tex) are
      > not in $PATH.
      >
      > So: how do I get $PATH set correctly? Is there any way to set
      > $PATH (or $VIM, for that matter) from a terminal window (preferably the
      > default tcshrc, but I guess I can handle another shell) and have the
      > value visible when gvim (Carbon) starts? I cannot find anything like a
      > .tcshrc on this system: where do environment variables get set, anyway?
      >
      > --Benji Fisher
      >
    • david craig
      ... Oooh, bad habit. As bob said, create your own ~/.cshrc. David Craig
      Message 2 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 3 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 4 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 5 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 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
              • 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 7 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 8 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.