Re: bug with grep 3.0.2 in cygwin 3.0.7
On 2019-08-28 3:16 am, ak...@free.fr wrote: Hi, I encounter some problem with grep option -E on cygwin 3.0.7 echo "a^b" | grep "a^b" #answer a^b ie it's OK but echo "a^b" | grep -E "a^b" #answer nothing " for me it's KO I have to backslash ^ to be OK like : grep -E 'a\^b' Is-it a bug ? I don't know if all versions of cygwin and grep are concerned. Hi Akiki. As others mentioned, it has to do with how regular expressions operate. However the best solution for you in this situation is to not use regular expressions. To search for fixed strings, use fgrep or grep -F. That avoids all issues with meta characters and covers the vast majority of cases when we use grep anyway. To use full power regular expressions read perlre and use grep -P. Thanks. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[PATCH] Cygwin: rmdir: fail if last component is a symlink, as on Linux
If the last component of the directory name is a symlink followed by a
slash, rmdir should fail, even if the symlink resolves to an existing
empty directory.
mkdir was similarly fixed in 2009 in commit
52dba6a5c45e8d8ba1e237a15213311dc11d91fb. Modify a comment to clarify
the purpose of that commit.
Addresses https://cygwin.com/ml/cygwin/2019-09/msg00221.html.
---
winsup/cygwin/dir.cc | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc
index b757851d5..f65c9bdad 100644
--- a/winsup/cygwin/dir.cc
+++ b/winsup/cygwin/dir.cc
@@ -305,15 +305,14 @@ mkdir (const char *dir, mode_t mode)
__try
{
- /* POSIX says mkdir("symlink-to-missing/") should create the
-directory "missing", but Linux rejects it with EEXIST. Copy
-Linux behavior for now. */
-
if (!*dir)
{
set_errno (ENOENT);
__leave;
}
+ /* Following Linux, do not resolve the last component of DIR if
+it is a symlink, even if DIR has a trailing slash. Achieve
+this by stripping trailing slashes or backslashes. */
if (isdirsep (dir[strlen (dir) - 1]))
{
/* This converts // to /, but since both give EEXIST, we're okay. */
@@ -354,6 +353,25 @@ rmdir (const char *dir)
__try
{
+ if (!*dir)
+ {
+ set_errno (ENOENT);
+ __leave;
+ }
+
+ /* Following Linux, do not resolve the last component of DIR if
+it is a symlink, even if DIR has a trailing slash. Achieve
+this by stripping trailing slashes or backslashes. */
+ if (isdirsep (dir[strlen (dir) - 1]))
+ {
+ /* This converts // to /, but since both give ENOTEMPTY,
+we're okay. */
+ char *buf;
+ char *p = stpcpy (buf = tp.c_get (), dir) - 1;
+ dir = buf;
+ while (p > dir && isdirsep (*p))
+ *p-- = '\0';
+ }
if (!(fh = build_fh_name (dir, PC_SYM_NOFOLLOW)))
__leave; /* errno already set */;
--
2.21.0
Re: tcl-tk-dev X dependencies?
On 2019-09-22 00:06, lloyd.wood.yahoo.co.uk via cygwin wrote: > gcc -O2 -DNO_ZLIB -Wall -Wextra -Wconversion -pedantic -I./include -c -o > main.o main.c > In file included from ./include/tcl_utils.h:40:0, > from main.c:38: > /usr/include/tk.h:96:13: fatal error: X11/Xlib.h: No such file or directory > # include > ^~~~ > compilation terminated. > > I'm reasonably sure that selecting and installing the tcl-tk-devel package > (8.6.whatever) should include the X libraries and libX11-devel as a > dependency as well, without having to figure it out and install libX11-devel > yourself. The (very old) Insight Tcl (4) didn't need X, this one does. tcl-tk-devel 8.5.18-1 had all those dependencies, but 8.6.6-1 and 8.6.8-1 dropped those, [possibly because the view of the target for tcl-tk-devel shifted from low level X11 development to high level tcl development, or possibly because ongoing replacement of X by EGL-based alternatives like Android and Wayland eliminate the X requirement] so the new setup does not require them, and may uninstall them on upgrade from the old release, so they would need to be reinstalled manually if you use them: setup... -P 'cygwin-devel libX11-devel libXext-devel libXft-devel libXrender-devel libXss-devel libbz2-devel libexpat-devel libfontconfig-devel libfreetype-devel libpng16-devel tcl-tk-devel'. Perhaps you should be using the Xming development package sources rather than Cygwin/X devel packages, which may not be at the same release as Xming? > (aside: I'm using XMing for all local X display stuff on Cygwin and the > Windows Linux Subsystem, so the X stuff I install under Cygwin is minimal. > Anyone else doing this?) Nope - preferred Cygwin/X as better integrated and more standard. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygwin 3.1.0-0.6 (TEST)
The following packages have been uploaded to the Cygwin distribution as test releases: * cygwin-3.1.0-0.6 * cygwin-devel-3.1.0-0.6 * cygwin-doc-3.1.0-0.6 This release comes with a couple of new features and quite a few bug fixes. The most interesting changes: - A revamp of the old FIFO code. It should now be possible to open FIFOs multiple times for writing, something the old code failed on. Courtesy Ken Brown. - Support the new pseudo console in PTY. Pseudo console is a new feature in Windows 10 1809, which provides console APIs on virtual terminal. With this patch, native console applications can work in Cygwin PTYs. Courtesy Takashi Yano. There have been a lot of changes in the PTY code since cygwin-3.1.0-0.5. Please test! === What's new: --- - Add 24 bit color support using xterm compatibility mode in Windows 10 1703 or later. Add fake 24 bit color support for legacy console, which uses the nearest color from 16 system colors. - Support pseudo console in PTY. Pseudo console is a new feature in Windows 10 1809, which provides console APIs on virtual terminal. With this patch, native console applications can work in PTYs such as mintty, ssh, gnu screen or tmux. - New APIs: sched_getaffinity, sched_setaffinity, pthread_getaffinity_np, pthread_setaffinity_np, plus CPU_SET macros. - New APIs: dbm_clearerr, dbm_close, dbm_delete, dbm_dirfno, dbm_error, dbm_fetch, dbm_firstkey, dbm_nextkey, dbm_open, dbm_store. What changed: - - FIFOs can now be opened multiple times for writing. Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00047.html https://cygwin.com/ml/cygwin/2015-12/msg00311.html - If a SA_SIGINFO signal handler changes the ucontext_t pointed to by the third parameter, follow it after returning from the handler. - Eliminate a header file name collision with on case insensitive filesystems by reverting back to . - Allow times(2) to have a NULL argument, as on Linux. Addresses: https://cygwin.com/ml/cygwin/2019-09/msg00141.html Bug Fixes - - Fix select() on console in canonical mode. Return after one line is completed, instead of when only one key is typed. - Make console I/O functions thread-safe. - Define missing MSG_EOR. It's unsupported by the underlying Winsock layer so using it in send(2), sendto(2), or sendmsg(2) will return -1 with errno set to EOPNOTSUPP and recvmsg(2) will never return it. - Fix a timerfd deadlock. Addresses: https://cygwin.com/ml/cygwin/2019-06/msg00096.html - Fix sigpending() incorrectly returning signals for unrelated threads. Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00051.html - Fix a hang when opening a FIFO with O_PATH. Addresses: https://cygwin.com/ml/cygwin-developers/2019-06/msg1.html - Don't append ".lnk" when renaming a socket file. Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00139.html - Make tcsetpgrp() return -1 if its argument is negative. Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00166.html - Avoid mistakenly moving a process under debugger control into the process group of the debugger. Addresses a problem visible in GDB 8.1.1, related to https://cygwin.com/ml/cygwin/2019-07/msg00166.html - Return ENOEXEC from execve for arbitrary files only if the files are executable. Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00054.html - Fix off-by-one in environment evaluation leading to an abort. Addresses: https://cygwin.com/ml/cygwin-patches/2019-q3/msg00069.html - Make output of /proc/[PID]/stat consistent with getpriority(). Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00082.html - 64 bit only: Avoid collisions between memory maps created with shmat and Windows datastructures during fork. Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00107.html === Have fun, Ken Brown, on behalf of Corinna
[ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
The following packages have been uploaded to the Cygwin distribution as test releases: * cygwin-3.1.0-0.6 * cygwin-devel-3.1.0-0.6 * cygwin-doc-3.1.0-0.6 This release comes with a couple of new features and quite a few bug fixes. The most interesting changes: - A revamp of the old FIFO code. It should now be possible to open FIFOs multiple times for writing, something the old code failed on. Courtesy Ken Brown. - Support the new pseudo console in PTY. Pseudo console is a new feature in Windows 10 1809, which provides console APIs on virtual terminal. With this patch, native console applications can work in Cygwin PTYs. Courtesy Takashi Yano. There have been a lot of changes in the PTY code since cygwin-3.1.0-0.5. Please test! === What's new: --- - Add 24 bit color support using xterm compatibility mode in Windows 10 1703 or later. Add fake 24 bit color support for legacy console, which uses the nearest color from 16 system colors. - Support pseudo console in PTY. Pseudo console is a new feature in Windows 10 1809, which provides console APIs on virtual terminal. With this patch, native console applications can work in PTYs such as mintty, ssh, gnu screen or tmux. - New APIs: sched_getaffinity, sched_setaffinity, pthread_getaffinity_np, pthread_setaffinity_np, plus CPU_SET macros. - New APIs: dbm_clearerr, dbm_close, dbm_delete, dbm_dirfno, dbm_error, dbm_fetch, dbm_firstkey, dbm_nextkey, dbm_open, dbm_store. What changed: - - FIFOs can now be opened multiple times for writing. Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00047.html https://cygwin.com/ml/cygwin/2015-12/msg00311.html - If a SA_SIGINFO signal handler changes the ucontext_t pointed to by the third parameter, follow it after returning from the handler. - Eliminate a header file name collision with on case insensitive filesystems by reverting back to . - Allow times(2) to have a NULL argument, as on Linux. Addresses: https://cygwin.com/ml/cygwin/2019-09/msg00141.html Bug Fixes - - Fix select() on console in canonical mode. Return after one line is completed, instead of when only one key is typed. - Make console I/O functions thread-safe. - Define missing MSG_EOR. It's unsupported by the underlying Winsock layer so using it in send(2), sendto(2), or sendmsg(2) will return -1 with errno set to EOPNOTSUPP and recvmsg(2) will never return it. - Fix a timerfd deadlock. Addresses: https://cygwin.com/ml/cygwin/2019-06/msg00096.html - Fix sigpending() incorrectly returning signals for unrelated threads. Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00051.html - Fix a hang when opening a FIFO with O_PATH. Addresses: https://cygwin.com/ml/cygwin-developers/2019-06/msg1.html - Don't append ".lnk" when renaming a socket file. Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00139.html - Make tcsetpgrp() return -1 if its argument is negative. Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00166.html - Avoid mistakenly moving a process under debugger control into the process group of the debugger. Addresses a problem visible in GDB 8.1.1, related to https://cygwin.com/ml/cygwin/2019-07/msg00166.html - Return ENOEXEC from execve for arbitrary files only if the files are executable. Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00054.html - Fix off-by-one in environment evaluation leading to an abort. Addresses: https://cygwin.com/ml/cygwin-patches/2019-q3/msg00069.html - Make output of /proc/[PID]/stat consistent with getpriority(). Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00082.html - 64 bit only: Avoid collisions between memory maps created with shmat and Windows datastructures during fork. Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00107.html === Have fun, Ken Brown, on behalf of Corinna -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...
On 9/22/2019 3:11 AM, Houder wrote: > - 1. - Farewell > > I will be hospitalized soon, and I do not think I will be back here (any > time soon?). I'm very sorry to hear that. Thanks for your contributions. Best wishes, Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Solved. Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...
Nothing new here; only correction of mistakes that I made (I decided to review my e-mail because Ken Brwon took an interrest in the subject matter). On Fri, 06 Sep 2019 23:53:05, Houder wrote: > To those still interested! :-P [snip] > While I took a closer look at the source code, I found a BUG in > path_conv::check() in winsup/cygwin/path.cc > > https://cygwin.com/ml/cygwin/2019-08/msg00418.html < wrong > ( Date: Sun, 01 Sep 2019 19:38:11 +0200 ) Correction: https://cygwin.com/ml/cygwin/2019-09/msg1.html [snip] > On September 3rd, I discovered that dropping Eric B.'s code snippet, > would introduce a BUG: > > https://cygwin.com/ml/cygwin/2019-09/msg00015.html > ( Date: Tue, 03 Sep 2019 10:39:54 +0200 ) > > 64-@@ ln -s aap noot > .. > 64-@@ rmdir aap > 64-@@ mkdir noot > mkdir: cannot create directory ‘noot’: File exists > 64-@@ mkdir noot/ < Whao! So that is what Eric indicated in his commit! > 64-@@ ls -ld aap < WRONG! WRONG! > drwxr-xr-x+ 1 Henri None 0 Sep 3 10:28 aap > > Different from Posix, Linux does not allow the creation of the directory > aap ... (btw, neither should rmdir delete an existing directory aap if > noot/ is specified) Correction: Linux is in agreement w/ Posix. Cygwin is NOT in agreement w/ Posix (and Linux)i wrt to rmdir(2). > While waiting for a reaction by Eric Blake, I decided to take a closer > look at path_conv::check() ... Could a solution be found in this method? > > (path arguments to (all?) commands are processed by this method) > > Basically, this method consists of a 'double loop', as follows: > > for (;;) // outer loop > for (;;) // inner loop > > - the inner loop tests whether or not a path component is a symlnk > - if it is, the outer loop is reentered, where the symlnk part of >the path is replaced by the target > - finally, the algorithm bails out of both loops if a "real" path >is found (or not) > > Or something very near to this explanation ... > > In case the last component is a symlnk, the name of the symlnk is > saved internally if the path had not been specified w/ a trailing > slash. Otherwise the name of the target is saved internally. Correction: A symlnk is always followed if the pathname ends w/ a trailing slash; if not, it depends on what the system call specified when it invoked "path resolution" (path_conv::check() ). If the system call specified "do not follow", "path resolution" does not follow the symlnk (again, if path does NOT end w/ a trailing /). > In short, there is a basic difference between specifying a path > w/ a trailing slash or not ... Correct! Look at how the response is different between stat final and stat final/ in case of a symlnk. (stat(1) basically calls lstat(2), which directs path resolution NOT to follow a symlnk; however that directive is ignored by path resolution if the pathname ends w/ a slash) mkdir(2) and rmdir(2) are exceptions, in that these syscalls must strip trailing slashes; they must also specify "do not follow". The reason is, that these syscalls must not accept a symlnk as an argument. Henri = -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Solved. Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...
On Sat, 21 Sep 2019 21:02:37, Ken Brown wrote:
[snip]
> I think you can simplify this by eliminating the second part and changing
> the first part to the following:
>
> char sep = dir[strlen (dir) - 1];
> if (isdirsep (sep)
>{
> /* This converts // to /, but since both give EEXIST, we're
> okay. */
> char *buf;
> char *p = stpcpy (buf = tp.c_get (), dir) - 1;
> dir = buf;
> while (p > dir && isdirsep (*p))
>*p-- = '\0';
> /* Reattach dirsep in case of "x:". */
> if (p == dir + 1 && *p == ':' && isalpha (dir[0]))
>p[1] = sep;
>}
Hi Ken,
The ball is your court now. Having said that, in case of multiple trailing
dirseps, your code will reattach the last one.
My code will reattach the first dirsep, not the last one.
And dirseps can be both \ and /.
But again, the ball is your court now ...
Regards,
Henri
=
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...
On Sat, 21 Sep 2019 15:42:36, Ken Brown wrote:
[snip]
> I'll fix this and then look at your patches to mkdir and rmdir. It would
> be very helpful if you would write these as a patch series with cover letter,
> using git format-patch, and send them to the cygwin-patches list.
Hi Ken,
I think this will be my last post. In order to help you understand what
I have been thinking, I describe (using terse language as in telegrams)
what I think path_conv::check() in path.cc does (should do) with regard
to "Unix path resolution", and as a _consequence_ of that understanding,
what mkdir() and rmdir() in dir.cc must do.
(also included are URLs to "standards" I have been studying)
- 1. - Farewell
I will be hospitalized soon, and I do not think I will be back here (any
time soon?).
Therefore, if you believe that the rational behind my modifications is
valid, (and you like to do all this), you are welcome to carry them out
yourself.
I will not be able to carry them out myself.
- 2. - rmdir(2) not in agreement w/ Posix (and Linux)
64-++ uname -a
CYGWIN_NT-6.1 Seven 3.1.0(0.340/5/3) 2019-09-15 17:57 x86_64 Cygwin
64-++ ln -s bar foo
64-++ ls -l foo
lrwxrwxrwx 1 Henri None 3 Sep 22 07:28 foo -> bar
64-++ mkdir bar
64-++ rmdir foo
rmdir: failed to remove 'foo': Not a directory < Correct!
64-++ rmdir foo/ # directory bar has been deleted -- Posix does not
# allow this to happen!
64-++ ls -l bar
ls: cannot access 'bar': No such file or directory
The same applies to mkdir(2).
Eric Blake fixed mkdir() in winsup/cygwin/dir.cc in 2009, but he did
not fix rmdir() in winsup/cygwin/dir.cc at the same time. Why he did
not, I am unable to tell.
- 3. - Path Resolution
Call flow:
mkdir() (and rmdir() ) in winsup/cygwin/dir.cc
path_conv::check() in winsup/cygwin/path.cc < path resolution
mkdir() (or rmdir(2) ) in winsup/cygwin/fhandler_disk_file.cc
To simplify what happens when either mkdir(1) or rmdir(1) is called:
- mkdir() (and rmdir() ) in dir.cc are "the system call entries"
- path_conv::check() performs the "Unix path resolution" (and a lot
of other things, I do not care about at the moment)
- mkdir() (likewise rmdir() ) in fhandler_disk_file.cc is called
by mkdir() in dir.cc, but only if the latter is "satisfied" with
the result of path resolution
- mkdir() (and rmdir() ) in fhandler_disk_file.cc do not perform
path resolution -- these functions use the path as "computed" by
path_conv::check()
Path Resolution (summarized):
pathname = /prefix/final[/]
(in general, there is a difference between a path not ending w/ slash and
a pathname that ends w/ a slash)
- if final/ is a symlnk, it is followed and the target must exist and must
be a directory
- the exceptions to this rule are mkdir(2) and rmdir(2) (in principle, both
these system calls ignore (strip!) the trailing slash)
- if final is a symlnk, it is followed by default (but the target does not
have to exist, let alone be a directory)
- however a system call can specify that the symlnk must NOT be followed;
mkdir(2) and rmdir(2) are examples of these system calls
(because, again, both mkdir(2) and rmdir(2) do _not_ accept a symlnk as
argument, according to specification)
path_conv::check() is "common code" to all system calls w/ arguments that
specify a pathname, i.e. this method does NOT know about the system calls
mkdir() and rmdir(). This method only knows whether or not the pathname
ended w/ a slash or not, and whether or not the system call specified to
follow a symlnk or not (only relevant in case the pathname did NOT end w/
a slash).
Because both mkdir(2) and rmdir(2) should not accept a symlnk as argument,
they must both strip trailing slashes AND specify "do not follow".
My understanding of what "path resolution" must do (that is, what method
path_conv::check() must do wrt Unix path resolution, is based on studying
the URLs I include below.
Regards,
Henri
-
file: references.txt
Bzzt. Posix goes over the top in an attempt to make the difference between
final and final/ as general as is possible.
According to Posix (with regard to "path resolution"), both mkdir(newdir/)
and rmdir(existing-dir/) obey the rules. [1]
-
However the argument to both mkdir(2) and rmdir(2) must be a directory; a
symbolic link is NOT allowed in case of these system calls ("functions").
Said differently, there is NO need to specify the argument WITH a trailing
slash: confusion does not exist: the argument must be a directory.
Moreover, if a symbolic link is specified as an argument in these cases,
"path resolution" should NOT follow this symbolic link.
That is why both mkdir(2) and rmdir(2) will strip a trailing slash; they
also specify "do not follow" for the same reason.
[1] however, my interpretation is, that rmdir(existing-dir/) should succeed
if the target of "existing-dir" (a symbolic link) s indeed a directory ...
But that is wrong! (a symlnk as argument should be
tcl-tk-dev X dependencies?
gcc -O2 -DNO_ZLIB -Wall -Wextra -Wconversion -pedantic -I./include -c -o main.o main.c In file included from ./include/tcl_utils.h:40:0, from main.c:38: /usr/include/tk.h:96:13: fatal error: X11/Xlib.h: No such file or directory # include ^~~~ compilation terminated. I'm reasonably sure that selecting and installing thetcl-tk-devel package (8.6.whatever) should include theX libraries and libX11-devel as a dependency as well,without having to figure it out and install libX11-develyourself. The (very old) Insight Tcl (4) didn't need X, thisone does. (aside: I'm using XMing for all local X display stuffon cygwin and the Windows linux subsystem, so the X stuffI install under Cygwin is minimal. Anyone else doing this?) thanks Lloyd Wood lloyd.w...@yahoo.co.uk http://about.me/lloydwood -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
