| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Unify the licence headers so that all same-licensed files use the exact
same text.
For some time now, libvte has been effectively LGPL3+ due to newer files being
LGPL3+ only while some older files were still nominally LGPL2+ as per their
licence headers. Exercise the "or (at your option) any later version" upgrade
option to henceforth use, modify and distribute all these files under LGPL3+
only.
|
|
|
|
|
| |
Pass unqiue_ptr<SpawnOperation> to ::run_async to make it clear that it
takes ownership of the operation.
|
|
|
|
|
|
|
| |
Ported from https://gitlab.gnome.org/GNOME/glib/-/issues/2140
with some adjustments.
Fixes: https://gitlab.gnome.org/GNOME/vte/-/issues/263
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The problem was that after moving the SpawnContext into the SpawnOperation,
~SpawnContext of the move source's context called the child setup data destructor
but the data now belongs to the move target.
Fix this by using a std::shared_ptr.
Fixes: https://gitlab.gnome.org/GNOME/vte/-/issues/237
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add vte_pty_spawn_with_fds_async() and vte_terminal_spawn_with_fds_async()
that take an array of file descriptors, and an array of integers specifying
where to assign the file descriptors to in the child process.
This also fixes the equivalent of gspawn/gsubprocess bug
https://gitlab.gnome.org/GNOME/glib/-/issues/2097 when using
these new functions (e.g. in gnome-terminal).
|
|
The old spawning code was copied from glib, and used a thread to
make the synchronous variant into an asynchronous one. This had the
problem that fork(3p) was called from the worker thread, not the
calling (main) thread.
The new code replaces this with a two-stage approach where the
fork takes place on the calling thread, and only the async wait
for the child error is done in a worker thread.
This also unifies the sync and async spawn variants to use
the exact same code, only called in one or two stages.
This also removes calls to setenv/unsetenv from the child setup
code, which are not safe to do there. Instead, the environment
is prepared in advance and used via execve(2).
Fixes: https://gitlab.gnome.org/GNOME/vte/-/issues/118
|