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

[BUG] :unlet $ENV does not work

Expand Messages
  • ZyX
    If I do vim -u NONE -c unlet $PATH I get “E488: Trailing characters” error. That means that there is no way to get rid of environment variable after it
    Message 1 of 27 , Feb 2, 2014
    • 0 Attachment
      If I do

      vim -u NONE -c 'unlet $PATH'

      I get “E488: Trailing characters” error.

      That means that there is no way to get rid of environment variable after it was set which may be essential if tools using variables check for their existence, not for their contents (e.g. in tcsh scripts checking for emptyness and for existence are different constructs and they are rarely checked both (and non-existent variables expand to errors, not to empty values), it is also not uncommon to write “if 'VARNAME' in os.environ:” or use EAFP principle in python in which cases empty string is treated just like any other value).

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Bram Moolenaar
      ... Historically environment variables cannot be deleted, only made empty. It s not a good idea to check for existence, check for it being non-empty instead.
      Message 2 of 27 , Feb 2, 2014
      • 0 Attachment
        ZyX wrote:

        > If I do
        >
        > vim -u NONE -c 'unlet $PATH'
        >
        > I get “E488: Trailing characters” error.
        >
        > That means that there is no way to get rid of environment variable
        > after it was set which may be essential if tools using variables check
        > for their existence, not for their contents (e.g. in tcsh scripts
        > checking for emptyness and for existence are different constructs and
        > they are rarely checked both (and non-existent variables expand to
        > errors, not to empty values), it is also not uncommon to write “if
        > 'VARNAME' in os.environ:” or use EAFP principle in python in which
        > cases empty string is treated just like any other value).

        Historically environment variables cannot be deleted, only made empty.
        It's not a good idea to check for existence, check for it being
        non-empty instead.

        Note that Vim will consider a non-existing environment variable to be
        empty, it doesn't give an error for ":let s = $ASDFASDF".

        --
        hundred-and-one symptoms of being an internet addict:
        248. You sign your letters with your e-mail address instead of your name.

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Bee
        ... Remove the internal variable {name}. Note: INTERNAL to vim If you have a variable named PATH internal to vim use: vim -u NONE -c unlet PATH -- -- You
        Message 3 of 27 , Feb 2, 2014
        • 0 Attachment
          On Sunday, February 2, 2014 8:39:43 AM UTC-8, ZyX wrote:
          > If I do
          > vim -u NONE -c 'unlet $PATH'
          > I get “E488: Trailing characters” error.

          :help :unlet

          :unl[et][!] {name} ... *:unlet* *:unl* *E108* *E795*
          Remove the internal variable {name}.

          Note: INTERNAL to vim

          If you have a variable named PATH internal to vim use:

          vim -u NONE -c 'unlet PATH'

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Bee
          ... Remove the internal variable {name}. Note: INTERNAL to vim -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply
          Message 4 of 27 , Feb 2, 2014
          • 0 Attachment
            On Sunday, February 2, 2014 8:39:43 AM UTC-8, ZyX wrote:
            > If I do
            > vim -u NONE -c 'unlet $PATH'
            > I get “E488: Trailing characters” error.

            :help :unlet

            :unl[et][!] {name} ... *:unlet* *:unl* *E108* *E795*
            Remove the internal variable {name}.

            Note: INTERNAL to vim

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • ZyX
            ... And guess where they are actually stored? In vim process memory. In linux there is a special global variable that is manipulated by various *env functions
            Message 5 of 27 , Feb 2, 2014
            • 0 Attachment
              > Note: INTERNAL to vim

              And guess where they are actually stored? In vim process memory. In linux there is a special global variable that is manipulated by various *env functions (see “man getenv”, there is a “SEE ALSO” list at the bottom). AFAIR I saw direct manipulations of this global in zsh sources under some circumstances (*env functions not available: search for USE_SET_UNSET_ENV macros in zsh sources).

              They are internal.

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • ZyX
              ... Do not tell it me. There is an example: if PYTHONDUMPREFS variable is set for debug build of python, no matter whether or not it is empty, python will dump
              Message 6 of 27 , Feb 2, 2014
              • 0 Attachment
                > Historically environment variables cannot be deleted, only made empty.
                > It's not a good idea to check for existence, check for it being
                > non-empty instead.

                Do not tell it me. There is an example: if PYTHONDUMPREFS variable is set for debug build of python, no matter whether or not it is empty, python will dump references.

                There is a way to delete variables on most system. I would expect vim to support deleting them. Also what for there is working `exists('$VAR')` if it is supposed to be `empty('$VAR')`? The statement in the doc (“could also be done by comparing with an empty string”) is not true, there is a difference between existing and empty in exists() output.

                > Note that Vim will consider a non-existing environment variable to be
                > empty, it doesn't give an error for ":let s = $ASDFASDF".

                Usually environment variables are for interprocess communication between parent and children processes. Vim being a child process of the vim is very uncommon. And `exists('$ASDFASDF')` does not tell 0 if environment variable exists, but is empty.

                All languages I use except VimL allow deleting environment variables: os.environ behaves like real dict in python, same for perl $ENV, shells have `unset`.

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Bee
                ... How about using a shell script: #!/bin/sh vimx=`which vim` PATH= echo $PATH exec $vimx ... returns empty. That way you do not disturb the system PATH. --
                Message 7 of 27 , Feb 2, 2014
                • 0 Attachment
                  On Sunday, February 2, 2014 11:08:05 AM UTC-8, ZyX wrote:
                  > > Note: INTERNAL to vim
                  >
                  >
                  >
                  > And guess where they are actually stored? In vim process memory. In linux there is a special global variable that is manipulated by various *env functions (see “man getenv”, there is a “SEE ALSO” list at the bottom). AFAIR I saw direct manipulations of this global in zsh sources under some circumstances (*env functions not available: search for USE_SET_UNSET_ENV macros in zsh sources).
                  >
                  >
                  >
                  > They are internal.

                  How about using a shell script:

                  #!/bin/sh
                  vimx=`which vim`
                  PATH=""
                  echo $PATH
                  exec $vimx

                  Then in vim:
                  :echo $PATH
                  returns empty.

                  That way you do not disturb the system PATH.

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • ZyX
                  ... ? I am talking about unsetting environment variables which are set in vim. How is this script related? Also for your job there is much easier way: `PATH=
                  Message 8 of 27 , Feb 2, 2014
                  • 0 Attachment
                    > How about using a shell script:
                    >
                    > #!/bin/sh
                    > vimx=`which vim`
                    > PATH=""
                    > echo $PATH
                    > exec $vimx
                    >
                    > Then in vim:
                    > :echo $PATH
                    > returns empty.
                    >
                    > That way you do not disturb the system PATH.

                    ? I am talking about unsetting environment variables which are set in vim. How is this script related?

                    Also for your job there is much easier way: `PATH= vim …`. And you forgot about quoting of `which vim`, vim arguments and so on.

                    --
                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Bee
                    ... Your original post said: vim -u NONE -c unlet $PATH It looked as though you were referring to system not vim. If you were trying to use unset in vim it
                    Message 9 of 27 , Feb 2, 2014
                    • 0 Attachment
                      On Sunday, February 2, 2014 12:06:25 PM UTC-8, ZyX wrote:
                      > > How about using a shell script:
                      > ? I am talking about unsetting environment variables which are set in vim. How is this script related?

                      Your original post said:
                      vim -u NONE -c 'unlet $PATH'

                      It looked as though you were referring to system not vim.

                      If you were trying to use 'unset' in vim it is without the '$'.

                      vim -u NONE -c 'unlet PATH'

                      But...
                      The '-u NONE' starts vim without your .vimrc.
                      Where would vim get variables to unset?

                      --
                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • ZyX
                      ... With. I am talking about unsetting *environment* variable. `$PATH` was used as the example of variable which is expected to exist to make example less
                      Message 10 of 27 , Feb 2, 2014
                      • 0 Attachment
                        On Monday, February 3, 2014 12:52:48 AM UTC+4, Bee wrote:
                        > On Sunday, February 2, 2014 12:06:25 PM UTC-8, ZyX wrote:
                        > > > How about using a shell script:
                        > > ? I am talking about unsetting environment variables which are set in vim. How is this script related?
                        >
                        > Your original post said:
                        > vim -u NONE -c 'unlet $PATH'
                        >
                        > It looked as though you were referring to system not vim.
                        >
                        > If you were trying to use 'unset' in vim it is without the '$'.

                        With. I am talking about unsetting *environment* variable. `$PATH` was used as the example of variable which is expected to exist to make example less verbose. The specific code I use is defining environment variable and *then* undefining it. No shell script can be helpful because it is defined inside vim.

                        >
                        > vim -u NONE -c 'unlet PATH'
                        >
                        > But...
                        > The '-u NONE' starts vim without your .vimrc.
                        > Where would vim get variables to unset?

                        --
                        --
                        You received this message from the "vim_dev" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php

                        ---
                        You received this message because you are subscribed to the Google Groups "vim_dev" group.
                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                        For more options, visit https://groups.google.com/groups/opt_out.
                      • Gary Johnson
                        ... I ve been frustrated by Vim s inability to unset environment variables on occasion, too. I don t know what systems would not support this. On my Ubuntu
                        Message 11 of 27 , Feb 2, 2014
                        • 0 Attachment
                          On 2014-02-02, ZyX wrote:
                          > > Historically environment variables cannot be deleted, only made empty.
                          > > It's not a good idea to check for existence, check for it being
                          > > non-empty instead.
                          >
                          > Do not tell it me. There is an example: if PYTHONDUMPREFS variable
                          > is set for debug build of python, no matter whether or not it is
                          > empty, python will dump references.
                          >
                          > There is a way to delete variables on most system. I would expect
                          > vim to support deleting them. Also what for there is working
                          > `exists('$VAR')` if it is supposed to be `empty('$VAR')`? The
                          > statement in the doc (“could also be done by comparing with an
                          > empty string”) is not true, there is a difference between existing
                          > and empty in exists() output.

                          I've been frustrated by Vim's inability to unset environment
                          variables on occasion, too. I don't know what systems would not
                          support this. On my Ubuntu Linux system, the unsetenv(3) man page
                          says that it conforms to 4.3BSD and POSIX.1-2001.

                          Regards,
                          Gary

                          --
                          --
                          You received this message from the "vim_dev" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php

                          ---
                          You received this message because you are subscribed to the Google Groups "vim_dev" group.
                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                          For more options, visit https://groups.google.com/groups/opt_out.
                        • Andre Sihera
                          ... It appears that we have two conflicting requirements here when only one can be supported. On the one hand we have ViM s current behaviour as pointed out by
                          Message 12 of 27 , Feb 2, 2014
                          • 0 Attachment
                            On 03/02/14 01:39, ZyX wrote:
                            > If I do
                            >
                            > vim -u NONE -c 'unlet $PATH'
                            >
                            > I get “E488: Trailing characters” error.
                            >
                            > That means that there is no way to get rid of environment variable after it was set which may be essential if tools using variables check for their existence, not for their contents (e.g. in tcsh scripts checking for emptyness and for existence are different constructs and they are rarely checked both (and non-existent variables expand to errors, not to empty values), it is also not uncommon to write “if 'VARNAME' in os.environ:” or use EAFP principle in python in which cases empty string is treated just like any other value).
                            >

                            It appears that we have two conflicting requirements here when only one
                            can be supported.

                            On the one hand we have ViM's current behaviour as pointed out by Bram:

                            On 03/02/14 02:54, Bram Moolenaar wrote:
                            >
                            > Historically environment variables cannot be deleted, only made empty.
                            > ...
                            > Note that Vim will consider a non-existing environment variable to be
                            > empty, it doesn't give an error for ":let s = $ASDFASDF".

                            While on the other we have the desire to be able to remove an environment
                            variable from the environment of the currently running ViM process, making
                            the ViM variable equivalent of that environment variable "non-existent".

                            The fact of the matter is that ViM's current behaviour, in considering a
                            "non-existent" environment variable as "defined but empty", means that
                            even if an "unlet" command on an environment variable were to exist it
                            still wouldn't give the desired effect, as any subsequent test on the unlet
                            variable would just yield an empty value, not "variable undefined" (which
                            is what is being called for).

                            Thus, as well as adding "unlet", as you would also have to modify the
                            fundamental way in which ViM environment variable handling works, this
                            kind of change could seriously upset all existing scripts and plug-ins.

                            However, in addition to the "unlet" command, if it were possible just to
                            modify the "exists()" function so that "exists($XXX)" returns Zero if XXX
                            is physically not in the environment and One if XXX is physically there,
                            regardless of its value, then unletting an environment variable and then
                            checking for its existence with "exists($XXX)" would solve the problem
                            (currently, "exists($XXX)" is the same as testing if $XXX is empty).

                            Furthermore, if only "exists()" is changed, while the impact to scripts
                            would still exist. the current behaviour of returning an empty string
                            value when accessing non-existent environment variables would be retained.
                            This would definitely be the lesser of two evils with regards to backward
                            compatibility.

                            Cheers,

                            --
                            --
                            You received this message from the "vim_dev" maillist.
                            Do not top-post! Type your reply below the text you are replying to.
                            For more information, visit http://www.vim.org/maillist.php

                            ---
                            You received this message because you are subscribed to the Google Groups "vim_dev" group.
                            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                            For more options, visit https://groups.google.com/groups/opt_out.
                          • ZyX
                            ... No. ... No. Shells have `unset` for years, it does not make them unable to treat unexistent variables as empty except for the certain cases. ... I did not
                            Message 13 of 27 , Feb 2, 2014
                            • 0 Attachment
                              > It appears that we have two conflicting requirements here when only one
                              > can be supported.

                              No.

                              > On the one hand we have ViM's current behaviour as pointed out by Bram:
                              >
                              > On 03/02/14 02:54, Bram Moolenaar wrote:
                              > >
                              > > Historically environment variables cannot be deleted, only made empty.
                              > > ...
                              > > Note that Vim will consider a non-existing environment variable to be
                              > > empty, it doesn't give an error for ":let s = $ASDFASDF".
                              >
                              > While on the other we have the desire to be able to remove an environment
                              > variable from the environment of the currently running ViM process, making
                              > the ViM variable equivalent of that environment variable "non-existent".

                              No. Shells have `unset` for years, it does not make them unable to treat unexistent variables as empty except for the certain cases.

                              > The fact of the matter is that ViM's current behaviour, in considering a
                              > "non-existent" environment variable as "defined but empty", means that
                              > even if an "unlet" command on an environment variable were to exist it
                              > still wouldn't give the desired effect, as any subsequent test on the unlet
                              > variable would just yield an empty value, not "variable undefined" (which
                              > is what is being called for).

                              I did not suggest altering this behavior.

                              > Thus, as well as adding "unlet", as you would also have to modify the
                              > fundamental way in which ViM environment variable handling works, this
                              > kind of change could seriously upset all existing scripts and plug-ins.

                              No. The only thing which is supposed to be altered is `:unlet $VAR` removing variable from global.

                              > However, in addition to the "unlet" command, if it were possible just to
                              > modify the "exists()" function so that "exists($XXX)" returns Zero if XXX
                              > is physically not in the environment and One if XXX is physically there,
                              > regardless of its value, then unletting an environment variable and then
                              > checking for its existence with "exists($XXX)" would solve the problem
                              > (currently, "exists($XXX)" is the same as testing if $XXX is empty).

                              Did you read me? My reply to Bram at least. It *already* works this way. `exist('$EMPTY')` will return 1 as far as value is in environment, regardless of whether or not is empty.

                              > Furthermore, if only "exists()" is changed, while the impact to scripts
                              > would still exist. the current behaviour of returning an empty string
                              > value when accessing non-existent environment variables would be retained.
                              > This would definitely be the lesser of two evils with regards to backward
                              > compatibility.

                              `exists()` does not have to be changed. Neither does result of accessing non-existent variables. I am only talking about `:unlet`.

                              --
                              --
                              You received this message from the "vim_dev" maillist.
                              Do not top-post! Type your reply below the text you are replying to.
                              For more information, visit http://www.vim.org/maillist.php

                              ---
                              You received this message because you are subscribed to the Google Groups "vim_dev" group.
                              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                              For more options, visit https://groups.google.com/groups/opt_out.
                            • Andre Sihera
                              ... Before you sit there in your arrogance and blast every suggestion that is put before you, why don t you READ people s posts. How can you have an unlet
                              Message 14 of 27 , Feb 2, 2014
                              • 0 Attachment
                                On 03/02/14 11:57, ZyX wrote:
                                >
                                > `exists()` does not have to be changed. Neither does result of accessing non-existent. I am only talking about `:unlet`.

                                Before you sit there in your arrogance and blast every suggestion
                                that is put before you, why don't you READ people's posts.

                                How can you have an "unlet" that removes it from the environment
                                when the non-existent variable isn't detectable with ViM's current
                                behaviour? The unlet command is *useless* unless you also have a
                                way to actually detect a non-existent variable from a purely empty
                                one. And that isn't possible in ViM as all usages of non-existent
                                variables in ViM are the same as those on "defined but empty"
                                variables.

                                Well, how do you propose to solve it?


                                --
                                --
                                You received this message from the "vim_dev" maillist.
                                Do not top-post! Type your reply below the text you are replying to.
                                For more information, visit http://www.vim.org/maillist.php

                                ---
                                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                For more options, visit https://groups.google.com/groups/opt_out.
                              • Andre Sihera
                                ... This is a language change and so therefore should fit into the language. Putting a language change for the benefit of external scripts only will break the
                                Message 15 of 27 , Feb 2, 2014
                                • 0 Attachment
                                  On 03/02/14 12:22, Andre Sihera wrote:
                                  > On 03/02/14 11:57, ZyX wrote:
                                  >>
                                  >> `exists()` does not have to be changed. Neither does result of
                                  >> accessing non-existent. I am only talking about `:unlet`.
                                  >
                                  > Before you sit there in your arrogance and blast every suggestion
                                  > that is put before you, why don't you READ people's posts.
                                  >
                                  > How can you have an "unlet" that removes it from the environment
                                  > when the non-existent variable isn't detectable with ViM's current
                                  > behaviour? The unlet command is *useless* unless you also have a
                                  > way to actually detect a non-existent variable from a purely empty
                                  > one. And that isn't possible in ViM as all usages of non-existent
                                  > variables in ViM are the same as those on "defined but empty"
                                  > variables.
                                  >
                                  > Well, how do you propose to solve it?
                                  >
                                  >

                                  This is a language change and so therefore should fit into the language.
                                  Putting a language change for the benefit of external scripts only will
                                  break the semantics of the language, which is why the language must
                                  be considered whether or not *your* personal usage will extend only
                                  to external "tool" scripts.

                                  --
                                  --
                                  You received this message from the "vim_dev" maillist.
                                  Do not top-post! Type your reply below the text you are replying to.
                                  For more information, visit http://www.vim.org/maillist.php

                                  ---
                                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                  For more options, visit https://groups.google.com/groups/opt_out.
                                • ZyX
                                  ... 1. It is. Just use `exists()`. 2. It is. Use `system( python -c import os; print ( VAR in os.environ) )`. ... Without `exists()` this would be useless
                                  Message 16 of 27 , Feb 2, 2014
                                  • 0 Attachment
                                    On Monday, February 3, 2014 7:22:28 AM UTC+4, Andre Sihera wrote:
                                    > On 03/02/14 11:57, ZyX wrote:
                                    >
                                    > >
                                    >
                                    > > `exists()` does not have to be changed. Neither does result of accessing non-existent. I am only talking about `:unlet`.
                                    >
                                    >
                                    >
                                    > Before you sit there in your arrogance and blast every suggestion
                                    >
                                    > that is put before you, why don't you READ people's posts.
                                    >
                                    >
                                    >
                                    > How can you have an "unlet" that removes it from the environment
                                    > when the non-existent variable isn't detectable with ViM's current
                                    > behaviour?

                                    1. It is. Just use `exists()`.
                                    2. It is. Use `system('python -c "import os; print (\"VAR\" in os.environ)"')`.

                                    > The unlet command is *useless* unless you also have a
                                    > way to actually detect a non-existent variable from a purely empty
                                    > one. And that isn't possible in ViM as all usages of non-existent
                                    > variables in ViM are the same as those on "defined but empty"
                                    > variables.

                                    Without `exists()` this would be useless for my purpose (restore environment after it was altered). Fortunately exists() work.

                                    > Well, how do you propose to solve it?

                                    `:unlet $ENV` should remove environment from `envp` global (on POSIX systems). I guess there is an equivalent for Windows. If no means of such removal are not known it should act like `:let $ENV=""`.

                                    --
                                    --
                                    You received this message from the "vim_dev" maillist.
                                    Do not top-post! Type your reply below the text you are replying to.
                                    For more information, visit http://www.vim.org/maillist.php

                                    ---
                                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                    For more options, visit https://groups.google.com/groups/opt_out.
                                  • Ernie Rael
                                    I m confused about something. With the release binary of 7.4 on windows, for echo exists( $xyzzy ) the following two give different results (xyzzy is not in
                                    Message 17 of 27 , Feb 2, 2014
                                    • 0 Attachment
                                      I'm confused about something. With the release binary of 7.4 on windows, for
                                      echo exists("$xyzzy")
                                      the following two give different results (xyzzy is not in the shell's environment).
                                      xyzzy=x vim
                                      xyzzy= vim
                                      This would seem to indicate that ":exists" is not able to detect if a variable does not exist in the environment. But that's not the real issue.

                                      Since vim executes a wide variety of commands, it should be possible to unset env variables, either fixing unlet or some other mechanism. And coming up with a way to detect not in env, should be trivial; all this discussion is a spec issue.

                                      -ernie

                                      On 2/2/2014 7:43 PM, ZyX wrote:
                                      On Monday, February 3, 2014 7:22:28 AM UTC+4, Andre Sihera wrote:
                                      
                                      On 03/02/14 11:57, ZyX wrote:
                                      
                                      
                                      `exists()` does not have to be changed. Neither does result of accessing non-existent. I am only talking about `:unlet`.
                                      
                                      
                                      
                                      Before you sit there in your arrogance and blast every suggestion
                                      
                                      that is put before you, why don't you READ people's posts.
                                      
                                      
                                      
                                      How can you have an "unlet" that removes it from the environment
                                      when the non-existent variable isn't detectable with ViM's current
                                      behaviour?
                                      
                                      1. It is. Just use `exists()`.
                                      2. It is. Use `system('python -c "import os; print (\"VAR\" in os.environ)"')`.
                                      
                                      
                                      The unlet command is *useless* unless you also have a
                                      way to actually detect a non-existent variable from a purely empty
                                      one. And that isn't possible in ViM as all usages of non-existent
                                      variables in ViM are the same as those on "defined but empty"
                                      variables.
                                      
                                      Without `exists()` this would be useless for my purpose (restore environment after it was altered). Fortunately exists() work.
                                      
                                      
                                      Well, how do you propose to solve it?
                                      
                                      `:unlet $ENV` should remove environment from `envp` global (on POSIX systems). I guess there is an equivalent for Windows. If no means of such removal are not known it should act like `:let $ENV=""`.
                                      
                                      

                                      --
                                      --
                                      You received this message from the "vim_dev" maillist.
                                      Do not top-post! Type your reply below the text you are replying to.
                                      For more information, visit http://www.vim.org/maillist.php
                                       
                                      ---
                                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                      For more options, visit https://groups.google.com/groups/opt_out.
                                    • ZyX
                                      ... I do not always use mild words, but I do read them. I have never blasted anything without explaining why. I see two messages where you are ignoring the
                                      Message 18 of 27 , Feb 2, 2014
                                      • 0 Attachment
                                        > Before you sit there in your arrogance and blast every suggestion
                                        > that is put before you, why don't you READ people's posts.

                                        I do not always use mild words, but I do read them. I have never blasted anything without explaining why.

                                        I see two messages where you are ignoring the fact that

                                        :echo exists('$EMPTY')
                                        " Echoes 0
                                        :let $EMPTY=''
                                        :echo exists('$EMPTY')
                                        " Echoes 1

                                        works at least on linux. Yes, help says that `exists()` and `!empty()` should return the same. But on linux they don’t.

                                        > This is a language change and so therefore should fit into the language.
                                        > Putting a language change for the benefit of external scripts only will
                                        > break the semantics of the language, which is why the language must
                                        > be considered whether or not *your* personal usage will extend only
                                        > to external "tool" scripts.

                                        Not only. I have grep’ed my `~/.vam` folder which contains third-party plugins and have found out a few ones that use `exists('$ENV')` like `exists('$RAILS_ENV')` or `exists('$PGPASSWORD')` (really a few, actually). For such a scripts you cannot change the execution flow by setting `$RAILS_ENV` to empty. I do not know whether author of script expected these variables not to be changed from within vim, expected `exists()` return 0 for empty or else, thus cannot say whether there is a problem here.

                                        It is also not the only thing that is useful for external scripts only. `shellescape()` is needed only for them. You do not need `let $ENV` except for the scripts.

                                        All languages I know that can launch other processes have means of unsetting environment variable. Python does, Perl does, *sh does, C (with POSIX libc) does.

                                        --
                                        --
                                        You received this message from the "vim_dev" maillist.
                                        Do not top-post! Type your reply below the text you are replying to.
                                        For more information, visit http://www.vim.org/maillist.php

                                        ---
                                        You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                        For more options, visit https://groups.google.com/groups/opt_out.
                                      • ZyX
                                        ... Good to know. I have checked out `wineconsole cmd` and this is what appears: C: set XXX Environment variable XXX not defined C: set XXX=1 C: set XXX
                                        Message 19 of 27 , Feb 2, 2014
                                        • 0 Attachment
                                          On Monday, February 3, 2014 8:14:37 AM UTC+4, Ernie Rael wrote:
                                          > I'm confused about something. With the release binary of 7.4 on
                                          > windows, for
                                          >
                                          > echo exists("$xyzzy")
                                          >
                                          >
                                          > the following two give different results (xyzzy is not in the
                                          > shell's environment).
                                          >
                                          > xyzzy=x vim
                                          >
                                          > xyzzy= vim
                                          >
                                          >
                                          > This would seem to indicate that ":exists" is not able to detect if
                                          > a variable does not exist in the environment. But that's not the
                                          > real issue.
                                          >
                                          >
                                          >
                                          > Since vim executes a wide variety of commands, it should be possible
                                          > to unset env variables, either fixing unlet or some other mechanism.
                                          > And coming up with a way to detect not in env, should be trivial;
                                          > all this discussion is a spec issue.

                                          Good to know. I have checked out `wineconsole cmd` and this is what appears:

                                          C:\>set XXX
                                          Environment variable XXX not defined

                                          C:\>set XXX=1

                                          C:\>set XXX
                                          XXX=1

                                          C:\>set XXX=

                                          C:\>set XXX
                                          Environment variable XXX not defined

                                          . That is, setting XXX to empty is effectively unsetting variable. Wondering what `let $XXX=''|echo exists('$XXX')|echo system('set XXX')` outputs. Maybe in windows it is simply not possible to have empty environment variable.

                                          --
                                          --
                                          You received this message from the "vim_dev" maillist.
                                          Do not top-post! Type your reply below the text you are replying to.
                                          For more information, visit http://www.vim.org/maillist.php

                                          ---
                                          You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                          For more options, visit https://groups.google.com/groups/opt_out.
                                        • LCD 47
                                          ... IIRC, SysV had putenv(3), while BSD had setenv(3). The latter had a corresponding unsetenv(3), while the former didn t. ... POSIX? As Wietse Venema used
                                          Message 20 of 27 , Feb 3, 2014
                                          • 0 Attachment
                                            On 2 February 2014, Gary Johnson <garyjohn@...> wrote:
                                            > I've been frustrated by Vim's inability to unset environment variables
                                            > on occasion, too. I don't know what systems would not support this.

                                            IIRC, SysV had putenv(3), while BSD had setenv(3). The latter had a
                                            corresponding unsetenv(3), while the former didn't.

                                            > On my Ubuntu Linux system, the unsetenv(3) man page says that it
                                            > conforms to 4.3BSD and POSIX.1-2001.

                                            POSIX? As Wietse Venema used to put it, you're young and impatient. ;)

                                            /lcd

                                            --
                                            --
                                            You received this message from the "vim_dev" maillist.
                                            Do not top-post! Type your reply below the text you are replying to.
                                            For more information, visit http://www.vim.org/maillist.php

                                            ---
                                            You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                            For more options, visit https://groups.google.com/groups/opt_out.
                                          • ZyX
                                            ... You mean SysV does not have C function for unsetting environment? I guess this is why zsh has coded direct environ global manipulations (controlled by
                                            Message 21 of 27 , Feb 3, 2014
                                            • 0 Attachment
                                              > IIRC, SysV had putenv(3), while BSD had setenv(3). The latter had a
                                              > corresponding unsetenv(3), while the former didn't.
                                              >
                                              > > On my Ubuntu Linux system, the unsetenv(3) man page says that it
                                              > > conforms to 4.3BSD and POSIX.1-2001.
                                              >
                                              > POSIX? As Wietse Venema used to put it, you're young and impatient. ;)

                                              You mean SysV does not have C function for unsetting environment? I guess this is why zsh has coded direct environ global manipulations (controlled by USE_SET_UNSET_ENV). We can probably borrow code from there. I cannot say though in which systems **environ is supported, but both bash and zsh just use only the execve function out of exec* functions family: this means that environment pointer is always passed directly (though with constructs like `FOO=bar frobnicate` and `local -x` it would be strange to see something else: it would be hard to constantly update global variable correctly).

                                              Vim is the opposite: no references of execve, only execl (if_cscope.c) and execvp. Does this mean something?

                                              There is also interesting comment in bash sources: “SUSv3 says unsetenv returns int; existing implementations (BSD) disagree.”. I.e. there is one other standard (SUSv3) with unsetenv.

                                              --
                                              --
                                              You received this message from the "vim_dev" maillist.
                                              Do not top-post! Type your reply below the text you are replying to.
                                              For more information, visit http://www.vim.org/maillist.php

                                              ---
                                              You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                              For more options, visit https://groups.google.com/groups/opt_out.
                                            • ZyX
                                              ... To be more specific: there are two kinds of “direct environ manipulations”: 1. environ = new_environ, 2. envp = (environ [+ i]); *envp = string. -- --
                                              Message 22 of 27 , Feb 3, 2014
                                              • 0 Attachment
                                                > You mean SysV does not have C function for unsetting environment? I guess this is why zsh has coded direct environ global manipulations (controlled by USE_SET_UNSET_ENV). We can probably borrow code from there. I cannot say though in which systems **environ is supported, but both bash and zsh just use only the execve function out of exec* functions family: this means that environment pointer is always passed directly (though with constructs like `FOO=bar frobnicate` and `local -x` it would be strange to see something else: it would be hard to constantly update global variable correctly).

                                                To be more specific: there are two kinds of “direct environ manipulations”:

                                                1. environ = new_environ,
                                                2. envp = (environ [+ i]); *envp = string.

                                                --
                                                --
                                                You received this message from the "vim_dev" maillist.
                                                Do not top-post! Type your reply below the text you are replying to.
                                                For more information, visit http://www.vim.org/maillist.php

                                                ---
                                                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                                For more options, visit https://groups.google.com/groups/opt_out.
                                              • LCD 47
                                                ... [...] Well, historically yes. OSF/1 2.0 (some 20+ years ago) didn t have any way to unset environment, then OSF/1 3.2 had unsetenv(3), but it wasn t
                                                Message 23 of 27 , Feb 3, 2014
                                                • 0 Attachment
                                                  On 3 February 2014, ZyX <zyx.vim@...> wrote:
                                                  > > IIRC, SysV had putenv(3), while BSD had setenv(3). The latter
                                                  > > had a corresponding unsetenv(3), while the former didn't.
                                                  > >
                                                  > > > On my Ubuntu Linux system, the unsetenv(3) man page says that it
                                                  > > > conforms to 4.3BSD and POSIX.1-2001.
                                                  > >
                                                  > > POSIX? As Wietse Venema used to put it, you're young and
                                                  > > impatient. ;)
                                                  >
                                                  > You mean SysV does not have C function for unsetting environment?
                                                  [...]

                                                  Well, historically yes. OSF/1 2.0 (some 20+ years ago) didn't
                                                  have any way to unset environment, then OSF/1 3.2 had unsetenv(3), but
                                                  it wasn't declared by default, or something like that. Sadly I don't
                                                  remember anything about Solaris.

                                                  /lcd

                                                  --
                                                  --
                                                  You received this message from the "vim_dev" maillist.
                                                  Do not top-post! Type your reply below the text you are replying to.
                                                  For more information, visit http://www.vim.org/maillist.php

                                                  ---
                                                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                                  For more options, visit https://groups.google.com/groups/opt_out.
                                                • LCD 47
                                                  ... A quick search reveals this: http://www.greenend.org.uk/rjk/tech/putenv.html According to this guy unsetenv() was added in Solaris 5.10, which is now ~10
                                                  Message 24 of 27 , Feb 3, 2014
                                                  • 0 Attachment
                                                    On 3 February 2014, LCD 47 <lcd047@...> wrote:
                                                    > On 3 February 2014, ZyX <zyx.vim@...> wrote:
                                                    > > > IIRC, SysV had putenv(3), while BSD had setenv(3). The latter
                                                    > > > had a corresponding unsetenv(3), while the former didn't.
                                                    > > >
                                                    > > > > On my Ubuntu Linux system, the unsetenv(3) man page says that it
                                                    > > > > conforms to 4.3BSD and POSIX.1-2001.
                                                    > > >
                                                    > > > POSIX? As Wietse Venema used to put it, you're young and
                                                    > > > impatient. ;)
                                                    > >
                                                    > > You mean SysV does not have C function for unsetting environment?
                                                    > [...]
                                                    >
                                                    > Well, historically yes. OSF/1 2.0 (some 20+ years ago) didn't
                                                    > have any way to unset environment, then OSF/1 3.2 had unsetenv(3), but
                                                    > it wasn't declared by default, or something like that. Sadly I don't
                                                    > remember anything about Solaris.

                                                    A quick search reveals this:

                                                    http://www.greenend.org.uk/rjk/tech/putenv.html

                                                    According to this guy unsetenv() was added in Solaris 5.10, which is
                                                    now ~10 years old. On Solaris you could modify *environment directly,
                                                    but IIRC on OSF/1 that was explicitly forbidden.

                                                    /lcd

                                                    --
                                                    --
                                                    You received this message from the "vim_dev" maillist.
                                                    Do not top-post! Type your reply below the text you are replying to.
                                                    For more information, visit http://www.vim.org/maillist.php

                                                    ---
                                                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                                    For more options, visit https://groups.google.com/groups/opt_out.
                                                  • ZyX
                                                    ... Then I guess most portable *nix solution would be copying **environ contents into some separate vim global and ignoring original global completely, using
                                                    Message 25 of 27 , Feb 3, 2014
                                                    • 0 Attachment
                                                      > A quick search reveals this:
                                                      >
                                                      > http://www.greenend.org.uk/rjk/tech/putenv.html
                                                      >
                                                      > According to this guy unsetenv() was added in Solaris 5.10, which is
                                                      > now ~10 years old. On Solaris you could modify *environment directly,
                                                      > but IIRC on OSF/1 that was explicitly forbidden.

                                                      Then I guess most portable *nix solution would be copying **environ contents into some separate vim global and ignoring original global completely, using execve() to run commands and new pointer for variable accesses from VimL.

                                                      To make changes to environment available in ruby* these changes should be mirrored in **environ with appropriate functions as much as it is possible. It seems that on some systems as an alternative (rather slow one though) to forbidden direct **environ manipulations and unavailable unsetenv() clearenv() with a following sequence of putenv() calls may be used.

                                                      Though before trying to code such workarounds it is better to check support status. If ruby (and, possibly, mzscheme and lua: depends on which ones actually respect **environ) is not supporting systems there is no need to bother.

                                                      * Note: python and perl both create dictionary with environment variable at startup and completely ignore environ global afterwards thus it does not matter for them whether or not **environ is kept up-to-date. Tcl, mzscheme and lua were not checked.


                                                      There are some questions about memory: do I read correctly that not to leak memory you must keep track which environment variables you have set with putenv() and run `vim_free(&(getenv("VAR")[-STRLEN("VAR")-1]));` just before you are about to use putenv() or unsetenv() for such variables? It is also interesting whether you need to free() variables which were already there.

                                                      --
                                                      --
                                                      You received this message from the "vim_dev" maillist.
                                                      Do not top-post! Type your reply below the text you are replying to.
                                                      For more information, visit http://www.vim.org/maillist.php

                                                      ---
                                                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                                      For more options, visit https://groups.google.com/groups/opt_out.
                                                    • LCD 47
                                                      ... [...] No, it s unsafe to free() environment variables. As far as I know most libc implementations just leak a tiny bit of memory there. It s harmless,
                                                      Message 26 of 27 , Feb 3, 2014
                                                      • 0 Attachment
                                                        On 3 February 2014, ZyX <zyx.vim@...> wrote:
                                                        > There are some questions about memory: do I read correctly
                                                        > that not to leak memory you must keep track which
                                                        > environment variables you have set with putenv() and run
                                                        > `vim_free(&(getenv("VAR")[-STRLEN("VAR")-1]));` just before you are
                                                        > about to use putenv() or unsetenv() for such variables? It is also
                                                        > interesting whether you need to free() variables which were already
                                                        > there.
                                                        [...]

                                                        No, it's unsafe to free() environment variables. As far as I know
                                                        most libc implementations just leak a tiny bit of memory there. It's
                                                        harmless, and you certainly aren't supposed to attempt to solve it.

                                                        /lcd

                                                        --
                                                        --
                                                        You received this message from the "vim_dev" maillist.
                                                        Do not top-post! Type your reply below the text you are replying to.
                                                        For more information, visit http://www.vim.org/maillist.php

                                                        ---
                                                        You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                                        For more options, visit https://groups.google.com/groups/opt_out.
                                                      • Bram Moolenaar
                                                        ... Yeah, so we could use unsetenv() if a configure check says it exists on the system. This also means how it works depends on the version of Vim you have.
                                                        Message 27 of 27 , Feb 5, 2014
                                                        • 0 Attachment
                                                          lcd wrote:

                                                          > On 3 February 2014, LCD 47 <lcd047@...> wrote:
                                                          > > On 3 February 2014, ZyX <zyx.vim@...> wrote:
                                                          > > > > IIRC, SysV had putenv(3), while BSD had setenv(3). The latter
                                                          > > > > had a corresponding unsetenv(3), while the former didn't.
                                                          > > > >
                                                          > > > > > On my Ubuntu Linux system, the unsetenv(3) man page says that it
                                                          > > > > > conforms to 4.3BSD and POSIX.1-2001.
                                                          > > > >
                                                          > > > > POSIX? As Wietse Venema used to put it, you're young and
                                                          > > > > impatient. ;)
                                                          > > >
                                                          > > > You mean SysV does not have C function for unsetting environment?
                                                          > > [...]
                                                          > >
                                                          > > Well, historically yes. OSF/1 2.0 (some 20+ years ago) didn't
                                                          > > have any way to unset environment, then OSF/1 3.2 had unsetenv(3), but
                                                          > > it wasn't declared by default, or something like that. Sadly I don't
                                                          > > remember anything about Solaris.
                                                          >
                                                          > A quick search reveals this:
                                                          >
                                                          > http://www.greenend.org.uk/rjk/tech/putenv.html
                                                          >
                                                          > According to this guy unsetenv() was added in Solaris 5.10, which is
                                                          > now ~10 years old. On Solaris you could modify *environment directly,
                                                          > but IIRC on OSF/1 that was explicitly forbidden.

                                                          Yeah, so we could use unsetenv() if a configure check says it exists on
                                                          the system. This also means how it works depends on the version of Vim
                                                          you have. Thus, when you "unlet" an environment variable it may have a
                                                          slightly different effect on different versions of Vim. We better
                                                          document that properly and hope script writers don't make assumptions.

                                                          --
                                                          hundred-and-one symptoms of being an internet addict:
                                                          256. You are able to write down over 250 symptoms of being an internet
                                                          addict, even though they only asked for 101.

                                                          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                                          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                                                          \\\ an exciting new programming language -- http://www.Zimbu.org ///
                                                          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                                                          --
                                                          --
                                                          You received this message from the "vim_dev" maillist.
                                                          Do not top-post! Type your reply below the text you are replying to.
                                                          For more information, visit http://www.vim.org/maillist.php

                                                          ---
                                                          You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                                          For more options, visit https://groups.google.com/groups/opt_out.
                                                        Your message has been successfully submitted and would be delivered to recipients shortly.