Re: attention alternatives maintainer
Doug Henderson via Cygwin-apps writes: > Please update alternatives to work properly for a first time install > of an alternative when CYGWIN=winsymlinks:nativestrict. I do not think of this as a bug in alternatives. POSIX programs that create symlinks to non-existing files are perfectly valid and they don't need to care whether they are pointing to files or directories either. A dangling POSIX symlink resolves once its target comes into existence. > In order to make it run I must set CYGWIN=winsymlinks:native, run the > postinstall script in an elevated shell (or from setup). Then I can > restore CYGWIN=winsymlinks:nativestrict. I think the link target must > be created before the symlink is created. Without looking at the code, > I suspect the order of two symlink needs to be reversed. No, setup should ignore the CYGWIN settings. These are for the user, not the installation. I wouldn't mind if there was an option to force this behaviour so people wanting to experiment with it can do it, but then they have to deal with the inevitable fallout themselves. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[PATCH 3/3] Cygwin: updates to wire in profiler, gmondump
These are updates to wire into the build tree the new tools profiler and gmondump, and to supply documentation for the tools. The documentation for profiler and ssp now mention each other but do not discuss their similarities or differences. That will be handled in a future update to the "Profiling Cygwin Programs" section of the Cygwin User's Guide, to be supplied. --- winsup/cygwin/release/3.2.1 | 7 ++ winsup/doc/utils.xml| 123 winsup/utils/Makefile.am| 5 ++ 3 files changed, 135 insertions(+) diff --git a/winsup/cygwin/release/3.2.1 b/winsup/cygwin/release/3.2.1 index 99c65ce30..4f4db622a 100644 --- a/winsup/cygwin/release/3.2.1 +++ b/winsup/cygwin/release/3.2.1 @@ -1,6 +1,13 @@ What's new: --- +- An IP-sampling profiler named 'profiler' has been added. It can be used + to profile any Cygwin program along with any DLLs loaded. + +- A new tool 'gmondump' has been added. It can dump the raw information + of any "gmon.out" file created by profiler, ssp, or use of the gcc/g++ + option '-pg'. (Continue using gprof to get symbolic profile displays.) + What changed: - diff --git a/winsup/doc/utils.xml b/winsup/doc/utils.xml index 1d9b8488c..0b7b5d0ea 100644 --- a/winsup/doc/utils.xml +++ b/winsup/doc/utils.xml @@ -793,6 +793,56 @@ line separates the ACLs for each file. + + + gmondump + 1 + Cygwin Utilities + + + + gmondump + Display formatted contents of profile data files + + + + +gmondump [OPTION]... FILENAME... + + + + + Options + + -h, --help Display usage information and exit + -v, --verbose Display more file details (toggle: default false) + -V, --version Display version information and exit + + + + + Description +The gmondump utility displays the contents of + one or more profile data files. Such files usually have names starting + with "gmon.out" and are created by a profiling program such as + profiler or ssp. Compiling your + gcc/g++ programs with option -pg also works. + By default, summary information is shown. You can use the + option -v to get more detailed displays. +Note that gmondump just displays the raw data; + one would usually use gprof to display the data in + a useful form incorporating symbolic info such as function names and + source line numbers. +Here is an example of gmondump operation: + +$ gmondump gmon.out.21900.zstd.exe +file gmon.out.21900.zstd.exe, gmon version 0x51879, sample rate 100 + address range 0x0x100401000..0x0x1004cc668 + numbuckets 208282, hitbuckets 1199, hitcount 12124, numrawarcs 0 + + + + kill @@ -2127,6 +2177,75 @@ specifying an empty password. + + + profiler + 1 + Cygwin Utilities + + + + profiler + Sampling profiler of Cygwin programs with their DLLs + + + + +profiler [OPTION]... PROGRAM [ARG]... +profiler [OPTION]... -p PID + + + + + Options + + -d, --debugDisplay debugging messages (toggle: default false) + -e, --events Display Windows DEBUG_EVENTS (toggle: default false) + -f, --fork-profile Profiles child processes (toggle: default false) + -h, --help Display usage information and exit + -o, --output=FILENAME Write output to file FILENAME rather than stdout + -p, --pid=NAttach to running program with Cygwin pid N + ...or with Windows pid -N + -s, --sample-rate=NSet IP sampling rate to N Hz (default 100) + -v, --verbose Display more status messages (toggle: default false) + -V, --version Display version information and exit + -w, --new-window Launch given command in a new window + + + + + Description +The profiler utility executes a given program, and + optionally the children of that program, collecting the location of the + CPU instruction pointer (IP) many times per second. This gives a profile + of the program's execution, showing where the most time is being spent. + This profiling technique is called "IP sampling". + +A novel feature of profiler is that time spent in + DLLs loaded with or by your program is profiled too. You use + gprof to process and display the resulting profile + information. In this fashion you can determine whether your own code, + the Cygwin DLL, or another DLL has "hot spots" that might benefit from + tuning. + +(See also ssp, another profiler that + operates in a different fashion: stepping by instruction. This can + provide a different view on your program's operation.) + +Here is an example of profiler operation: + +$ profiler du -khs . +22G . +97 samples across 83 buckets written to gmon.out.5908.cygwin1.dll +4 samples
[PATCH 2/3] Cygwin: New tool: gmondump
This new tool was formerly part of 'profiler' but was spun out thanks to
Jon T's reasonable review comment. Gmondump is more of a debugging tool
than something users might have need for. Users would more likely use
gprof to make use of symbolic info like function names and source line
numbers.
---
winsup/utils/gmondump.c | 255
1 file changed, 255 insertions(+)
create mode 100644 winsup/utils/gmondump.c
diff --git a/winsup/utils/gmondump.c b/winsup/utils/gmondump.c
new file mode 100644
index 0..e469f01f1
--- /dev/null
+++ b/winsup/utils/gmondump.c
@@ -0,0 +1,255 @@
+/*
+gmondump.c
+Displays summary info about given profile data file(s).
+
+Written by Mark Geisert .
+
+This file is part of Cygwin.
+
+This software is a copyrighted work licensed under the terms of the
+Cygwin license. Please consult the file "CYGWIN_LICENSE" for details.
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "cygwin/version.h"
+
+typedef unsigned short ushort;
+typedef uint16_t u_int16_t; // Non-standard sized type needed by ancient gmon.h
+#include "gmon.h"
+
+FILE *ofile;
+const char *pgm = "gmondump";
+int verbose = 0;
+
+void __attribute__ ((__noreturn__))
+usage (FILE *where)
+{
+ fprintf (where, "\
+Usage: %s [OPTIONS] FILENAME...\n\
+\n\
+Display formatted contents of profile data file(s).\n\
+Such files usually have names starting with \"gmon.out\".\n\
+OPTIONS are:\n\
+\n\
+ -h, --help Display usage information and exit\n\
+ -v, --verbose Display more file details (toggle: default false)\n\
+ -V, --version Display version information and exit\n\
+\n", pgm);
+
+ exit (where == stderr ? 1 : 0 );
+}
+
+void
+note (const char *fmt, ...)
+{
+ va_list args;
+ charbuf[4096];
+
+ va_start (args, fmt);
+ vsprintf (buf, fmt, args);
+ va_end (args);
+
+ fputs (buf, ofile);
+ fflush (ofile);
+}
+
+void
+warn (int geterrno, const char *fmt, ...)
+{
+ va_list args;
+ charbuf[4096];
+
+ va_start (args, fmt);
+ sprintf (buf, "%s: ", pgm);
+ vsprintf (strchr (buf, '\0'), fmt, args);
+ va_end (args);
+ if (geterrno)
+perror (buf);
+ else
+{
+ fputs (buf, ofile);
+ fputs ("\n", ofile);
+ fflush (ofile);
+}
+}
+
+void __attribute__ ((noreturn))
+error (int geterrno, const char *fmt, ...)
+{
+ va_list args;
+
+ va_start (args, fmt);
+ warn (geterrno, fmt, args);
+ va_end (args);
+
+ exit (1);
+}
+
+void
+gmondump1 (char *filename)
+{
+ ushort*bucket = NULL;
+ intfd;
+ struct gmonhdr hdr;
+ inthitbuckets;
+ inthitcount;
+ intnumbuckets;
+ intnumrawarcs;
+ struct rawarc *rawarc = NULL;
+ intres;
+ struct stat stat;
+
+ fd = open (filename, O_RDONLY | O_BINARY);
+ if (fd < 0)
+{
+ note ("file%s %s couldn't be opened; continuing\n",
+strchr (filename, '*') ? "s" : "", filename);
+ return;
+}
+
+ /* Read and sanity-check what should be a gmon header. */
+ res = fstat (fd, );
+ if (res < 0)
+goto notgmon;
+ if (S_IFREG != (stat.st_mode & S_IFMT))
+goto notgmon;
+ res = read (fd, , sizeof (hdr));
+ if (res != sizeof (hdr))
+goto notgmon;
+ if (hdr.lpc >= hdr.hpc)
+goto notgmon;
+ numbuckets = (hdr.ncnt - sizeof (hdr)) / sizeof (short);
+ if (numbuckets != (hdr.hpc - hdr.lpc) / 4)
+goto notgmon;
+ numrawarcs = 0;
+ if (stat.st_size != hdr.ncnt)
+{
+ numrawarcs = stat.st_size - hdr.ncnt;
+ if (numrawarcs !=
+ (int) sizeof (rawarc) * (numrawarcs / (int) sizeof (rawarc)))
+goto notgmon;
+ numrawarcs /= (int) sizeof (rawarc);
+}
+
+ /* Looks good, so read and display the profiling info. */
+ bucket = (ushort *) calloc (numbuckets, sizeof (ushort));
+ res = read (fd, bucket, hdr.ncnt - sizeof (hdr));
+ if (res != hdr.ncnt - (int) sizeof (hdr))
+goto notgmon;
+ hitcount = hitbuckets = 0;
+ for (res = 0; res < numbuckets; ++bucket, ++res)
+if (*bucket)
+ {
+++hitbuckets;
+hitcount += *bucket;
+ }
+ bucket -= numbuckets;
+
+ note ("file %s, gmon version 0x%x, sample rate %d\n",
+filename, hdr.version, hdr.profrate);
+ note (" address range 0x%p..0x%p\n", hdr.lpc, hdr.hpc);
+ note (" numbuckets %d, hitbuckets %d, hitcount %d, numrawarcs %d\n",
+numbuckets, hitbuckets, hitcount, numrawarcs);
+
+ /* If verbose is set, display contents of buckets and rawarcs arrays. */
+ if (verbose)
+{
+ if (hitbuckets)
+note (" bucket data follows...\n");
+ char *addr = (char *) hdr.lpc;
+ int incr = (hdr.hpc - hdr.lpc) / numbuckets;
+ for (res = 0; res < numbuckets; ++bucket, ++res, addr += incr)
+if (*bucket)
+ note ("address 0x%p, hitcount %d\n", addr, *bucket);
+ bucket -= numbuckets;
+
+ if (numrawarcs)
+{
+ rawarc = (struct
[PATCH 1/3] Cygwin: New tool: profiler
The new tool formerly known as cygmon is renamed to 'profiler'. For the
name I considered 'ipsampler' and could not think of any others. I'm open
to a different name if any is suggested.
I decided that a discussion of the pros and cons of this profiler vs the
existing ssp should probably be in the "Profiling Cygwin Programs" section
of the Cygwin User's Guide rather than in the help for either. That
material will be supplied at some point.
CONTEXT buffers are made child-specific and thus thread-specific since
there is one profiler thread for each child program being profiled.
The SetThreadPriority() warning comment has been expanded.
chmod() works on Cygwin so the "//XXX ineffective" comment is gone.
I decided to make the "sample all executable sections" and "sample
dynamically generated code" suggestions simply expanded comments for now.
The profiler program is now a Cygwin exe rather than a native exe.
---
winsup/utils/profiler.cc | 1109 ++
1 file changed, 1109 insertions(+)
create mode 100644 winsup/utils/profiler.cc
diff --git a/winsup/utils/profiler.cc b/winsup/utils/profiler.cc
new file mode 100644
index 0..d1a01c3a2
--- /dev/null
+++ b/winsup/utils/profiler.cc
@@ -0,0 +1,1109 @@
+/*
+profiler.cc
+Periodically samples IP of a process and its DLLs; writes gprof data files.
+
+Written by Mark Geisert , who admits to
+copying pretty liberally from strace.cc. h/t to cgf for strace!
+
+This file is part of Cygwin.
+
+This software is a copyrighted work licensed under the terms of the
+Cygwin license. Please consult the file "CYGWIN_LICENSE" for details.
+*/
+
+#define WIN32_LEAN_AND_MEAN
+#include
+
+#define cygwin_internal cygwin_internal_dontuse
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "cygwin/version.h"
+#include "cygtls_padsize.h"
+#include "gcc_seh.h"
+typedef unsigned short ushort;
+typedef uint16_t u_int16_t; // Non-standard sized type needed by ancient gmon.h
+#define NO_GLOBALS_H
+#include "gmon.h"
+#include "path.h"
+#undef cygwin_internal
+
+/* Undo this #define from winsup.h. */
+#ifdef ExitThread
+#undef ExitThread
+#endif
+
+#define SCALE_SHIFT 2 // == 4 bytes of address space per bucket
+#define MS_VC_EXCEPTION 0x406D1388 // thread name notification from child
+
+DWORD child_pid;
+int debugging = 0;
+void *drive_map;
+int events = 0;
+int forkprofile = 0;
+int new_window;
+int numprocesses;
+FILE *ofile = stdout;
+const char *pgm;
+char *prefix = (char *) "gmon.out";
+int samplerate = 100; // in Hz; up to 1000 might work
+int verbose = 0;
+
+void __attribute__ ((__noreturn__))
+usage (FILE *where = stderr)
+{
+ fprintf (where, "\
+Usage: %s [OPTIONS] \n\
+ or: %s [OPTIONS] -p \n\
+\n\
+Profiles a command or process by sampling its IP (instruction pointer).\n\
+OPTIONS are:\n\
+\n\
+ -d, --debugDisplay debugging messages (toggle: default false)\n\
+ -e, --events Display Windows DEBUG_EVENTS (toggle: default
false)\n\
+ -f, --fork-profile Profile child processes (toggle: default false)\n\
+ -h, --help Display usage information and exit\n\
+ -o, --output=FILENAME Write output to file FILENAME rather than stdout\n\
+ -p, --pid=NAttach to running program with Cygwin pid N\n\
+ ...or with Windows pid -N\n\
+ -s, --sample-rate=NSet IP sampling rate to N Hz (default 100)\n\
+ -v, --verbose Display more status messages (toggle: default
false)\n\
+ -V, --version Display version information and exit\n\
+ -w, --new-window Launch given command in a new window\n\
+\n", pgm, pgm);
+
+ exit (where == stderr ? 1 : 0 );
+}
+
+/* A span is a memory address range covering an EXE's or DLL's .text segment.
*/
+struct span_list
+{
+ WCHAR *name;
+ LPVOID base;
+ size_t textlo;
+ size_t texthi;
+ int hitcount;
+ int hitbuckets;
+ int numbuckets;
+ int*buckets;
+ struct span_list *next;
+};
+
+/* A thread. */
+struct thread_list
+{
+ DWORD tid;
+ HANDLE hthread;
+ WCHAR *name;
+ struct thread_list *next;
+};
+
+/* A child is any process being sampled in this profiler run. */
+struct child_list
+{
+ DWORD pid;
+ volatile int profiling;
+ HANDLE hproc;
+ HANDLE hquitevt;
+ HANDLE hprofthr;
+ CONTEXT*context;
+ struct thread_list *threads;
+ struct span_list *spans;
+ struct child_list *next;
+};
+
+child_list children;
+typedef struct child_list child;
+
+void
+note (const char *fmt, ...)
+{
+ va_list args;
+ charbuf[4096];
+
+ va_start (args, fmt);
+ vsprintf (buf, fmt, args);
+ va_end (args);
+
+ fputs (buf, ofile);
+ fflush (ofile);
+}
+
+void
+warn (int geterrno, const char *fmt, ...)
+{
+ va_list args;
+ charbuf[4096];
+
+ va_start (args,
Re: objects created in a dir w/cygwin mangled perms; inherit no-access
Greetings, L A Walsh! > On 2021/07/07 11:43, Andrey Repin wrote: What is "progd" ? Did you mount some directory into Cygwin tree? >> >>> Sorta, actually the cygtree mounted at 'C:\'. >> >> Ugh. Been there twenty years ago. Had a lot of unexpected issues and finally >> opted out of it. > --- > If you have something unexpected happening on your own > computer, and you choose not to find the cause, you really don't > know if it was a virus, malware or some other problem. I've found the cause, which does not change the fact the documented behavior was undesirable. This is, after all, whyinstalling Cygwin in a system root is discouraged. > I've had my directory tree mounted the way it is since > Windows XP, and have tried to understand issues about computers > that many term "magick" (or black magick). Being a computer > scientist, I've always tried to understand what was going on. > I don't always find out quickly, but I often return to problems > that I haven't solved years later to sometimes find the cause, or > sometimes find the problems have gone away. > Considering my life has been about computers, opting out > has really not been an option for me. "Doctor, when I poke my eye with a knife, it pains me!" >>> Certainly, having it create no-access dirs >>> for the user isn't desirable. I'm betting that they'd >>> be denied locally as well if my local user didn't >>> have admin override rights. >> >> It may be something in the parent directory. > --- > Nope... can't be, windows doesn't work that way. > A directory can affect its contents, but permissions that are > inherited can't skip a generation. > or fstab mount options. > --- > I pretty much use the default: > > # /etc/fstab > # > #This file is read once by the first process in a Cygwin > #process tree. To pick up changes, restart all Cygwin > #processes. For a description > #see https://cygwin.com/cygwin-ug-net/using.html#mount-table > # This is default anyway: > none / cygdrive binary,posix=0,user 0 0 > This, basically, tells Cygwin to override Windows permissions manager. Creating all sort of permission issues for unsuspecting Windows programs. Saner approach would be to leave Windows permissions to Windows. none / cygdrive noacl,binary,nouser,posix=0 0 0 C:/Users /home bind noacl,binary,exec,posix=0 0 0 none /tmp usertemp binary,nouser,posix=1 0 0 But then again, consider you have two conflicting permission schemes over directories on the system drive. >> Needs a more thorough investigation. But I think it would easily be avoided >> by a saner directory layout. > --- > What is more sane, ignoring a problem that was opted out > of for 20 years, or understand what causes problems. That's baseless assumption. The problem was thoroughly investigated and the final decision was that the lowest number of workarounds is preferable. > I can't speak for Windows 10, but through Windows 7, > especially in the X64 world, it makes little to no sense to > cut your cygwin tools off from being able to access and work > on your windows installation. Eh? I have Cygwin in %PATH% and use its tools primarily, even though I have Git for Windows for example. Which I only use for VS Code. Exception is curl and tidy, both of which I have native builds. > If you have ever boot to a rescue system running from > your hard drive -- you have the choice of using all your cygwin > tools to recover your system, or to just use Windows tools. I have my own rescue system. I'm a support engineer after all. These are tools of my trade. And for the record, TakeCommand is more useful for rescue tool than Cygwin. I have both. > If you have 30+ years of unix/linux/posix experience > with linux/posix tools, does it make any sense to throw that > away when trying to recover your system? When system is not Linux/UNIX? Absolutely. Use right tool for the job. I only have 12 or so years of *NIX experience, and I would never ditch a chance of using bash script to do the work for me, but if I have a choice of native tool that's almost equivalent in performance, I'd use that. > X64 Cygwin tools work natively when installed at root. They work equally well when installed in C:\Programs\Cygwin64. JFYI. > Many of the Windows tools are still x32 which won't run on a rescue system. That's why I opted for 64-bit tools where possible. In my experience, they work faster on 64-bit system, than 32-bit tools, even if built from same source. > Linux xfs has 2 acls on directories -- one for the directory > and one that can be the default for contents to inherit. It's > not identical to windows, but it is similar and if you > understand one, the other isn't that different. Cygwin > has placed the most emphasis on POSIX compatibility vs. > Windows compatibility. In some places it could have been > more Windows compatible and still achieved POSIX compat.
Re: Setup shows errors from gnuplot-base.dash and python38-devel.sh
Greetings, Doug Henderson! >> >>> When I do that in an elevated shell: >> >>> >> >>> $ cd /etc/postinstall/ >> >>> >> >>> $ cat gnuplot-base.dash >> >>> /usr/sbin/alternatives --install /usr/bin/gnuplot gnuplot >> >>> /usr/bin/gnuplot-base.exe 10 >> >>> >> >>> $ . gnuplot-base.dash >> >>> failed to read link /usr/bin/gnuplot: No such file or directory >> >>> failed to link /usr/bin/gnuplot -> /etc/alternatives/gnuplot: No such >> >>> file or directory >> >> >> >> Something seems to be confusing 'alternatives'. Can you show a listing of >> >> /etc/alternatives? >> > >> > $ cd /etc/alternatives/ >> > >> > $ ls -l >> > total 2.0K >> > lrwxrwxrwx 1 Admin None 35 Oct 3 2017 automake-doc -> >> > /usr/share/info/automake1.9.info.gz >> > lrwxrwxrwx 1 Admin None 19 Jun 16 17:48 lua -> /usr/bin/lua5.3.exe* >> > lrwxrwxrwx 1 Admin None 31 Jun 16 17:48 lua.1.gz -> >> > /usr/share/man/man1/lua5.3.1.gz >> > lrwxrwxrwx 1 Admin None 20 Jun 16 17:48 luac -> /usr/bin/luac5.3.exe* >> > lrwxrwxrwx 1 Admin None 32 Jun 16 17:48 luac.1.gz -> >> > /usr/share/man/man1/luac5.3.1.gz >> > lrwxrwxrwx 1 Admin None 15 Jun 5 08:46 pip3 -> /usr/bin/pip3.8* >> > lrwxrwxrwx 1 Admin None 22 Jun 16 07:34 python -> /usr/bin/python3.8.exe* >> > -rw-r--r-- 1 Admin None 163 Apr 4 2013 README >> >> This shows that alternatives worked in June. Have you changed anything since >> then that might be related to symlinks (e.g., the CYGWIN environment >> variable)? >> >> Here are a few other things you could try: >> >> 1. Attach cygcheck output as requested in https://cygwin.com/problems.html >> >> 2. Add --verbose to the alternatives call. >> >> 3. Run the alternatives call under strace and look for errors involving >> symlinks. Or post the output somewhere so that we can look at it. > Now using setup-x86_64.exe version 2.909 (64 bit) > Postinstall script errors: > Package: _/Unknown package > gnuplot-base.dash exit code 2 > python38-devel.sh exit code 2 > Here's what I did in an elevated shell. > $ cd /etc/alternatives > $ cat /etc/postinstall/gnuplot-base.dash > /usr/sbin/alternatives --install /usr/bin/gnuplot gnuplot > /usr/bin/gnuplot-base.exe 10 > $ /usr/sbin/alternatives --verbose --install /usr/bin/gnuplot gnuplot > /usr/bin/gnuplot-base.exe 10 > reading /var/lib/alternatives/gnuplot > failed to read link /usr/bin/gnuplot: No such file or directory > failed to link /usr/bin/gnuplot -> /etc/alternatives/gnuplot: No such > file or directory > $ echo $CYGWIN > winsymlinks:nativestrict > *** changed system environment > $ echo $CYGWIN > winsymlinks:native > $ /usr/sbin/alternatives --verbose --install /usr/bin/gnuplot gnuplot > /usr/bin/gnuplot-base.exe 10 > reading /var/lib/alternatives/gnuplot > *** Success > Alternatives does not work correctly when CYGWIN=nativestrict. Perhaps > it is trying to create a link before the link target exists. Unlike > Linux, Windows does not allow creating symbolic links to non-existent > targets. > The /etc/postinstall/python38-devel.sh also works now. > Also after changing env back to CYGWIN=winsymlinks:nativestrict the > erroring postinstall scripts continue to work. This supports my > suspicion that /usr/sbin/alternatives is trying to create a symbolic > link to a target before it creates the target when it is performing > the first install for an alternative. On subsequent runs, the target > already exists. > I have unattached the output from cygcheck, as I do not believe it > will help now. > Am I the only person that uses "CYGWIN=winsymlinks:nativestrict" ??? $ echo "$CYGWIN" wincmdln winsymlinks:nativestrict glob:ignorecase > Sorry for all the bother. My aging brain forgot how I made > alternatives work for Lua last month. I've stumbled upon the same problem earlier. alternatives tries to create a link pointing to a nonexistent file. Which is valid in Linux, but impossible in Windows. IMO, this is a logical fallacy and should not be attempted, making it an upstream bug. -- With best regards, Andrey Repin Friday, July 16, 2021 6:56:55 Sorry for my terrible english... -- 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: attention alternatives maintainer
On 7/15/2021 9:56 PM, Ken Brown via Cygwin-apps wrote: On 7/15/2021 7:07 PM, Doug Henderson via Cygwin-apps wrote: Please update alternatives to work properly for a first time install of an alternative when CYGWIN=winsymlinks:nativestrict. Cygwin doesn't have an alternatives maintainer. Would you like to volunteer? If so, start at https://cygwin.com/packages.html and follow up on the cygwin-apps mailing list if you need help. Sorry, I see you're already a package maintainer, so you know how to do it. Ken
Re: attention alternatives maintainer
On 7/15/2021 7:07 PM, Doug Henderson via Cygwin-apps wrote: Please update alternatives to work properly for a first time install of an alternative when CYGWIN=winsymlinks:nativestrict. Cygwin doesn't have an alternatives maintainer. Would you like to volunteer? If so, start at https://cygwin.com/packages.html and follow up on the cygwin-apps mailing list if you need help. Ken
attention alternatives maintainer
Please update alternatives to work properly for a first time install of an alternative when CYGWIN=winsymlinks:nativestrict. See the recent thread on the cygwin mailing list with subject Setup shows errors from gnuplot-base.dash and python38-devel.sh In essence, when CYGWIN=winsymlinks:nativestrict., the first time it runs, a postinstall script for a package that uses alternatives will fail. Once it has succeeded once, it will subsequently run without error. In order to make it run I must set CYGWIN=winsymlinks:native, run the postinstall script in an elevated shell (or from setup). Then I can restore CYGWIN=winsymlinks:nativestrict. I think the link target must be created before the symlink is created. Without looking at the code, I suspect the order of two symlink needs to be reversed. The basis for the problem is the difference between POSIX and Windows symlinks.As I understand it, Windows symlinks need to :"know" if the target is a file or directory, while the POSIX symlink does not require the target to exist. Thanks, Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Re: Updated: setup (2.909)
I adjusted the column widths because there seems to be a lot of unused space, which makes for a very wide window. But when I restart the Cygwin setup application, the columns return to their default widths. Could a feature be added to save the column widths from run to run? -- Jim Reisert AD1C, , https://www.ad1c.us -- 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: Setup shows errors from gnuplot-base.dash and python38-devel.sh
Doug Henderson via Cygwin writes: > Alternatives does not work correctly when CYGWIN=nativestrict. Perhaps > it is trying to create a link before the link target exists. Unlike > Linux, Windows does not allow creating symbolic links to non-existent > targets. Which is one reason why Windows symlinks are not POSIX symlinks. The real reason is that you need to need to tell Windows whether you're pointing the symlink at a directory or a file when the target does not yet exist. > Am I the only person that uses "CYGWIN=winsymlinks:nativestrict" ??? Well, you should certainly pay more attention to where, when and how it breaks. It papers over one of the differences between the POSIX and Windows world, but creates another gap elsewhere. This is exactly why I have backed out the commit that uses the CYGWIN environment variable in setup.exe. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: Setup shows errors from gnuplot-base.dash and python38-devel.sh
"On Thu, 15 Jul 2021 at 05:59, Ken Brown via Cygwin wrote: > > On 7/14/2021 9:20 PM, Doug Henderson via Cygwin wrote: > > On Wed, 14 Jul 2021 at 16:33, Ken Brown via Cygwin > > wrote: > >> > >> On 7/14/2021 5:08 PM, Doug Henderson via Cygwin wrote: > >>> On Wed, 14 Jul 2021 at 13:03, Achim Gratz wrote: > > Doug Henderson via Cygwin writes: > > The first error message occurred when I installed all pending packages > > this morning. I hoped to heal the problem by reinstalling the > > installed gnuplot packages. Now I get both the messages. > > If you look in /var7Log/setup.log.full you should be able to see what > error messages, if any, were recorded. > > The gnuplot related script should just set up the current alternative > for "gnuplot" to use, but something on your system seems to prevent > that from happening. You can also run the script in sh (you must tell > the shell to source it) and should get the same error (most likely). > >>> > >>> When I do that in an elevated shell: > >>> > >>> $ cd /etc/postinstall/ > >>> > >>> $ cat gnuplot-base.dash > >>> /usr/sbin/alternatives --install /usr/bin/gnuplot gnuplot > >>> /usr/bin/gnuplot-base.exe 10 > >>> > >>> $ . gnuplot-base.dash > >>> failed to read link /usr/bin/gnuplot: No such file or directory > >>> failed to link /usr/bin/gnuplot -> /etc/alternatives/gnuplot: No such > >>> file or directory > >> > >> Something seems to be confusing 'alternatives'. Can you show a listing of > >> /etc/alternatives? > > > > $ cd /etc/alternatives/ > > > > $ ls -l > > total 2.0K > > lrwxrwxrwx 1 Admin None 35 Oct 3 2017 automake-doc -> > > /usr/share/info/automake1.9.info.gz > > lrwxrwxrwx 1 Admin None 19 Jun 16 17:48 lua -> /usr/bin/lua5.3.exe* > > lrwxrwxrwx 1 Admin None 31 Jun 16 17:48 lua.1.gz -> > > /usr/share/man/man1/lua5.3.1.gz > > lrwxrwxrwx 1 Admin None 20 Jun 16 17:48 luac -> /usr/bin/luac5.3.exe* > > lrwxrwxrwx 1 Admin None 32 Jun 16 17:48 luac.1.gz -> > > /usr/share/man/man1/luac5.3.1.gz > > lrwxrwxrwx 1 Admin None 15 Jun 5 08:46 pip3 -> /usr/bin/pip3.8* > > lrwxrwxrwx 1 Admin None 22 Jun 16 07:34 python -> /usr/bin/python3.8.exe* > > -rw-r--r-- 1 Admin None 163 Apr 4 2013 README > > This shows that alternatives worked in June. Have you changed anything since > then that might be related to symlinks (e.g., the CYGWIN environment > variable)? > > Here are a few other things you could try: > > 1. Attach cygcheck output as requested in https://cygwin.com/problems.html > > 2. Add --verbose to the alternatives call. > > 3. Run the alternatives call under strace and look for errors involving > symlinks. Or post the output somewhere so that we can look at it. Now using setup-x86_64.exe version 2.909 (64 bit) Postinstall script errors: Package: _/Unknown package gnuplot-base.dash exit code 2 python38-devel.sh exit code 2 Here's what I did in an elevated shell. $ cd /etc/alternatives $ cat /etc/postinstall/gnuplot-base.dash /usr/sbin/alternatives --install /usr/bin/gnuplot gnuplot /usr/bin/gnuplot-base.exe 10 $ /usr/sbin/alternatives --verbose --install /usr/bin/gnuplot gnuplot /usr/bin/gnuplot-base.exe 10 reading /var/lib/alternatives/gnuplot failed to read link /usr/bin/gnuplot: No such file or directory failed to link /usr/bin/gnuplot -> /etc/alternatives/gnuplot: No such file or directory $ echo $CYGWIN winsymlinks:nativestrict *** changed system environment $ echo $CYGWIN winsymlinks:native $ /usr/sbin/alternatives --verbose --install /usr/bin/gnuplot gnuplot /usr/bin/gnuplot-base.exe 10 reading /var/lib/alternatives/gnuplot *** Success Alternatives does not work correctly when CYGWIN=nativestrict. Perhaps it is trying to create a link before the link target exists. Unlike Linux, Windows does not allow creating symbolic links to non-existent targets. The /etc/postinstall/python38-devel.sh also works now. Also after changing env back to CYGWIN=winsymlinks:nativestrict the erroring postinstall scripts continue to work. This supports my suspicion that /usr/sbin/alternatives is trying to create a symbolic link to a target before it creates the target when it is performing the first install for an alternative. On subsequent runs, the target already exists. I have unattached the output from cygcheck, as I do not believe it will help now. Am I the only person that uses "CYGWIN=winsymlinks:nativestrict" ??? Sorry for all the bother. My aging brain forgot how I made alternatives work for Lua last month. HTH Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com -- 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: setup-x86_64.exe crashes randomly on user interaction, too often to use
On 14/07/2021 21:06, Philip Goetz via Cygwin wrote: On Wed, Jul 14, 2021 at 2:57 PM Philip Goetz wrote: On Wed, Jul 14, 2021 at 9:10 AM Jon Turney wrote: On 13/07/2021 20:30, Philip Goetz via Cygwin wrote: ... I change display mode from Pending to Category, and start clicking through the category tree selecting packages. But every time I click on something in the cygwin setup window, or scroll the window, there's maybe 1 chance in 10 that setup-x86_64.exe will terminate. ... I'd like to try using an older Cygwin installer, but I didn't find links to older versions on cygwin.com. You can find older version of setup at https://cygwin.com/setup/ Thank you! I tried setup-2.905.x86_64.exe and setup-2.907.x86_64.exe, and neither gave me any problems! I spoke too soon. I just ran setup-2.907.x86_64.exe again, to install some more programs, and it did the same thing. But I spent a long time in 2.905 without it crashing. Thanks to the reproduction steps, I was able to (finally) develop some useful information about this crash, and that is consistent with where I think the problem was introduced. I've built setup 2.909 with a putative fix for this. Perhaps you could try that and see if it improves things for you? Thanks. -- 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
[ANNOUNCEMENT] Updated: setup (2.909)
A new version of Setup (2.909) 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.908: - Fix a sporadic crash which could occur while using the package chooser GUI (a regression since 2.906) Addresses: https://cygwin.com/pipermail/cygwin/2021-July/248893.html - Various cosmetic fixes For instructions on obtaining and building the source code for setup, see https://sourceware.org/cygwin-apps/setup.html Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com. -- 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
Updated: setup (2.909)
A new version of Setup (2.909) 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.908: - Fix a sporadic crash which could occur while using the package chooser GUI (a regression since 2.906) Addresses: https://cygwin.com/pipermail/cygwin/2021-July/248893.html - Various cosmetic fixes For instructions on obtaining and building the source code for setup, see https://sourceware.org/cygwin-apps/setup.html Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com.
Re: Setup shows errors from gnuplot-base.dash and python38-devel.sh
On 7/14/2021 9:20 PM, Doug Henderson via Cygwin wrote: On Wed, 14 Jul 2021 at 16:33, Ken Brown via Cygwin wrote: On 7/14/2021 5:08 PM, Doug Henderson via Cygwin wrote: On Wed, 14 Jul 2021 at 13:03, Achim Gratz wrote: Doug Henderson via Cygwin writes: The first error message occurred when I installed all pending packages this morning. I hoped to heal the problem by reinstalling the installed gnuplot packages. Now I get both the messages. If you look in /var7Log/setup.log.full you should be able to see what error messages, if any, were recorded. The gnuplot related script should just set up the current alternative for "gnuplot" to use, but something on your system seems to prevent that from happening. You can also run the script in sh (you must tell the shell to source it) and should get the same error (most likely). When I do that in an elevated shell: $ cd /etc/postinstall/ $ cat gnuplot-base.dash /usr/sbin/alternatives --install /usr/bin/gnuplot gnuplot /usr/bin/gnuplot-base.exe 10 $ . gnuplot-base.dash failed to read link /usr/bin/gnuplot: No such file or directory failed to link /usr/bin/gnuplot -> /etc/alternatives/gnuplot: No such file or directory Something seems to be confusing 'alternatives'. Can you show a listing of /etc/alternatives? $ cd /etc/alternatives/ $ ls -l total 2.0K lrwxrwxrwx 1 Admin None 35 Oct 3 2017 automake-doc -> /usr/share/info/automake1.9.info.gz lrwxrwxrwx 1 Admin None 19 Jun 16 17:48 lua -> /usr/bin/lua5.3.exe* lrwxrwxrwx 1 Admin None 31 Jun 16 17:48 lua.1.gz -> /usr/share/man/man1/lua5.3.1.gz lrwxrwxrwx 1 Admin None 20 Jun 16 17:48 luac -> /usr/bin/luac5.3.exe* lrwxrwxrwx 1 Admin None 32 Jun 16 17:48 luac.1.gz -> /usr/share/man/man1/luac5.3.1.gz lrwxrwxrwx 1 Admin None 15 Jun 5 08:46 pip3 -> /usr/bin/pip3.8* lrwxrwxrwx 1 Admin None 22 Jun 16 07:34 python -> /usr/bin/python3.8.exe* -rw-r--r-- 1 Admin None 163 Apr 4 2013 README This shows that alternatives worked in June. Have you changed anything since then that might be related to symlinks (e.g., the CYGWIN environment variable)? Here are a few other things you could try: 1. Attach cygcheck output as requested in https://cygwin.com/problems.html 2. Add --verbose to the alternatives call. 3. Run the alternatives call under strace and look for errors involving symlinks. Or post the output somewhere so that we can look at it. Ken -- 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: cygpath and star character
On Jul 14 15:26, Ken Brown via Cygwin wrote: > On 7/14/2021 4:10 AM, Tomas Jura via Cygwin wrote: > > Hi > > > > I found a strange behaviour of the program cygpath program > > > > 0 >cygpath -w "./*/*" <--- IMHO wrong output > > \ > > > > 0 >cygpath -w "./*/*" | od -a <--- a detailed dump > > 000 o nul * \ o nul * nl > > 010 > > What you're seeing here is a consequence of the way Cygwin handles valid > POSIX file names that contain characters (like '*') that are not allowed in > Windows file names. See "Forbidden characters in filenames" at > > https://cygwin.com/cygwin-ug-net/using-specialnames.html > > Internally, Cygwin converts "./*/*" to the wide char string L"*\*" with '*' > replaced by 0xf02a. This then gets converted to the multibyte sequence in > your "detailed dump", which is not quite detailed enough: > > $ cygpath -w "./*/*" | od -b > 000 357 200 252 134 357 200 252 012 > 010 > > I tend to agree that this is not desirable behavior. I doubt if users of > 'cygpath -w' expect to get a result that contains transformed forbidden > characters. But maybe there's a use case for this that I'm missing. > Corinna? The purpose of cygpath is to convert paths between Cygwin and Windows, so that you can access the same file in both worlds. The '*' character is a valid character in Cygwin, but the created file will have a unicode 0xf02a in its place. If cygpath doesn't convert the path accordingly, accessing the file from Windows via the converted path would fail. > > 0 >cygpath -wp "./*/*" <-- but this works as expected > > *\* > > > > Is this bug or expected behavior ? > > It looks to me like a bug that 'cygpath -w' and 'cygpath -wp' give different > results on a path that doesn't contain a colon. Yeah, that's not quite right. Historically, the conversion of path lists is performed on multibyte paths, not on wide char paths. This has never been changed, and that results in special characters getting lost. So in fact, the behaviour in -p is wrong for those chars invalid in Windows and only valid for POSIX paths. Corinna -- 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: objects created in a dir w/cygwin mangled perms; inherit no-access
On 15/07/2021 08:02, L A Walsh wrote: On 2021/07/07 11:43, Andrey Repin wrote: Sorta, actually the cygtree mounted at 'C:\'. Ugh. Been there twenty years ago. Had a lot of unexpected issues and finally opted out of it. If you have ever boot to a rescue system running from your hard drive -- you have the choice of using all your cygwin tools to recover your system, or to just use Windows tools. After wading through the unsolicited self-congratulation a few observations. 1. You want support from the Cygwin community for problems you're having despite having installed it in a way that is expressly discouraged. (https://cygwin.com/faq.html#faq.setup.c) Good luck with that. 2. You've not bothered to search the archives or even read the manual, specifically https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files but instead immediately assume a flaw in the code. Not very scientific ... or polite. (By the way, the permission workaround is another good reason for not installing in system root if advice from the authors of Cygwin - Corinna et al - isn't enough for you.) 3. Installing Cygwin under, say, C:\cygwin64 does not prevent you from using it for recovery. PEBCAK -- Sam Edge -- 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: objects created in a dir w/cygwin mangled perms; inherit no-access
On 2021/07/07 11:43, Andrey Repin wrote: What is "progd" ? Did you mount some directory into Cygwin tree? Sorta, actually the cygtree mounted at 'C:\'. Ugh. Been there twenty years ago. Had a lot of unexpected issues and finally opted out of it. --- If you have something unexpected happening on your own computer, and you choose not to find the cause, you really don't know if it was a virus, malware or some other problem. I've had my directory tree mounted the way it is since Windows XP, and have tried to understand issues about computers that many term "magick" (or black magick). Being a computer scientist, I've always tried to understand what was going on. I don't always find out quickly, but I often return to problems that I haven't solved years later to sometimes find the cause, or sometimes find the problems have gone away. Considering my life has been about computers, opting out has really not been an option for me. Certainly, having it create no-access dirs for the user isn't desirable. I'm betting that they'd be denied locally as well if my local user didn't have admin override rights. It may be something in the parent directory. --- Nope... can't be, windows doesn't work that way. A directory can affect its contents, but permissions that are inherited can't skip a generation. or fstab mount options. --- I pretty much use the default: # /etc/fstab # #This file is read once by the first process in a Cygwin #process tree. To pick up changes, restart all Cygwin #processes. For a description #see https://cygwin.com/cygwin-ug-net/using.html#mount-table # This is default anyway: none / cygdrive binary,posix=0,user 0 0 Needs a more thorough investigation. But I think it would easily be avoided by a saner directory layout. --- What is more sane, ignoring a problem that was opted out of for 20 years, or understand what causes problems. I can't speak for Windows 10, but through Windows 7, especially in the X64 world, it makes little to no sense to cut your cygwin tools off from being able to access and work on your windows installation. If you have ever boot to a rescue system running from your hard drive -- you have the choice of using all your cygwin tools to recover your system, or to just use Windows tools. If you have 30+ years of unix/linux/posix experience with linux/posix tools, does it make any sense to throw that away when trying to recover your system? X64 Cygwin tools work natively when installed at root. Many of the Windows tools are still x32 which won't run on a rescue system. Linux xfs has 2 acls on directories -- one for the directory and one that can be the default for contents to inherit. It's not identical to windows, but it is similar and if you understand one, the other isn't that different. Cygwin has placed the most emphasis on POSIX compatibility vs. Windows compatibility. In some places it could have been more Windows compatible and still achieved POSIX compat. I do know, that if you have several added Deny acls added to every file, it can mess up default inheritance on content files. What windows has added to the mix has to be deleted -- special perms for creators (user+group). It's similar to default perms in linux, but it isn't the same. It is messed up, other devs have said so -- cygwin perms will conflict with windows perms when they are mixed. They've never tried to fix that. The result are utilities and permissions that have 'no access' set for 'creators' (usually owners). That's not a desired feature unless you opt out of using the windows GUI. But that's the main reason I use it, so what's the point? In any event, I know there are bugs in cygwin, but I don't care enough + know enough about windows development to fix them. That doesn't mean I opt out of using Cygwin or Windows (if I can help it), but it doesn't mean I won't report problems or bugs when I encounter them (doesn't mean I will either, depends on time). Anyway...opting out of understanding why things are or work they way they do is not something I can easily do, by nature. I'm too curious. (too much so, for the time I have to deal with things!). :-) Linda -- 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: cygpath and star character
On 15/07/2021 00:07, Tomas Jura via Cygwin wrote:
Hi
My use case is building the CLASSPATH environment variable for java.
Like:
export CLASSPATH="${CLASSPATH}${PATH_SEPARATOR}$(cygpath -w
'my/java/jar/directory/*' )"
CLASSPATH can contain the star character at the end on Windows.
Example C:\Apps\java\lib\* , which means something different then just
C:\Apps\java\lib, ie. the star is necessary there.
Tomas
So do:
export CLASSPATH="${CLASSPATH}${PATH_SEPARATOR}$(cygpath -w
'my/java/jar/directory')\*"
If you pass the asterisk to cygpath it will naturally consider it to be
a character in a pathname and give you the equivalent Windows path that
Cygwin would construct using the open() syscall. This is cygpath's
purpose, after all!
--
Sam Edge
--
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
