>
> On Sun, Aug 9, 2009 at 5:43 PM, Tony Mechelynck wrote:
>>
>> On 26/07/09 20:07, Matt Wozniski wrote:
>>>
>>> On Sun, Jul 26, 2009 at 11:34 AM, Efraim Yawitz<efraim.yawitz@gmail.com> wrote:
>>>>
>>>> On Sun, Jul 26, 2009 at 6:20 PM, Gregory Margo<gmargo@pacbell.net> wrote:
>>>>>
>>>>> No. Shells in general (bash,dash,ksh,zsh,tcsh,csh) allow complete
>>>>> removal of the environment variable. Bourne-type shells use "unset"
>>>>> and C-type shells use "unsetenv" commands.
>>>>>
>>>> OK, but why is that necessary?
>>>
>>> For programs that have different behavior depending on whether or not
>>> a given environment variable exists - there are a great many programs
>>> that fall into this category. For instance...
>>>
>>> $ export PAGER='echo hello'
>>> $ man man
>>> hello
>>> $ PAGER=
>>> $ man man
>>> <... implicitly paged as though by 'cat' ...>
>>> $ unset PAGER
>>> $ man man
>>> <... implicitly paged through 'more' ...>
>>>
>>> So, you get different behavior for a non-empty environment variable,
>>> an empty environment variable, and no environment variable.
>>>
>>> ~Matt
>>
>> I think we're up against a culture difference here. On Dos/Windows,
>> setting an environmant variable to the empty string, e.g. by
>>
>> SET SOMESTUFF=
>>
>> actually removes it, and to test if it exists, you check it against the
>> empty sring, e.g;
>>
>> IF x%SOMESTUFF% == x GOTO SOMESTUFFERROR
>> GOTO SOMESTUFFON
>> :SOMESTUFFERROR
>> ECHO SOMESTUFF undefined
>> GOTO FINISH
>> :SOMESTUFFON
>> ...
>> ...
>> :FINISH
>>
>> On Unix, it's not the same: you can set an environment variable
>> explicitly to the empty string, e.g. (with bash)
>>
>> export SOMESTUFF=''
>>
>> and that's not the same as having it unset.
>
> That's not really a culture difference, afaics. It's not uncommon to
> see something like
>
> if [ "x$var" = x ]; then
> ...
> fi
>
> in shell scripts on Unix, even though there is a distinction between
> empty environment variables and nonexistent ones. The same
> distinction exists on Windows as well, even if it isn't exposed by the
> batch scripting language. The only reason code checking if a variable
> expands to the empty string is idiomatic is because it's common to
> want to treat empty and nonexistent variables the same way, not
> because it's impossible to distinguish them.
>
> ~Matt
On Dos (and Windows AFAIK),
SET STUFF=
_unsets_ the STUFF environment variable. On Unix (assuming bash syntax
with which I am most familiar),
export STUFF=
_sets_ it to the empty string, and you need a different command to unset
it. On Dos, you cannot set an environment variable to the empty string
other than by writing your own assembly-language program to meddle with
the program's parent's environment (SET STUFF="" on the command-line
sets it to two quotes), and the only case when an environment can be set
in the "normal" run of things to the empty string is, IIRC, if there is
no COMSPEC line in CONFIG.SYS, the initial COMMAND.COM shell starts from
C:\ with no command-line arguments, and you don't set COMSPEC
thereafter. That's in Dos. I don't think you can have an empty
environment variable variable in Windows other than by means of the
"Advanced System Settings" GUI or (in console mode) of an ad-hoc program
(as above).
Best regards,
Tony.
--
Measure with a micrometer. Mark with chalk. Cut with an axe.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
No comments:
Post a Comment