| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch addresses an issue whereby the window of
a process created with CreateProcess fails to come
to the foreground.
This occurs when the calling process itself hasn't run any
Windows event processing loop. A repro test case is to make a
program with a main, and and call CreateProcess to spawn
calc.exe or notepad.exe before doing anything else.
It turns out that a dummy call to TranslateMessage makes this
issue goes away. If such a call is made before CreateProcess,
then the spawned process' window comes up in the foreground
as expected.
* winsup/cygwin/Makefile.in (DLL_IMPORTS): We need to link
in user32.dll to call TranslateMessage. Condense the
multiple ${shell ...} call repetition with a foreach.
* winsup/cygwin/spawn.cc (child_info_spawn::worker): Do the
dummy TranslateMessage call before the section of code that
calls CreateProcess or CreateProcessAsUser.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On the majority of VT100-like terminals, when you print a
character in the last column, the cursor sits in a kind of
"limbo", as if the cursor position were one column past the
edge of the screen. Thus when a line feed is output next,
the cursor is then at the start of the next line.
The Win32 console write doesn't do this; the cursor position
wraps to the start of the next line. If a newline is put out,
it translates to an extra newline going to the next-next line.
This spoils the behavior of programs which depend on the VT100
behavior.
In this patch, the VT100 behavior is simulated as follows. A
new flag in the dev_console structure is set when a character
is output to the last column. This flag is then observed in
order to discard a newline (or rather any character which is
mapped mapped to the DWN action).
* winsup/cygwin/fhandler.h (class dev_console): New boolean
data member, eat_newline. This indicates that if a character
is output which moves down to the next line, it should be
discarded rather than sent to the console.
* winsup/cygwin/fhandler_console.cc
(fhandler_console::write_normal): Set the eat_newline flag
if the text output ends up at column zero. Honor the
eat_newline flag when processing a DWN character, and clear
it when processing certain other control characters.
|
|
|
|
|
|
|
|
| |
This allows applications to distinguish whether they
are running on the stock Cygwin or Cygnal.
* winsup/cygwin/uname.cc (uname, uname_x): sysname is now filled
in with CYGNAL_ prefix rather than CYGWIN_.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* winsup/cygwin/include/paths.h (_PATH_CMDEXE): New
preprocessor symbol.
* winsup/cygwin/spawn.cc (av_setup): Use _PATH_CMDEXE
rather than "/bin/sh".
* winsup/cygwin/syscalls.cc (system): Spawn _PATH_CMDEXE
with /c option rather than /bin/sh.
(ETC_SHELLS): Preprocessor symbol removed.
(shell_fp): Global variable removed.
(getusershell): Don't open ETC_SHELLS, just march through
static array of shell names. That array contains only one
entry: _PATH_CMDEXE.
(setusershell, endusershell): Remove references to shell_fp.
(popen): Exec _PATH_CMDEXE rather than "/bin/sh", and the
option is /c.
|
|
|
|
|
|
|
|
|
| |
* winsup/cygwin/spawn.cc (child_info_spawn::worker): Do not
call fhandler_console::need_invisible. It's not working
properly. In an application which has no console because it
was compiled -mwindows, calling this funcion causes a visible
console window to appear. We don't need this in Cygnal;
the Microsoft spawn functions don't pop up such windows.
|
|
|
|
|
|
| |
* winsup/cygwin/spawn.cc (child_info_spawn::worker): Add
STARTF_USESHOWWINDOW to dwFlags of the STARTUPINFOW structure,
and set wShowWindow to SW_SHOWNORMAL.
|
|
|
|
| |
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the Windows Store version of Python is installed, so-called "app
execution aliases" are put into the `PATH`. These are reparse points
under the hood, with an undocumented format.
We do know a bit about this format, though, as per the excellent analysis:
https://www.tiraniddo.dev/2019/09/overview-of-windows-execution-aliases.html
The first 4 bytes is the reparse tag, in this case it's
0x8000001B which is documented in the Windows SDK as
IO_REPARSE_TAG_APPEXECLINK. Unfortunately there doesn't seem to
be a corresponding structure, but with a bit of reverse
engineering we can work out the format is as follows:
Version: <4 byte integer>
Package ID: <NUL Terminated Unicode String>
Entry Point: <NUL Terminated Unicode String>
Executable: <NUL Terminated Unicode String>
Application Type: <NUL Terminated Unicode String>
Let's treat them as symbolic links. For example, in this developer's
setup, this will result in the following nice output:
$ cd $LOCALAPPDATA/Microsoft/WindowsApps/
$ ls -l python3.exe
lrwxrwxrwx 1 me 4096 105 Aug 23 2020 python3.exe -> '/c/Program Files/WindowsApps/PythonSoftwareFoundation.Python.3.7_3.7.2544.0_x64__qbz5n2kfra8p0/python.exe'
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Windows Store version of Python (and apparently other Windows Store
applications) install a special reparse point called "app execution
alias" into the user's `PATH`.
These applications can be executed without any problem, but they cannot
be read as if they were files. This trips up Cygwin's beautiful logic that
tries to determine whether we're about to execute a Cygwin executable or
not: instead of executing the application, it will fail, saying
"Permission denied".
Let's detect this situation (`NtOpenFile()` helpfully says that this
operation is not supported on this reparse point type), and simply skip
the logic: Windows Store apps are not Cygwin executables (and even if
they were, it is unlikely that they would come with a compatible
`cygwin1.dll` or `msys-2.0.dll`).
This fixes https://github.com/msys2/MSYS2-packages/issues/1943
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
|
|
|
|
|
|
| |
- Currently, names of output pipes are "pty%d-to-master" and "pty%d-
to-master-cyg" and names of input pipes are "pty%d-to-slave" and
"pty%d-from-master". With this patch, these pipes are renamed to
"pty%d-to-master-nat", "pty%d-to-master", "pty%d-from-master-nat"
and "pty%d-from-master" respectively.
|
|
|
|
|
| |
- The commit 12325677f73a did not fix enough. With this patch, more
transfer_input() calls are skipped if stdin is redirected or piped.
|
|
|
|
| |
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
|
|
| |
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
|
|
|
|
| |
- Currently, transfer input is triggered even if the stdin of native
app is not a pseudo console. With this patch it is triggered only
if the stdin is a pseudo console.
|
| |
|
|
|
|
|
|
|
|
| |
- If two non-cygwin apps are started simultaneously, attaching to
pseudo console sometimes fails. This is because the second app
trys to attach to the process not started yet. This patch avoids
the issue by attaching to the stub process rather than the other
non-cygwin app.
|
|
|
|
| |
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
|
|
| |
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
|
|
|
|
|
| |
- Perhaps current code misunderstand meaning of the IGNBRK. As far
as I investigated, IGNBRK is concerned with break signal in serial
port but there is no evidence that it has effect to ignore Ctrl-C.
This patch stops ignoring Ctrl-C by IGNBRK for non-cygwin apps.
|
|
|
|
|
| |
- Currently, input already accepted is not discarded on interrupt
by VINTR, VQUIT and VSUSP keys. This patch fixes the issue.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dynamically"
This reverts commit 532b91d24e9496c7988b2b1dda7fc0e8b161f782.
It turned out that this patch has undesired side effects. To wit, if a
newer, post-uname_x executable was linked against or loading an older,
pre-uname_x DLL, and this DLL called uname. This call would jump into
the old uname with the old struct utsname as parameter, but given the
newer executable it would get redirected to uname_x. uname_x in turn
would overwrite stack memory it should leave well alone, given it
expects the newer, larger struct utsname.
For the entire discussion see the thread starting at
https://cygwin.com/pipermail/cygwin/2021-February/247870.html
and continuing in March at
https://cygwin.com/pipermail/cygwin/2021-March/247930.html
For a description where we're coming from, see
https://cygwin.com/pipermail/cygwin/2021-March/247959.html
While we *could* make the scenario in question work by patching dlsym,
the problem would actually be the same, just for dynamic loading. In
the end, we're missing the information, which Cygwin version has been
used when building DLLs.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
| |
|
|
|
|
|
|
|
| |
- Restoring console mode fails in the following scenario.
1) Start cygwin shell in command prompt.
2) Run 'exec chcp.com'.
This patch fixes the issue.
|
|
|
|
|
|
|
|
| |
- If two non-cygwin apps are started simultaneously and this is the
first execution of non-cygwin apps in the pty, these occasionally
hang up. The cause is the race issue between term_has_pcon_cap(),
reset_switch_to_pcon() and setup_pseudoconsole(). This patch fixes
the issue.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
linkat(olddirfd, oldpath, oldname, newdirfd, newname, AT_EMPTY_PATH)
is supposed to create a link to the file referenced by olddirfd if
oldname is the empty string. Currently this is done via the /proc
filesystem by converting the call to
linkat(AT_FDCWD, "/proc/self/fd/<olddirfd>", newdirfd, newname,
AT_SYMLINK_FOLLOW),
which ultimately leads to a call to the appropriate fhandler's link
method. Simplify this by using cygheap_fdget to obtain the fhandler
directly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If linkat(2) is called with AT_EMPTY_PATH on an AF_LOCAL or
AF_UNIX socket that is not a socket file, the current code calls
fhandler_disk_file::link in most cases. The latter expects to be
operating on a disk file and uses the socket's io_handle, which
is not a file handle.
Fix this by calling fhandler_disk_file::link only if the
fhandler_socket object is a file (determined by testing
dev().isfs()).
Also fix the case of a socket file opened with O_PATH by setting
the fhandler_disk_file's io_handle.
|
|
|
|
|
|
|
|
|
|
| |
If facl(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fhandler_disk_file::facl in most
cases. The latter expects to be operating on a disk file and uses the
socket's io_handle, which is not a file handle.
Fix this by calling fhandler_disk_file::facl only if the
fhandler_socket object is a file (determined by testing dev().isfs()).
|
|
|
|
|
|
|
|
|
|
| |
If fchown(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fhandler_disk_file::fchown in most
cases. The latter expects to be operating on a disk file and uses the
socket's io_handle, which is not a file handle.
Fix this by calling fhandler_disk_file::fchown only if the
fhandler_socket object is a file (determined by testing dev().isfs()).
|
|
|
|
|
|
|
|
|
|
| |
If fchmod(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fhandler_disk_file::fchmod in most
cases. The latter expects to be operating on a disk file and uses the
socket's io_handle, which is not a file handle.
Fix this by calling fhandler_disk_file::fchmod only if the
fhandler_socket object is a file (determined by testing dev().isfs()).
|
|
|
|
|
|
|
|
|
|
|
| |
If fstatvfs(2) is called on an AF_LOCAL or AF_UNIX socket that is not
a socket file, the current code calls fhandler_disk_file::fstatvfs in
most cases. The latter expects to be operating on a disk file and
uses the socket's io_handle, which is not a file handle.
Fix this by calling fhandler_disk_file::fstatvfs only if the
fhandler_socket object is a socket file (determined by testing
dev().isfs()).
|
|
|
|
|
|
|
|
|
|
| |
If fstat(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fstat_fs. The latter expects to
be operating on a disk file and uses the socket's io_handle, which is
not a file handle.
Fix this by calling fstat_fs only if the fhandler_socket object is a
file (determined by testing dev().isfs()).
|
| |
|
| |
|
|
|
|
|
|
| |
This is in the spirit of the Linux requirement that file operations
like fchmod(2), fchown(2), and fgetxattr(2) fail with EBADF on files
opened with O_PATH.
|
|
|
|
|
|
| |
This was done for the fhandler_socket_local class in commits
3a2191653a, 141437d374, and 477121317d, but the fhandler_socket_unix
class was overlooked.
|
|
|
|
|
|
|
|
|
|
|
| |
Hi:
RISC-V has added big-endian support recently, which require config.*
stuff update, and we'll send further patch for fix big-endian build,
so I believe this fundamental change should upstream first.
Import upstream 2021-01-25.
Upstream sha1 6faca61810d335c7837f320733fe8e15a1431fc2
|
|
|
|
|
| |
- There seems to be a case that shared_console_info is not set yet
when close() is called. This patch adds guard for such case.
|
|
|
|
|
|
|
|
| |
- After commit 253352e796ff9ec9a447e5375f5bc3e2b92b5293, mc (midnight
commander) crashes with segfault if the shell is bash. This is due
to NULL pointer access in read(). This patch fixes the issue.
Addresses::
https://cygwin.com/pipermail/cygwin/2021-February/247870.html
|
|
|
|
|
|
|
|
|
|
|
| |
When a FIFO is opened, syscalls.cc:open always calls fstat on the
newly-created fhandler_fifo. This results from a call to
device_access_denied.
To speed-up this fstat call, and therefore the open(2) call, use
PC_KEEP_HANDLE when the fhandler is created. The resulting
conv_handle is retained until after the fstat call if the fhandler is
a FIFO; otherwise, it is closed immediately.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the call to get_file_attribute for FIFOs set the first
argument to NULL instead of the handle h returned by get_stat_handle,
thereby forcing the file to be opened for fetching the security
descriptor in get_file_sd(). This was done because h might have been
a pipe handle rather than a file handle, and its permissions would not
necessarily reflect those of the file.
That situation can no longer occur with the new fhandler_fifo::fstat
introduced in the previous commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously fstat on a FIFO would call fhandler_base::fstat.
The latter is not appropriate if fhandler_fifo::open has already been
called (and O_PATH is not set), for the following reason. If a FIFO
has been opened as a writer or duplexer, then it has an io_handle that
is a pipe handle rather than a file handle. fhandler_base::fstat will
use this handle and potentially return incorrect results. If the FIFO
has been opened as a reader, then it has no io_handle, and a call to
fhandler_base::fstat will lead to a call to fhandler_base::open.
Opening the fhandler a second time can change it in undesired ways;
for example, it can modify the flags and status_flags.
The new fhandler_fifo::fstat avoids these problems by creating an
fhandler_disk_file and calling its fstat method in case
fhandler_fifo::open has already been called and O_PATH is not set.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider this case:
- Cygwin installed in C:\cygwin64
- mklink /j D:\cygwin64 C:\cygwin64
- create testcase calling
realpath("/", result);
printf ("%s\n", result);
- start cmd
>C:\cygwin64\bin\bash -lc <path-to-testcase>
/
>D\cygwin64\bin\bash -lc <path-to-testcase>
/cygdrive/c/cygwin64
This scenario circumventing the mount point handling which is automated
in terms of /, depending on the path returned from GetModuleFileNameW
for the Cygwin DLL. When calling D:\cygwin64\bin\bash the dir returned
from GetModuleFileNameW is D:\cygwin64\bin, thus root is D:\cygwin64.
However, junctions are treated as symlinks in Cygwin which explains why
the path gets converted to a cygdrive path.
Fix this by calling GetFinalPathNameByHandleW on the result from
GetModuleFileNameW to get the correct root path, even if accessed via
a junction point.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
|
|
|
|
|
|
|
|
| |
This only affects the very seldom bordercase of apps calling setmode(fd,
0) on fhandlers not calling fhandler_base::set_open_status(). All
fhandlers not calling set_open_status() are binary mode only, but the
way reset_to_open_binmode worked, calling setmode(fd, 0) would have
"reset" their open flags to O_TEXT accidentally.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
|
|
| |
- With this patch, FLUSHO and Ctrl-O (VDISCARD) get working.
|
|
|
|
|
| |
- Previously, FLUSHO feature was implemented incompletely. With
this patch, FLUSHO and Ctrl-O (VDISCARD) get working.
|
|
|
|
| |
- With this patch, "stty noflsh" gets working in pty.
|
|
|
|
|
| |
- With this patch, tty setting such as echo, icanon, isig and onlcr
are reflected to pseudo console mode.
|
| |
|
|
|
|
|
|
|
| |
- If ENABLE_LINE_INPUT is set, Ctrl-S is handled by Windows if the
OS is Windows 7. This conflicts with Ctrl-S handling in cygwin
console code. This patch unsets ENABLE_LINE_INPUT flag in cygwin
and set it when native app is executed.
|
|
|
|
|
|
|
|
| |
- If ENABLE_VIRTUAL_TERMINAL_INPUT is not set, changing window height
does not generate WINDOW_BUFFER_SIZE_EVENT. This happens if console
is in the legacy mode. Therefore, with this patch, the windows size
is checked every time in cons_master_thread() if the cosole is in
the legacy mode.
|