Mercurial > vim
view CONTRIBUTING.md @ 34394:a400c8f9506f v9.1.0123
patch 9.1.0123: MS-Windows: system() may deadlock
Commit: https://github.com/vim/vim/commit/52ecc76c7fa1865603f27bc838efaeaa03cad77c
Author: GuyBrush <miguel.barro@live.com>
Date: Wed Feb 21 20:16:38 2024 +0100
patch 9.1.0123: MS-Windows: system() may deadlock
Problem: MS-Windows: system() may deadlock when calling binaries that
expect stdin
Solution: Ignore the SHELL_EXPAND flag
(GuyBrush)
This happens on binaries that expect stdin. For example:
:echo system("xxd")
will cause a deadlock.
SHELL_EXPAND is a flag devoted to support the linux implementation of
the backtick-expansion mechanism.
On linux backtic-expansion relies in the function mch_expand_wildchars()
(os_unix.c) that delegates on each specific shell (bash, sh, csh, zsh)
the expansion. Basically it composes a shell command that does the
expansion and redirects the output to a file and call_shell() it. On
windows backtick-expansion is performed by Vim itself.
On linux SHELL_EXPAND modifies how mch_call_shell_fork() (os_unix.c)
works. This function:
- relies on posix fork() to spawn a child process to execute a
external command.
- Child and parent process communicate using pipes (or pseudoterminal
if available).
User input (type ahead content) is processed in a loop only if
!(SHELL_EXPAND || SHELL_COOKED).
Though signals are used to detect Ctrl-C in all cases (the input
loop is not necessary to interrupt the function).
In the backtick-expansion the external command is the shell command
that provides the expansion. For the child redirection:
- SHELL_EXPAND replaces stdin, stdout & stderr to /dev/null. This is
why the shell command composed includes redirection (otherwise
output would be lost).
- !SHELL_EXPAND replaces stdin, stdout & stderr with the parent
created pipes (or pseudoterminal).
Note that the use of SIGINT signal prevents mch_call_shell_fork()
from hanging vim.
On Windows mch_system_piped() (os_win32.c) (which is only used when the
GUI is running) mimics mch_call_shell_fork() (os_unix.c).
Win32 lacks fork() and relies on CreateProcessW() and only has pipe
support (not pseudoterminal) which makes the implementation much
different.
But, the key idea is that windows lacks signals, the OS provides support
for console apps but gvim is not one. The only way of detecting a Ctrl-C
is actually processing user input (type ahead content). By ignoring the
user input under SHELL_EXPAND the function can hang gvim.
Ignoring SHELL_EXPAND flag has no consequence in Windows because as
mentioned above it is only meaningful in linux.
closes: #13988
Signed-off-by: GuyBrush <miguel.barro@live.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
| author | Christian Brabandt <cb@256bit.org> |
|---|---|
| date | Wed, 21 Feb 2024 20:30:02 +0100 |
| parents | c97e9e2d79a4 |
| children | be122dc08867 |
line wrap: on
line source
# Contributing to Vim Patches are welcome in whatever form. Discussions about patches happen on the [vim-dev][0] mailing list. If you create a pull request on GitHub it will be forwarded to the vim-dev mailing list. You can also send your patch there directly (but please note, the initial posting is subject to moderation). In that case an attachment with a unified diff format is preferred. Information about the mailing list can be found [on the Vim website][0] A pull request has the advantage that it will trigger the Continuous Integration tests, you will be warned of problems (you can ignore the coverage warning, it's noisy). Please consider adding a test. All new functionality should be tested and bug fixes should be tested for regressions: the test should fail before the fix and pass after the fix. Look through recent patches for examples and find help with ":help testing". The tests are located under "src/testdir". Contributions will be distributed with Vim under the Vim license. Providing a change to be included implies that you agree with this and your contribution does not cause us trouble with trademarks or patents. There is no CLA to sign. # Reporting issues We use GitHub issues, but that is not a requirement. Writing to the Vim mailing list is also fine. Please use the GitHub issues only for actual issues. If you are not 100% sure that your problem is a Vim issue, please first discuss this on the Vim user mailing list. Try reproducing the problem without any of your plugins or settings: vim --clean If you report an issue, please describe exactly how to reproduce it. For example, don't say "insert some text" but say what you did exactly: `ahere is some text<Esc>`. Ideally, the steps you list can be used to write a test to verify the problem is fixed. Feel free to report even the smallest problem, also typos in the documentation. You can find known issues in the todo file: `:help todo`. Or open [the todo file][todo list] on GitHub to see the latest version. # Syntax, indent and other runtime files The latest version of these files can be obtained from the repository. They are usually not updated with numbered patches. If you find a problem with one of these files or have a suggestion for improvement, please first try to contact the maintainer directly. Look in the header of the file for the name and email address. The maintainer will take care of issues and send updates to the Vim project for distribution with Vim. If the maintainer does not respond, contact the [vim-dev][0] mailing list. # Translations Translating messages and runtime files is very much appreciated! These things can be translated: * Messages in Vim, see [src/po/README.txt][1] Also used for the desktop icons. * Menus, see [runtime/lang/README.txt][2] * Vim tutor, see [runtime/tutor/README.txt][3] * Manual pages, see [runtime/doc/\*.1][4] for examples * Installer, see [nsis/lang/\*.nsi][5] for examples The help files can be translated and made available separately. See https://www.vim.org/translations.php for examples. # How do I contribute to the project? Please have a look at the following [discussion][6], which should give you some ideas. Please also check the [develop.txt][7] helpfile for the recommended style. Often it's also beneficial to check the surrounding code for the style being used. # I have a question If you have some question on the style guide, please contact the [vim-dev][0] mailing list. For other questions please use the [Vi Stack Exchange][8] website, the [vim-use][9] mailing list or make use of the [discussion][10] feature here at github. [todo list]: https://github.com/vim/vim/blob/master/runtime/doc/todo.txt [0]: http://www.vim.org/maillist.php#vim-dev [1]: https://github.com/vim/vim/blob/master/src/po/README.txt [2]: https://github.com/vim/vim/blob/master/runtime/lang/README.txt [3]: https://github.com/vim/vim/blob/master/runtime/tutor/README.txt [4]: https://github.com/vim/vim/blob/master/runtime/doc/vim.1 [5]: https://github.com/vim/vim/blob/master/nsis/lang/english.nsi [6]: https://github.com/vim/vim/discussions/13087 [7]: https://github.com/vim/vim/blob/master/runtime/doc/develop.txt [8]: https://vi.stackexchange.com [9]: http://www.vim.org/maillist.php#vim-use [10]: https://github.com/vim/vim/discussions