Re: Interest in Emacs patched to handle Windows paths?
On 2019-07-26 10:11, Soegtrop, Michael wrote: Dear Cygwin Team and Users, In May I modified Emacs for Cygwin so that it can truly handle Windows paths. You might be interested in the Cygnal project: http://www.kylheku.com/cygnal/ In this project, I modified Cygwin itself to use Windows paths. There are some other changes, of course, all documented in detail. I use Cygnal for a native Windows port of the TXR language. This is just the Cygwin version of txr.exe bundled with the patched cygwin.dll (plus some additional needed libs), wrapped up in an installer. There is no separate build; just packaging. Cygnal isn't an environment; it doesn't replace Cygwin. It's a way of deploying Cygwin programs stand-alone to Windows users who expect certain Windows conventions, while retaining the advantages of Cygwin's large and detailed POSIX API footprint. -- 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: Interest in Emacs patched to handle Windows paths?
On 2019-07-26 13:08, Soegtrop, Michael wrote: Dear Kaz, You might be interested in the Cygnal project: http://www.kylheku.com/cygnal/ from your description I would think this doesn't work for Emacs. Emacs has its own functions for path management, e.g. to decide what an absolute path is. Yes, like this: :) C:\Users\kaz>txr This is the TXR Lisp interactive listener of TXR 221. Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet. 1> (abs-path-p "C:\\foo") t 2> (abs-path-p "C:foo") nil 3> (abs-path-p "/foo") t Cygnal is not a magic fix for programs that manipulate path; it provides a POSIX-like system interface, but which takes Windows paths. If the program manipulates paths, that has to be ported/extended to support Windows paths. What it provides is that the open() system call and others understand drive letter names and such. chdir() understands the concept of a per-drive current working directory, and the "currently logged drive". Check this out: 4> (chdir "f:") ;; basically a bare interface to the chdir syscall t 5> (pwd) ;; wrapper for getcwd "F:/" 6> (chdir "c:") t 7> (pwd) "C:/Users/kaz" 8> If you want a program ported to Windows via Cygwin to understand native conventions, Cygnal goes a long way. -- 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: Bug report: Killing a native process may not actually kill it
On 2019-08-28 08:59, Quanah Gibson-Mount wrote: --On Wednesday, August 28, 2019 6:45 PM +0200 Corinna Vinschen wrote: Not likely. Cygwin handles Ctrl-C by generating SIGINT. This only works reliably with Cygwin processes. There's $ /bin/kill -f to call the Win32 function TerminateProcess(pid) on a non-Cygwin process or an unresponsive Cygwin process. As I noted, it was not unique to control-C. In any case, unfortunate to hear that Cygwin will not address this issue. kill -f is clearly not desirable for doing a clean shutdown of a process. Cygwin can't introduce Unix-like shutdown mechanisms (like the handling a non-fatal signal) into non-Cygwin processes which have no concept of that. It makes no sense. The Windows way to try to try to obtain a clean shutdown is to send a message to a window handle (WM_CLOSE or WM_QUIT or whatever); then if that fails, TerminateProcess rudely. kill shouldn't try to translate signals to window handle messages; it makes no sense. -- 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: Where is igawk and why doesn't @include replicate this feature?
On 2019-09-10 23:54, Troy Kenah wrote: Hi All, I have a large number of scripts that were using the the igawk script, however I have updated my gawk to a newer release that has obsoleted/removed the igawk script. Gawk's build system stopped installing igawk over five years ago: http://git.savannah.gnu.org/cgit/gawk.git/commit/?id=577ece63770a6c4b5ad00d6998127fb7e85b86b9 I used to embed @include junk.awk statements to reduce repetitive code but this no longer works. These were files were not functions, simply code snippets; this is the type of error I am now seeing: Clearly, the script is not exactly obsolete, since the @include facility in Gawk seems only to work with syntactically complete units, whereas igawk performs blind textual inclusion. If I were you, I'd just bring the igawk script into my code base and continue that way. It's a tiny script that is licensed as public domain; it doesn't carry much "technical debt" or licensing debt. -- 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: malloc(0) crashing with SIGABRT
On 2019-09-11 20:59, Brian Inglis wrote: On 2019-09-09 11:13, Petr Skočík wrote: There's been a twitter discussion on how different POSIX platforms handle malloc(0): https://twitter.com/sortiecat/status/1170697927804817412 . As for Cygwin, the answer appears to be "not well", but this should be easy to fix. POSIX SUS V4 2018 says: "RETURN VALUE Upon successful completion with size not equal to 0, malloc() shall return a pointer to the allocated space. If size is 0, either: A null pointer shall be returned [CX] [Option Start] and errno may be set to an implementation-defined value, [Option End] or A pointer to the allocated space shall be returned. The application shall ensure that the pointer is not used to access an object. Otherwise, it shall return a null pointer [CX] [Option Start] and set errno to indicate the error. [Option End]" The second option could be implemented by a pointer to an unmapped page, or a reference to an inaccessible mmap-ed area length zero. That's easy: the null pointer, plus some small offset that observes alignment, like 16. (Alignment is important even if the memory isn't accessed, because nonportable programs depend on it for other reasons, like being able to use the least significant few bits of a pointer for tagging.) -- 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: Bug in TIME function
On 2019-09-12 11:05, tl...@twcny.rr.com wrote:
The code below returns -1. It shouldn't.
Says who?
I don't see anything in the specification which says that a null pointer
argument is allowed:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/times.html
Passing a null pointer to an ISO C or POSIX library function results in
undefined behavior,
except where it is documented otherwise.
GNU/Linux (specifically the Glibc implementation of libc) also doesn't
document any such extension (being able to pass a null pointer to
times).
So even in light of the goal of Cygwin providing GNU/Linux compatibility
beyond POSIX, there is no justification for supporting times(0).
#include
#include
int main(int argc, char *argv[])
{
printf("return value %ld\n", (long)times((struct tms*)0));
The pointer cast is not required here; you have a prototype of
the times function in scope; the equivalent times(0) will give you
the undefined behavior you're asking for.
return 0;
}
--
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: Bug in TIME function
On 2019-09-12 11:16, Kaz Kylheku wrote: So even in light of the goal of Cygwin providing GNU/Linux compatibility beyond POSIX, there is no justification for supporting times(0). What I wrote here is not true; on Linux, this is a system call, which provides detection of some kinds of bad pointers, turning them into -1/EFAULT. -- 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: Bug in TIME function
On 2019-09-13 12:11, Wayne Davison wrote: On Fri, Sep 13, 2019 at 4:27 AM wrote: In Linux [times()] returns a time value and return code of 0: The Linux man page for times() mentions this special behavior, how it isn't portable, and even advises against using the function: "On Linux, the buf argument can be specified as NULL, with the result that times() just returns a function result. However, POSIX does not specify this behavior, and most other UNIX implementations require a non-NULL value for buf." Ah, so it is a documented extension in Linux, after all. In that case, Cygwin should support it. One might argue that it would be nice to emulate the Linux behavior, but it's not required by POSIX. Cygwin's explicit motto is "Get that Linux feeling --- on Windows"; and a tiny part of the Linux feeling is that times(NULL) works. -- 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: Hippo icon!
On Tue, 3 May 2005, Chris Herborth wrote: > Date: Tue, 03 May 2005 12:02:21 -0400 > From: Chris Herborth <[EMAIL PROTECTED]> > To: cygwin@cygwin.com > Subject: Re: Hippo icon! > > Chris January wrote: > >> I noticed that the icon for Cygwin on the website has changed from the > >> green-n-black C to a roaring hippo. > >> http://www.cygwin.com/hippo.jpg > > > > It's to shake off the impression that Cygwin is bloated and slow. No, > > wait > > Hippos are bloated and fast. And rather dangerous, actually... Most people don't know anything about hippos, other than the content of the popular stereotype. An icon exploits the stereotyped image of its subject, not its hidden properties that are known to few, and are possibly controversial. Are hippos fast? Well, compared to what? From among images of land animals, would you choose one of a hippo to represent speed? What about agility? Assuming hippos are fast, can they change direction rapidly also? Are they flexible? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: LS and spaces in path names (the xth)
On Tue, 28 Jun 2005, Andreas Eibach wrote: > Needless to say that scripts containing > > for i in `ls *.dat*`; do Ouch!!! > will NOT work, because Cygwin will interpret each sub-string between the \ ' > s separately, making parsing files a nuisance. That script won't work anywhere. Who ever writes braindamaged shell code like that? It takes the output of a command and re-tokenizes it, so that files with spaces will turn into multiple tokens. You want: for i in *.dat* ; do some-command "$i" ; done The quotes around $i are important too. Or, to be properly paranoid, you have to watch for "$i" expanding into something that looks like a command option to some-command. If some-command is properly designed, it takes the -- option to indicate ``no more options'': for i in *.dat* ; do some-command -- "$i" ; done -- Meta-CVS: the working replacement for CVS that has been stable since 2002. It versions the directory structure, symbolic links and execute permissions. It figures out renaming on import. Plus it babysits the kids and does light housekeeping! http://freshmeat.net/projects/mcvs -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Trouble with key in vim (and more)
On Sun, 17 Jul 2005, Myles wrote: > Hi forum, > > When trying to use to complete on help items, or file loading, > or etc, I get a ^I (ctrl-I) character instead. For example: > > :h h > > I see > > :h h^I^I > > Also, the arrow keys don't work like they're supposed to. Like if I've > alreads performed some : commands and then I > > : > > I don't get recall like I should. This is the normal vim behavior. Unless you configure vim otherwise via ``:set nocompatible,'' it behaves in a vi compatibility mode. You stick this into your .vimrc file. Someone must have enabled this for you in the previous Vim installations, or else you did it so long ago that you forgot about it. -- Meta-CVS: the working replacement for CVS that has been stable since 2002. It versions the directory structure, symbolic links and execute permissions. It figures out renaming on import. Plus it babysits the kids and does light housekeeping! http://freshmeat.net/projects/mcvs -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Obscene Content Tiebreaker
Sorry folks I just could not resist. A twit hit a free software mailing list. On censoring fortune he did insist. ``Can't have limericks about pussies and dicks!'' A few clicks Googled him out a masochist! (Sheer creative writing, of course. Even the slightest resemblance between this limeric and any actual mailing list participants anywhere is purely coincidental). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: _beginthreadex
On Wed, 19 Jan 2005, Kukuk Barbara wrote: > Hi, > I would like to know how I can use _beginthreadex in my program. > It is shown as an unresolved external. Do I have to link a special > library? This function is not a Win32 API, but a function in Microsoft Visual Studio's C library. Unlike UNIX-like systems, Windows does not have the equivalent of a C library for providing run-time support to C programs (malloc, printf, etc). C programming environments targetting Windows have to provide their own. _beginthreadex is a wrapper for CreateThread which routes the thread through a startup function within the C library, where it can initialize some thread-local storage specific to that library and whatnot. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: file globbing
On Thu, 17 Feb 2005, James Lemke wrote: > Date: Thu, 17 Feb 2005 10:31:37 -0500 > From: James Lemke <[EMAIL PROTECTED]> > To: cygwin@cygwin.com > Subject: file globbing > > I've recently noticed a problem with Cygwin ls. I did a quick search of It's not ls that does the globbing. That is done by the shell before it runs ls. > the archives, but didn't get any hits. Has anyone else seen this? > Try: ls -dl ../tcl[7-9]* > Result on Linux: ../tcl ../tcl8 > Result on Cygwin: ../tcl8 > > That is, on Cygwin tcl[7-9]* does not match tcl. I think it should. It should not. Shell regular expressions for globbing filenames are not the same as normal regular expressions. [7-9]* does not mean ``zero or more occurences of a character in the 7-9 class'' it means ``exactly one occurence of 7, 8 or 9 followed by zero or more characters''. Not sure what is going on with the Linux example. If you are investigating glob behavior, try using echo rather than ls: echo ../tcl[7-9]* If there is any confusion about what is being matched due to leading, trailing or embedded whitespace, try this: for x in ; do echo "<$x>"; done Then you get each matching name, in angle braces, on a separate line. > I have upgraded to the latest coreutils and still see the problem. > Comments? The only apparent problem is on the Linux side, where a pattern that calls for a digit in the range 7-8 seems to be matching a name that contains no such thing. It does look like the shell you are using on Linux is interpreting the pattern as a full regular expression. -- Meta-CVS: the working replacement for CVS that has been stable since 2002. It versions the directory structure, symbolic links and execute permissions. It figures out renaming on import. Plus it babysits the kids and does light housekeeping! http://freshmeat.net/projects/mcvs -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Directory names
On Tue, 22 Feb 2005, Shankar Unni wrote: > Dave Korn wrote: > > > First off, even on POSIX, * isn't a valid filename character > > [Clang!] > > % mkdir '*' > % ls > */ > % POSIX makes some recommendations about what constitutes portable filenames. The above is a nonportable name that your operating system or file system accepts. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: lstat on FAT - Was: Problem with find on FAT drives
On Tue, 23 Mar 2004, Volker Quetschke wrote: > Date: Tue, 23 Mar 2004 14:45:41 -0500 > From: Volker Quetschke <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [cygwin] lstat on FAT - Was: Problem with find on FAT drives > > > Hi! > > > > I just found a strange problem when using find on a FAT drive. > > I got: "find: .\tmp changed during execution of find" > > OK, I analyzed the problem a bit and found that lstat can > give different inode numbers on fat, see the attached testcase. Structurally, FAT does not have inodes or hard links. Consequently, the inode numbers in a stat() implementation over FAT don't have the semantics of inode identifiers. So for instance "tmp" and "tmp/." are different objects, not merely different directory entries pointing at the same inode as they would be in a UNIX-like filesystem. By the way, you can investigate inode numbers using the -i option of ls instead of hacking up your own C program. $ mkdir tmp $ ls -din tmp tmp/. -- Meta-CVS: the working replacement for CVS that has been stable for two years. It versions the directory structure, symbolic links and execute permissions. It figures out renaming on import. Plus it babysits the kids and does light housekeeping! http://freshmeat.net/projects/mcvs -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Behaviour of 'find' under 'bash'
On Wed, 12 May 2004, Song Ken Vern-E11804 wrote: > Hi, > > The find command seems to be behaving differently depending on the content of the > current directory. Isn't that sort of a design requirement for a search tool? ;) > drwxr-xr-x+ 4 Administ 4096 May 12 08:41 ./ > drwxr-xr-x+ 12 Administ 8192 May 6 17:02 ../ > drwxr-xr-x+ 2 Administ 8192 May 11 14:06 Code/ > drwxr-xr-x+ 4 Administ 0 Mar 24 10:22 XML/ > -rwxr-xr-x+ 1 Administ 55022 Apr 20 11:00 XMLParser-rik.java* > -rw---1 E11804 mkgroup-28367 May 12 08:41 cygcheck.out > > When I issue a : - > > 08:43$ find ./ -name *.java You do know that your shell expands the *.java expression before feeding the resulting command line to the find command? So you are essentially invoking find like this: find . -name XMLParser-rik.java you are telling find to locate all files which have that exact name. > > But when I issue a :- > > 08:43$ find ./ -name \*.java Now you are escaping the wildcard so the shell does not process it. The find command now receives the pattern and interprets it in the context of its search. > It seems like the the shell is substituting '*' with the filename in the current > directory. You are close. The shell is doing something, indeed. ;) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Netsky worm
On Wed, 30 Jun 2004, Robert Pendell wrote: > Right. Windows actually stole certain things from UNIX. Example: The > system32\drivers\etc folder is taken directly from UNIX. There are > certain others stolen from UNIX too but I can't remember what. ``Stolen'' is a big word. Microsoft has as much right to imitate good or bad ideas from elsewhere as anyone else. I can think of lots of things in Windows that were imitated from Unix and surrounding culture. Most of them are imitated badly; the nice, simple concepts are typically contorted and murdered in the process. - The use of the C language for expressing the system interfaces and for developing the kernel. [ All very bastardized under Windows. Crap like __declspec(dllimport) and __stdcall and __pascal, WINAPI hack layered upon hack. ] - Network stack. [ Direct from Berkeley Unix ]. - The basic kernel architecture. [ Though unreliable; trivial driver reconfigurations require reboot. ] - Hierarchical filesystem with . and .. directories, and paths expressed left to right separated by slashes (albeit backslashes). [ But with drive letter name stupidities, 8.3 backward compatibility hacks, UNC paths that don't work everywhere, etc. ] - Symbolic links (shortcuts) [ Not recognized at the deepest OS levels, just a superficial trick seen by the Shell API ], and hard links (NTFS). - Unstructured files with open/read/write type primitives, with EOF indicated by a short read. [ Complicated API with a huge number of parameters just to open a file. Stupidities in the filesystem regarding concurrent operations. ] - Object file formats like COFF and ar archives in the Microsoft toolchain. - Command shell with < > | redirection, by way of DOS. [ Antedeluvial syntax and semantics. ] - Shell and utilities as a separate programs called by name. - Devices mapped into the filesystem space [ but without regard for pathname namespaces. Cannot have a file called CON or PRN in any directory! ] - Command lines and environment variables, passed down to child processes. [ But a single command line string is passed that must be tokenized by the called process, so there is no consistent, reliable way to pass a general list of arguments. ] - Path environment variable, containing delimited list of places to look for executables. The list goes on. Do you know that animated film _The Nightmare before Christmas_? If UNIX is like Christmas, then Windows is like Pumpkin King Jack Skellington's bastardized misunderstanding of Christmas. The interfaces and mechanisms of Windows are like Jack's gruesome toys that scare the children. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem with clisp package.
The packaged CLISP is built using libsigsegv. However, that library is
not packaged with it, so it's not possible to do custom links of CLISP,
which some CLISP-based applications need to do!
(That is to say, some programs add their own C functions to CLISP by
adding them to the set of pieces from which CLISP is made to link
a custom image. These pieces, static libs really, are collectively
called a ``linking set''. When CLISP is built and installed, it
creates two linking sets by default, in $PREFIX/lib/clisp/base and
$PREFIX/lib/clisp/full representing a minimal and fully featured
image, respectively. CLISP includes a ``linkkit'' mechanism by which
new linking sets can be constructed based on adding material to existing
ones.)
Anyway, the packaged CLISP wants to link in -lsigsegv which it expects
to find in /usr/local/libsigsegv-cygin/lib. It's an external piece,
not part of the linking set. This reference is found
in the makevars file of both the base and full linking set:
/usr/lib/clisp/{base,full}/makevars.
The very location of the reference is fishy in itself since a package
unstalled in /usr shouldn't refer to /usr/local stuff!
It looks like the package was built against a locally installed
libsigsegv, introducing a dependency which was then overlooked.
If you don't have libsigsegv, CLISP will build without it; it's not an
essential dependency. In that case the makevars files will end up with
-DNO_SIGGSEGV in CFLAGS, and there is no reference to -lsigsegv in the
LIBS variable. In other words, rebuilding CLISP from scratch without
installing libsigsegv at all is one way to cure the problem. Another
fix would be to have a proper Cygwin package for this lib and make it a
dependency.
--
Meta-CVS: directory structure versioning; versioned symbolic links;
versioned execute permission; versioned property lists; easy branching
and merging and third party code tracking; all implemented over the
standard CVS command line client -- http://freshmeat.net/projects/mcvs
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Missing /dev
This is a tiny little annoyance in Cygwin: various device paths exist, like your controlling terminal /dev/conin. However, there is no actual /dev directory in the filesystem. This confuses some programs that do parsing on the path rather than just pass the entire string to open(). E.g. CLISP's file I/O library: [6]> (with-open-file (f "/dev/conin" :direction :input) (read f)) *** - nonexistent directory: #P"/dev/" The simple workaround is to ``mkdir /dev'', but would it be a bad idea for the Cygwin installer to create this directory? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: stdio.h: broken standard compliance.
On Sun, 09 Oct 2011 11:08:58 -0700, Kaz Kylheku
wrote:
> reason, I cannot get a warning about fileno from this test case if
> I add a reference to it. I will try to produce a minimal repro test
> case for that.
In my real program I have -Wall, and I'm not taking the function
pointers.
With -Wall we get warnings about implicit declarations.
So, here is a better test case which shows that these identifiers are
not declared when they should be. Of course the two errors occur
without -Wall.
$ cat posix-ansi.c
#include
void foo(void)
{
int (*f1)(FILE *) = fileno;
int (*f2)(FILE *) = pclose;
}
int main(void)
{
int x = fileno(stdin);
pclose(NULL);
return 0;
}
$ gcc -Wall -ansi -D_POSIX_C_SOURCE=2 posix-ansi.c
posix-ansi.c: In function 'foo':
posix-ansi.c:5:23: error: 'fileno' undeclared (first use in this
function)
posix-ansi.c:5:23: note: each undeclared identifier is reported only
once for ea
ch function it appears in
posix-ansi.c:6:23: error: 'pclose' undeclared (first use in this
function)
posix-ansi.c:6:9: warning: unused variable 'f2'
posix-ansi.c:5:9: warning: unused variable 'f1'
posix-ansi.c: In function 'main':
posix-ansi.c:11:3: warning: implicit declaration of function 'fileno'
posix-ansi.c:12:3: warning: implicit declaration of function 'pclose'
posix-ansi.c:11:7: warning: unused variable 'x'
--
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: stdio.h: broken standard compliance.
Corinna Vinschen writes:
> $ gcc -Wall -ansi -D_POSIX_C_SOURCE=2 posix-ansi.c
^
fileno and pclose are *not* ANSI functions. Therefore, if you define
-ansi, you get the below errors. The newlib headers have explicit
#ifndef __STRICT_ANSI__ guards around the non-ANSI definitions.
Hi Corinna,
(Could you use "reply all?" for discussions so the original
person is included, but the mailing list is kept in the loop with a
CC?
I had to dig your reply out of the online archives.)
I do not believe that your interpretation of the applicable standards
is
entirely correct.
The -ansi flag tells the GNU *compiler* to disable its built-in
extensions. So for instance the block evaluation syntax
({ expr1; ... ; exprn }) won't be available.
The -D_POSIX_C_SOURCE=2 tells the *library headers* to enable
their extensions to a certain revision of POSIX.
With -D_POSIX_SOURCE, programs must see pclose and fileno declared
in
It is not correct for those headers to be testing GCC's
compliance level with __STRICT_ANSI__ to determine whether
to reveal these symbols.
FYI:
Summary of Feature Test Macros in the glibc documentation:
http://www.gnu.org/s/hello/manual/libc/Feature-Test-Macros.html
In your Linux manual pages:
$ man 7 feature_test_macros
In the Single Unix Specification:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02
Cheers ...
--
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: stdio.h: broken standard compliance.
Christopher Faylor writes: The convention in this mailing list is that you read the mailing list. Hi Christopher, I see now from the archives that this list is configured to generate the unfortunate Reply-to header, which by many is considered a mailing list misconfiguration. [[ Apologies to Corinna: I understand now that you fell victim to this Reply-to trap! Argh! ]] In other respects, this is a completely ordinary mailing list, like countless ones that came before it. How mailing lists work is that you use "reply all" to keep the discussion together. The mailing list is just another party that is on the CC list of the discussion, thereby keeping numerous other people (subscribers) in on the loop. The purpose of subscribing is to receive the e-mails; it is not a requirement for participating in the discussion. (Though many lists are member-only these days; but that is due to the spam problem.) Say, if I'm not reading the list, how come I can reply to you? It's because I'm making an effort to work around your misconfigured bouncer. I have your archives (thanks for putting them up). That's my preferred way of reading the list. Practically speaking, if you want help, it pays to comply with Where do you get the idea that I want help? Who do you think is helping whom here? People who find issues are the ones who help the developer. convention rather than asking others to accommodate you. I hope you realize that by "accomodate you", you are actually referring to a proper use of the e-mail in the manner of how everyone does it everywhere on the planet. Namely that when you get an e-mail "From:" someone, that someone is among the recipients of the reply; and furthermore, that everyone else who was in the loop stays in the loop (if it is a discussion). It is your mailing list which munged the headers to make it difficult for you to reply to me, and that is what is creating the need for special accomodation. You can do whatever you want in your list, but do you not suppose it is in your interest to make it easy for people to communicate with you? If I have an issue report of some kind, please don't make me jump through hoops, and subscribe to have stuff dripping into my mailbox that I'm not interested in just so I can see the reply. Since you're letting non-subscribers post to the list, what are you protecting yourself from, anyway? Those evil bastard who are only interested in how their particular report turns out, but don't want to drink the whole jar of Cygwin Kool-Aid? Man, do you know how hard it is to get feedback from people? In this world, people just give up and move on, and you don't even know! You write some program, 50 people download it and install it, if you're lucky. Then unknown to you, 48 of them get stuck on something and you never hear from them. Anyway, you have the complete information to deal with (or not) the problem in the subject line. URL's given in my previous e-mail, etc. I do not need to be involved in any further discussion. Next time I have any kind of report, I will make it a complete "kit" in the very first e-mail, so I don't have to watch for clueless replies in the archives, and come back to burp you and change your dirty diapers after giving you the milk. Good luck. -- 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: stdio.h: broken standard compliance.
One more thing: RFC 2822: ``When the "Reply-To:" field is present, it indicates the mailbox(es) to which the author of the message suggests that replies be sent.'' [ 3.6.2 Originator fields ] Note that the Cygwin mailing list is not the author of this message; herefore, it is abusing the Reply-To: header in violation of the RFC which governs e-mail communication. -- 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: stdio.h: broken standard compliance.
Greg Chicares writes: An argument could be made for giving _POSIX_C_SOURCE precedence over __STRICT_ANSI__ if both are defined; but as long as that's not the The time to discuss this sort of stuff was back in 1990 or so, when it was all settled and POSIX.1 came out. (Luckily, it went your way, so you don't need a time machine.) Even if you don't believe in the certainty of people's interpretations of the standards, other implementations do it that way. Since Cygwin is supposed to produce "that Linux feeling", this is one way in which it doesn't. The Linux "feeling" is that a program which uses "" and calls fileno compiles cleanly with -ansi -D_POSIX_SOURCE. The Cygwin "feeling" is that you get ugly warnings, and perhaps your program doesn't compile (takes the address of a function which is not declared) or makes a bad call (implicit declaration has the wrong prototype). So if looks and feelings be substitutes for documents, it's still wrong. I suggest you people look into /usr/include/features.h on a glibc system (and copy like crazy). Here is a nice comment from that file: The `-ansi' switch to the GNU C compiler defines __STRICT_ANSI__. If none of these are defined, the default is to have _SVID_SOURCE, _BSD_SOURCE, and _POSIX_SOURCE set to one and _POSIX_C_SOURCE set to 200112L. If more than one of these are defined, they accumulate. For example __STRICT_ANSI__, _POSIX_SOURCE and _POSIX_C_SOURCE together give you ISO C, 1003.1, and 1003.2, but nothing else. I would say that the above summarizes the "Linux feeling" on the matter, be it correct or not. behavior, you might want to undef __STRICT_ANSI__ as appropriate. Again, I do not require help, or advice. The above is just one of many possible workarounds. It's not a real problem for me in this program anyway, because the implicit declarations match the functions being called. I can get my stuff working, and I don't have to be sending these reports. Just send me an e-mail saying "Noncompliance is not a bug, do not bother Cygwin with this petty crap" and you won't hear from me again on this subject. The project has the privilege of defining what is and isn't an issue. -- 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: stdio.h: broken standard compliance.
Christopher Faylor writes: The cygwin mailing list does not set Reply-To. It does set "Mail-Followup-To". Effectively, there is no difference. This is an idiotic header that is defined by a 1998 IETF draft that was never approved, as far as I can find. This *DEAD* draft is here: http://tools.ietf.org/id/draft-ietf-drums-mail-followup-to-00.txt This document, in a nutshell, says "Reply-To is broken, so here is a replacement". But the replacement is just as poor and not needed. Reply-To is not broken; it's a tool for a specific job. For a good discussion see: http://pjakma.wordpress.com/2009/07/08/mail-followup-to-considered-harmful/ (Highlight: ``Mail-Followup-To == more mess == even more brokenness.'') According to this cretinous IETF draft, the new header IS allowed to be set by mailing list expanders, unlike Reply-To, which is just for authors. Good grief, look: 2.3 Mailing List action A mailing list expander may insert the "Mail-Followup-To" header, with a reference to the list, if there is no previous "Mail-Followup-To" in the message. A mailing list expander SHOULD NOT change an existing "Mail-Followup-To" header, since this may reduce the set of recipients suggested in the original message. This is still a very rude and completely unnecessary thing for a mailing list expander to do. But it does seem to provide an API for communicating with the list by a nonsubscriber: set your own Mail-Followup-To header which the list must respect, if it obeys what the above document. This is even explicitly documented: 2.2 Sender Action [ ... ] 4. When a message is sent to a mailing list, which contains sublists, there is a risk that the sublists will insert "Reply-To" or "Mail-Follow-Up-To" headers referring to the sublist. If this happens, replies might be sent to the sublist, and thus not reaching the full set of readers of the primary mailing list. Use of the "Mail-Followup-To" can be used by the author or the primary mailing list to stop sublists inserting "Mail-Followup-To" in the header. Easier said than done for many people. Now you need every mail client to have the option to set the header, and for users to have the prescience of knowing when it has to be used. (Or sticking it into every outgoing message, just in case!) Kindly, someone please fix the Cygwin mailing list not to add this idiotic nonstandard header described in a 13 year old dead IETF draft. [rest of message snipped since it was based on an incorrect assumption] That isn't a fair characterization of everything that the rest of the message was about. -- 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: Why 'script' utility require SHELL (and work fine under Linux)?
So SHELL env var does not exported by bash... Why? This is a bug in bash which hides broken behavior in the OS. Bash expects this to be an existing environment variable, and it usually is in normal Unix like operating systems. However, bash internally sets the variable if it is missing (without exporting it): From "info bash". `SHELL' The full pathname to the shell is kept in this environment variable. If it is not set when the shell starts, Bash assigns to it the full pathname of the current user's login shell. It is correct not to export the variable. Bash might not be the user's shell, so it has no right to introduce itself as the SHELL to child processes. But, in fact, the shell does not own that variable at all and so it should not be setting it up even as an internal variable. The variable should stay unset to indicate that "there does not exist a configuration for the user's shell in this system". Let's confirm your finding: linux $ env | grep SHELL SHELL=/bin/bash cygwin $ env | grep SHELL cygwin $ # nothing Where does it come from on Linux? On the distro I have here, it is not exported by anything in /etc or my /home directory. Of course not. It comes from the "login" process which authenticates you and fetches your shell from the password file. Linux man page for "login": The value for $HOME, $SHELL, $PATH, $LOGNAME, and $MAIL are set according to the appropriate fields in the password entry. Cygwin sets HOME, and PATH, but not SHELL and LOGNAME. -- 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: displaying Chinese radicals
Wynfield writes: Linguis, The "radicals" you speak of are only a component part of a Chinese character and not the character itself, just as the little dot above > a lower case 'I' is not an alphabet and doesn't have a code. Oops! http://en.wikipedia.org/wiki/List_of_Kangxi_radicals "The Kangxi radicals are encoded in the Unicode U+2F00–2FDF range." Good job on being first to register "wynfield" at Gmail though! Pretty sharp! -- 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: displaying Chinese radicals
Lingyis writes: cygwin xterm or rxvt does a good job when it comes to displaying Chinese characters, but it doesn't have fonts for all the Chinese radicals. maybe half of them show up as "SQUARES". the ones that do show up i can tell cygwin did some substitutions--i.e. dug up other fonts when current font doesn't have this glyph. Since you're on Windows, try running a ssh daemon and log into your Cygwin using PuTTY. (Or heck, properly secured telnet.) In PuTTY you can easily configure the font and character encoding. It does a good job with Asian characters. I just confirmed that I can see radicals in PuTTY (Method: go to http://en.wikipedia.org/wiki/Radical_%28Chinese_character%29, and cut and paste random radicals from the table into my PuTTY window. The ones I sampled all showed up fine. The font is just Courier, on Windows XP. "Translation" is set to "UTF-8". This is in the settings under "Window".) (But my putty is connected to a Linux system, not to Cygwin: that's something for you to try. :) -- 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
Problem with line buffering and getc function on 1.7.33.
Hi all, On a Cygwin installation version 1.7.33-2(0.280/5/3), I encountered an odd issue. I wrote it up in a StackOverflow question: http://stackoverflow.com/questions/35928828/cygwin-missing-stream-data-due-to-stdio-putc-line-buffering This contains a repro test case. For the benefit of non-users of WWW, the summary is this: I'm sending data to a stdio stream which has been fdopen-ed from a socket descriptor (which could be irrelevant). The stream is put into line buffered mode with setvbuf. When the getc function is used to perform output on this stream, it loses data. When the string "REPLY\n" is sent, character by character, the receiver receives only "\n". If line buffering is not employed, or of putc(ch, stream) is replaced by fputs(str, stream) (where str is a one-character-long string containing the character to be output), then things work as expected. Here is a patch I put into the real program where this issue was found: http://www.kylheku.com/cgit/txr/commit/?id=3c5f110cc29f8d3fbf2069c68d25ccebee46679e with the patch, TXR's socket test cases pass on Cygwin. The tests pass on Solaris 10, various GNU/Linuxes and Mac OS 10.7.3. -- 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: Problem with line buffering and getc function on 1.7.33.
On 11.03.2016 12:08, Yaakov Selkowitz wrote: On 2016-03-11 13:16, Kaz Kylheku wrote: On a Cygwin installation version 1.7.33-2(0.280/5/3), I encountered an odd issue. This is a 15-month old release which is no longer supported. Please update to 2.4.1. Do you mean, "Please update to 2.4.1, it is fixed there!" or do you mean "You haven't done enough with that minimal C repro case; please keep investigating against the latest code?" I'm not looking for support for old versions of Cygwin. My program *is* supported for users who have that 15-month-old version, and I can provide that support entirely by myself, as you can see. There is no benefit to me in reporting this issue at all, since the workaround is acceptable and will likely keep working indefinitely. -- 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: Problem with line buffering and getc function on 1.7.33.
On 11.03.2016 14:14, Marco Atzeri wrote:
On 11/03/2016 22:57, Kaz Kylheku wrote:
On 11.03.2016 12:08, Yaakov Selkowitz wrote:
On 2016-03-11 13:16, Kaz Kylheku wrote:
On a Cygwin installation version 1.7.33-2(0.280/5/3), I encountered
an odd issue.
This is a 15-month old release which is no longer supported. Please
update to 2.4.1.
Do you mean, "Please update to 2.4.1, it is fixed there!"
or do you mean "You haven't done enough with that minimal
C repro case; please keep investigating against
the latest code?"
#2 please verify if the issue is still present in the last code.
We don't have the bandwith to check claims on older release.
on 2.4.1 the output is:
$ ./test_stream.exe
received REQUEST
from client
received
from server
That confirms that the issue is still there.
We can reproduce the problem with just file streams using
a much simpler program:
#include
int main(void)
{
FILE *out = fopen("file", "w+");
setvbuf(out, (char *) NULL, _IOLBF, 0);
getc(out);
clearerr(out);
fseek(out, 0, SEEK_SET);
putc('a', out);
putc('b', out);
putc('c', out);
putc('d', out);
putc('e', out);
putc('\n', out);
fclose(out);
return 0;
}
The contents of file end up being "\n": one empty
line, instead of "abcde\n":
$ cat file
$
The necessary ingredients seem to be: open the stream for update;
put into line buffered mode; do some input. In this program,
replacing putc with fputs doesn't make the problem go away;
the workaround isn't working:
fputs("a", out);
fputs("b", out);
fputs("c", out);
fputs("d", out);
fputs("e", out);
fputs("\n", out);
However, if we do it as one string, then the file does contain
the correct line:
fputs("abcde\n", out);
This sequence also gets us correct file contents:
fputs("ab", out);
putc('c', out);
putc('d', out);
putc('e', out);
putc('\n', out);
HOWEVER, these distracting effects are because GCC is
optimizing one-character fputs calls into _fputc calls.
Annoyingly, this happens even with gcc -O0.
The clearerr and fseek calls are red herrings; they seem to make
make no difference. I put in the fseek for formal ISO C compliance:
ISO C says that before performing an output operation on an update
stream whose last operation was input, we "shall" perform a
positioning operation. (No sanely implemented libc actually
breaks code that doesn't meet this silly requirement.)
--
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: Application not working in 64-bit cygwin cygwin/X
On 11.03.2016 22:27, Marco Atzeri wrote: On 12/03/2016 00:10, David Stacey wrote: On 11/03/16 14:23, Girish Joglekar wrote: I have cleaned up the test example based on X-Windows/Motif which crashes on 64-bit cygwin cygwin/X but runs on the 32-bit version. The only warnings are of the type 'variable set but not used'. Here is the link to the tar file. https://www.dropbox.com/s/lknuoac64hfql4s/test.tar?dl=0 Hope you can reproduce the behavior and fix the problem. I tried this on Fedora 23 64-bit and it works. I had to add an empty utcrcu.h file, as the code tries to #include this, and it doesn't exist in the tar file. Given that it runs in 64-bit Linux, the problem is unlikely to be an issue associated with porting 32-bit applications to 64-bit. Dave. it can be a bug not triggered on linux due the difference in managing function arguments in the stack. Among a myriad other things! Undefined behaviors can have totally different consequences even on architecturally similar systems. E.g. a malloced buffer overrun depends on the heap structure and allocation pattern driven by program inputs. Uninitialized memory will have different garbage in it. And so on. So it works on Fedora 23 64-bit? That could be by fluke. How about this: does it run with zero errors under Valgrind on the same system? That represents a greater confidence that "it works". In any case, this is a poor approach to problem solving in the context of open source: "Hi, on your platform the program in my multi-megabyte archive crashes ... somewhere in the code (I could tell you where, but I can't be bothered to use the debugger). Please download the whole, reproduce the problem, and debug it for me." This kind of burp-and-diaper changing is done in the industry only for paying customers. -- 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: Problem with line buffering and getc function on 1.7.33.
On 12.03.2016 14:29, Corinna Vinschen wrote:
On Mar 12 20:39, Corinna Vinschen wrote:
On Mar 11 16:05, Kaz Kylheku wrote:
> We can reproduce the problem with just file streams using
> a much simpler program:
>
> #include
>
> int main(void)
> {
> FILE *out = fopen("file", "w+");
> setvbuf(out, (char *) NULL, _IOLBF, 0);
> getc(out);
> clearerr(out);
> fseek(out, 0, SEEK_SET);
> putc('a', out);
> putc('b', out);
> putc('c', out);
> putc('d', out);
> putc('e', out);
> putc('\n', out);
> fclose(out);
> return 0;
> }
>
> The contents of file end up being "\n": one empty
> line, instead of "abcde\n":
>
> $ cat file
>
> $
Thanks for the testcase. I can reproduce the issue and I see where
the
problem occurs, but I'm still puzzled. Comparing the code in our
newlib
C library with its BSD counterparts, I could swear the same behaviour
happens on OpenBSD as well. If not (which needs testing), I wonder
why
and where newlib's actually different. Right now I don't see the
difference.
I do now. Basically it's setvbuf screwing up the internal flags in the
FILE structure. I took the liberty to update newlib's setvbuf to the
OpenBSD version locally and I'm going to apply my patches to newlib
soon. I'll provide a new 2.5.0 test release of Cygwin with this patch
tomorrow or early next week.
Indeed, I thought it would have something to do with the
stream->_flags, because when I single-stepped over the getc(stream)
line (necessary for the problem to repro, IIRC) the only apparent state
change in the stream was to the _flags member:
(gdb) n
8 getc(out);
(gdb) p *out
$2 = {_p = 0x80039c28 "", _r = 0, _w = 0, _flags = -30575, _file = 3,
_bf = {
_base = 0x80039c28 "", _size = 1024}, _lbfsize = -1024, _data = 0x0,
_cookie = 0x80039a30, _read = 0x61164cb0 <__sread>,
_write = 0x61164f30 <__swrite64>, _seek = 0x61164e50 <__sseek>,
_close = 0x61164ea0 <__sclose>, _ub = {_base = 0x0, _size = 0}, _up =
0x0,
_ur = 0, _ubuf = "\000\000", _nbuf = "", _lb = {_base = 0x0, _size =
0},
_blksize = 0, _flags2 = 0, _offset = 0, _seek64 = 0x61164ed0
<__sseek64>,
_lock = 0x80039bf8, _mbstate = {__count = 0, __value = {__wch = 0,
__wchb = "\000\000\000"}}}
(gdb) n
9 clearerr(out);
(gdb) p *out
$3 = {_p = 0x80039c28 "", _r = 0, _w = 0, _flags = -22347, _file = 3,
_bf = {
^^
_base = 0x80039c28 "", _size = 1024}, _lbfsize = -1024, _data = 0x0,
_cookie = 0x80039a30, _read = 0x61164cb0 <__sread>,
_write = 0x61164f30 <__swrite64>, _seek = 0x61164e50 <__sseek>,
_close = 0x61164ea0 <__sclose>, _ub = {_base = 0x0, _size = 0}, _up =
0x0,
_ur = 0, _ubuf = "\000\000", _nbuf = "", _lb = {_base = 0x0, _size =
0},
_blksize = 0, _flags2 = 0, _offset = 0, _seek64 = 0x61164ed0
<__sseek64>,
_lock = 0x80039bf8, _mbstate = {__count = 0, __value = {__wch = 0,
__wchb = "\000\000\000"}}}
--
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: Problem with line buffering and getc function on 1.7.33.
On 12.03.2016 14:29, Corinna Vinschen wrote: I do now. Basically it's setvbuf screwing up the internal flags in the FILE structure. I took the liberty to update newlib's setvbuf to the OpenBSD version locally and I'm going to apply my patches to newlib soon. I'll provide a new 2.5.0 test release of Cygwin with this patch tomorrow or early next week. The change in git now seems risky; it substantially rewrites setvbuf. Of course, it's not that I think OpenBSD has it wrong, but that it's being cherry-picked in isolation into what looks like a code base with some other old pieces. Just a thought. -- 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: ctrl-c doesn't reliably kill applications
On 14.03.2016 10:18, Björn Stabel wrote: My eyes blinked there for a second! Nope, not the Xpilot co-author, Norwegian Bjørn Stabell. :) -- 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: ctrl-c doesn't reliably kill ping
On 15.03.2016 04:00, Andrey Repin wrote: Greetings, Frank Farance! So all of this is normal ISP stuff: they actually resolve unknown addresses to their own website (which is 90.242.140.21). This is NOT "normal", this is a violation of protocol. Whoever encounter such behavior should call their ISP and tell them to stop doing it. Or don't tell them anything and just find an alternative DNS upstream for your network. -- 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: ctrl-c doesn't reliably kill ping
On 16.03.2016 08:57, Michael Enright wrote: On Wed, Mar 16, 2016 at 7:51 AM, cyg Simple wrote: My ISP for my connection to the WWW is the one that is doing the inappropriate redirects. I sometime get these even when using VPN to my employer's intranet. My ISP also provides phone and TV Cable and I'm guessing that the accepted practiced exception is practiced by all such companies. Can confirm. Readers may be interested to learn that I tried to set the DNS manually in the connection properties of my VPN connection (to the exact same thing the VPN connection would have configured anyway) but this did not work either. You have to point your local network's router to some alternative DNS servers. You shouldn't have to do anything in an individual client workstations and devices. Example: I have dnmasq running on a Linksys wireless router. All my machines here obtain their DHCP from that and point their DNS resolvers to it (because the DHCP tells them to). If I weren't happy with upstream DNS, I'd go into the router's configuration and tell dnsmasq to send its queries to some alternative DNS. -- 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: distinguishing cygwin from mingw binaries
On 10.07.2017 10:40, Nellis, Kenneth wrote: For my personal use, I use gcc to generate binaries, but occasionally I need to make a binary available to someone who doesn't use Cygwin. For that I use Cygwin's x86_64-w64-mingw32-gcc. After the fact, I would like to know whether the binary requires Cygwin support or not. One way is: strings foo.exe | grep cygwin1.dll Curious what techniques others might use. There is always the technique of actually packaging the program deliverables and then testing them, beginning with installation, if you were the end-user. If the program doesn't run when installed by itself in C:\Program Files somewhere, then it might be missing DLLs. I use a special fork of Cygwin called Cygnal for delivering programs to users who don't use Cygwin and don't understand POSIX conventions for paths and other things. http://www.kylheku.com/cygnal/ With this, you make your executable with the regular Cygwin host compiler. Yes, you know your executable needs a CYGWIN1.DLL (and possibly others); no guesswork. You package the needed DLL's with the program. Except, you use the CYGWIN1.DLL from the Cygnal project rather than the stock Cygwin one. Example software shipping with Cygnal is the port of the TXR language to Win32 and Win64. Installers available here: https://bintray.com/kazinator/Binaries/TXR/ -- 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: Car Auto Wrap
On 10.07.2017 11:58, Wayne Barron wrote: SPAM Not some misplaced Lisp posting? [1]> (car '#1=(a b . #1#)) A [2]> (cadr '#1=(a b . #1#)) B [3]> (caddr '#1=(a b . #1#)) A [4]> (cadddr '#1=(a b . #1#)) B CAR auto-wrap! -- 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: Request to the git maintainer
On 10.07.2017 14:02, Eliot Moss wrote: On 7/10/2017 4:24 PM, Achim Gratz wrote: Eliot Moss writes: Dear maintainer of git I use CrashPlan as my backup engine. It has difficulty backing up files with no "other" access. Many git locale (.mo) and doc-related files have permissions 600 (directories 700). Is there a good reason for this? I would think that 644 and 755 access would be fine for these files, and it would prevent the problems I see with CrashPlan. That's an upstream build system bug. Some of the installation scripts use cp instead of install and that in turn makes them dependent on umask (which doesn't get set aywhere I can easily find). I guess Adam could work around that by setting 'umask 022' in the cygport file, but it really should be fixed in git.git. I looked upstream, and at least some of the files I am concerned about are installed using "tar" piped to another "tar", with umask 022 set explicitly. I think the problem is that the source of this copying has 600 or 700 permissions. Not sure if *that* is an upstream problem or not ... I would say, get a backup system that handles whatever bits you have on your disk, or find out how to configure the existing one. If there are some permission problems, maybe it needs more privilege to do its job. You can't ask every vendor of everything that you have installed or "git pulled" to fix their permissions because your backup program has bizarre limitations. -- 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: How to repeat a bash shell script until success
On 12.07.2017 08:35, Bryan Dunphy wrote: I have a shell script, originally created for Mac OS X. that waits for an external drive to be mounted (by testing an “ls” of the volume’s root directory for success) then runs an “rsync” command. How do I get the script to be run repeatedly until successful exit under Cygwin? Multi-line while ! program arg1 arg2 ... do : # explicit null statement: syntactically mandatory! done one-liner: semicolon between program and "do", semicolon between : statement and "done": while ! program arg1 arg2 ... ; do : ; done The space between ! and the command is required. I would throw a sleep in there, not to create a CPU-intensive busy loop: while ! program args ... ; do sleep 1 done -- 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: How to repeat a bash shell script until success
On 14.07.2017 10:34, Brian Inglis wrote: On 2017-07-14 11:07, Kaz Kylheku wrote: while ! program args ... ; do sleep 1 done Has everyone forgotten there is also an until loop, supported by at least sh, dash, bash, [m]ksh: I've forgotten that at least twice. (I don't remember the exact number of times.) -- 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: Cygwin strptime() is missing "%s" which strftime() has
On 22.07.2017 13:48, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Hello, It looks like Cygwin implementation of strptime(3) cannot understand the "%s" format (seconds since Jan 1, 1970 UTC), which strftime() can. But that's just scanning a decimal integer to time_t. Where implemented, how does that deal with overflows and such compared to strtoul? -- 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: Cygwin strptime() is missing "%s" which strftime() has
On 23.07.2017 19:09, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: But that's just scanning a decimal integer to time_t. It's not a question of whether I can or can't convert a string into an integer, rather it's a question about portability of code that uses %s for both functions and expects it to work unchanged in the Cygwin environment. Also, strptime() was designed to be a reversal to strftime() (from the man-pages: the strptime() function is the converse function to strftime(3)) so both are supposed to "understand" the same basic set of formats. Because of Cygwin's strptime() missing "%s", the following also does not work even from command line: $ date +"%s" | strptime "%s" strptime: cannot make sense of `1500861577' using the given input formats There is no %s in POSIX. It is a GNU C library extension. Thus this is only a matter of compatibility between Cygwin and GNU/Linux (and portability between those systems). Linux compatibility *is* an explicit goal of the Cygwin project. If %s works on Linux but not Cygwin, in that moment you're not getting quite that "Linux feeling" on Windows. -- 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: Cygwin strptime() is missing "%s" which strftime() has
On 24.07.2017 15:51, Brian Inglis wrote:
On 2017-07-24 15:02, Hans-Bernhard Bröker wrote:
Am 24.07.2017 um 04:09 schrieb Lavrentiev, Anton (NIH/NLM/NCBI) [C]:
rather it's a question about portability of code that
uses %s for both functions and expects it to work unchanged in the
Cygwin environment.
And the answer to that question is: such code _is_not_portable_, and
therefore
that expectation is wrong.
If that code claims to be portable, then its use of %s in either of
those
functions constitutes a _bug_.
In the old days there was a well-known fallacy known by the slogan
"all the
world's a VAX." Nowadays it appears to have been replaced by an
equally
wide-spread, and equally incorrect belief that all the world is Linux.
Well,
it's not. Not even the whole Un*x world is Linux.
Rather "all the world's a GNU" i.e. glibc, but there's also BSD libc,
RTEMS and
Cygwin newlib, and others.
Since the utilities depend on the C library functionality for strptime
and
strftime, even having GNU utilities won't help.
There doesn't appear any nice way in POSIX shell scripting to have
access to
the seconds since the Epoch.
If you have GNU Awk, it has some time functions like mktime, which don't
rely
on any C library extensions.
$ gawk 'BEGIN { print mktime("2017 07 22 12 31 55") }'
1500751915
$ gawk 'BEGIN { print systime() }'
1500938050
If you can install GNU Awk on a system, chances are you can get some
real
programming language, too, though. GNU Awk may be a little more common
in
that if, for your given OS, a bundle of freeware exists, chances are
good
that GNU Awk is part of its core.
--
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: Signal delivered while blocked
On 04.08.2017 10:02, Corinna Vinschen wrote: On Aug 4 00:44, Noah Misch wrote: The attached demonstration program blocks signals (with sigprocmask()) to achieve mutual exclusion between signal handlers. It aborts upon receipt of a blocked signal. On "CYGWIN_NT-10.0 2.7.0(0.306/5/3) 2017-02-12 13:18 x86_64", signals regularly arrive despite being blocked. Essential parts of the program include handling two signal numbers and having handlers run for at least 1-2ms; this problem goes away if I remove one of those attributes. GNU/Linux, AIX, Solaris, and "CYGWIN_NT-6.0 1.7.27(0.271/5/3) 2013-12-09 11:57 i686" never deliver a blocked signal to this program. I think this Cygwin behavior is non-conforming. Thanks for the testcase. I debugged this a while today but the problem is far from trivial, apparently. Don't hold your breath for a quick solution. Hi! It seems I haven't grasped at straws in a few weeks, so I'm eager to tug on some dry turf. What the hay, you know? The test case depends on accesses to the global variable sigblocked not to be reordered w.r.t. siggprocmask calls. It is important that the variable not be set to 1 until after the signals are blocked, and be reset to 0 until after they are unblocked. Thus, the variable should be declared volatile. (Even basic ISO C says that variables modified by signal handlers shall be of type "volatile sig_atomic_t", not just "atomic_t"). Although I would be surprised if this were actually happening, in principle at least, compiler could be too clever and "just know" that the sigprocmask standard library function has no interactions with a user-defined global variable and so the order of the call with respect to the manipulation of that variable doesn't matter. Also, related remarks: for the reason that we can't factor out compiler behavior, with absolute certainty, it would be good to mention not only the system versions but also GCC. The compiler differs, obviously, between Cygwin 1.7 and 2.7; not to mention that the case is reported against i686 of the one, and x86_74 of the other. Cheers ... -- 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: REVISITED: Signal delivered while blocked
Both testcases confirm that Cygwin _sometimes_ delivers a signal, although the signal mask specifies (verified by the test case) it should not. Hence, your fixes are not relevant to the issue. However, they also demonstrate that the signal nesting (at least, self-esting: the same signal being handled more than once) is also not relevant to the issue. Eliminating unlimited nesting can be regarded as an improvement to the test case, since it doesn't have to worry about hitting a stack depth limit. The original test case is simple in that it uses precisely one known signal mask for blocking the signals, and another one for unblocking them. So it it is easy to see that the signal went off when it shouldn't have. This global clobbering of the signal mask leads to the nesting because, for instance, when the SIGCHLD signal is running, before it has reached the sigforbid() call, the SIGUSR1 signal handler can go off. That handler will finish by calling sigpermit() which will unblock not only SIGUSR1 but also SIGCHLD. So control returns to the SIGCHLD handler, and SIGCHLD is now unblocked, opening the door to nesting of that signal. Another window for this to happen is after the SIGCHLD has itself called sigpermit(), as the last step before returning. You're not correct in insinuating that POSIX forbids such a manipulation. Such a manipulation is merely a bad idea; it is not good application practice for a signal handler to clobber the mask bits belonging to other signals. "We wouldn't do this in a real program" isn't the same as "POSIX doesn't define it". It's perfectly okay for API test programs to deviate from best practices. If that is necessary to make a problem easier to reproduce, or to simplify the test case, then it should be done that way. -- 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: alias appears to not work inside a called bash script
On 21.08.2017 15:53, Eliot Moss wrote: From the bash man page: "Aliases are ot expanded when the shell is not interactive, unless the expand_aliases shell option is set using shopt (see the description of shopt under SHELL BUILTIN COMMANDS below)." Could that be the root of your difficulty? There is an issue there (though not for the Cygwin project). I don't see where this behavior is required in POSIX: that is, expanding aliases in interactive mode, but ignoring them in non-interactive operation. POSIX seems to unequivocally be calling for Alias Expansion to occur under all conditions. And, indeed, this is not a bug in Bash; they know that this is a POSIX deviation. Because, voila, aliases *are* expanded in script mode if we do one of two things: #!/bin/bash --posix #!/bin/sh Bash in POSIX mode knows every well that it had better expand aliases regardless of non-interactive operation. However, *suppressing* a useful behavior in a default, non-standard mode is highly counter-intuitive. I mean we can't even call this a vendor *extension* with a straight face. What do we call this? "retraction?" :) "To disable the vendor-specific retraction that aliases don't work, operate bash in POSIX mode, or use the expand_aliases shopt." :) -- 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: Aw: Re: Strange errors with gcc and top, even after rebaseall
On 24.08.2017 04:16, Eliot Moss wrote: On 8/24/2017 3:16 AM, nobo...@web.de wrote: Hi, the 64bit version, with all packages installed, has no problem. But i also want a 32bit version. You can have the 32 bit version installed, but not all the packages. Cygwin's approach to making fork work as closely as possible to the way it works on Posix requires each Cygwin DLL to be put in its own reserved place in the address space. The sum total of the DLLs exceeds the available 32 bit address space. Remember "a.out shared libraries" in mid-1990's Linux? These had pre-assigned, fixed addresses. Building them involved a trick which captured the assembly output from gcc and was text filtering it. Yikes! -- 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: Problem with differences with DLOPEN / DLSYM compared to ubuntu (16.04) / debian (stretch).
On 14.09.2017 08:44, Gary Schneir wrote: Can anyone provide some assistance to understanding the differences and a way get a single code base to work in all three environments without naming the library file? On Cygwin, libraries are Windows DLL's. That appears to be a conscious project decision. The TL;DR is that Windows DLL's are not going to give you the behaviors of ELF shared libraries on GNU/Linux. Cygwin would probably have to whip up its own shared library format for that, or port one. The complication doesn't seem worth it. You can think of dlopen as a wrapper around LoadLibrary, and dlsym doing GetProcAddress. In Windows programming, doing GetProcAddress on symbols within an .exe is something that isn't normally done; it's not clear that it is supposed to work at all. For it to even have any hope of working, the function would have to be somehow declared "dllexport" (in Visual C terms). I think the shared lib building mechanism under Cygwin hides that; there is no Visual C __declspec(dllexport) stuff: See: https://cygwin.com/cygwin-ug-net/dll.html Still, the toolchain has to be arranging for the equivalent of __declspec(dllexport) for the external symbols. It's probably not configured to do that for the symbols in a regular executable. -- 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: Problem with differences with DLOPEN / DLSYM compared to ubuntu (16.04) / debian (stretch).
On 15.09.2017 06:51, Gary Schneir wrote: Thanks for the response but I am a little confused by it. If Cygwin is supposed to provide POSIX API functionality and DLOPEN / DLSYM are supported in CYGWIN, then I shouldn't care about the underlying complexity or restrictions of running within the Windows environment and using DLLs. The behavior should be the same as in other POSIX environments. I don't see this behavior on Linux. This is a transcript from an Ubuntu 16.04 system: $ txr This is the TXR Lisp interactive listener of TXR 186. Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet. 1> (dlopen nil) # 2> (dlsym *1 "cons") # 3> (dlsym *1 "car") # 4> (dlsym *1 "cdr") # 5> (dlsym *1 "malloc") # 6> (dlsym *1 "printf") # The external functions cons, car and cdr in the txr executable (I assure everyone they are there) cannot be found by dlsym, but malloc and printf in the linked C library are found. I.e. the same issue you're having on Cygwin. Cygwin aims for Linux compatibility more than POSIX. The motto is "get that Linux feeling on Windows", after all. It's splashed right below the Cygwin banner here: https://cygwin.com/ Not finding the executable's own symbol with dlsym (unless some special arrangements are made to dynamically export the symbols) looks very much like a "Linux feeling"! If we run "nm -D" on the executable to see what dynamic symbols are provided, we find only "_init" and "_fini": $ nm -D /usr/local/bin/txr | grep T 080fa3cc T _fini 0804a7a4 T _init and, by golly, these *can* be found with dlsym on the dlopen(NULL, ...) handle! 7> (dlsym *1 "_fini") # 8> (dlsym *1 "_init") # -- 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: Kindle Fire Utility 0.9.6
On 27.09.2017 15:18, Kevin McCaffrey wrote: Hello, I am trying to "Install Permanent Root with Superuser" with Kindle Fire Utility 0.9.6 . Why are you posting this question as a follow-up in the middle of a thread titled "Challenge: a VERY strange problem with command substitution in bash" in the Cygwin mailing list? and the Boot Status : Unknown . Any help would be appreciated. Try some Kindle Fire or Android mailing list maybe? "Kindle Fire Utility" doesn't appear to be a Cygwin component. From some cursory Google searches, it appears some people with Cygwin installations have had problems with the KF utility due to the wrong find.exe (Cygwin's, rather than Windows') and possibly other utilities being found in PATH. -- 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: bash pipe race condition
On 03.10.2017 05:56, cyg Simple wrote: On 10/2/2017 9:06 PM, Matthew McGIllis wrote: If I use the same code from bash I get: $ ./input.exe | ./simple.exe line1 <—— Hangs indefinitely until you kill it or ctrl-c Some how if input has a delay between its line output then things will get hung, if you remove the sleep from the input things work, add the sleep in it fails. input.exe is generate from input.vb using: vbc input.vb [ ... ] It is a known issue of the PTY emulation between a Cygwin runtime and a Windows runtime enabled app. It just cannot be fixed. You're even lucky that it works in the Windows command shell. Lucky? Are VB console apps known to have unreliable piping when used from the Windows command processor? Either convert simple.vb to simple.c and use Cygwin's gcc to build it or create a Windows runtime version of input.exe. Isn't that what "input.exe is generate[d] from input.vb using: vbc input.vb" is referring to? -- 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: a few tar.xz packages are bigger than their uncompressed tar
On 24.09.2017 11:46, Jérôme Bouat wrote: Hello, I looked into the local folder where the downloaded packages are saved before they are installed. I noticed that a few compressed archives files are using more size than their uncompressed form. For example, the libstdc++6-6.4.0-1.tar.xz file uses more space than its uncompressed tar file (on cygwin x86_64). That is not surprising. All compression methods may sometimes inflate the final amount of data. No compression method need ever increase the size of the datum by more than one bit. The compressed representation can begin with a header bit which is 1 to indicate "compressed" and 0 to indicate "stored without compression". -- 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: Request to link to your website
On 26.10.2017 08:43, Kristopher Kelly wrote: The University of Phoenix, a for-profit university accredited by the Higher Learning Commission, would like to link to one or more pages within https://cygwin.com and install the associated software. The link(s) will be provided to students and faculty within university courses; the university will not be copying your content. Wow, outlandish ... In the long run, it may be cheaper for the U of Phoenix to get some sort of group counselling for this paranoia, if it is departmentally proliferated. If permission had to be obtained for every link, we would not have a World Wide Web to speak of. You do realize there are user-submission-driven news sites out there which feature hundreds of stories daily, each with a random link to something? SlashDot has been doing this since 1997; twenty years. Yes, it is safe to come out of your bunker; the radio-activity report was exaggerated ... -- 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
[ANNOUNCEMENT] Cygnal 2.8.99.97.
Cygnal (http://www.kylheku.com/cygnal/) is a replacement for "cygwin1.dll" which provides native-Windows-app behaviors. The basic idea, scope and aim of the project is that programs built in the Cygwin environment with its native compiler can be deployed with Cygnal as native Windows programs. This is the first release of Cygnal since August 2016. In this release, Cygnal has been rebased to Cygwin 2.9.0, from the previous 2.5.2. -- 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: [ANNOUNCEMENT] Cygnal 2.8.99.97.
On 23.11.2017 22:00, Brian Inglis wrote: Sorry, it was not obvious to me that this was *NOT* an official announcement, Cygnal is *NOT* a Cygwin package, and should *NOT* have been posted with that subject prefix: that post is deceptive. I used [ANNOUNCEMENT] simply because I saw the tag on other announcements. Some people might have filters based on this exact subject line tag; inventing a different, similar tag would evade those filters, possibly to someone's chagrin. I apologize to people who were curious about this, yet then disappointed to discover that it's something other than a program that they can just install under Cygwin and then use. Also, sorry if I broke any automated process which relies on these specially formatted subject lines matching official packages. I will remember to refrain from using the tag in the future. (which could easily be well over a year from now; whenever is the next time I sync up with Cygwin mainline.) -- 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: Wrong file position after writing 65537 bytes to block device
On 18.12.2017 16:27, Steven Penny wrote: On Mon, 18 Dec 2017 14:10:35, Corinna Vinschen wrote: In general, the writes on disk devices is sector-oriented. Howewver, in this case ftell should have returned 65536. The problem here is that the newlib implmentation of ftell/ftello performs an fflush when called on a write stream since about 2008 to adjust for appending streams. Given your example (thanks for the testcase!) this seems pretty wrong. Looking further it turns out that neither glibc nor BSD actually calls fflush in this case. There's only a special case for appending streams, but this calls lseek, not fflush. Looks like a patch is required. Stay tuned. is it though? he says "write 65536 + 1 bytes", but as far as i can tell, you cant do that. quoting myself: Seeking, reading and writing must all be done in multiples of sector size, in my case 512 bytes http://web.archive.org/web/stackoverflow.com/questions/37228874/how-to-fwrite-to-removable-volume so it would make sense that the position becomes "65536 + 512" You can do that on a "block" device. It's "raw" devices that have transfer unit restrictions. A block device creates an abstraction over a disk, dividing it into blocks. Those blocks are not related to the underlying sector size; they could be larger (e.g. 4096 byte block size, versus 512 byte sectors) or even smaller (e.g. 4096 byte block size, versus 65536 byte flash erase block size). Unix block devices let you read, write and seek using byte offsets and sizes. The bytes which are affected by a write operation map to one or more ranges in one or more blocks. All of the blocks have to be read into memory (if they aren't already). The bytes are updated, and then the blocks are marked dirty and written out (eventually). More changes can take place before that happens. So for instance if we have a block device (4096 bytes) over a flash device with 64 kB erase blocks, we can write just one byte somewhere in a block. When this change is flushed, the entire erase block has to be erased and rewritten. Because of the abstract nature of block devices, it's largely pointless to use the "dd" utility; you can use "cp" to copy them. "dd" is required when you need to control the exact size of the read and write calls. Thus "cat /dev/zero > /dev/blockdevice" has the same effect as "dd if=/dev/zero of=/dev/blockdevice". -- 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: fast/native fork?
On 2018-01-21 00:32, Jay K wrote: I have some desire to discuss fork. I know it is an old and difficult topic. I found this: "Cygwin fork and RtlCloneUserProcess" https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/afdf1b68-1f3e-47f5-94cf-51e397afe073/cygwin-fork-and-rtlcloneuserprocess?forum=windowsgeneraldevelopmentissues NT has had fork since v1. The Posix subsystem used it. You didn't need Vista's introduction of RtlCloneUserProcess. This from 2005 alludes to how to make it work: https://www.winvistatips.com/threads/question-about-ntcreateprocess.186504/ but I have difficult questions for you -- anyone, but including Corinna. What do you expect it to do? I mean, consider that there is no pthread_atfork or an analog in Win32. That's the last of your problems; pthread_atfork doesn't require kernel support. Dlls at all levels of the Win32 stack, might have process-specific state, that needs to be reinitialized. That issue affects any implementation of fork, including the current Cygwin one. https://www.cygwin.com/faq.html#faq.api.fork ntdll.dll is special. It somehow knows fork occured and can reinitialize itself. "Somehow" probably being the fact that ntdll.dll is special Or, rather "Somehow" being the fact that ntdll.dll is where the RtlCloneUserProcess function lives, so of course ntdll.dll is notified when a fork takes place: it's taking a direct function call. You don't get any more more notified than that. But no other dll expects this. But under the current implementation of fork in Cygwin, no regular Windows DLL expects to be attached to a Cygwin process which forks by copying .bss and .data and executing a longjmp in the child to recover the stack context. Moreover, ntdll.dll does not know about Cygwin fork, unlike its own fork. So it really just boils down to this forking mechanism just not being documented. An idea might be to have fork be switchable between the current implementation (default) and the RtlCloneUserProcess (experimental, run-time switchable). Just to get it to users to experiment with while keeping things stable, and without requiring special builds. -- 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: Setting a bash variable from backtick operator fails
On 2018-02-27 09:10, Numien wrote: Jürgen Wagner nailed it; it was my antivirus, and disabling the shellcode injection check fixed it. However, this time-wasting pattern of dealing with the issue by end users is not a good way. A better approach would be to identify some common paterns of BLODA interference and code a test which can detect the interference. This should be executed at startup by the Cygwin shell so that a diagnostic can be displayed to the user. WARNING: Cygwin detected interference from a "dodgy" application such as anti-virus software. Your Cygwin installation may malfunction. See http:// -- 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: Quotes around command-line argument that has unicode characters are not removed
On 2018-03-22 04:24, Andrey Repin wrote: Greetings, Dmitry Katsubo! Dear Cygwin community, I observe the following on my Cygwin: This is not cygwin, this is bare Windows. That may be so, yet there may be an issue here for someone packaging Cygwin programs for use as native Windows applications. That is to say, there could potentially be something here that the Cygnal project could address: http://www.kylheku.com/cygnal/ Cygnal is an ultra-light fork of the Cygwin DLL that is intended for users like Dmitry Katsubo, who run Cygwin programs out of the Windows environment directly, after building them in Cygwin. when I put quotes around file that has non-ASCII symbols, these quotes are passed to argv of the process literally, otherwise they are removed. I would expect that there is a consistency. Parameter unquoting done by the shell. CMD does that differently from POSIX shells. As I seem to recall, CMD doesn't do anything, period! It passes the command line as one big string. It has to since that's the OS mechanism. The quoting conventions come from how various run-time libraries deal with that string. An influential convention is that of the MS Visual C run-time library; it behooves other run-times to be compatible with that for consistency with programs whose main() was compiled with MSVC. -- 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: Quotes around command-line argument that has unicode characters are not removed
On 2018-03-22 15:21, Dmitry Katsubo via cygwin wrote: On 2018-03-22 18:10, Kaz Kylheku wrote: That may be so, yet there may be an issue here for someone packaging Cygwin programs for use as native Windows applications. That is to say, there could potentially be something here that the Cygnal project could address: http://www.kylheku.com/cygnal/ Cygnal is an ultra-light fork of the Cygwin DLL that is intended for users, who run Cygwin programs out of the Windows environment directly, after building them in Cygwin. Thanks for the hint. I confirm that just substituting cygwin1.dll makes the test working: D:\cli> test "текст плюс.txt" param 0 = test param 1 = текст плюс.txt File 'текст плюс.txt' was opened Well, that seems like a miracle, because in Cygnal, I don't remember doing anything to the processing of the command line or initial locale. I was not able to find any relevant difference in dcrt0.cc, but perhaps the difference is in initial setting of locale (Cygnal initialization). Could be some Cygwin issue caused by newer commit that isn't picked up in Cygnal; i.e "red herring". -- 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: Circular dependency with mingw64-x86_64-runtime
On 2018-05-01 16:33, Steven Penny wrote: On Tue, 1 May 2018 13:44:45, JonY wrote: What is the actual problem you are facing? i already described it: when 2 things depend on each other in this way, that is an error: http://wikipedia.org/wiki/Circular_dependency Nowhere does this page substantiate what you're saying; it doesn't say that the existence of a circular dependency is /ipso facto/ a form of error. If A cannot be used unless B is also installed, and if B cannot be used unless A is also installed, then there is a cycle in the dependency graph. The packaging system must express the cycle (and handle it). This means that if a user selects A for installation, it must be automatically accompanied by an installation of B, and vice versa. If you say that the dependency which is stated in the package system is incorrect, then you have to prove that either A or B can be usefully installed by itself. (Or even both, in which case they are independent.) If the circular dependency is right, but unwanted, it can only be broken by making some code changes in A or B, or both (and only then changing the dependency expressions at the package level). You can't simply say, "I don't like circular dependencies; I will break any cycles in the package system dependency definitions, whether or not they reflect the underlying packages". The only situation in which that would be justified would be that the package system is too weak to deal with circular dependencies; it gets into an infinite loop or whatever, so cycles must be avoided. -- 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: Programs become a no-op
On 2018-05-02 14:15, David Rothenberger wrote: On 5/2/2018 1:13 PM, Boylan, Ross wrote: I've tried ssh -V ssh --help ssh -v somene@somewhere and in all cases nothing happens except that I get a new command prompt. They used to work fine. This is usually due to a missing dependency. You can try "echo $?" after one of the failing commands. If it is 127, that's probably the issue. I usually track down the missing dependency by running the program under strace (strace ssh --help). It should pop-up a dialog window with the missing dependency library. What if it is 127 and the dialog says "The procedure entry point __locale_ctype_ptr could not be located in the dynamic link library cygwin1.dll"? That looks like an outdated cygwin1.dll w.r.t. that program (in this case gdb). But why doesn't setup.exe ensure that cygwin1.dll is up-to-date for other things it installs? -- 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: hdparm "Couldn't compute FAST_CWD pointer"
On 2018-05-03 14:02, Alejandro Soret wrote: I would really like to be of help to you so please tell me anything I can do to help you mitigate this error. You could ... search the mailing list archives, for any of the N times that the question has come up. Someone asked this just within the last week or two. Google Search confined to cygwin.com alone: https://www.google.com/search?q=%22couldn%27t+compute+FAST_CWD+pointer%22+site%3Acygwin.com Not to mention, not confined to cygwin.com: https://www.google.com/search?q=%22couldn%27t+compute+FAST_CWD+pointer%22 -- 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: cygwin not showing afp files since update
On 2018-05-03 12:30, Marco Atzeri wrote: On 5/3/2018 8:15 PM, Franz Joseph Bowman wrote: More information. It looks like Temporary files are created when using Print To File from Adobe. I went back and looked at old Postscript and AFP files created that way and Cygwin cannot see them when listing the directory or perl globbing. When specifying the whole filename, ls does see the file. Please email me if you have any help at franz D-O-T j D-O-T bowman A-T rrd D-O-T com Franz, We expect people that post on this mailing list are also reading it. That's a very rude/silly expectation: that to discuss something, you have to subscribe to receive discussions about topics you don't care about. (Topics which are being archived in quasi-real-time, so you can read them anyway!) What you've done there (adding F. J. to the Cc: line) is what any properly configured mailing list should be doing in the first place. Or, rather, the reply to F. J.'s message should be "To: F. J. ..." and then "cygwin AT cygwin.com" should be in the Cc: line. Classically speaking, of course, harkening to a time before this "Reply-To munging" bullshit became fashionable on mailing lists. -- 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: hdparm "Couldn't compute FAST_CWD pointer"
On 2018-05-03 14:23, Kaz Kylheku wrote: times that the question has come up. Someone asked this just within the last week or two. s/within.*two./today!/ -- 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
Use of spawnvp function makes console window appear.
Hi all,
I've encountered a strange behavior. When a Cygwin C application that is
compiled with "-mwindows" tries to spawn another program, that
application
suddenly gets a console window!
Here is a simple, complete, repro case, that demonstrates the problem
under Cygwin 2.5.2, on Windows 7:
#include
#include
int main(void)
{
const char * const argv[] = {
"c:/Windows/System32/notepad.exe",
0
};
Sleep(5000);
return spawnvp(_P_WAIT, argv[0], argv);
}
This is compiled as:
gcc -mwindows spawn.c -o spawn
If we launch this from the Windows Shell, then, correctly, it runs
with no console window. Nothing appears on the display for five
seconds, while it sits in the Sleep call.
Then, a console window opens with spawn.exe in its title,
immediately followed by the Notepad window over top.
What the heck?
--
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
Lengthy "xmlto" build step in Cygwin.
Hi All, What's this doing? Writing faq.html for article(faq) sed -i 's;;;g' faq/faq.html ../../.././winsup/doc/bodysnatcher.pl faq/faq.html xmlto --skip-validation --with-dblatex pdf -o cygwin-ug-net/ -m ../../.././winsup/doc/fo.xsl ../../.. /./winsup/doc/cygwin-ug-net.xml Build the book set list... Build the listings... It sat for a long time in "book set list ..." with the CPU idle. Same thing for "Build the listings...". It's just sitting there and sitting there. Task Manager shows an xsltproc.exe that isn't doing anything. Is this making network calls to an unresponsive server in Cameroon or something? -- 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: Use of spawnvp function makes console window appear.
On 29.06.2016 15:28, Kaz Kylheku wrote: Hi all, I've encountered a strange behavior. When a Cygwin C application that is compiled with "-mwindows" tries to spawn another program, that application suddenly gets a console window! I tracked this down to the fhandler_console::need_invisible() call in child_info_spawn::worker(). Whatever that is supposed to do is not working properly because the invisible window is perfectly visible. -- 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: Use of spawnvp function makes console window appear.
On July 1, 2016 Corinna Vinschen wrote: On Jun 30 20:38, Kaz Kylheku wrote: > I tracked this down to the fhandler_console::need_invisible() call in > child_info_spawn::worker(). > > Whatever that is supposed to do is not working properly because > the invisible window is perfectly visible. Try starting the process detached: spawnvp(_P_DETACH, argv[0], argv); Without a doubt that will work, since the call to fhandler_console::need_invisible is conditional on the mode not being _P_DETACH. The problem is that sometimes you don't want this detach behavior. Secondly, this child_info_spawn::worker is used underneath various functions: exec*, spawn*, popen, system. Not all these can pass through _P_DETACH at all. (I'm only using spawnvp for the sake of producing a minimal test case). Cheers ... -- 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
Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
The test program featured below works fine under
the Cygwin console window.
If executed from a cmd.exe console, strange things happen with the
cmd.exe window. Suddenly, the window spontaneously resizes so that
is taller than the desktop. A horizontal scrollbar may appear in it
also, as well as an unpainted area through which the desktop is
visible. As soon as you try to grab the title bar to resize it, it
disappears. It hasn't quit; it is actually minimized. You can
maximize it from the task bar and then resize the tall window to
its original shape.
This is using 32 bit Cygwin 2.5.2, on 64 bit Win 7.
All the program does is hammer Cygwin's VT100 emulation code
with the clear screen escape sequence: ESC [ 2 J.
A 1000 iterations are more than enough to reproduce it;
I made it 1.
If we change it to 100, some interesting variations
occur. It may take multiple runs of the program to reproduce
a problem. Then, suddenly, the window might shrink vertically
On a subsequent run, it might shrink again. In these situations,
it remains susceptible to a manual resize without
disappearing.
#include
int main(void)
{
int i;
for (i = 0; i < 1; i++) {
fputs("\x1b[2J", stdout);
fflush(stdout);
}
return 0;
}
--
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: Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
On 26.07.2016 22:19, Kaz Kylheku wrote: The test program featured below works fine under the Cygwin console window. If executed from a cmd.exe console, strange things happen with the cmd.exe window. Suddenly, the window spontaneously resizes so that is taller than the desktop. A horizontal scrollbar may appear in it also, as well as an unpainted area through which the desktop is visible. As soon as you try to grab the title bar to resize it, it disappears. It hasn't quit; it is actually minimized. You can maximize it from the task bar and then resize the tall window to its original shape. Narrowed it down to the con.scroll_window call in fhandler_console::clear_screen. The following test change makes the behavior go away. Moreover, the repeated clear screen requests stop making the vertical scroll bar jump around like crazy: diff --git a/winsup/cygwin/fhandler_console.cc b/winsup/cygwin/fhandler_console.cc index 5fe4480..2b8acb5 100644 --- a/winsup/cygwin/fhandler_console.cc +++ b/winsup/cygwin/fhandler_console.cc @@ -1261,7 +1261,9 @@ fhandler_console::clear_screen (cltype xc1, cltype yc1, cltype xc2, cltype yc2) /* Detect special case - scroll the screen if we have a buffer in order to preserve the buffer. */ +#if 0 if (!con.scroll_window (h, x1, y1, x2, y2)) +#endif con.clear_screen (h, x1, y1, x2, y2); } -- 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] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
The patch below seems to solves it for me:
Cygwin should not be faking a scroll of the console by shrinking it
and then restoring its size. Though clever, this is evidently
unreliable; cmd.exe misbehaves if the console handle
is hit with rapid SetConsoleScreenBufferSize calls.
From: Kaz Kylheku
Date: Wed, 27 Jul 2016 07:12:54 -0700
Subject: Replace bogus resize-window-to-clear-screen logic.
This removes (ab)uses of SetConsoleScreenBufferSize
which sometimes cause cmd.exe to badly misbehave.
It probably doesn't like the closely spaced timing of
shrinking the window down to one line followed by a restore
of the size. Instead we just output newlines to clear
the window.
* winsup/cygwin/fhandler.h (dev_console::scroll_window):
Member function declaration removed.
(dev_console::clear_should_scroll): New member
function declared.
* winsup/cygwin/fhandler_console.cc
(dev_console::scroll_window): Member function removed.
(dev_console::clear_should_scroll): New member function.
Performs only the test that was performed by scroll_window,
not the actual scrolling. The scrolling is now done in
the caller in the fhandler_console class.
(fhandler_console::clear_screen): Call con.clear_should_scroll
instead of con.scroll_window. If this returns false, act
as before. Otherwise, clear the screen by scrolling the
window. This is done not by making SetConsoleScreenBufferSize
calls to shrink and restore the window, but by earnestly
emitting a number of carriage returns equal to the vertical
screen size and then restoring the cursor position.
diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index 21c71d7..4af584b 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -1361,7 +1361,7 @@ class dev_console
int set_cl_x (cltype);
int set_cl_y (cltype);
bool fillin (HANDLE);
- bool __reg3 scroll_window (HANDLE, int, int, int, int);
+ bool __reg3 clear_should_scroll (HANDLE, int, int, int, int);
void __reg3 scroll_buffer (HANDLE, int, int, int, int, int, int);
void __reg3 clear_screen (HANDLE, int, int, int, int);
void __reg3 save_restore (HANDLE, char);
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 5fe4480..f4806e0 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -1209,38 +1209,11 @@ dev_console::set_cl_y (cltype y)
}
bool
-dev_console::scroll_window (HANDLE h, int x1, int y1, int x2, int y2)
+dev_console::clear_should_scroll (HANDLE h, int x1, int y1, int x2, int
y2)
{
if (save_buf || x1 != 0 || x2 != dwWinSize.X - 1 || y1 !=
b.srWindow.Top
|| y2 != b.srWindow.Bottom || b.dwSize.Y <= dwWinSize.Y)
return false;
-
- SMALL_RECT sr;
- int toscroll = 2 + dwEnd.Y - b.srWindow.Top;
- int shrink = 1 + toscroll + b.srWindow.Bottom - b.dwSize.Y;
- sr.Left = sr.Right = dwEnd.X = 0;
- /* Can't increment dwEnd yet since we may not have space in
- the buffer. */
- SetConsoleCursorPosition (h, dwEnd);
- if (shrink > 0)
-{
- COORD c = b.dwSize;
- c.Y = dwEnd.Y - shrink;
- SetConsoleScreenBufferSize (h, c);
- SetConsoleScreenBufferSize (h, b.dwSize);
- dwEnd.Y = 0;
- fillin (h);
- toscroll = 2 + dwEnd.Y - b.srWindow.Top;
-}
-
- sr.Top = sr.Bottom = toscroll;
-
- SetConsoleWindowInfo (h, FALSE, &sr);
-
- dwEnd.Y++;
- SetConsoleCursorPosition (h, dwEnd);
-
- fillin (h);
return true;
}
@@ -1261,8 +1234,28 @@ fhandler_console::clear_screen (cltype xc1,
cltype yc1, cltype xc2, cltype yc2)
/* Detect special case - scroll the screen if we have a buffer in
order to
preserve the buffer. */
- if (!con.scroll_window (h, x1, y1, x2, y2))
-con.clear_screen (h, x1, y1, x2, y2);
+ if (!con.clear_should_scroll (h, x1, y1, x2, y2))
+{
+ con.clear_screen (h, x1, y1, x2, y2);
+ return;
+}
+
+ int xpos, ypos;
+ cursor_get(&xpos, &ypos);
+
+ for (int i = 0; i < con.dwWinSize.Y; i++)
+{
+ WCHAR buf[] = { L'\n' };
+ DWORD done;
+
+ if (!WriteConsoleW (get_output_handle (), buf, 1, &done, 0))
+{
+ __seterrno ();
+ break;
+ }
+}
+
+ cursor_set(false, xpos, ypos);
}
void __reg3
--
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: [PATCH] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
On 27.07.2016 07:31, Kaz Kylheku wrote: The patch below seems to solves it for me: Oops, no it doesn't. Stay tuned. :) -- 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: [PATCH] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
On 27.07.2016 07:35, Kaz Kylheku wrote:
On 27.07.2016 07:31, Kaz Kylheku wrote:
The patch below seems to solves it for me:
Oops, no it doesn't. Stay tuned. :)
This is a bit more like it:
From: Kaz Kylheku
Date: Wed, 27 Jul 2016 07:49:54 -0700
Subject: Replace bogus resize-window-to-clear-screen logic.
This removes (ab)uses of SetConsoleScreenBufferSize
which sometimes cause cmd.exe to badly misbehave.
It probably doesn't like the closely spaced timing of
shrinking the window down to one line followed by a restore
of the size. Instead we just output newlines to clear
the window.
* winsup/cygwin/fhandler.h (dev_console::scroll_window):
Member function declaration removed.
(dev_console::clear_should_scroll): New member
function declared.
* winsup/cygwin/fhandler_console.cc
(dev_console::scroll_window): Member function removed.
(dev_console::clear_should_scroll): New member function.
Performs only the test that was performed by scroll_window,
not the actual scrolling. The scrolling is now done in
the caller in the fhandler_console class.
(fhandler_console::clear_screen): Call con.clear_should_scroll
instead of con.scroll_window. If this returns false, act
as before. Otherwise, clear the screen by scrolling the
window. This is done not by making SetConsoleScreenBufferSize
calls to shrink and restore the window, but by earnestly
emitting a number of carriage returns equal to the vertical
screen size and then restoring the cursor position.
diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index 21c71d7..4af584b 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -1361,7 +1361,7 @@ class dev_console
int set_cl_x (cltype);
int set_cl_y (cltype);
bool fillin (HANDLE);
- bool __reg3 scroll_window (HANDLE, int, int, int, int);
+ bool __reg3 clear_should_scroll (HANDLE, int, int, int, int);
void __reg3 scroll_buffer (HANDLE, int, int, int, int, int, int);
void __reg3 clear_screen (HANDLE, int, int, int, int);
void __reg3 save_restore (HANDLE, char);
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 5fe4480..380aeec 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -1209,38 +1209,11 @@ dev_console::set_cl_y (cltype y)
}
bool
-dev_console::scroll_window (HANDLE h, int x1, int y1, int x2, int y2)
+dev_console::clear_should_scroll (HANDLE h, int x1, int y1, int x2, int
y2)
{
if (save_buf || x1 != 0 || x2 != dwWinSize.X - 1 || y1 !=
b.srWindow.Top
|| y2 != b.srWindow.Bottom || b.dwSize.Y <= dwWinSize.Y)
return false;
-
- SMALL_RECT sr;
- int toscroll = 2 + dwEnd.Y - b.srWindow.Top;
- int shrink = 1 + toscroll + b.srWindow.Bottom - b.dwSize.Y;
- sr.Left = sr.Right = dwEnd.X = 0;
- /* Can't increment dwEnd yet since we may not have space in
- the buffer. */
- SetConsoleCursorPosition (h, dwEnd);
- if (shrink > 0)
-{
- COORD c = b.dwSize;
- c.Y = dwEnd.Y - shrink;
- SetConsoleScreenBufferSize (h, c);
- SetConsoleScreenBufferSize (h, b.dwSize);
- dwEnd.Y = 0;
- fillin (h);
- toscroll = 2 + dwEnd.Y - b.srWindow.Top;
-}
-
- sr.Top = sr.Bottom = toscroll;
-
- SetConsoleWindowInfo (h, FALSE, &sr);
-
- dwEnd.Y++;
- SetConsoleCursorPosition (h, dwEnd);
-
- fillin (h);
return true;
}
@@ -1261,8 +1234,27 @@ fhandler_console::clear_screen (cltype xc1,
cltype yc1, cltype xc2, cltype yc2)
/* Detect special case - scroll the screen if we have a buffer in
order to
preserve the buffer. */
- if (!con.scroll_window (h, x1, y1, x2, y2))
-con.clear_screen (h, x1, y1, x2, y2);
+ if (!con.clear_should_scroll (h, x1, y1, x2, y2))
+{
+ con.clear_screen (h, x1, y1, x2, y2);
+ return;
+}
+
+ int xpos, ypos;
+ DWORD done;
+ cursor_get(&xpos, &ypos);
+ cursor_set(false, 0, con.b.dwSize.Y - 1);
+
+ for (int i = 0; i < con.dwWinSize.Y; i += done)
+{
+ if (!WriteConsoleW (h, L"\n", 1, &done, 0))
+{
+ __seterrno ();
+ break;
+ }
+}
+
+ cursor_set(false, xpos, ypos);
}
void __reg3
--
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: [PATCH] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
On 27.07.2016 11:45, Corinna Vinschen wrote: Btw, since you're apparently building your own Cygwin DLL I thought just sending the patch for testing is sufficient. If you prefer to get a developer snapshot with this patch, I can do that, too. Just say the word. The patch looks good and in many cases avoids padding the history with blank lines, compared to the naive newline emission approach. Usually, the clear screen operation is preceded by a homing of the cursor. I.e., in VT100 language: ESC [ H, ESC [ 2 J. In this case, your approach seems to nicely trim the console data at that line. Rather, that is to say, when we scroll back, there aren't any blank lines, since none were added; the clear was done as a pure scrolling operation without any padding data. Blank lines are only generated if the cursor is in the middle of the buffer. Since the cursor position is restored after the scrolling, that then adds blank lines between the scrolled-away material and the cursor position. And if the clear is repeated at that position, more blank lines are added for each repetition. Who cares about that case, though. Other implementations behave the same way, if not worse. Case in point: Gnome Terminal (3.4.1.1) behaves like my naive \n repetition patch! Every issue of ESC [ 2 J adds a window height's worth of blank lines to the history, regardless of the position of the cursor! That is what I compared to as a "gold standard", so I was okay with it. -- 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: [PATCH] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
On 28.07.2016 00:08, Corinna Vinschen wrote: Thanks for testing. I'll check in the patch as is for now, but I'd still be interested to fix the aforementioned empty lines problem, even if just for completeness. If you have an idea, feel free to propose. Hi Corinna, The blank lines above the cursor position, as well as any that are below, are entering into the history simply because they are part of the window content being saved. Any non-blank lines in their place would be expected to be saved, and no processing takes place to distinguish blank from non-blank. One way to address this is to basically scan the entire window portion of the buffer for trailing blank lines and trim the buffer to exclude them. Then scroll by the amount of remaining lines lines, to usher them into the history. Finally, restore the cursor position. Or, perhaps, two or more trailing blank lines in the window could be condensed down to one which does get saved, so the separation is not misleadingly condensed down to nothing. However, there are possible arguments against trimming blank lines which are above the cursor position. Say the window contains this: +--- | nonblank | blank | blank | > [] cursor | blank | blank | blank +--- It's uncontroversial to obliterate the three blank lines below the cursor. However the blank lines between the nonblank line and the cursor could be semantic; the user might want them in the scrollback history "as is". The leading nonblank line is a red herring; even if all the lines above the cursor are blank, the reasoning applies. -- 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: [PATCH] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
On 29.07.2016 03:39, Corinna Vinschen wrote: On Jul 28 21:51, Corinna Vinschen wrote: However, the former cursor position in the buffer is still known at clear screen time. It's stored in dev_console::dwEnd. So what I was thinking about is to check the above situation and then, rather then to just keep it as is, move the console window and the cursor position up to the line right after the former cursor position, i.e: After (desired?): buffer +--- | nonblank | nonblank | blank | blank window | > ---+ | > [] cursor | | blank | | blank ---+ | blank | blank | blank | blank +--- Does that make sense or am I still missing something? I applied a patch to perform this action. It's in the latest 2.6.0-0.5 test release I just announced. I've done some interactive testing with this using the interpreter for a Lisp dialect. I would evaluate this expression to generate a 5 second delay and then a clear screen VT100 sequence: (progn (usleep 500) (put-string "\e[2J")) during this time, I would scroll the buffer somewhere. I also tested with a cursor position somewhere in the middle of the window, having issued: (put-string "\e[12H") The programming language details don't matter; we could do this with bash echo $'\e...' and sleep 5. In terms of the final appearance of the terminal window, the best results are obtained using the naive newline ejection method! The screen is clear, and the cursor is at the proper *window* position. (That's what we care about in VT100-land; we don't care about Windows console buffer semantics, and the position in the abstract buffer; position means screen position.) Your first patch has the effect that the physical screen position is not always restored. The window is clear, but the cursor is sometimes at the bottom, even though it was somewhere in the middle of the window before the operation. In the abstract buffer coordinates, it is correct; it's just that the window viewport is not all the way down. With the third patch, I've run into behavior in which the display isn't cleared at all if the clear is issued in a scrolled-back state. The naive newline ejection, in spite of its flaw of adding more blank lines to the history than one would like, achieves the best visual results in all cases because the viewport jumps to the bottom of the buffer when the newlines are being emitted, and then the cursor position is restored in that viewport position. Cheers ... -- 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: [PATCH] Strange behavior of cmd.exe when hammered with clear screen operations from Cygwin program.
On 01.08.2016 01:51, Corinna Vinschen wrote: On Jul 29 08:59, Kaz Kylheku wrote: On 29.07.2016 03:39, Corinna Vinschen wrote: > I applied a patch to perform this action. It's in the latest > 2.6.0-0.5 test release I just announced. [...] I've done some interactive testing with this using the interpreter for a Lisp dialect. I would evaluate this expression to generate a 5 second delay and then a clear screen VT100 sequence: (progn (usleep 500) (put-string "\e[2J")) during this time, I would scroll the buffer somewhere. I also tested with a cursor position somewhere in the middle of the window, having issued: (put-string "\e[12H") The programming language details don't matter; we could do this with bash echo $'\e...' and sleep 5. [...] With the third patch, I've run into behavior in which the display isn't cleared at all if the clear is issued in a scrolled-back state. I can't reproduce this. If I don't click wildly on the scroll bat at the time the clear screen action takes place (so I move the window right after clear screen), the cursor is positioned at the top of the screen, at the end of the buffer. So, how would I reproduce your observation so that all window positioning is guaranteed to take place *before* the clear screen action and still see the broken output? Hi Corinna, I have figured out how to reproduce it. There are two necessary conditions. No, three: 1. You must scroll the display all the way to the top as far as you can before the clear screen is issued. 2. The scrollback history must be full. I.e., this won't happen in a fresh cmd.exe window. First, print thousands of lines of stuff to make the buffer "tall". This is why it only started happening to me after some amount of testing; I had filled the buffer. 3. It's probably a necessary condition that there is additional output immediately after the clear screen (such as the programming language prompt being printed), because the console scrolls to bottom on any output. I'm not sure if these are sufficient, but they seem to be on my end. This is perhaps some kind of race condition between the scrolling issued by cmd.exe, and the scrolling issued by the console API. Or maybe not a race, as such, but some backlog-processing logic. Perhaps the console simply drops scroll actions that it hasn't had time to perform. The API-requested scroll is thrown in the bit bucket, superseded by the scroll-to-bottom on output. -- 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: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN
On 03.08.2016 18:43, Michel LaBarre wrote: Problem 1: Cygwin does not support PATHEXT and really should. A casual websearch shows that this topic has come up before. For instance, someone posted, some decade ago, to the Cygwin mailing list, a patch against GNU Bash to make its command search algorithm take PATHEXT into account. Fundamental reason: from the Cygwin FAQ - What is it? "Cygwin is a distribution of popular GNU and other Open Source tools running on Microsoft Windows." PATHEXT is as fundamental component of Windows program execution as PATH. I can't find any reference anywhere to PATHEXT being used outside of the CMD.EXE interpreter, which rather tends to make it substantially less than fundamental to Windows, though noteworthy. Certainly, CreateProcess does not use PATHEXT. I can't find any documentation which says that ShellExecuteEx uses PATHEXT, either. (Can anyone confirm?) Everything points to it being a CMD.EXE "gizmo". If you want to execute a command such that PATHEXT is taken into account, you have to spawn CMD.EXE /C . Cygwin provides a POSIX environment on Windows. Users of a POSIX environment don't expect a command "foo" to resolve to a file "foo.bat". If they want to run "foo.bat" they use "foo.bat". Without using extensions, bash can use execution privileges to determine if a file is executable. However, that does not work when invoking a command from CMD. What does not work from CMD is Microsoft's problem, not Cygwin's. Yes, even though you have a "myscript.sh" and you do "chmod a+x myscript.sh" inside Cygwin, the outside Windows world doesn't agree that myscript.sh is now executable, and that it uses /bin/sh by default as its interpreter, if a #! line is absent, otherwise the interpreter nominated by the #! line. Adding ".sh" to PATHEXT might work in causing CMD.EXE to resolve "myscript" to "myscript.sh"; however, it will not then successfully execute "myscript.sh", because the underlying CreateProcess API will not find it executable. CMD.EXE will probably *try* to execute it, and fail. This means that when invoked from BASH, you name a command "ZOT" but "ZOT.sh" (or similar) if invoked from CMD. From CMD, you have do something explicit like this: C:\Cygwin\bin\bash C:\Path\to\zot.sh That is, you have to run Bash, and pass it the script as an argument. Windows and CMD.EXE will not associate .sh with Bash and certainly won't look at any #! line you may have in the script. Not supporting arbitrary interpreters for scripts is a Windows problem/limitation. Cygwin overcomes that limitation within its "garden". If you solve the entry point problem of how to invoke Cygwin code from the outside, once you are in Cygwin land, you have no further problems. Scripts marked executable and containing #! use their respective interpreters and so on. The published solutions in the various FAQs are not satisfactory. Creating links between ZOT.sh and ZOT creates substantial overhead. I don't think that will work, unless by "creating a link" you mean that you create a ZOT.BAT file shim which invokes the neighboring ZOT.sh by passing its full path to bash.exe. If CYGWIN really intends to support Windows it should support its fundamental execution framework. It should be equally easy to invoke a bash script from a bash script or a CMD script. What you need on Windows is a script-to-EXE application deployment tool, which takes your "script.sh" and combines it with a copy of a special binary executable, and writes out the combination to "script.exe". Then even a raw CreateProcess Win32 API call can invoke "script.exe". Problem 2: Cygwin does not support CR-LF delimiters. For the same reason, it is unfortunate that CYGWIN/bash does not cope with both types of line delimiters transparently. The way Cygwin deals with CR/LF has evolved over time, and there are various ways to deal with this, depending on the specific situation. Firstly, the binary mode default treatment for files comes from the mount table: $ mount C:/Cygwin/bin on /usr/bin type ntfs (binary,auto) C:/Cygwin/lib on /usr/lib type ntfs (binary,auto) C:/Cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) See how that /cygdrive/c is mounted "binary" (as is everything else?) That's what causes text files to be treated as LF rather than CR/LF. That can be altered; you can mount some Windows path into Cygwin's POSIX file system view as text, and then CR/LF conversion is done. Then, secondly, there are approaches for individual C programs. If you're porting something written in C, the C library in Cygwin supports the "t" flag in fopen and related functions. This is similar to the Microsoft extension, found in the Visual C run-time library. In ISO C, if you omit the "b" mode, then a file is open in text mode, but on POSIX that is the same as binary mode. In Cygwin, if you specify "t", you get the Windows text mode, CR/LF.
Re: PATHEXT is fundamental to Windows and Should be recognised by CYGWIN
[private, off-list reply] Hi Michael, Do you have some sort of list of detailed requirements implemented by MKS tools where Cygwin is different or lacking in some way? Maybe Cygwin could pick up some of them. Anyway, about a month ago, when I learned that Cygwin is now under the Lesser GPL, I started a project called Cygnal (Cygwin Native Application Library) whose goal is to improve the usefulness of Cygwin for Windows development. http://www.kylheku.com/cygnal However, I have a different angle on it: the perspective is of developing a native application (which ships native executables, without any apparent POSIX environment with a shell, commands or any of that). I don't need to infuse the Cygwin environment with Windows conventions; building my program within the POSIX conventions suits me just fine. However, I don't want the *users* of the program (a binary .exe accompanied by .dll files, wrapped up in an installer) to be exposed to POSIX conventions. With Cygnal, you can develop a single executable file, which works with POSIX and Windows conventions, simply based on which flavor of the cygwin1.dll it is linking against. Cheers ... -- 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: Please explain how to add to a thread in this mailing list
On 11.08.2016 17:44, Thomas Taylor wrote: Thank you for responding to my post. I think I asked the wrong question. What I really want to know is how to use this mailing list and others like it. I'm new at this, and can't find any instructions anywhere. Such lists must have become part of the culture, and I must have missed school that day. I'm able to create a post, but don't know how to reply to one. On pretty much any mailing list, you can use "reply all". The most important thing that is going wrong on your end is that your replies are lacking a References: header which cites the Message-ID: values obtained from postings in the thread. These message ID references are actually what organizes the message objects into threads; it's how mail user agents and archivers can reconstruct the conversation tree. Somehow I got the feeling that I should only reply to the mailing list, rather than directly to the person (like you) who responded to my post. Some mailing lists (like this one) are configured such that when you reply to a list posting that you received from the list robot, a list reply occurs whether or not you use "reply" or "reply all". This is because the mailing list robot rewrites the From: headers of the postings which it replicates so that it appears to be the author. This is very useful when lists are expected to be used by kindergarten children rather than grown-ups, because it steers the users to the common behavior of keeping the conversation in the list, without those users having to understand e-mail, mailing lists, or which reply button to use. (In some modern e-mail clients, a third way of replying has also appeared, namely "reply list", I just want to mention. It's an unnecessary feature with an unclear justification that appears to emanate from a deep-rooted misunderstanding of e-mail.) "Reply all" works in most circumstances, regardless of how mailing lists are configured. In the classic mailing list that doesn't rewrite From: lines, nor assert the Reply-To: header, you must use "Reply All", otherwise the reply will only go to the originator. "Reply All" also honors the Cc: line. Your reply is targetted to everyone in the To: and Cc:, which might include some parties who are not subscribers of the mailing list, but are "in the loop" of that particular conversation. I don't get responses via email, and don't even know if I should. If you're subscribed to the list, you should see them; if you aren't, there is some mail delivery problem. Instead, I check for them periodically on the web page for the mailing list archive. If I find a response, I don't know the right way to reply. Replying via the archive is difficult, because it's not set up for that. Some better archivers have such a feature; I use one called "Lurker" on my mailing lists. You can simply click on a reply button in the web archive, and it redirects to your configured mail program, passing the original text and other pieces of information as URL parameters. If I want to reply to a conventionally archived mailing list posting, I copy the raw text version. Then do some editing to restore certain masked syntax like "foo dot bar" to "foo.bar" and "foo at bar" to "foo@bar", in the headers only. I also take care to edit the mbox-format "From ..." line to include the colon after the From, as is required in the regular RFC 822 format. Then I telnet to port 25 of my mail server, compose an envelope from and to myself, and copy and paste that raw e-mail as the SMTP DATA. It arrives in my inbox as if the list had sent it to me; and I can reply to it in the conventional way. Sometimes this method generates a Cc: to the list owner; that has to be removed, either when composing or when editing the raw text before SMTP. I have the feeling you might be cutting and pasting quoted text from the archive and composing new messages, which is why your replies are lacking the References: header. The archiver is able to infer that this is going on, and is threading your replies anyway, under a node marked "". It's probably figuring this out based on some heuristics involving the common Subject: line and perhaps some fuzzy matching on pieces of quoted text. [I'm adding you to the Cc: list in hopes that perhaps direct mail delivery from me-to-you will work, since you aren't getting list traffic.] -- 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
Standard LEX variable doesn't work in Make.
Hi, I'm changing a FOSS project to rely more on standard Make vars such as CC and CFLAGS and such: use $(CC) for the compiler unless told otherwise, incorporate $(CFLAGS) if it is defined, and so forth. This is friendly toward distro package maintainers. Anyway, even though my Cygwin installation has GNU Flex, the lex command is nonexistent; thus the $(LEX) Make variable fails. Either LEX should go to "flex", or there should be a "lex" alias. If the installation has some sort of lex, the predefined $(LEX) variable should resolve to it. -- 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: ExitProcess does not work in Cygwin?
On 2022-01-13 05:40, Eliot Moss wrote: On 1/13/2022 1:39 AM, Jay K wrote: ExitProcess does not work in Cygwin? ExitProcess does not appear to be a POSIX function. This is a real issue worth looking into. Though ExitProcess isn't a POSIX function, Cygwin can capture the termination status of non-Cygwin programs. The concept of termination status cannot be entirely walled off in a private Cygwin garden; it belongs to the underlying platform. In Cygwin, I can do this: C:\Cygwin\cygwin64\home\kaz>exit 1 1:BLACKBOX:~$ 1:BLACKBOX:~$ echo $? 1 0:BLACKBOX:~$ cmd Microsoft Windows [Version 10.0.19042.1052] (c) Microsoft Corporation. All rights reserved. C:\Cygwin\cygwin64\home\kaz>exit 0 0:BLACKBOX:~$ The number in my Bash prompt is the last exit code. As you can see, the non-Cygwin CMD.EXE program produces a termination code which is recognized in the Cygwin world. Most likely it does that via ExitProcess. It is odd if calling ExitProcess in a Cygwin process causes a Cygwin parent not to similarly process the status, as seems to be shown by Jay's test cases. Cygwin supports non-POSIX programming; you can write GUI applications using Win32 calls for instance. (Now I agree that for exiting your process, even if it's a GUI application using numerous win32 calls, you should probably do it the Cygwin way, and use exit, or return from main. But still ...) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Typed characters are mis-ordered when CPU usage is high
On 2022-02-27 06:53, Takashi Yano wrote: I think this is due to a bug which I recently fixed. https://cygwin.com/pipermail/cygwin-patches/2022q1/011791.html Was that upstreamed? Sorry to be a pain, but something in the log message about the cause and the fix (not just the manifested issue being addressed) would be good. Reversed characters might mess not only with the user's input, but with input coming from terminal emulation, like escape sequences, which may be a worse problem. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
cygwin@cygwin.com
On 2023-12-17 22:22, Dan Shelton via Cygwin wrote: > It would be nice if someone from the Cygwin authors could assist me in > figuring out why this happens. Cygwin is famously slow; this is nothing new. We are grateful for Cygwin because it makes stuff work at all; if it were blazing fast that would be a bonus. E.g. git operations (clone, rebase, ...); ./configure scripts; ...: all run like molasses. The following is just my fast and loose opinion, shot from the hip, and possibly off or wrong, but it likely has to do with the layering. Cygwin's core API is based on a C library called Newlib. Cygwin bolts Newlib to Windows by means of an additional shim below Newlib that is based on C++ objects, where there is path munging going on and such, and that's where the Win32 calls get made. It's an additional abstraction. I worked with the internals a bit when producing the Cygnal project. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
cygwin@cygwin.com
On 2023-12-21 04:16, Martin Wege via Cygwin wrote:
> On Wed, Dec 20, 2023 at 6:21 PM Kaz Kylheku via Cygwin
> wrote:
>>
>> On 2023-12-17 22:22, Dan Shelton via Cygwin wrote:
>> > It would be nice if someone from the Cygwin authors could assist me in
>> > figuring out why this happens.
>>
>> Cygwin is famously slow; this is nothing new. We are grateful
>> for Cygwin because it makes stuff work at all; if it were blazing
>> fast that would be a bonus.
>>
>> E.g. git operations (clone, rebase, ...); ./configure scripts; ...: all
>> run like molasses.
>>
>> The following is just my fast and loose opinion, shot from the hip,
>> and possibly off or wrong, but it likely has to do with the layering.
>> Cygwin's core API is based on a C library called Newlib. Cygwin bolts
>> Newlib to Windows by means of an additional shim below Newlib that
>> is based on C++ objects, where there is path munging going on and such,
>> and that's where the Win32 calls get made. It's an additional abstraction.
>
> I disagree with that. Ok, part of that is that the layering causes
> more memory allocations and copies, but this is not the root cause.
I seem to recall that most operations that take a path argument have
to convert the path from Cygwin to Win32, and I think that also involves
going from 8 bit to UTF-16 also. That's gotta hurt a bit.
> The root cause is IMO the extra Win32 syscalls (>= 3 per file lookup,
> compared to 1 on Linux) to lookup the *.lnk and *.exe.lnk files on
> filesystems which have native link support (NTFS, ReFS, SMBFS, NFS).
> On SMBFS and NFS it hurts the most, because access latency is the
> highest for networked filesystems.
Could some intelligent caching be added there? (Discussion of
associated invalidation problem in 3... 2 1... )
Can you discuss more details, so people don't have to dive into code
to understand it? If we are accessing some file "foo", the application
or user may actually be referring to a "foo.lnk" link. But in the
happy case that "foo" exists, why would we bother looking for "foo.lnk"?
If "foo" does not exist, but "foo.lnk" does, that could probably be
cached, so that next time "foo" is accessed, we go straight for "foo.lnk",
and keep using that while it exists.
If someone has both "foo" and "foo.lnk" in the same directory,
that's a bit of a degenerate case; how important is it to be "correct",
anyway.
> So my proposal would be to add an option ('fslinktypes') to the CYGWIN
> environment variable to define which types of links are supported:
> default 'all'. which is an shortcut for 'native,lnk,lnkexe'.
> So in case people do not want 'lnk' link support they just add
> CYGWIN+=' fslinktypes:native' to env, to turn off support for
> lnk/lnk.exe style links, and be happy.
So this complements the winsymlinks option? winsymlinks has to do
with how the Cygwin DLL creates symbolic links, whereas this has to do
with what objects are recognized as links.
The implementation would probably want to compare fslinktypes
and winsymlinks to make sure they are harmonized together;
if winsymlinks tells Cygwin to make .lnk files, but then fslinktypes
banishes them, that's something diagnosable somehow.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Possibly buggy use of ctype.h macros.
Hi All, I noticed that this macro, defined in winsup/cygwin/local_includes/path.h: #define isdrive(s) (isalpha (*(s)) && (s)[1] == ':') is being used with arguments of type char, like dereferenced "char *" pointers. Unless the isalpha implementation is robust against this, it should be isalpha((unsigned char) *(s)). -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Possibly buggy use of ctype.h macros.
On 2024-01-02 15:25, Takashi Yano via Cygwin wrote: > On Tue, 02 Jan 2024 14:18:15 -0800 > Kaz Kylheku via Cygwin wrote: >> I noticed that this macro, defined in winsup/cygwin/local_includes/path.h: >> >> #define isdrive(s) (isalpha (*(s)) && (s)[1] == ':') >> >> is being used with arguments of type char, like dereferenced "char *" >> pointers. >> >> Unless the isalpha implementation is robust against this, it should be >> isalpha((unsigned char) *(s)). > > > https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/ctype/ctype_.h;h=a73870b3e4ade5545fd41bcc6f10446a22b4b46e;hb=HEAD I see, so on Cygwin, the negative index is allowed, thanks to a displacement. # define DEFAULT_CTYPE_PTR ((char *) _ctype_b + 127) But, 127? A (signed) char can go to -128. '\x80' will access _ctype_b[-1]. Is that also somehow OK? (Tangential remark: all ctype implementations have to handle at least one negative value, namely EOF.) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Possibly buggy use of ctype.h macros.
On 2024-01-02 16:11, Takashi Yano via Cygwin wrote: > Perhaps, the off-by-one is for EOF as you guess. I doubt it. If EOF were out of range of char, it would have to be -129 or less, so that -127 would look even more wrong. I see EOF is just -1. That value will also be produced by '\xFF', or "\xff"[0], etc. This -127 displacement is worth looking into; there is a smell emanating from it. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Possiblly bug of cygwin1.dll
On 2024-01-19 20:18, Takashi Yano via Cygwin wrote:
> And I tried to observe the pthread_mutex_xxx() call. Then found the
> test case does like:
>
> #include
> int main()
> {
> for (;;) {
> pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
> pthread_mutex_lock(&m);
> pthread_mutex_unlock(&m);
> }
> return 0;
> }
Note POSIX:
In cases where default mutex attributes are appropriate,
the macro PTHREAD_MUTEX_INITIALIZER can be used to initialize
mutexes. The effect shall be equivalent to dynamic initialization
by a call to pthread_mutex_init() with parameter attr specified as NULL,
except that no error checks are performed.
Thus, the following is correct:
for (;;) {
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&m);
pthread_mutex_unlock(&m);
pthread_mutex_destroy(&m); // <--- added
}
Does your above code leak if you add the destroy call?
If so, pthread_mutex_destroy needs to be fixed.
Either way, libstdc++ should be calling pthread_mutex_destroy
in the destructor, in spite of initializing the object with
a simple initializer.
That libstdc++ library could be fixed in the same way;
the mutex object's destructor should call pthread_mutex_destroy,
even though the constructor didn't call pthread_mutex_init.
This is a "moral equivalent":
class buf {
unsigned char *ptr;
public:
buf() : ptr(NULL) { }
~buf() { delete [] ptr; }
// ...
};
Just because you have a constructor that trivially initializes
some resource with a constant expression doesn't mean that the
destructor has nothing to free. In between there the object
is mutated so that it holds resources.
> POSIX states pthread_mutex_t can be initialized with
> PTREAD_MUTEX_INITIALZER when it is STATICALLY allocated.
I'm looking at this and don't see such a constraint:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_destroy.html
The word "static" only occurs in the Rationale section.
Use of the initializer is not restricted to static objects
by any normative wording.
In real systems, the static distinction has no meaning.
This code can be inside a shared library:
static pthread_mutex_t g_lock = PTHREAD_MUTEX_INITIALIZER;
this library could be loaded by dlopen and unloaded with dlclose.
Thus static becomes dynamic!
And, by the way, this is a problem: if we have a library
which does the above, and we repeatedly load it and unload
it while using the mutex in between, it will leak.
I think you don't want to do this kind of initialization in
reloadable plugins, unless you put in some destructor hooks,
or wrap it with C++ objects with destructors.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Possiblly bug of cygwin1.dll
On 2024-01-24 03:55, Takashi Yano via Cygwin wrote: > Are there any code examples that use PTHREAD_MUTEX_INITIALIZER > with pthread_mutex_destroy()? I don't think I've seen one. I think they are rare in the field, precisely because PTHREAD_MUTEX_INITIALIZER is mainly used in C code to "initialize and forget" global mutexes, so they are ready before the first thread is every created (and before main is even called). Nobody cares about destruction of global mutexes in an executable (not shared library). >> Use of the initializer is not restricted to static objects >> by any normative wording. > > It seems that I had read the older POSIX document. > > https://pubs.opengroup.org/onlinepubs/007904875/functions/pthread_mutex_destroy.html Aha! OK! Because I had a memory of there had been something about a static restriction. I took it for granted you were right about that, and was looking at that for other reasons. So, good, that is gone. It never made sense anyway. Pairing the initializer with the destructor call can be done in all situations now. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Possiblly bug of cygwin1.dll
On 2024-01-24 05:11, Corinna Vinschen via Cygwin wrote: > Is anybody willing to give this a whirl? We have a good year until > the next major release... As far as the problem of not allocating per-mutex kernel objects, this can be done by implementing futex. Linux has futexes, mainly for solving certain problems having to do with doing synchronization efficiently in user space, while requiring the kernel to actually make threads wait. But the technique has an attractive aspect in that programs do not have to allocate and free futexes. Any memory location is a futex. (A vaguely similar idea was implemented in early Unix: the "wait channel" (wchan). Any memory location in the kernel could be waited on and signaled, without allocating or freeing any sync object. That's where the wchan field comes from in ps; showing the address of what the process is waiting in. Because the wait channel had no state, any address could be used. Addresses of functions were used, because those could be resolved back to meaningful names via the symbol table. Futexes have state, though.) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: MULTIPLE VULNERABILITY REPORT: Multiple DLL Hijacking Vulnerability in CygWin setup-x86_64.exe
On 2024-02-04 21:22, Suman Chakraborty via Cygwin wrote: > 1. Executive Summary: > > The vulnerability pertains to not finding > the profapi.dll, CFGMGR32.dll, edputil.dll, urlmon.dll, SspiCli.dll, > Wldp.dll, MPR.dll, ServicingCommon.dll, TextShaping.dll, CRYPTBASE.DLL, > PROPSYS.dll and insecure loading of dynamic link libraries (DLLs), > specifically profapi.dll. If exploited, this vulnerability could allow an > attacker to execute arbitrary code on a victim's machine, potentially > leading to data breaches, system compromise, and other malicious activities. By what means is setup.exe probing these DLLs? I don't see any references to profapi.dll in its source tree (git grep -i profapi turns up nothing). If these DLL's being missing doesn't stop the program from running, doesn't that mean it's just probing for them with LoadLibrary or LoadLibraryEx explicitly, and then handling the failure gracefully? Setup itself doesn't use LoadLibrary or LoadLibraryEx. The MinGW toolchain must be introducing that somehow? It is curious. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Updated: setup (2.930)
On 2024-02-07 11:57, Jon Turney via Cygwin wrote: > A new version of Setup (2.930) has been uploaded to: > > https://cygwin.com/setup-x86_64.exe (64 bit version) > https://cygwin.com/setup-x86.exe (32 bit version) > > Changes compared to 2.929: > > - Add some hardening against "DLL hijacking" attacks (Thanks to Corinna > Vinschen for doing all the thinking involved) Is this because of the report submitted by Suman Chakraborty? I didn't see any public response confirming that there is any problem,and that that action would be taken. I see the commit: https://cygwin.com/cgit/cygwin-apps/setup/commit/?id=0122154811bacdd7dc042cff0c80bb0a36af360c I'm curious, what improvement arises out of looking up the SetDefaultDllDirectories function dynamically in kernel32.dll? Is it the case that malicious software can interpose itself somehow such that the statically linked SetDefaultDllDirectories call goes elsewhere other than kernel32.dll, which we can thwart by asking for the genuine article in kernel32.dll? (If this fixes the problem for Suman, he has some malware or antivirus crap on his PC.) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Using ARM GNU GCC with Cygwin
On 2020-04-04 02:00, Ben wrote: Is there something else I'm missing? That by cross-compiling for your targets on Cygwin instead of a real POSIX OS, you will something like double your compile times, if not more. Why would you involve Cygwin in a development activity whose target isn't POSIX on Windows. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Using ARM GNU GCC with Cygwin
On 2020-04-04 11:58, Åke Rehnman via Cygwin wrote: On 2020-04-04 16:32, Kaz Kylheku via Cygwin wrote: On 2020-04-04 02:00, Ben wrote: Is there something else I'm missing? That by cross-compiling for your targets on Cygwin instead of a real POSIX OS, you will something like double your compile times, if not more. Why would you involve Cygwin in a development activity whose target isn't POSIX on Windows. Most strange comment I have read... With your reasoning why bother with cygwin at all for any reason? There are excellent reasons, obviously: Firstly: to have a familiar POSIX environment available on Windows, for personal use, where Windows is dictated by a workplace. For instance, one use case of mine for dropping into Cygwin is to run ImageMagick's convert command to either convert a .pdf file into multiple .png files or vice versa. This is in the context of work e-mails (Outlook, Exchange, ...). I have a major use case for Cygwin for providing remote access to Windows. Using a non-Cygwin utility called "RunAsService.EXE", I turned a Cygwin Bash script into a Windows service. This Bash script loops around and makes a SSH connection to a host in a domain that I control, setting up a tunnel for port 3389 (RDP). From that domain, I can then remote desktop into the Windows system. Basically I can deploy this solution on any Windows machine on any network where outbound SSH is allowed, and have remote access to it. Secondly: to port stuff to Windows that has to run on Windows for reasons like the target users being tied to Windows, yet uses lots of POSIX API's. "A cross-compiling GNU toolchain" isn't an example of an application that must run on Windows. It's not shipped to users. The system/device being targeted by the cross-compiling is what is shipped to users. Why wouldn't you use the best possible environment for that, on a robust, fast OS. OP has explained that he's just curious to get that working, and there is certainly nothing wrong with that. I certainly don't want to dictate to him what he should find interesting and motivating; that was not the intent of my remark. I also must acknowledge the following: there may be a situation whereby the embedded system in question (quite stupidly, but out of your control) requires communication with Windows for some procedure like flashing part of the firmware or something (say over USB). The people responsible for that developed a utility which only runs on Windows. If you can build on Windows, then the whole workflow is easily streamlined, including the part where you have to kick off the FOOBAR.EXE to do that annoying step. It nicely runs on just one machine without any extra copying of images and whatnot. (Yes, I've dealt with stuff like that, but usually outside of the regular dev cycle. Like say for flashing an low-level bootloader not touched by regular rebuilds of the main image, or recovering a totally "bricked" unit and such.) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Using ARM GNU GCC with Cygwin
On 2020-04-08 13:58, David Rothenberger wrote: On 4/8/2020 1:50 PM, Kaz Kylheku via Cygwin wrote: On 2020-04-04 11:58, Åke Rehnman via Cygwin wrote: I have a major use case for Cygwin for providing remote access to Windows. Using a non-Cygwin utility called "RunAsService.EXE", I turned a Cygwin Bash script into a Windows service. This Bash script loops around and makes a SSH connection to a host in a domain that I control, setting up a tunnel for port 3389 (RDP). From that domain, I can then remote desktop into the Windows system. Basically I can deploy this solution on any Windows machine on any network where outbound SSH is allowed, and have remote access to it. You might want to look at the "autossh" Cygwin package. It handles exactly this use case and can be registered as a Windows service without any non-Cygwin utilities. Hi David, thanks for bringing this to my attention. That seems to use something called cygrunsrv, which is what I should have used for that script (and will be sure to do upon the next opportunity of using it again). Just look at /usr/share/doc/autossh/README.Cygwin after you install the package for details about the service. I've been using this for years for the purpose you've described and it's been working great. I'm reading the documentation and basically my 25 line script has all the features, including exponential backoff for restarting a failed connection. I'm not terribly in favor of formal packages that can be replaced by a shell scripts that fit into an 80x25 window. Here it is: #!/bin/bash PATH=/bin:/usr/bin THISDIR=/cygdrive/C/Cygwin/.ssh DEST=@ sleep_exp=0 while true ; do time_before=$(date +%s) ssh -i $THISDIR/id_rsa -vv -R :3389:127.0.0.2:3389 \ -o UserKnownHostsFile=$THISDIR/known_hosts \ -o PasswordAuthentication=no \ -o ServerAliveInterval=60 \ -o ServerAliveCountMax=3 \ $DEST rdp 2> /.ssh/log time_now=$(date +%s) if [ $(( time_now - time_before )) -le 600 ] ; then sleep_exp=$(( sleep_exp >= 9 ? sleep_exp : sleep_exp + 1 )) else sleep_exp=0 fi sleep $(( ((1 << sleep_exp) + 15) / 16 )) done Why do we execute a command called "rdp" on the remote host? Because the home directory of the account that is used has the following shell script as its login shell: #!/bin/bash if [ $# -ne 2 ] || [ "$1" != "-c" ] ; then echo interactive login not permitted echo "$@" >> ~/.log exit 1 fi case "$2" in rdp ) while true ; do sleep 3600 ; done ;; * ) echo that command is not allowed exit 1 ;; esac This is necessary because the Windows machine has a password-unprotected private key that it uses to log in to this. The service automatically starts if the Windows is rebooted, without requiring any password. Anyone with access to the Windows machine (such as an IT admin) who finds this stuff could use that key to SSH to that account on that host. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
