Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

VIM shell extension added LANG environment variable to explorer.exe #11

Closed
GoogleCodeExporter opened this issue Aug 18, 2015 · 2 comments
Closed

VIM shell extension added LANG environment variable to explorer.exe #11

GoogleCodeExporter opened this issue Aug 18, 2015 · 2 comments
Labels
auto-migrated defect platform-windows Priority-Medium

Comments

@GoogleCodeExporter
Copy link 

What steps will reproduce the problem?
1. reboot
2. right click any file
3. after menu popup, LANG environment variable (with value zh_CN) is injected 
to explorer.exe (which will affect any new child process of it)

What is the expected output? What do you see instead?
-

What version of the product are you using? On what operating system?
vim73_46 on Windows XP Professional (Simplified Chinese).

Please provide any additional information below.
I'm not sure why VIM need a LANG environment variable to be put to 
explorer.exe, because even without LANG environment, vim display the correct 
GUI language (for me, it's simplified chinese).

Add a LANG environment variable to explorer.exe will affect all new child 
process, I often use Cygwin 1.7, LANG will affect Cygwin to display 
Chinese/multibytes characters.

If LANG environment is needed by vim.exe/gvim.exe, why not putenv to 
vim.exe/gvim.exe itself instead of explorer.exe?

related code may be here:
http://code.google.com/p/vim/source/browse/src/GvimExt/gvimext.cpp#286

Original issue reported on code.google.com by loveti...@gmail.com on 16 Jun 2011 at 3:01
@GoogleCodeExporter
Copy link
Author 

This should be fixed by patch 7.3.276.  Please verify.

Original comment by brammool...@gmail.com on 10 Aug 2011 at 2:33

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author 

Looking at the current code, I don't see how this would be fixed.

The patch apparently touches code that is responsible for launching gvim.exe, 
but LANG= is injected into explorer.exe already at this point.
LANG= will leak into ALL OTHER processes started by Explorer, which also hosts 
the Start Menu, therefore the LANG set by the Vim Shell Extension is very 
likely to leak into ALL OTHER processes started by the user.

The environment of the calling process (which can be a random process hosting a 
Common Controls Dialog or a shell view or something else) is never safe to 
modify.

Please consider not setting LANG= at all.

(I could not test patch 276 as I do not have a vim build environment here and 
the prebuilt binary is patch level 46.)

Original comment by christia...@gmail.com on 29 Dec 2012 at 10:43

@guotsuan guotsuan mentioned this issue Sep 27, 2015
Closed
@coresh coresh mentioned this issue Nov 5, 2015
Closed
@brammool brammool mentioned this issue Nov 19, 2015
Closed
rbtnn referenced this issue in rbtnn/vim Apr 9, 2016
@h-east
Closed #11
e66c1a9
@vim-ml vim-ml mentioned this issue Sep 9, 2016
Open
@marv marv mentioned this issue Apr 10, 2017
Closed
@oymy oymy mentioned this issue Jun 11, 2017
Closed
@brammool brammool mentioned this issue Aug 5, 2017
Closed
@brammool brammool mentioned this issue Oct 26, 2017
Closed
@brammool brammool mentioned this issue Dec 16, 2017
Closed
This was referenced Dec 19, 2017
Closed
Closed
Closed
@brammool brammool mentioned this issue Feb 12, 2018
Closed
@desdic desdic mentioned this issue Aug 20, 2018
Closed
@brammool brammool mentioned this issue Oct 10, 2018
Closed
@clan clan mentioned this issue Dec 28, 2018
Open
@brammool brammool mentioned this issue Jan 5, 2019
Closed
@vim-ml vim-ml mentioned this issue Feb 25, 2019
Closed
@brammool brammool mentioned this issue Apr 15, 2019
Closed
@brammool brammool mentioned this issue Jul 5, 2019
Closed
@JZuming JZuming mentioned this issue Sep 9, 2019
Closed
@mowgli mowgli mentioned this issue Dec 30, 2019
Closed
@brammool brammool mentioned this issue Jan 2, 2020
Closed
@sinaraya sinaraya mentioned this issue Sep 4, 2020
Closed
@estoianovici estoianovici mentioned this issue Nov 2, 2020
Closed
@brammool brammool mentioned this issue Nov 4, 2020
Closed
@k-takata k-takata mentioned this issue Nov 18, 2020
Closed
@chrisbra chrisbra mentioned this issue Dec 7, 2020
Closed
@brammool brammool mentioned this issue Feb 21, 2021
Closed
@Shane-XB-Qian Shane-XB-Qian mentioned this issue Jul 3, 2021
Closed
@brammool brammool mentioned this issue Sep 1, 2021
Open
@easylyou easylyou mentioned this issue Nov 24, 2021
Closed
@brammool brammool mentioned this issue Sep 20, 2022
Open
@jidhub jidhub mentioned this issue Sep 28, 2022
Open
@ant0sha ant0sha mentioned this issue Jan 28, 2023
Closed
@ZWUGA ZWUGA mentioned this issue Oct 19, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
auto-migrated defect platform-windows Priority-Medium
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@k-takata @GoogleCodeExporter