Re: Some repeated tasks at every update
>> A list of those would be useful unless access to your system is available? Thank you Brian. For info my very reduced but entirely adequate Cygwin installation (to my purposes) is driven by setup-x86_64 -P ImageMagick,R,autoconf,automake,bash-completion,bc,binutils,bison,byacc, coreutils,cpio,csih,cygutils,cygutils-extra,diffutils,dos2unix,e2fsprogs,fdupes,file, findutils,flex, gcc,gcc-core,gcc-g++,gnuplot-X11,gv,hexedit,joe,libRmath-devel,libX11-devel, libheif-devel,libheif-tool,libncurses-devel,libreadline-devel,libsqlite3-devel,libusb-devel, lua,lua-devel,make,mintty,mkisofs,moreutils,mysql,nano,ncurses,patchutils,python,sqlite3, tcl-tix,tcl-tk-devel,texlive-collection-latex,tree,util-linux,xinit,xorg-x11-fonts-dpi75, xorg-x11-fonts-dpi100,xpdf (sorry for the length) (and some of these are probably carried by Base or setup-defined dependencies) and as a consequence my 12 persistent updates in /etc/postinstall/ are zp_hicolor-icon-theme.sh zp_fontconfig_dtd.dash zp_adwaita-icon-theme.sh 0p_000_autorebase.dash zp_glib2.0.sh zp_desktop-file-utils.sh zp_fontconfig_cache_1.sh zp_shared-mime-info.sh zp_man-db-update-index.dash 0p_texlive_prep.dash zp_texlive_finish.dash 0p_update-info-dir.dash The requirements adwaita and texlive are the most time-consuming (and perplexing!). Fergus -- 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
Some repeated tasks at every update
There are 12 tasks never shown ".done" in /etc/postinstall/ (6 .dash and 6 .sh) and therefore repeated at every update. (Other users' installations might have 12 +/-.) They are not particularly intrusive (though they can take a while) but nor is their inclusion or the exclusion of many others at all obvious, except perhaps for *update* and maybe autorebase. Not really too bothered about rationale but can an Admin confirm their necessary presence? -- 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
exit code 2 from /etc/preremove/python39-pip.sh
I don't think it matters much (or at all*) but while installing today's python39 update I got: running: .. .. \bin\bash.exe --norc --noprofile "/etc/preremove/python39-pip.sh" abnormal exit: exit code=2 On inspection the .sh file contains the single command: /usr/sbin/alternatives --remove pip3 /usr/bin/pip3.9 This syntax with arguments and switches is duplicated frequently in /etc/preremove/ scripts so I cannot quite see where the problem resides .. .. Fergus (*) Nothing seems to be broken. -- 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: New installation of Cygwin64: xinit.sh exit code 3
<< Detail >>
>> When I used Explorer to visit C:\ProgramData\Microsoft\Windows\Start
>> Menu\Cygwin-X I was told:
>> "You don't currently have permission to access this folder"
>> and clicking on Continue to get access I was told:
>> "You have been denied permission to access this folder"
>>There was then offered an option to edit Permissions which I didn't feel like
>>pursuing.
>> (I am the Administrator on my own standalone Windows machine. The denial of
>> access to Cygwin-X feels odd.
>> PS I also have Cygwin32 installed and running. I _am_ permitted access to
>> the equivalent folder Cygwin-X (32-bit).)
> Please try running the following command/s, under Cygwin 32 and 64, and
> posting
> the outputs:
> $ for p in "`cygpath -A -P -U`"{,/Cygwin-X}; do for c in 'lsattr -d' 'ls -dl'
> getfacl; do $c "$p"; echo; done; icacls "`cygpath -m "$p"`"; done
Thank you. (Again.)
1. Actually before reading this I had deleted both folders
(successfully, despite not being permitted entry into one
of them) and the re-ran the xinit installation with no
bother at all.
I'm guessing the Permissions glitch resulted from some local
recent accidental keypress or sequence.
2. icacls? Haven't got this though I have got getfacl; found icacl in
"Search packages" under libattica-devel and ng-spice-debuginfo?
--
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: New installation of Cygwin64: xinit.sh exit code 3
>> Should have added: the file /var/log/setup.log shows no detail beyond
>> 2023/10/21 09:29:46 running: G:\console64\bin\bash.exe --norc --noprofile
>> "/etc/postinstall/xinit.sh"
>> 2023/10/21 09:29:49 abnormal exit: exit code=3
>>
>> -Original Message-
>>
>> I made a new installation of Cygwin 64 on a new USB stick, including the
>> package xinit.
>> (I use setup -P followed by a longish but far from complete list of required
>> packages ..,..,xinit,..,..)
>> At this first use of setup I got a single error message:
>>Package: _/xinit xinit.sh exit code 3
>> At 2nd and all subsequent uses of setup (i.e. as update) I get the slightly
>> altered error message:
>>Package: _/Unknown package xinit.sh exit code 3
>> In practice, any usage of xinit (e.g. to launch xterm) seems to work
>> perfectly well, but the repeated
>> error message at any update transaction (including when empty) is
>> disconcerting.
>> I have not tried an explicit command "bash (or dash)
>> /etc/postinstall/xinit.sh" as - even if this worked -
>> I would prefer to canvass opinion on this minor glitch.
>> All the same - the glitch is recent, despite being minor .. ..
> What filesystem is the drive formatted as: NTFS, ExFAT, FAT32, or other?
> Try rerunning the xinit postinstall script as follows and report the failing
> command(s) and error messages:
> $ CYGWINFORALL=-A /bin/sh -vx /etc/postinstall/xinit.sh
Thank you!
1. The identical error msg occurs on all of NTFS, FAT32, exFAT file systems.
2. The output from your test command is identical on all file systems,
3. The failing commands are the two separate "case .. mkdir .. mkshortcut"
sequences that occur
at the end of the xinit.sh script, with consequent error notification as
follows:
case $(uname -s) in *-WOW*) wow64=" (32-bit)" ;; esac
+ case $(uname -s) in
++ uname -s
/usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X${wow64}"
++ /usr/bin/cygpath -A -P
+ /usr/bin/mkdir -p '/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs/Cygwin-X'
/usr/bin/mkshortcut $CYGWINFORALL -P -w / -i /usr/bin/xwin-xdg-menu.exe -n
"Cygwin-X${wow64}/XWin Server" -a "--quote /usr/bin/bash.exe
-l -c \"cd; exec /usr/bin/startxwin\"" /usr/bin/run.exe
+ /usr/bin/mkshortcut -A -P -w / -i /usr/bin/xwin-xdg-menu.exe -n
'Cygwin-X/XWin Server' -a '--quote /usr/bin/bash.exe
-l -c "cd; exec /usr/bin/startxwin"' /usr/bin/run.exe
mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs/Cygwin-X/XWin Server.lnk" failed;
does the target directory exist?
case $(uname -s) in *-WOW*) wow64=" (32-bit)" ;; esac
+ case $(uname -s) in
++ uname -s
/usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X${wow64}"
++ /usr/bin/cygpath -A -P
+ /usr/bin/mkdir -p '/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs/Cygwin-X'
/usr/bin/mkshortcut $CYGWINFORALL -P -w / -i /usr/bin/XWin.exe -n
"Cygwin-X${wow64}/User script" -a "--quote /usr/bin/bash.exe
-l -c \"cd; XSESSION_ICON= exec /usr/bin/startx /etc/X11/xinit/Xsession
xinit-compat\"" /usr/bin/run.exe
+ /usr/bin/mkshortcut -A -P -w / -i /usr/bin/XWin.exe -n 'Cygwin-X/User script'
-a '--quote /usr/bin/bash.exe
-l -c "cd; XSESSION_ICON= exec /usr/bin/startx /etc/X11/xinit/Xsession
xinit-compat"' /usr/bin/run.exe
mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
Menu/Programs/Cygwin-X/User script.lnk" failed;
does the target directory exist?
When I used Explorer to visit C:\ProgramData\Microsoft\Windows\Start
Menu\Cygwin-X I was told:
"You don't currently have permission to access this folder"
and clicking on Continue to get access I was told:
"You have been denied permission to access this folder"
There was then offered an option to edit Permissions which I didn't feel like
pursuing.
(I am the Administrator on my own standalone Windows machine. The denial of
access to Cygwin-X feels odd.
PS I also have Cygwin32 installed and running. I _am_ permitted access to the
equivalent folder Cygwin-X (32-bit).)
--
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: New installation of Cygwin64: xinit.sh exit code 3
Should have added: the file /var/log/setup.log shows no detail beyond 2023/10/21 09:29:46 running: G:\console64\bin\bash.exe --norc --noprofile "/etc/postinstall/xinit.sh" 2023/10/21 09:29:49 abnormal exit: exit code=3 -Original Message- I made a new installation of Cygwin 64 on a new USB stick, including the package xinit. (I use setup -P followed by a longish but far from complete list of required packages ..,..,xinit,..,..) At this first use of setup I got a single error message: Package: _/xinit xinit.sh exit code 3 At 2nd and all subsequent uses of setup (i.e. as update) I get the slightly altered error message: Package: _/Unknown package xinit.sh exit code 3 In practice, any usage of xinit (e.g. to launch xterm) seems to work perfectly well, but the repeated error message at any update transaction (including when empty) is disconcerting. I have not tried an explicit command "bash (or dash) /etc/postinstall/xinit.sh" as - even if this worked - I would prefer to canvass opinion on this minor glitch. All the same - the glitch is recent, despite being minor .. .. -- 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
New installation of Cygwin64: xinit.sh exit code 3
I made a new installation of Cygwin 64 on a new USB stick, including the package xinit. (I use setup -P followed by a longish but far from complete list of required packages ..,..,xinit,..,..) At this first use of setup I got a single error message: Package: _/xinit xinit.sh exit code 3 At 2nd and all subsequent uses of setup (i.e. as update) I get the slightly altered error message: Package: _/Unknown package xinit.sh exit code 3 In practice, any usage of xinit (e.g. to launch xterm) seems to work perfectly well, but the repeated error message at any update transaction (including when empty) is disconcerting. I have not tried an explicit command "bash (or dash) /etc/postinstall/xinit.sh" as - even if this worked - I would prefer to canvass opinion on this minor glitch. All the same - the glitch is recent, despite being minor .. .. -- 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: openssl 1.1.1u-1
During today's update (not test 3.0.9-0.1) this probably unimportant error msg occurred: running: D:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/openssl.sh" can't run /etc/postinstall/openssl.sh: No such file -- 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
Has anybody managed to build FSArchiver?
A visit to https://www.fsarchiver.org/ yields references to versions 0.8.x but at ./configure (though at a very late stage) presents the error msg configure: error: Unsupported system type Cygwin The application looks very competent. Has anybody managed to hack it for Cygwin? -- 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: Error running setup-x86_64.exe: syntax error in setup.zst
>> I'm concerned that the bad setup.zst might propagate to other mirrors. Yes, identical error arising at https://cygwin.mirror.uk.sargasso.net/x86_64/setup.zst and elsewhere. -- 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
bash shell script: recently running, now failing
I have a "hash bang" bash shell script i.e. first line #! /bin/sh or equivalently #! /bin/bash For various reasons I want this file to be identified as binary so its second line is the single character null \x00 showing up in some editors e.g. nano as ^@ This does not prevent the script from running to a successful conclusion. Or not until recently. Now the script fails with /home/user/bin/file.old.sh: cannot execute binary file Q1 - was bash recently updated? Would this explain the changed behaviour? Q2 - if so, is this newly introduced "glitch" known and presumably intended? Or an unintended consequence that will be retracted in a later update? I then altered the first line to #! /bin/dash whilst retaining the null character at line 2 and subsequent content also unaltered.. The altered script file.new.sh runs as previously to a successful conclusion. Q3 - at 1/8 the size of bash and sh, I am not at all sure of the role and reach of dash. Should the edit (dash replacing bash/sh) be incorporated elsewhere or would this be a bad idea (and retained only locally in what is indeed an eccentric and one-off context)? -- 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: Strange link /bin/rungs in 32-bit Cygwin
>> Maybe of diminishing interest (32-bit Cygwin) - but: >> Out of nowhere (but see below (*)) a link has occurred >> /bin/rungs -> /usr/share/texmf-dist/scripts/texlive/rungs.tlu >> which is, I think, a typo for /usr/share/texmf-dist/scripts/texlive/rungs.lua >> Can anybody confirm? > The symlink and script come from texlive-collection-basic. In current > TeX Live on 64-bit Cygwin, the link does indeed point to rungs.lua. But > I think the .tlu extension is used for texlua scripts, so what you're > seeing might not be a typo. I'd have to look back at last year's > texlive-collection-basic to be sure, but you can do that more easily > than I can, since you already have a system with last year's > texlive-collection-basic. You are right. The provision is right though different: Cygwin32: texlive-collection-basic-20220321-1 Cygwin64: texlive-collection-basic-20230313-2 Both setup.ini files are right and so is their enactment. Actually both my platforms were correctly configured with correct links too. My housekeeping, or rather my interpretation of housekeeping reports, was faulty. Sorry for wasted time. -- 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
Strange link /bin/rungs in 32-bit Cygwin
Maybe of diminishing interest (32-bit Cygwin) - but: Out of nowhere (but see below (*)) a link has occurred /bin/rungs -> /usr/share/texmf-dist/scripts/texlive/rungs.tlu which is, I think, a typo for /usr/share/texmf-dist/scripts/texlive/rungs.lua Can anybody confirm? (*) Weird. For no particular reason other than for OC fun I ran the 32-bit setup command setup-x86-2.924.exe --allow-unsupported-windows --site http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/2022/11/23/063457 (all on one line) on an EXISTING setup (with, as anticipated, no obvious change to the entire resource and, in particular, no change to the timestamp 1669214097 i.e. almost exactly 17 weeks ago when Cygwin-32 was archived. Either (1) this error (if it is one) has been there all the time or (2) has been recently introduced. (1) would be odd because of the recently mentioned OCD and (2) would be odd because it raises questions How? and Why? Notwithstanding the diminishing relevance any enlightenment would be interesting and welcome. -- 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
A query about latest update to "make"
I update my local Cygwin using setup-x86_64.exe. The latest setup.ini file includes the lines setup-timestamp: 1676945925 setup-version: 2.924 @ make version: 4.4-1 [prev] version: 4.3-1 [test] version: 4.4.0.91-1 I definitely do not use the switch -t (for test versions); and yet, following today's update, my /etc/setup/installed.db file includes the lines INSTALLED.DB 3 make make-4.4.0.91-1.tar.bz2 0 Not at all sure why not v.4.4-1? -- 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 x86 end-of-life instructions worked really well
Just to say: the instructions at https://cygwin.com/pipermail/cygwin-announce/2022-November/010810.html work really well. I used the following single command at the Command Prompt: "setup-x86-2.924.exe --allow-unsupported-windows --site http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/2022/11/23/063457 -P package1,package2,..,packageN" (all on one line) to recover completely my original Cygwin32 platform (being Base + list of required additions). PS1: If you visit this page there is an intrusive word "option" in the instruction .. '--allow-unsupported-windows option --site circa_URL' .. PS2: Can't actually remember where or how I got the required executable setup-x86-2.924.exe -- 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
Contents of /dev/
Until recently my Cygwin installation (which is of considerable size though far from complete) consisted entirely of directories (here about 3300), files (49000), links (2300) and just 1 socket. Now under /dev/ I find 3 directories 0 files 4 links 12 type b being block (buffered) special 17 type c being character (unbuffered) special I don't think I've installed anything new for ages so these have probably arrived with an update. For me the last two types are an entirely new animal. Is it easy to explain what they are and (only secondly, out of interest) whether anybody else is experiencing this for the first time? -- 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: gcc v.11.3.0 failing - possible cause gcc or libreadline.a?
>>> In a gcc build script terminating with the instruction
>>> gcc -w -static -o myexe -O3 ./myarchive.a -lreadline -lncurses -lm
>>> I have suddenly started getting very many instances of both of
>>> ld: /usr/src/debug/readline-8.2-2/terminal.c:nn various: undefined
>>> reference to `{various}'
>>> ld: /usr/src/debug/readline-8.2-2/display.c:nn various: undefined
>>> reference to `{various}'
>>> and the build fails.
>> The problem was with readline not gcc
>> and I assume originates in myarchive.a and the required switch -lreadline in
>> the gcc line
>> rather than in readline: nevertheless I reverted both libreadline-devel and
>> libreadline7
>> from 8.2-2 to 7.03 and the problem went away.
> Please provide a few examples which include the actual texts of "nn various"
> and
> `{various}' especially where any prefixes vary.
> Did you also upgrade/downgrade libncurses-devel concurrent with
> libreadline-devel as they are dependent?
> Why suppress all warnings -w from the ld (or any) phase of compilation?
> Those warnings could tell you what causes an issue.
No I didn't upgrade / downgrade libncurses-devel concurrently with
libreadline-devel.
In fact after upgrading back to 8.2-2 and confirming the failed build I
retained all current and up-to-date
and made _just_one_change_: I extracted the single file libreadline.a from
libreadline-devel-8.1-2.tar.xz
(i.e. just one reversion to 8.1 not two to 7.0) and substituted it in place
leaving everything else as for 8.2-2
including libreadline.dll.a and confirmed that this single substitution allowed
the build.
I suppress the warnings because there are so many of them! I can supply them
but for the moment the issues
that prevent a successful build using libreadline.a (8.2-2) are listed in the
attached text file.
Thank you very much for taking an interest.
Description:
--
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: gcc v.11.3.0 failing - possible cause gcc or libreadline.a?
>> In a gcc build script terminating with the instruction
>> gcc -w -static -o myexe -O3 ./myarchive.a -lreadline -lncurses -lm
>> I have suddenly started getting very many instances of both of
>> ld: /usr/src/debug/readline-8.2-2/terminal.c:nn various: undefined
>> reference to `{various}'
>> ld: /usr/src/debug/readline-8.2-2/display.c:nn various: undefined
>> reference to `{various}'
>> and the build fails.
The problem was with readline not gcc
and I assume originates in myarchive.a and the required switch -lreadline in
the gcc line
rather than in readline: nevertheless I reverted both libreadline-devel and
libreadline7
from 8.22 to 7.03 and the problem went away.
--
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
Long lines in posts to this mailing list
What causes long lines without word wrap in posts to this list (such as the immediately preceding "gcc v.11.3.0 failing") and how can they be avoided? (They are very inconvenient - sorry!) -- 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
gcc v.11.3.0 failing - possible cause gcc or libreadline.a?
In a gcc build script terminating with the instruction
gcc -w -static -o myexe -O3 ./myarchive.a -lreadline -lncurses -lm
I have suddenly started getting very many instances of both of
ld: /usr/src/debug/readline-8.2-2/terminal.c:nn various: undefined
reference to `{various}'
ld: /usr/src/debug/readline-8.2-2/display.c:nn various: undefined reference
to `{various}'
and the build fails.
It's a while since I attempted this build of myexe (myarchive has been
unaltered for years) and the attempt is triggered by a reported bug in gcc -pg
after update that has been corrected.
I don't know whether it is a change in readline (libreadline.a) or gcc that has
possibly caused the glitch (and obviously I cannot and do not expect anybody to
debug my build for me) but is this glitch familiar to anybody through current
or previous experience, or by appearance, that means you could point to cause
or possible cause?
Thank you!
--
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
How to search this Archive
I know I have asked this before but because I cannot search the Archive I cannot find the query or any responses. One used to be able to type site:cygwin.com "keyword1 keyword2 .." into Google and depending on the search string(s) a slew of results appeared. This way, one could find all the posts that one had ever originated or contributed to; or every mention of chmod; or, with care, recover a particular thread. Now, this approach still kind of works, but in such a restricted manner that the effort is not rewarded. (Either Google has changed practice or pipermail is not accessible in this way - as from memory cygwin.com/ml/ was .. .. ) I explored https://mail.python.org/pipermail/ but to no useful effect. Is there a way to explore the entire archive back to 1997? I cannot find any hints at https://cygwin.com/mailman/listinfo/cygwin Thank you. -- 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
When only rsync will do .. or maybe not
Requirement: to move some selected files and folders under /folder1/ to
/folder2/, preserving full pathnames.
Using cp with the switch --parents (taking care over syntax and importantly
location $PWD) it is possible to _copy_ the
Required content across from /folder1/ to /folder2/ but there does not seem to
be a matching switch for mv that would
achieve the same purpose.
One solution would be (i) to copy the required content to /folder2/ and then
(ii) delete the identical content under /folder1/;
but this is expensive (one might not even have the disk space to do it) and it
seems seriously unsatisfactory and not without risk
to have to copy folders and files (possibly huge) when all one wants to do is
to change the {pathname} to them.
Question 1
Would the command (or something like it, again with care over syntax and $PWD)
$ rsync -axuv --progress {pathto}/folder1/{content} {pathto}/folder2/
do the trick? Or is the very existence of the switch
$ rsync -axuv --remove-source-files --progress {pathto}/folder1/{content}
{pathto}/folder2/
indicative that here too the "move" is achieved through a two-stage
"copy-then-delete" operation?
Question 2
If rsync can provide a genuine "move" capability then is installing the rsync
package adequate to the purpose;
or would librsync-devel and/or librsync2 packages need to be installed also?
Question 3
If not rsync, is there any operation for which "move" can be achieved without
involving "copy-then-delete"?
Thank you for any assistance.
--
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: Frequent Warning messages using gv
Thank you. Installing these two packages has done the trick, at least for the several files that previously generated warning messages. Sent via Outlook on my Asus ZenFone 8 From: Jon Turney Sent: Saturday, October 8, 2022 2:01:50 PM To: Fergus Daly ; The Cygwin Mailing List Subject: Re: Frequent Warning messages using gv On 05/10/2022 06:45, Fergus Daly wrote: > Whenever I use gv on a PostScript file as in > $ gv filename.ps > then a (usually) successful display is (almost invariably) accompanied by > Warning messages about font conversions. > It is not obvious what limitations or errors are affecting the displayed > output, if any, and I have got into the habit > of issuing the command with the qualifier > $ gv filename.ps 2> /dev/null > However: the Warning messages whilst occasionally very esoteric nearly always > include the form > Warning: Missing charsets in String to FontSet conversion > Warning: Cannot convert string > "-*-Helvetica-Bold-R-Normal--*-120-*-*-P-*-ISO8859-1" to type FontStruct > Warning: Cannot convert string > "-*-Helvetica-Medium-R-Normal--*-100-*-*-P-*-ISO8859-1" to type FontStruct > Warning: Cannot convert string > "-*-Helvetica-Medium-R-Normal--*-120-*-*-P-*-ISO8859-1" to type FontStruct > Warning: Cannot convert string > "-*-Helvetica-Medium-R-Normal--*-140-*-*-P-*-ISO8859-1" to type FontStruct > Is there some additional fonts package or group of packages that I could > usefully incorporate into my Cygwin setup that > would reduce warnings when using gv? (And maybe improve the rendering of > outputs.) > My directory /usr/share/fonts/microsoft/ contains 120+ ttf links, though none > looking anything like helv*. Installing 'xorg-x11-fonts-dpi75' and/or 'xorg-x11-fonts-dpi100' will probably resolve these warnings. It's unclear to me if gv needs a dependency on more font packages or not, since the PS could be using any fonts? -- 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
Frequent Warning messages using gv
Whenever I use gv on a PostScript file as in $ gv filename.ps then a (usually) successful display is (almost invariably) accompanied by Warning messages about font conversions. It is not obvious what limitations or errors are affecting the displayed output, if any, and I have got into the habit of issuing the command with the qualifier $ gv filename.ps 2> /dev/null However: the Warning messages whilst occasionally very esoteric nearly always include the form Warning: Missing charsets in String to FontSet conversion Warning: Cannot convert string "-*-Helvetica-Bold-R-Normal--*-120-*-*-P-*-ISO8859-1" to type FontStruct Warning: Cannot convert string "-*-Helvetica-Medium-R-Normal--*-100-*-*-P-*-ISO8859-1" to type FontStruct Warning: Cannot convert string "-*-Helvetica-Medium-R-Normal--*-120-*-*-P-*-ISO8859-1" to type FontStruct Warning: Cannot convert string "-*-Helvetica-Medium-R-Normal--*-140-*-*-P-*-ISO8859-1" to type FontStruct Is there some additional fonts package or group of packages that I could usefully incorporate into my Cygwin setup that would reduce warnings when using gv? (And maybe improve the rendering of outputs.) My directory /usr/share/fonts/microsoft/ contains 120+ ttf links, though none looking anything like helv*. Thank you. -- 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: heic to jpg conversion
>> $ magick test.heic test.jpg >> $ mogrify -format jpg test.heic >> Any ideas? EITHER (a) your syntax might be faulty? Try: $ convert test.heic test.jpg OR (b) you need to install the two packages libheif-tool and libheif-devel into your Cygwin platform; and then try the same thing: $ convert test.heic test.jpg -- 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: coreutils 9.1
Brian Inglis wrote: >> Setup still shows 9.1 as test, but it should not be installed by anyone. >> Setup now also shows 9.0 in test, and it can and should be installed by >> anyone who experienced issues with 9.1. Jim Reisert wrote: > 9.0 (test) is working for me now, whereas 9.1 did not work. > Thanks for the fixes! .. can and should be installed .. Done. 9.0 (test) is working for me now, whereas 9.1 did not work. (I had earlier reported a glitch.) Thank you! -- 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: coreutils 9.1
Since updating from coreutils 8.32 I’m getting a weird glitch from cp. If /location1/dir1/ contains additional material to /location2/dir1/ (as might frequently be the case when maintaining a backup) then the command $ cp -vrn /location1/dir1 /location2 should copy the additional material across. (I do this regularly, working in two locations on two machines with a stick to manage the transactions.) Since updating coreutils, this command yields an error message as follows: $ cp -vrn /location1/dir1 /location2 /bin/cp: cannot create directory '/location2/dir1': File exists I haven’t tried any other variations on cp or explored any other commands (e.g. ls) that have altered with the update. This occurs in both 32-bit and 64-bit Cygwin. Fergus -- 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: Re: Updated: coreutils 8.32
>> I've just updated coreutils. I don't use test versions. So I have $ uname >> --version uname (GNU coreutils) 8.32 Packaged by Cygwin (8.32-1) >> Now on 32-bit Cygwin I get >> $ uname -s >> CYGWIN_NT-10.0-19044-WOW64 [ previously CYGWIN_NT-10.0-WOW ] >> And on 64-bit Cygwin I get >> $ uname -s >> CYGWIN_NT-10.0-19044 [ previously CYGWIN_NT-10.0 ] >> Packaging error? > That build is a value we have said for years we would make visible for > easier determination of Windows version used (21H2 for you and I), > previously only visible in /proc/version: > $ head /proc/version > CYGWIN_NT-10.0-19044 version 3.3.5-341.x86_64 (corinna@calimero) (gcc > version 11.2.0 20210728 (Fedora Cygwin 11.2.0-2) (GCC) ) 2022-05-13 > 12:27 UTC Thank you. > What products or processes does it affect negatively, and are there > arguments for suppression, other than backward compatibility? None central. I have a script with sequenced case `uname -s` in allowing for multiple platforms and it wobbled with this change. I will rewrite it. Thanks for clarity. Fergus -- 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: coreutils 8.32
I've just updated coreutils. I don't use test versions. So I have $ uname --version uname (GNU coreutils) 8.32 Packaged by Cygwin (8.32-1) Now on 32-bit Cygwin I get $ uname -s CYGWIN_NT-10.0-19044-WOW64 [ previously CYGWIN_NT-10.0-WOW ] And on 64-bit Cygwin I get $ uname -s CYGWIN_NT-10.0-19044 [ previously CYGWIN_NT-10.0 ] Packaging error? Fergus -- 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: Longfilename problem with mintty 3.6.0
>> I'm having difficulty with longfilename in the latest mintty. >> This is new since 3.6.0. Sorry. On a different machine, no difficulties. Possibly (or even likely) a local problem. Apologies for sending. -- 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
Longfilename problem with mintty 3.6.0
I'm having difficulty with longfilename in the latest mintty. As follows: If I try to work with a file with such a longfilename that it extends beyond the right hand edge of the mintty window, as in say $ mv longfilename .. .. OR $ cp longfilename .. .. OR $ md5sum longfilename OR similar; and if I try to save effort by (as usual) $ mv long and similar, then word-wrap does not occur and I end up with visual gobbledegook on a single line (though I think the instruction completes). This is new since 3.6.0. (I thought it might be something to do with the new "re-wrap on re-size" facility but cannot develop this suspicion into anything useful.) Fergus -- 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
Problem with gnuplot output
In an xterm console: The file gn0 contains all necessary instructions for displaying a gnuplot plot: 1 As expected (or as in the past, anyway) the command "gnuplot gn0" causes the gnuplot display to flash on screen for an instant and then disappear. The user remains at the xterm prompt. 2 As ditto, the command "gnuplot gn0 -" presents the gnuplot display which persists, but the user is left in a gnuplot process (i.e. showing the prompt gnuplot>) needing to press crtl-D to return to the xterm prompt. So no problem and nothing new up to now. 3 What is desired should result from "gnuplot gn0 - &": the gnuplot display is shown on screen and will persist as long as required, and the user returned to the xterm prompt to carry on with whatever other stuff; but what actually happens is an empty gnuplot display with a clockface. Has the required command syntax "gnuplot gn0 - &" altered? Thank you! -- 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: Cygwin/X fatal error
On 08.01.2022 07:57, Fergus Daly wrote: > Not quite sure what recent update has caused this failure. > Up to now (and for a very long time indeed) typing > $ /bin/xinit /bin/xterm -- -nolock -multiwindow > at the mintty prompt has successfully started an xterm process. > Now I get: > "A fatal error has occurred and Cygwin/X will now exit. > Cannot establish any listening sockets." > Over the years the one-liner typed above has had to evolve with changing > execs so I'm not surprised, or bothered, at this glitch. > But can anybody please advise the necessary change in syntax that will again > enable a successful xterm from mintty? > Thank you! Marco Atzero replied: > Hi Fergus, > It works for me, so it seems not due to the sintax > Can you start X with startxwin ? > Please provide the cygcheck.out as mentioned on > Problem reports: https://cygwin.com/problems.html > Regards > Marco SOLVED I ran $ rm -vrf /tmp/.X11* in order to enable a "fresh start" and all is good. On all devices and for both Cygwin32 and Cygwin64. Thank you, Marco. Fergus -- 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/X fatal error
Not quite sure what recent update has caused this failure. Up to now (and for a very long time indeed) typing $ /bin/xinit /bin/xterm -- -nolock -multiwindow at the mintty prompt has successfully started an xterm process. Now I get: "A fatal error has occurred and Cygwin/X will now exit. Cannot establish any listening sockets." Over the years the one-liner typed above has had to evolve with changing execs so I'm not surprised, or bothered, at this glitch. But can anybody please advise the necessary change in syntax that will again enable a successful xterm from mintty? Thank you! -- 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
terminfo packaging glitch?
Does this: $ ls /usr/share/terminfo/terminfo lrwxrwxrwx /usr/share/terminfo/terminfo -> /usr/share/terminfo/ serve a purpose, or supply a workaround .. or .. is it a packaging glitch? (Only in Cygwin64, not Cygwin32.) -- 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: Portable CygWin version for Windows?
Am 14.11.2021 um 11:32 schrieb Marco Atzeri via Cygwin: > On 14.11.2021 08:37, Peter Steiner via Cygwin wrote: >> On webpage >> >> https://cygwin.com/ >> >> I found only a CgyWin Installer to download. >> >> I prefer to put CygWin on an USB flash drive and run it on various >> computers without leaving installation traces. >> >> Is there really no portable version to download? > > correct. No one should install all the files > >> >> What if I install it once one computer and copy all the files to my >> USB flash drive? >> Are there any disadvantages? > > The file permissions will be not correct. Actually, if you format your USB stick to NTFS, this should work. I remember to have had a mobile cygwin stick around a while ago. > > What you can do is use the USB stick as location for the cache download > and install from the USB on the other computers. > >> >> Peter >> > > Regards > Marco >> The file permissions will be not correct. >> Actually, if you format your USB stick to NTFS, this should work. I >> remember to have had a mobile cygwin stick around a while ago. Having trouble following the assertions here. I've had a FAT32 portable USB stick supporting both Cygwin32 and Cygwin64 for, dunno, 20 years or something. I made a new one from scratch last night, actually, absolutely coincidentally to this post. Whilst not "Full" the installation is way in advance of "Base". I just run setup -P at the Windows command prompt, installing to a formatted FAT32 stick, and away I go. Time after time after time. Fergus -- 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: rename using regexpr - is it possible?
-Original Message-
From: Eliot Moss
Sent: 24 October 2021 17:11
To: Fergus Daly ; 'cygwin@cygwin.com'
Subject: Re: rename using regexpr - is it possible?
On 10/24/2021 4:55 PM, Fergus Daly wrote:
>>> I might be wrong but:
>>> The Cygwin implementation of rename seems completely different from "the"
>>> (my) Linux version.
>>> (Almost unique? Otherwise the matching in Cygwin of all syntax -
>>> vocab, switches, outcomes - to Linux, seems almost perfect.) Can I
>>> rename a set of files *.d (say) as filename.d -> XXfilename.d?
>>> In Linux this would be achieved by
>>> $ rename 's/^/XX/g' ./*.d
>>> whereas in Cygwin
>>> $ rename ^ XX *.d
>>> (and all similar attempts) fails.
>>> Thank you.
>
>> You're confusing perl-rename with util-linu rename.
>> The former, which seems to be what you want, can be installed using
>> cpan (install File::Rename), assuming you have perl installed.
>> It will put its rename command in /usr/local/bin, presumably taking
>> precedence over the util-linux one in /usr/bin.
>> It further seems that "normally" these two have different names, like
>> rename.ul and prename, and /etc/alternatives is used to set up the rename
>> command.
>> This required some web searching to determine ...
>> Cheers - Eliot
>
> Perfect. Worked like a dream.
> All in place, and naming managed.
> Thanks so much.
No problem - learned something myself! EM
PS When I said .. ..
> Perfect. Worked like a dream
.. .. I had only tried things in Cygwin32. The cpan step failed in Cygwin64 so
I couldn't follow up with the install File::Rename command.
(I'm quite surprised. Here, the Cygwin32 and Cygwin64 setups are identical
in that, whilst incomplete i.e. not "Full", they are constructed using the
identical
C:> setup -P {long list of packages separated by commas}
command at the Windows prompt. Up to now they have behaved identically.
Solved by copying across from Cygwin32 to Cygwin64 all the newly
"rename-augmented"
files under /usr/local/bin/, /usr/local/lib/, /usr/local/man/, and not
forgetting the
augmented file /etc/bash.bashrc containing the 4 export perl* lines.
Seems to work so far. But if I hadn't also got Cygwin32, I would have been
stuck with the
cpan failure under Cygwin64. I must have missed something for Cygwin64 .. ..
but Goodness
knows what.
--
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: rename using regexpr - is it possible?
>> I might be wrong but: >> The Cygwin implementation of rename seems completely different from "the" >> (my) Linux version. >> (Almost unique? Otherwise the matching in Cygwin of all syntax - >> vocab, switches, outcomes - to Linux, seems almost perfect.) >> Can I rename a set of files *.d (say) as filename.d -> XXfilename.d? >> In Linux this would be achieved by >> $ rename 's/^/XX/g' ./*.d >> whereas in Cygwin >> $ rename ^ XX *.d >> (and all similar attempts) fails. >> Thank you. > You're confusing perl-rename with util-linu rename. > The former, which seems to be what you want, can be installed using cpan > (install File::Rename), > assuming you have perl installed. > It will put its rename command in /usr/local/bin, presumably taking > precedence over the util-linux one in /usr/bin. > It further seems that "normally" these two have different names, like > rename.ul and prename, > and /etc/alternatives is used to set up the rename command. > This required some web searching to determine ... > Cheers - Eliot Perfect. Worked like a dream. All in place, and naming managed. Thanks so much. Fergus -- 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: Trouble with setting ini files : gnuplot and vi
>> Despite best efforts I cannot find a way of setting user preferences >> for vi (e.g. preferred syntax-sensitive settings) and gnuplot (e.g. >> preferred line colours / thickness). >> I have tried editing /etc/vimrc, /etc/virc for vi; and >> /etc/X11/app-defaults/Gnuplot for gnuplot accordingly. >> (I use gnuplot-x11.) No change from standard representation. >> Any ideas? > If you are really using /usr/bin/vi and not /usr/bin/vim, then you are using > the small version of vim, > which does not support filetype detection or syntax highlighting as well as > some other vim features. > If you want a full-featured vim, install the vim package. > Regards, Gary Seen immediately after my reply to Eliot. Thanks very much - now all is clear. Fergus -- 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: Trouble with setting ini files : gnuplot and vi
>> Despite best efforts I cannot find a way of setting user preferences >> for vi (e.g. preferred syntax-sensitive settings) and gnuplot (e.g. >> preferred line colours / thickness). >> I have tried editing /etc/vimrc, /etc/virc for vi; and >> /etc/X11/app-defaults/Gnuplot for gnuplot accordingly. >> (I use gnuplot-x11.) No change from standard representation. >> Any ideas? >The first thing I would check is whether you have an individual ~/.virc or >~/.gnuplot file that is overriding the settings of interest. > For gnuplot, at least, the man page says that its "show loadpath" command > will indicate where it looks for gnuplotrc. > On my system that is /usr/share/gnuplot/5.4/. > Since my gnuplot offers x11 for "set term", I think I'm looking at the right > thing, but if gnuplot-x11 is truly different, > then maybe try the "show loadpath" command for it. I don't have vi installed > (only vim) so I can't speak to that. > The next thing I would check are the various permissions, to make sure the > program can actually read the file(s) in question. > Maybe you have done all this, in which case I'm sorry my ideas were not > helpful ... > Best wishes - Eliot Moss Thank you! For gnuplot your suggestion worked perfectly. I have now tweaked /usr/share/gnuplot/5.4/gnuplotrc as required. Perplexed by your "vim not vi". I set up my Cygwin platform using setup -P and do not specify any editor beyond nano (which is perfect to my needs). Nevertheless I get vi. From "Package search" I'm guessing it comes as an adjunct because I also need groff and latex. You must actually specify vim? which I vaguely recall preferring to vi but cannot remember why. (Mainly, I liked neither. But I can remember easily setting and locating /etc/vimrc, and that it was properly picked up.) Nevertheless, still having problems with setting and location virc - since I've got vi, I'd just like to be able to use it effectively .. .. Thanks again, anyway. -- 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
gnuplot post-install : exit code 1
Both cygwin32 and cygwin64, both up-to-date: Following recent update to gnuplot I'm getting post-install errors as follows in both setup logs: running: D:\cygwin..\bin\bash.exe --norc --noprofile "/etc/postinstall/gnuplot.sh" abnormal exit: exit code=1 My installed.db shows gnuplot-X11 gnuplot-X11-5.4.1-1.tar.bz2 1 gnuplot-base gnuplot-base-5.4.1-1.tar.bz2 0 for both 32 and 64 bit setups. Previously to this update, no such messages. Any ideas? -- 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
Starting xterm as a DOS Command Prompt one-liner
This one-line DOS command to start an xterm terminal: D:\cygwin> bin\run bin\XWin -clipboard -nolock -multiwindow 2> nul & timeout 4 > nul 2> nul & bin\xterm -display :0.0 2> nul & bin\kill -KILL -- -1 (broken here after each "&" for clarity of presentation only) works, and is a neat and convenient alternative to starting xterm at the bash or mintty prompt with the single line $ /bin/xinit /bin/xterm -- -nolock -multiwindow 2> /dev/null (The "> nul" phrases in all the above just suppress notifications.) Question 1: I find the timeout .. chunk necessary to give XWin enough time to load before the xterm .. chunk draws upon it. Is there a different conjunction to "&" that says "wait till this is enacted before moving on" (which is actually what I thought "&" did!)? Question 2: The final kill .. chunk only operates after the xterm terminal is closed, and its purpose is to kill XWin, which otherwise hangs about. Is there some other way of assuring that the un-needed XWin is killed, maybe (I dunno) by adding a qualifier to the initial "run XWin" chunk? Thank you! -- 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: Trouble with starting XWin, "(EE) Can't read lock file /tmp/.XO-lock"
-Original Message- From: Cygwin On Behalf Of rt...@sciencetools.com Sent: 18 November 2020 22:03 To: cygwin@cygwin.com Subject: Trouble with starting XWin, "(EE) Can't read lock file /tmp/.XO-lock" Hey everyone, SUPER long time Cygwin user, seldom need help, and my versions are all ancient now and I can't upgrade, I don't think. I'm on Windows 7 and am stuck there. Other version data follows. Everything had been working fine for years, then I had a system crash and on restart, this is the only error I can find. When run from the Cygwin shell command line, it goes like this: $ XWin :0 -multiwindow -clipboard -wgl -ac -listen tcp Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.19.2.0 OS: CYGWIN_NT-6.1 Okrasa 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) Package: version 1.19.2-1 built 2017-03-09 XWin was started with the following command line: XWin :0 -multiwindow -clipboard -wgl -ac -listen tcp (EE) Fatal server error: (EE) Could not create lock file in /tmp/.tX0-lock winDeinitMultiWindowWM - Noting shutdown in progress $ I tried with window IDs 1 and 2 instead of zero but these didn't work either. Later, while busy with other things, there was a power failure for the facility and when the power came back on, of course the system had rebooted so I tried again and got the same thing. ...Somehow early in my testing to get this going, without intentionally doing anything else, I noticed the error changed from "Could not create lock file in", to "Can't read lock file /tmp/.X0-lock". Looking for the directory previously mentioned, it wasn't there so I decided to try and create that directory. When I do that, the error goes back to "Could not create lockfile in". ... I wonder if I created it with the right ownership and permissions, so I tried several things with no success. ...I'm rather desperate to fix this as this feature has become a key tool for this particular system. Ideas? Help? Thanks, RT Also a long-time W7 user: try deleting everything X-relevant under /tmp/ (in my case .X11-unix/ and its contents) and then $ run XWin -clipboard -nolock -multiwindow I know, simpler than yours - but this has evolved over the years, replacing earlier more complex command lines which suddenly broke, usually after some relevant update. Any good? BUT NB I am Cygwin-current - what's your difficulty with updating? Fergus -- 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-64 on W10-64 : the only game in town?
With W7 no longer supported, W10-32 supported but no longer provided on new machines (Microsoft states that, "Beginning with Windows 10, version 2004, all new Windows 10 systems will be required to use 64-bit builds and Microsoft will no longer release 32-bit builds for OEM distribution .. the weaker version of Windows 10 has several limitations, like capping out at 3.2GB of RAM and less stringent security measures") and the functionality of Cygwin-32 significantly downplayed on Cygwin's own Home page, that really does leave Cygwin-64 on W10-64 on 64-bit hardware as the sole recommended platform. Yes? -- 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: postinstall: fontconfig abnormal exit
>> Fergus and Hamish, the problem you reported should be fixed with >> fontconfig 2.13.1-2 and libxml2-2.9.10-2. Yes: all good now. For me, anyway: I tried setup-x86.exe -P texlive-collection-latex -mn (i.e. just Base + TeX) which earlier caused the problem: no errors. Thank you! -- 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: postinstall: fontconfig abnormal exit
> On 2020-09-10 04:57, Fergus Daly via Cygwin wrote:
> >>>> Sorry if this has been asked 4 million times already.
> >
> >>> $ head /etc/postinstall/{fontconfig_dtd,libxml2}.*
> >>==> /etc/postinstall/fontconfig_dtd.sh.done <==
> hmmm. i don't understand exactly what this thread is about, but i do know
> that on my latest fresh install of cygwin,
> the fontconfig_dtd install is claiming an error at the end.
> is this related to that ?
Exactly. On first setup and all subsequent updates this post-installation error
recurs.
The cure described depends on the presence of several files including one that
the script creates if necessary.
PS Before I enlisted help to cure this glitch "properly", I found it and its
recurrence sufficiently intrusive to become an annoyance.
Since nothing was obviously broken I guessed that nothing further would be
broken by artificially achieving the post-installation
sequence as follows:
$ mv /etc/postinstall/fontconfig_dtd.sh /etc/postinstall/fontconfig_dtd.sh.done
And so it transpired: nothing awful seemed to happen, or fail to happen, as a
consequence of this "fix"; and the error msg stopped.
--
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: postinstall: fontconfig abnormal exit
>>> Sorry if this has been asked 4 million times already.
>> $ head /etc/postinstall/{fontconfig_dtd,libxml2}.*
>==> /etc/postinstall/fontconfig_dtd.sh.done <==
>> if [ -x /usr/bin/xmlcatalog ] ; then
> /usr/bin/xmlcatalog --noout --add "system" "fonts.dtd"
> /usr/share/xml/fontconfig/fonts.dtd /etc/xml/catalog
> fi
==>> /etc/postinstall/libxml2.sh.done <==
>> if test ! -f /etc/xml/catalog; then
> /bin/mkdir -p /etc/xml
> /usr/bin/xmlcatalog --noout --create /etc/xml/catalog
> fi
>> $ llgo /{etc/xml/,usr/bin/xml}catalog /usr/share/xml/fontconfig/fonts.dtd
> /etc/postinstall/{fontconfig_dtd,libxml2}.*
> Thank you!
Out of interest:
Is this something that would usually be achieved during setup, as in other
instances of
.sh -> .sh.done, but has just fallen off?
Or (say) would it be achieved if I appended some specific package using setup
-P?
Or .. .. ?
--
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: postinstall: fontconfig abnormal exit
> Greetings, Fergus Daly!
>> Sorry if this has been asked 4 million times already.
>> During postinstall, both at ground-zero installation and at every update
>> thereafter, and for both Cygwin-32 and -64,
>> (both using the appropriate setup-x86[_64].exe) I get:
>> running: {pathToCygwin}\bin\bash.exe --norc --noprofile
>> "/etc/postinstall/fontconfig_dtd.sh"
>> abnormal exit: exit code=2
>> Is there something that can be done to address this "error", if that is
>> what it is, or is it just a quirk of setup?
> Run the same command manually and see where it's failing.
> IIRC (as this has been raised before), the problem is that a certain
> file/directory not exists.
> Check the mailing list archive?
Thank you for this advice.
1
For a long time (years) I have included an empty file
/etc/X11/fontpath.d/thisisafile
in my architecture as a workaround to address some installation problem,
the nature of which I have completely forgotten.
Having incorporated this dummy file, I should then re-install some package,
but precisely which one I have regrettably also forgotten.
2
This kind suggestion came from Ken Brown. By a strange coincidence, less than a
week ago,
https://cygwin.com/pipermail/cygwin/2020-September/246128.html,
I lamented the lack of ease with which one may search this archive. I just
searched in a limited way
to try to discover the problem for which Ken's workaround provided the cure,
but without success.
3
I also just now added "fontconfig" to my setup using "setup -P fontconfig" and
then also ran the command
fc-cache -v
at the bash prompt, and whilst achieving a raft of checks, this has not
addressed the original postinstall error
message.
I did not really think it would, guessing that if the fontconfig package were
to successfully address such a
basic (and recurrent) fault, then it would necessarily have been included in
Base.
So: nil progress, but thank you for your suggestion.
--
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: heic to jpg conversion
> The just uploaded ImageMagick 7 is able to convert > from heic to both jpg and png (and more I assume ..) > I also added libheif and libde265 needed for the job. All working well. THANK YOU! -- 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: heic to jpg conversion
>> Does Cygwin include the capability to convert heic to jpg (or png or >> anything else Windows-readable)? >> I tried "convert" (previously all-powerful) but that does not work (in any >> obvious way, anyway). >> Thank you! > Works for me. What does `type convert` say? I have this: ~/tmp> type convert convert is /usr/bin/convert ~/tmp> ls -x L1a.heic L2a.heic ~/tmp> file * L1a.heic: ISO Media L2a.heic: ISO Media ~/tmp> convert L1a.heic L1a.jpg convert: no decode delegate for this image format `HEIC' @ error/constitute.c/ReadImage/560. convert: no images defined `L1a.jpg' @ error/convert.c/ConvertImageCommand/3258. (BTW, in the above dialogue, should ISO Media read IOS Media?) -- 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
Needing readline to build a local 64-bit exec
Of more than 640 *.c files incorporated into a locally-built executable, exactly one contains many references to readline, such as "#include ". The 32-bit build proceeds impeccably to completion: there is a subdirectory x86/release/readline in the Cygwin resource and a paragraph for @ readline in the file x86/setup.ini, albeit with "obsolete" qualifiers. However the 64-bit build fails at the compilation of the file containing the reference to readline: various *.h not found. There is a subdirectory x86_64/release/readline in the resource but it contains only subdirectories, not the root readline-7.*.tar.xz files. The file x86_64/setup.ini contains no paragraph for @ readline. I do not fully understand the interpretation or consequences of obsoletion, but this changed provision relating to readline is the key difference between x86/ and x86_64/. I tried supplementing the resource under x86_64/release/readline with the "missing" *.tar.xz files and editing x86_64/setup.ini to include the paragraph for @ readline, but this broke setup.ini.sig. (I use a constantly updated mirror on a local drive. It takes 62G but it's worth it.) It is clear (well, given my limited understanding of the handling of obsoleted files) that in some way the provision under x86/release/readline and its referencing in x86/setup.ini remains critical to the successful build of the 32-bit executable, and the lack of provision under x86_64/release/readline and omission from x86_64/setup.ini is critical to the failed build. It seems to be located, picked up and used, despite its obsolete status? Can it be recovered into the x86_64 provision? Or can somebody who understands it better please explain the discrepancy in x86 and x86_64 provision that triggers the contrasting success and failure for 32-bit and 64-bit version build attempts. And, even better, how to achieve 64-bit success? Thank you! -- 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
xterm stackdump
Lately I have been experiencing an xterm stackdump with varying triggers but all leading to a forced exit. Here is typical output. Exception: STATUS_INTEGER_DIVIDE_BY_ZERO at eip=0045D5EF eax=0092 ebx=80080300 ecx= edx= esi=800D4C88 edi= ebp=0004 esp=006BC820 program=D:\console32\bin\xterm.exe, pid 1661, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args ~> Identical problem on Windows 10 AND Windows 7. (And that really is unusual. Most times a problem on W10 is not mimicked on the ultra-robust W7 platform.) Using cygwin1.dll v.3.1.6 and up-to-datest versions of xinit, xterm, gnuplot, etc. I can provide output from cygcheck -srv but the file is 1600 lines long and 98K? Not sure if this is useful / welcome - or how best to transmit it, if it is. -- 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
Setting appearance in bash / mintty
This is a bash question, but it is posed only because I am experiencing a lack of parallel alignment between bash and mintty in Cygwin. Hope OK to ask. The file /etc/minttyrc [or equivalent] [or R-click in the mintty console] can be used to set FG and BG colours, font style and size. When using mintty, it picks up all of echo -n $'\e]4; 3;255, 0, 0\a' echo -n $'\e]4; 6;139, 69, 19\a' echo -n $'\e]4;10; 0,127, 0\a' echo -n $'\e]4;12; 0, 0,255\a' echo -n $'\e]4;14;127, 0, 0\a' in /etc/bash.bashrc [or equivalent] so that ls shows directories in blue, text files in black, executables in green, links in dark brown. I daresay other fine and attractive distinctions are available. Thus the full working appearance, within mintty, may be set to the user's preference. For various reasons I have reverted to a bash shell*. R-click -> Properties to set FG, BG, font, placement, etc. But the settings above in /etc/bash.bashrc seem to be missed, or maybe interpreted differently. If missed, can anybody dictate where I should set them? If interpreted differently, can anybody point me to a recipe book for bash appearance? Thank you. * Some odd behaviours in mintty, not mimicked in bash or xterm, when calling a non-Cygwin external (which admittedly could be the source of the problem). If/when I can trigger these behaviours entirely within Cygwin, I shall try to describe them here. -- 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: Current setup timestamp 1590343308
>> It looks to me that /etc/setup/timestamp is updated by the last successful
>> setup
>> (upgrade?) run, and contains a copy of the selected mirror's setup.ini
>> setup_timestamp field as of the last successful setup (upgrade?) run, a few
>> hours earlier than the last successful setup (upgrade?) run.
Thank you for this.
I can't really think of anything to say other than repeat my observation,
today, of altered practice.
Since as long as I can remember (and I mean - a matter of years) a successful
upgrade of Cygwin32
(implementing the current version of setup-x86.exe currently 2.904
and pulling in the latest version of setup.ini found at {source}/Cygwin/x86/)
has concluded with
(i) a glitch-free accounting in /var/log/setup.log(.full), together with
(ii) a revision of the file /etc/setup/timestamp
which reflects the timestamp line in the aforementioned setup.ini file.
(And other things too, quite apart from any updates to the Cygwin provision -
e.g. an updated /etc/setup/installed.db file.)
What I have observed, twice now (earlier today using setup.ini incorporating
timestamp 1590343308 and now using the latest setup.ini incorporating timestamp
1590407755) is that event (ii) is failing: the file /etc/setup/timestamp is not
updated - and if it isn't there at all, it is not created.
Maybe this does not matter. The file is not referred to during any upgrade
session (or not obviously - I think the contents of /etc/setup/installed.db
are what dictate any necessary upgrades to an individual user's Cygwin
provision) but it has been, for me at least, a useful rapid check of whether
"what I've got" matches "what is now available".
All I was trying to do was draw attention to (what I perceive to be) suddenly
altered practice, with no change to the setup executable that might have
explained it or caused it. So (a) is it a real change? (easily confirmed, or
not, by anybody with /etc/setup/timestamp reporting < 1590407755 then running
an upgrade, and seeing what happens to /etc/setup/timestamp); and (b) if so, is
it intended? or is it a trivial glitch introduced goodness-knows-how that can
be corrected; and (c) if intended, to provide what improvement? because it
seems to me a bad move.
Fergus
--
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: Current setup timestamp 1590343308
-Original Message- From: marco atzeri [mailto:marco.atz...@gmail.com] Sent: 25 May 2020 13:13 To: Fergus Daly Cc: cygwin@cygwin.com Subject: Re: Current setup timestamp 1590343308 On Mon, May 25, 2020 at 2:08 PM Fergus Daly via Cygwin wrote: > > Current setup timestamp 1590343308 > does not seem to overwrite /etc/setup/timestamp accurately (or at all). > I think /etc/setup/installed.db is seen to as it should be. > Fergus > -- What exactly is your problem ? Be verbose we can NOT guess your thoughts. Unix time: seconds since Jan 01 1970. (UTC) https://www.unixtimestamp.com/index.php Sorry for lack of clarity. Cygwin32. Current installed timestamp 1590341902 (got from /etc/setup/timestamp). I noticed there's a newer setup.ini with timestamp 1590343308. So I ran setup-x86.exe. After a (presumed) successful run I noticed however, that the file /etc/setup/timestamp had not altered. "Presumed successful run" because the file /etc/setup/installed.db had a new, current, timestamp. Fergus (I deleted /etc/setup/timestamp and re-running setup-x86.exe to see whether any self-correcting behaviour would ensue. The file was not recovered.) -- 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: Has rename syntax changed?
> $ rename "anything" "AnyThing" *.ext > What I remember as past behaviour now fails, leaving he filename unaltered. >> Try it with the '-v' option So I did: $ touch "This is the test file" $ ls -al -rw-r--r-- 10 Feb 29 08:10 This is the test file $ rename -v " the " " The " * `This is the test file' -> `This is The test file' $ ls -al -rw-r--r-- 10 Feb 29 08:10 This is the test file Filename unaltered, contrary to verbose confirmation. Just checking: in DOS Command Prompt box, dir also shows filename unaltered. BTW failure consistent on both FAT32 and exFAT filesystems; but the rename command _works_as_expected_ on NTFS. I get the subtle distinctions between FAT (all versions) and NTFS platforms; but, all the same, the rename command surely worked on *FAT* in the past - I would have noticed if it didn't because I toggle lc <> UC quite a lot. Fergus -- 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
Has rename syntax changed?
I am almost certain that the command $ rename "anything" "AnyThing" *.ext would alter the string from lc to uc as shown, anywhere it occurred in any filename in *.ext in the current directory. What I remember as past behaviour now fails, leaving he filename unaltered. (Failure in much the same way as mv would fail if the similar attempt was made.) (Good old DOS command rename (or the abbreviation ren) used to achieve multiple-rename in an easy manner that just eludes bash.) Anyway: has something altered (and quite recently, i think), or am I just mis-remembering the versatility of the command rename? Fergus -- 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: grap, anybody?
>> Try following patch.
--- configure.ac.orig 2014-08-31 00:33:45.0 +0900
+++ configure.ac2020-01-07 08:43:59.559103700 +0900
@@ -45,10 +45,10 @@
AC_MSG_CHECKING(if ${CXX} supports -std=c++0x)
old_cxxflags="$CXXFLAGS"
old_cppflags="$CPPFLAGS"
-CXXFLAGS="$CXXFLAGS -std=c++0x"
-CPPFLAGS="$CPPFLAGS -std=c++0x"
+CXXFLAGS="$CXXFLAGS -D_XOPEN_SOURCE=700"
+CPPFLAGS="$CPPFLAGS -D_XOPEN_SOURCE=700"
AC_TRY_COMPILE([], [], [
- CX0FLAGS="-std=c++0x"
+ CX0FLAGS=""
AC_MSG_RESULT(yes)
], [
CX0FLAGS=""
> Thank you! This patch enabled compilation of the grap-1.45 executable for
> 32-bit and 64-bit Cygwin respectively.
I'm just not up to it, but given the trivial nature of the single required
patch, is there anybody out there who could take this on for the Cygwin
provision?
(There must be 00s of users who need it? I'm truly surprised that grap, or
rather its lack, hasn't had a much higher historical profile in this forum.)
Does it matter that the source files
https://www.lunabase.org/~faber/Vault/software/grap/grap-1.45.tar.gz are
"owned" by somebody else?
(I imagine it does. Just asking.)
--
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: grap, anybody?
>> Try following patch.
--- configure.ac.orig 2014-08-31 00:33:45.0 +0900
+++ configure.ac2020-01-07 08:43:59.559103700 +0900
@@ -45,10 +45,10 @@
AC_MSG_CHECKING(if ${CXX} supports -std=c++0x)
old_cxxflags="$CXXFLAGS"
old_cppflags="$CPPFLAGS"
-CXXFLAGS="$CXXFLAGS -std=c++0x"
-CPPFLAGS="$CPPFLAGS -std=c++0x"
+CXXFLAGS="$CXXFLAGS -D_XOPEN_SOURCE=700"
+CPPFLAGS="$CPPFLAGS -D_XOPEN_SOURCE=700"
AC_TRY_COMPILE([], [], [
- CX0FLAGS="-std=c++0x"
+ CX0FLAGS=""
AC_MSG_RESULT(yes)
], [
CX0FLAGS=""
Thank you! This patch enabled compilation of the grap-1.45 executable for
32-bit and 64-bit Cygwin respectively.
Fergus
--
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
setup -P ..,xinit,.. didn't install twm even though xinit requires twm
Strange recent experience: I made a fresh installation of Cygwin, intending to mimick exactly previous installations, using the command setup -P ,xinit, and then compared the new installation with previous ones. Not quite an exact match: the new installation lacked several entries of the form /bin/cyg*dll, /etc/peremove/*.done, /etc/setup/*gz and others which I won't bother detailing here; but in particular the new installation is missing ALL of the executable /bin/twm.exe the file /etc/setup/twm.lst.gz the directory /usr/share/X11/twm the directory /usr/share/doc/twm the directory/usr/share/man/man1/twm.1.gz and yet: in setup.ini it appears that @ xinit requires: .. twm .. So how is it that twm has been "missed" in the new installation? (I am guessing / hoping that when this conundrum is solved and twm recovered - if that is what the solution entails - then the other missing * files might also be recovered.) Thank you! Fergus -- 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
Wild card to address drives
I have none / cygdrive binary 0 0 as the only line in the file /etc/fstab to allow for example $ ls /h/config.sys instead of the long-hand $ ls /cygdrive/h/config.sys In Linux I can type something like ls /?/ -Ax as a wild card to address ALL drives, but this does not work in Cygwin. Is there a wild card syntax that would? Thank you. Fergus -- 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
Can anybody point me to wish84
Can anybody supply or point me to the Cygwin .tar.xz (or probably .tar.bz2, it will be that ancient) for wish v.8.4? Please, if at all possible, an email attachment or explicit pointer rather than a HowTo would be so much appreciated. (I've tried the Time Machine.) Thank you. Fergus -- 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: Needing the executable grap
>>> I still have grap-1.42.tar.gz and can get the current grap-1.45.tar.gz from
>>> https://www.lunabase.org/~faber/Vault/software/grap/grap-1.45.tar.gz
>>> But I am unable to compile either under the current Cygwin.x86 or under
>>> Cygwin.x86_64.
>> What did you try and what was the error message?
> What errors do you get?
> Pretty often you're just missing required devel packages.
Csaba, Corinna -
Thank you so much for responding.
I use, at the Command Prompt,
setup -P .., bison,flex,gcc-g++,yacc, .. [I think these are the
relevant ones]
to provide a beautifully compact and yet (up to now) fully functional Cygwin
resource.
Then, in Cygwin
./configure
make
I mis-reported.
This sequence works perfectly well in grap-1.42 to create grap.exe but in
grap-1.45, after a successful ./configure step, make yields
make all-am
make[1]: Entering directory '/d/mole/grap-1.45'
g++ -DHAVE_CONFIG_H -I. -std=c++0x -Wall -std=c++0x -g -O2 -std=c++0x
-MT grap.o -MD -MP -MF .deps/grap.Tpo -c -o grap.o grap.cc
grap.yy: In function 'int yyparse()':
grap.yy:582:12: error: 'strptime' was not declared in this scope
if (strptime($5->c_str(), $3->c_str(), ) != 0) {
^~~~
grap.yy:582:12: note: suggested alternative: 'strftime'
if (strptime($5->c_str(), $3->c_str(), ) != 0) {
^~~~
strftime
make[1]: *** [Makefile:496: grap.o] Error 1
make[1]: Leaving directory '/d/mole/grap-1.45'
make: *** [Makefile:380: all] Error 2
I guess you are right that I am missing a package.
Thank you.
Fergus
--
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
Needing the executable grap
Sadly the executable grap is not part of the Cygwin provision. I use a version derived from the same place as the current https://www.lunabase.org/~faber/Vault/software/grap/grap-1.45.tar.gz but actually it is v.1.42 from Goodness knows when and compiled under CYGWIN_NT-6.1 1.5.25(0.156/4/2). It works just fine under W7 and W10 and in the past under XP. It compiled, then, perfectly easily. I still have grap-1.42.tar.gz and can get the current grap-1.45.tar.gz from the location above. But I am unable to compile either under the current Cygwin.x86 or under Cygwin.x86_64. What / where / how do other users requiring grap (in both x86 and x86_64 environments) get it / build it? Can you provide a HowTo? Thank you! Fergus PS I find the requirements for, and utilisation of, ghostscript / gsview / gv incredibly opaque, and suspect I need the same hand-holding there; but I'll try to crack the requirement for grap first. -- 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: readline in Cygwin64?
>> Just installed Cygwin64. Beautiful. >> However, I need to build an executable. In Cygwin32 the build proceeds >> without exception but in Cygwin64 two error msgs are generated during the >> attempt: >> 1) fatal error: readline/readline.h: No such file or directory >> 2) cannot find -lreadline >> Both platforms Cygwin32(64) are identically bespoke and are constructed >> using the command >> setup-x86(_64).exe -P ,readline, >> In Cygwin32 this results in the creation of all 3 files >> /usr/include/readline/readline.h >> /usr/lib/libreadline.a > Cygwin32 has an obsoletion package for "readline" that pulls in the > development headers as the old package had everything bundled. On > Cygwin64 that readline package never existed, so you'll need > libreadline-devel. >> /usr/lib/libreadline.dll.a >> but none of these are created in Cygwin64. This is what breaks the build of >> the executable required. >> (Possibly it is another element of that has this consequence for >> Cygwin32, but whatever the trigger there is the same lack in Cygwin64.) >> Can these necessary components be recovered in Cygwin64 by some amendment to >> the "setup -P .. .." instruction? > cygcheck -p libreadline.dll.a Just brilliant. Solved all. Thank you. -- 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
readline in Cygwin64?
Just installed Cygwin64. Beautiful. However, I need to build an executable. In Cygwin32 the build proceeds without exception but in Cygwin64 two error msgs are generated during the attempt: 1) fatal error: readline/readline.h: No such file or directory 2) cannot find -lreadline Both platforms Cygwin32(64) are identically bespoke and are constructed using the command setup-x86(_64).exe -P ,readline, In Cygwin32 this results in the creation of all 3 files /usr/include/readline/readline.h /usr/lib/libreadline.a /usr/lib/libreadline.dll.a but none of these are created in Cygwin64. This is what breaks the build of the executable required. (Possibly it is another element of that has this consequence for Cygwin32, but whatever the trigger there is the same lack in Cygwin64.) Can these necessary components be recovered in Cygwin64 by some amendment to the "setup -P .. .." instruction? Thank you. Fergus -- 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: Creation of weird WINDOWS-related (sub)directories
>> Just noticed: strange directory %SystemDrive% created at root of Cygwin >> installation: >> As in: >> /consoleX/%SystemDrive% > I doubt it is due to a cygwin program. > "consoleX" does not appear in the package search > https://cygwin.com/cgi-bin2/package-grep.cgi Unintentionally I have confounded the discussion. The directory named "consoleX" is my home-grown Cygwin root directory. (Others' preferred locationname might be "cygwin" or "mycygwin" or whatever.) The directory %SystemDrive% occurs at the root of the Cygwin filesystem. I cannot work out what activity has triggered it .. .. Fergus -- 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
Creation of weird WINDOWS-related (sub)directories
Just noticed: strange directory %SystemDrive% created at root of Cygwin
installation:
As in:
/consoleX/%SystemDrive%
/consoleX/%SystemDrive%/ProgramData
/consoleX/%SystemDrive%/ProgramData/Microsoft
/consoleX/%SystemDrive%/ProgramData/Microsoft/Windows
/consoleX/%SystemDrive%/ProgramData/Microsoft/Windows/Caches
/consoleX/%SystemDrive%/ProgramData/Microsoft/Windows/Caches/cversions.2.db
/consoleX/%SystemDrive%/ProgramData/Microsoft/Windows/Caches/{69CFC75E-EC11-
4152-A489-8B4850814862}.2.ver0x0001.db
/consoleX/%SystemDrive%/ProgramData/Microsoft/Windows/Caches/{6AF0698E-D558-
4F6E-9B3C-3716689AF493}.2.ver0x0001.db
/consoleX/%SystemDrive%/ProgramData/Microsoft/Windows/Caches/{9BF0A9D6-626F-
4F67-8DFA-14BFC3D7213A}.2.ver0x0001.db
/consoleX/%SystemDrive%/ProgramData/Microsoft/Windows/Caches/{DDF571F2-BE98-
426D-8288-1A9A39C3FDA2}.2.ver0x0001.db
Any ideas why? .. how to prevent?
Thank you!
Fergus
--
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
fc-cache-1.exe.stackdump
Just lately getting repeated episodes of this file, located at /, and referring to a STATUS_ACCESS_VIOLATION .. .. program=\usr\libexec\fc-cache-1.exe which I am not knowingly calling. Delete the file and sooner or later (half a day) it's back again: so far I have not identified the trigger for it. Anybody else? Any ideas? Thank you! Fergus -- 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: sed seems to force UC filename on Mixed 8.3 filenames on FAT32
>> I looked for recent similar issues and only found https://superuser.com/questions/1297658/folder-names-become-uppercase-when-syncing-to-fat32-drive >> So if other users of this Win10 build start tripping on this same problem >> and reporting it, it may get looked at by MS. The site you mention also asked about variations in hardware or formatting mechanism. I find the identical behaviour in USB drives (local) and USB sticks (removable). In the past I have used Hitachi Microdrive to render Removable sticks Local, but can't find a version of this driver upgrade for 64-bit. (Not one that works, anyway. Several that don't.) Also identical behaviours whether the filesystem is formatted FAT32 in Windows or formatted FAT32 in Linux. So summarising: SOME (but not ALL) file transactions on FAT32 result in "Mixed case but no spaces 8.3" -> "ALL UPPER CASE 8.3" Examples are sed and dos2unix (and family); but not nano, or joe. I can't think of anything that I could reasonably test on a folder rather than a file to see the effect on foldername. Goodness knows how to upstream anything to MS. Finally, there was another Windows update yesterday, 05-MAR-2018: to version 1709 OS build 16299.251. Hopes of a return to correct behaviours were immediately dashed. :o( Fergus -- 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: sed seems to force UC filename on Mixed 8.3 filenames on FAT32
>> ..."or operation on FAT32 was changed by Windows updates." Starting to look exactly like that. On Windows 7 there is no problem. On earlier W10 machines in this office there is no problem. My machine underwent a massive (time-consuming) update on or around 13-FEB to Microsoft Windows Version 1709 Build 16299.248] from the previous Microsoft Windows Version 1703 Build 15063.936] and the troubles began then: ~> touch TryThis.TxT ~> ls T* TryThis.TxT ~> dos2unix TryThis.TxT dos2unix: converting file TryThis.TxT to Unix format... ~> ls T* TRYTHIS.TXT This on a FAT32 stick. (Can anybody confirm this behaviour?) So I'm guessing Windows has revised its default mount shortname syntax for VFAT. Is there a way I can climb in and alter / override that, does anybody know? Fergus -- 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: sed seems to force UC filename on Mixed 8.3 filenames on FAT32
>> Run stat on original and converted files. OK. I get this: ~> stat /j/PStart.xml File: /j/PStart.xml Size: 7233Blocks: 8 IO Block: 65536 regular file Device: a6418e7fh/2789314175d Inode: 7206475022584976007 Links: 1 Access: (0644/-rw-r--r--) Uid: (197609/ fergusd) Gid: (197609/ fergusd) Access: 2018-03-03 00:00:00.0 + Modify: 2018-03-02 11:50:12.0 + Change: 2018-03-02 11:50:12.0 + Birth: 2018-03-02 09:26:44.06000 + ~> dos2unix.exe /j/PStart.xml dos2unix: converting file /j/PStart.xml to Unix format... ~> stat /j/PSTART.XML File: /j/PSTART.XML Size: 6943Blocks: 8 IO Block: 65536 regular file Device: a6418e7fh/2789314175d Inode: 7206475022584976007 Links: 1 Access: (0644/-rw-r--r--) Uid: (197609/ fergusd) Gid: (197609/ fergusd) Access: 2018-03-03 00:00:00.0 + Modify: 2018-03-03 08:27:16.0 + Change: 2018-03-03 08:27:16.0 + Birth: 2018-03-03 08:27:15.21000 + Does that help at all? It's not so much the behaviour on FAT32, which I could put up with as a filesystem pehenomenon if it had always been the case: but it's just started in the past few days. Can't think what has been updated that would cause this change. Previously sed and dos2unix which I use constantly (and others) did NOT change the case of the filename. Fergus -- 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: sed seems to force UC filename on Mixed 8.3 filenames on FAT32
.. AND dos2unix: ~> ls -al /j/P* -rw-r--r-- 1 dell ferg 6767 Mar 2 09:15 /j/PStart.xml ~> dos2unix /j/PStart.xml dos2unix: converting file /j/PStart.xml to Unix format... ~> ls -al /j/P* -rw-r--r-- 1 dell ferg 6767 Mar 2 09:16 /j/PSTART.XML So something a bit major seems to be going on .. .. Fergus -- 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
sed seems to force UC filename on Mixed 8.3 filenames on FAT32
Noticed just lately that sed seems to force 8.3 (all upper-case) file-naming if applied to 8.3 file on FAT32 filesystem. For example ~> ls -al /j/P* -rw-r--r-- 1 dell ferg 6767 Mar 2 09:15 /j/PStart.xml ~> sed -i '/count/d ; /date/d ; /time/d' /j/PStart.xml ~> ls -al /j/P* -rw-r--r-- 1 dell ferg 6767 Mar 2 09:16 /j/PSTART.XML This used not to happen; and on a exFAT filesystem, the uc/lc Mixed is preserved even if filename is 8.3. FYI ~> uname -sr ; /usr/lib/csih/winProductName.exe CYGWIN_NT-10.0-WOW 2.10.0(0.325/5/3) Microsoft Windows 10 Professional, 64-bit (build 16299) ~> sed --version sed (GNU sed) 4.4 Packaged by Cygwin (4.4-1) Fergus -- 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: cygcheck failing to find file
> For the third time, cygcheck is no Cygwin application, and unaware of Cygwin > paths. > Please give it native Windows paths. Thank you. Thank you. Thank you. [ You are usually so patient. :o( ] It seemed to me that a reasonable interpretation of the phrase >>> I pushed a fix and uploaded new developer snapshots to >>> https://cygwin.de/snapshots/ >>> Please give them a try. was that something might have changed. Clearly an over-interpretation. Fergus -- 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: cygcheck failing to find file
>> Cygcheck is a native Windows executable .. .. >> I pushed a fix and uploaded new developer snapshots to >> https://cygwin.de/snapshots/ >> Please give them a try. I tried your link above but got "HTTP 404 Not found". Just in case this was your intention I tried the latest cygwin1.dll snapshot from https://cygwin.com/snapshots/ being 20180216 but still got > $ cygcheck /d/src/sc.exe > cygcheck: could not find '/d/src/sc.exe' I just tried the 20180220 snapshot; but still get > $ cygcheck /d/src/sc.exe > cygcheck: could not find '/d/src/sc.exe' Fergus -- 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
cygcheck failing to find file
I have an executable (created in Cygwin) located on a mobile drive D: $ ls -al /cygdrive/d/src/sc.exe -rwxr-xr-x 1 ferg dell 1426958 Jan 28 17:44 /cygdrive/d/src/sc.exe* $ cygcheck /cygdrive/d/src/sc.exe d:\src\sc.exe D:\consoleX\bin\cygwin1.dll C:\Windows\system32\KERNEL32.dll # but it all works Now omit the need for /cygdrive/ by writing /etc/fstab as none / cygdrive binary 0 0 and re-start Cygwin. $ ls -al /d/src/sc.exe -rwxr-xr-x 1 ferg dell 1426958 Jan 28 17:44 /d/src/sc.exe* $ cygcheck /d/src/sc.exe cygcheck: could not find '/d/src/sc.exe' Why can't cygcheck find the file? (Particularly, when ls can. And so can, say, md5sum.) -- 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: setup takes a long time
>> $ ./setup-2.884.x86_64.exe --local-install >> '\\necker\download\cygwin-packages' --no-admin --upgrade-also --quiet-mode >> --mirror-mode --no-shortcuts | ts -i Thank you, using ts is really illuminating. As an incidental query: I deduce from the look of the snip above that you update Cygwin from within Cygwin? I have always done so from within a DOS Command Prompt window, believing your way to be fatally flawed. Is your way (much more convenient) ALWAYS OK? What if cygwin1.dll is itself being updated? Fergus PS Or maybe you are using Windows PowerShell or similar. -- 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
setup takes a long time
The setup program does seem to take a long time, even when it just means "update" and even when there's nothing to update. Here's what happens in unattended mode: C:\Users\User0044>D:\cyg\setup-x86.exe -L D:\cyg -R D:\consoleX -Wgqmn Starting cygwin install, version 2.884 User has backup/restore rights Current Directory: D:\cyg Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. root: D:\consoleX system Selected local directory: D:\cyg Changing gid back to original running: D:\consoleX\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash" running: D:\consoleX\bin\dash.exe "/etc/postinstall/0p_texlive_prep.dash" running: D:\consoleX\bin\dash.exe "/etc/postinstall/0p_update-info-dir.dash" running: D:\consoleX\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_adwaita-icon-theme.sh" running: D:\consoleX\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_desktop-file-utils.sh" running: D:\consoleX\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_fontconfig_cache_1.sh" running: D:\consoleX\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_glib2.0.sh" running: D:\consoleX\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_hicolor-icon-theme.sh" running: D:\consoleX\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_man-db.sh" running: D:\consoleX\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_shared-mime-info.sh" running: D:\consoleX\bin\dash.exe "/etc/postinstall/zp_texlive_finish.dash" Changing gid to Administrators Ending cygwin install I can kind of see the point of autorebase and update-info-dir, but why revisit texlive every time, and why all the zp stuff, every time? Why does setup explore McShield and McAfee? Incidentally note the switch -m. Without it, checking sha1sum's I guess provides some kind of protection, but it's incredibly time-consuming and seems quite unnecessarily to cover much more than the files downloaded, even the entire resource? In the presumably very rare event of a broken download, could the update not more simply just abort? -- 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: tcl / tcl-tk updates - two links going nowhere
> The recent updates > tcl-8.6.6-1 ; tcl-tix-8.4.3-3 ; tcl-tk-8.6.6-1 > have induced two links > /lib/tcl8.6/tclConfig.sh -> ../tclConfig.sh > /lib/tk8.6/tkConfig.sh -> ../tkConfig.sh > that lead nowhere. Is there a fix? The two missing t*Config.sh files can be obtained by decompressing tcl-devel-8.6.6-1.tar.xz tcl-tk-devel-8.6.6-1.tar.xz (These two files were not part of the original downloaded update. Should they have been?) Fergus -- 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
tcl / tcl-tk updates - two links going nowhere
The recent updates tcl-8.6.6-1 ; tcl-tix-8.4.3-3 ; tcl-tk-8.6.6-1 have induced two links /lib/tcl8.6/tclConfig.sh -> ../tclConfig.sh /lib/tk8.6/tkConfig.sh -> ../tkConfig.sh that lead nowhere. Is there a fix? Thank you. Fergus -- 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 x86 setup issue:Can't connect to (null):80
>> Oh, I get it. >> You're just saying you update the (partial?) mirror in 'D:\cyg'. >> Sorry for the misunderstanding. Not at all. I guess I wasn't clear. I run [quite a small subset of the complete] Cygwin from D:\consoleX. I maintain the source at D:\cyg by checking it against a mirror regularly - when out of date I wget what's needed including setup.ini and setup.ini.sig. Then update from Local Directory using setup. I'm still nervy of upversioning again to 2.882 from 2.880 but noting your observant "time machine" comment and the dearth of "Me Too" on the mailing list I'll give it another crack. If it works I'll forget it once didn't; if it doesn't work I'll try to dig deeper. Fergus -- 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 x86 setup issue:Can't connect to (null):80
>> .. we are using our internal cygwin mirror >> .. when we setup x86-setup.exe .. it show download incomplete .. >> I thought perhaps setup couldn't handle a nonstandard port .. Not quite certain what is going on but something is, possibly related to the latest recent up-versioning of the setup-x86 executable to 2.882? Forever I have updated Cygwin using a Command Prompt window and the typed command setup-x86.exe -L D:\cyg -R D:\consoleX -gqnm where the key switches are to update to the Cygwin provision located at D:\consoleX from a local mirror located at D:\cyg. (Previously I will have updated x86\setup.ini and x86\setup.ini.sig and augmented x86\release\ so that everything is in place that is needed.) This command now fails, but too early in the process for a logfile to be commenced. Basically the locally-based installation procedure hangs. I changed the command to update conventionally from the internet and everything worked properly: the update occurred without a glitch. Fergus -- 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
Missing python2?
During attempted update today timestamp 1490167294: Error message reads: "Package python has dependency python2 we can't find" Usually dependencies are identified automatically and found and installed. Is there something that I should be doing, or that I should have done? Thank you. Fergus -- 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
Timestamp going backwards
Never seen this before: I updated Cygwin about 5 hours ago using setup.ini with timestamp 1485762241 downloaded from ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/cygwin/x86/setup*ini* Just interrogated the same site again. The timestamp is 1485760326. Perplexing. -- 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: New Cygwin "setup" program useless on my Win-XP box. Not very nice at all.
>> Cygwin installation on XP >> 1. Use the following version of setup*.exe: >> 32-bit: ftp://www.fruitbat.org/pub/cygwin/setup/snapshots/setup-x86-2.874.exe >> 2. Run setup*.exe with the -X option, using the following mirror: >> 32-bit: ftp://www.fruitbat.org/pub/cygwin/circa/2016/08/30/104223 Thank you for this really helpful distillation. I followed the instructions exactly, with the minor and probably unnecessary preparation of using regedit to remove from the registry all mentions of Cygnus / Cygwin (because I have occasionally found that previous installations - or, rather, usages - of Cygwin interfere with the groundwork for new usages). And everything worked - in principle, but not in practice. After initiating setup I selected "Download without Installing", clicked on the roundel to select "All" instead of "Default" in order to achieve a Full download rather than the Base download, and away we went. BUT (a) the download appeared to be very slow, which I attributed to properties of fruitbat.org or even the download site ftp://.../104223 which I guess is in some sense virtual (?); however (b) when I checked things this morning having set the thing going last night, I found that in 6 hours only 2048-cli/, 2048-qt/ and the beginnings of 4ti2/ had been downloaded, i.e. the merest starting fragment of what was anticipated. So: the logic seems just fine, the implementation flawed in some way, or on this occasion. Q1 Any ideas of what might be de-railing this simple operation? Q2 [... virtual(?);] Could one instead use wget on ftp://www.fruitbat.org/pub/cygwin/circa/2016/08/30/104223? This would be easy to initiate, it would avoid the layer of complication induced by setup (and anyway I only want a download, not a setup) and finally - really usefully, since the intention is to build a local mirror and then maybe do something useful with it - it would pull down the *src files, which are a pain in setup, requiring individual ticking of many many checkboxes. But: I tried wget, and just came to a halt with no files found. Thank you. Fergus -- 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: New Cygwin "setup" program useless on my Win-XP box. Not very nice at all.
> WinXP is not supported. Complain as you wish, write as long a posts as you were, it won't change. > If you need old, outdated and unsupported OS, go into old, outdated and unsupported Cygwin Time Machine. Hang on, this is just a bit dismissive. Years ago the Cygwin nobility gave us all loads of warning of the demise of v.1.5 (the last installation that could be used on W95/98); they took fantastic trouble over supplying - and deploying to mirrors - the last relevant sources under release-legacy/ with an associated setup-legacy.ini AND an associated setup-legacy.exe to set the whole thing up. And, finally, seven or more years on, this version is still available: see, for example, http://ftp.uni-kl.de/pub/windows/cygwin/. No such efforts with the last available XP version. Come on, the Time Machine is really hard to navigate. It would have been really helpful to do for XP exactly what was done for 95/98: petrify the last relevant sources along with .ini and .exe, re-label conveniently and obviously, and upload to mirrors. Could this not still be done? Sure, continuing usage of XP carries its own risks, but that's a quite different issue. Fergus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin resource
Bit of a milestone: I think with the current setup 1478562213 the Cygwin installation resource tops 20,000 distinct files for the first time (actually 20,013 under noarch/ and x86/); and, for the first time now or very recently, needs 50G altogether being 20G under noarch/ and 30G under x86 I've no idea what space a full install requires: fwiw my installation including some extras under /home/ and /usr/local/ takes 5G on a hard drive and the identical setup just 1.2G on a stick. Even including TeX, it's tiny. Fergus -- 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
Line ending digits in /etc/setup/installed.db
About 18% of the lines in my /etc/setup/installed.db end in " 1", the rest i.e. large majority end in " 0". Running setup does NOT attempt to re-install the packages identified by " 0". (Strange - that's exactly what I thought it would do ...) The set-up seems to possess full functionality. Can anybody explain / interpret the different endings? Fergus -- 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: wget seems to have lost executive capacity
Thanks very much for advice. I got ~> strace wget --- Process 1216 created --- Process 1216 loaded C:\Windows\System32\ntdll.dll at 7721 --- Process 1216 loaded C:\Windows\System32\kernel32.dll at 7699 --- Process 1216 loaded C:\Windows\System32\KernelBase.dll at 7540 --- Process 1216 loaded M:\CONSOLE7\bin\CYGWIN1.DLL at 6100 --- Process 1216 loaded M:\CONSOLE7\bin\CYGGNUTLS-28.DLL at 67AB --- Process 1216 loaded M:\CONSOLE7\bin\CYGGMP-10.DLL at 6D75 --- Process 1216 loaded M:\CONSOLE7\bin\CYGHOGWEED-2.DLL at 668B --- Process 1216 loaded M:\CONSOLE7\bin\CYGNETTLE-4.DLL at 5CD6 --- Process 1216 loaded M:\CONSOLE7\bin\CYGGCC_S-1.DLL at 6C76 --- Process 1216 loaded M:\CONSOLE7\bin\CYGICONV-2.DLL at 6673 --- Process 1216 loaded M:\CONSOLE7\bin\CYGINTL-8.DLL at 6B2F --- Process 1216 loaded M:\CONSOLE7\bin\CYGP11-KIT-0.DLL at 5CCA --- Process 1216 loaded M:\CONSOLE7\bin\CYGFFI-6.DLL at 6870 --- Process 1216 loaded M:\CONSOLE7\bin\CYGTASN1-6.DLL at 6CB5 --- Process 1216 loaded M:\CONSOLE7\bin\CYGZ.DLL at 5AF1 --- Process 1216 loaded M:\CONSOLE7\bin\CYGIDN-11.DLL at 6166 --- Process 1216 loaded M:\CONSOLE7\bin\CYGPCRE-1.DLL at 6D16 --- Process 1216 loaded M:\CONSOLE7\bin\CYGPSL-5.DLL at 6CE2 --- Process 1216 loaded M:\CONSOLE7\bin\CYGUNISTRING-2.DLL at 5B43 --- Process 1216 loaded M:\CONSOLE7\bin\CYGUUID-1.DLL at 5B40 3 3 [main] wget (1216) ** 92 95 [main] wget (1216) Program name: M:\console7\bin\wget.exe (windows pid 1216) 44 139 [main] wget (1216) OS version: Windows NT-6.1 44 183 [main] wget (1216) ** 114 297 [main] wget (1216) sigprocmask: 0 = sigprocmask (0, 0x0, 0x612B462C) 409 706 [main] wget 1216 open_shared: name shared.5, n 5, shared 0x60FF (wanted 0x60FF), h 0x6C, *m 6 60 766 [main] wget 1216 user_heap_info::init: heap base 0x2000, heap top 0x2000, heap size 0x1800 (402653184) 69 835 [main] wget 1216 open_shared: name S-1-5-21-3115978415-3618363037-3249477967-500.1, n 1, shared 0x60FE (wanted 0x60FE), h 0x68, *m 6 44 879 [main] wget 1216 user_info::create: opening user shared for 'S-1-5-21-3115978415-3618363037-3249477967-500' at 0x60FE 47 926 [main] wget 1216 user_info::create: user shared version AB1FCCE8 771003 [main] wget 1216 fhandler_pipe::create: name \\.\pipe\cygwin-0135e22f5f64b05a-1216-sigwait, size 5412, mode PIPE_TYPE_MESSAGE 1041107 [main] wget 1216 fhandler_pipe::create: pipe read handle 0x80 451152 [main] wget 1216 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-0135e22f5f64b05a-1216-sigwait 751227 [main] wget 1216 fhandler_pipe::create: pipe write handle 0x84 411268 [main] wget 1216 dll_crt0_0: finished dll_crt0_0 initialization --- Process 1216, exception c005 at 6CB5BDE2 --- Process 1216 exited with status 0xc005 Segmentation fault and cannot translate this either as a guide to the cause of the problem, or its solution. Can anybody please provide any insight / instruction? Thank you. Fergus -- 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
wget seems to have lost executive capacity
Just noticed (this has occurred since Tuesday, I think, but I can think of no associated Cygwin update or any other local event): all scripts involving a wget command line move on to the next line as though it had been simply a comment of no executive status. Examples (showing other execs under /bin are not broken): ~> gcc --version gcc (GCC) 5.4.0 ~> ls --version ls (GNU coreutils) 8.25 Packaged by Cygwin (8.25-3) ~> wc --version wc (GNU coreutils) 8.25 Packaged by Cygwin (8.25-3)~> wget --version ~> wget --version ~> ~> IE NIL RESPONSE ~> ls -al /bin/wget* -rwxr-xr-x 1 Administrator None 514589 Jul 11 18:10 wget.exe* If the size is right, is there any explanation for its demise and can I recover its functionality (other than by re-installing?? Thank you! Fergus -- 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
Latest Ghostscript 9.19.1 problematic
I have had huge problems with the presentation of graphics (figures, diagrams, graphs) since the GPL Post script update from 9.15 to 9.19. (Won't go into details as it's external software.) Reverting to 9.15, everything works again except that I am being nagged for a missing fle > GPL Ghostscript 9.15: Can't find initialization file gs_init.ps. Can anybody please point me to an example gs_init.ps file, and where it should be located? Thank you. Fergus I realise the fundamental problem might reside outside Ghostscript and outside Cygwin, but for the moment I am after a fix. -- 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: Syntax for sed .. altered?
>> $ find archive -type f | wc 87 871698 >> $ time find archive -type f | xargs sed -i 's/string1/string2/g' real1m2.587s user0m1.200s sys 0m12.884s >> More than a minute for 90 files is just extraordinary. >> Anybody else having a similar experience? > $ find test -type f |wc 177 1775119 > $ time find test -type f | xargs sed -i -e "s/Octave/Pippo/g" real0m5.149s user0m0.170s sys 0m1.183s BLODA ? All very perplexing. Within and between 3 different machines I get very variable timings of anything from 0m 52s to 3m 08s across 90 files, but never brief. On a 4th machine I get a more or less consistent 8s. Previously I tried reverting to an earlier cygwin1.dll (much earlier: a year) and to the [prev] offering in setup for sed. No difference in experience. On local machines I have reduced all services and cut startup processes to just antivirus (MS Security Essentials or other). No difference. So this is not a consequence of a weird file set or, apparently, a faulty Cygwin installation, but a manifestation of different machine architectures / platforms. All W7 but some 32 some 64. All protected, some differently, but having no congruence with the diverse timings above. Sio far sed is the only operation where extreme sloth is exhibited. A favoured benchtest using a long computation within Cygwin has not suddenly slowed down, and remains consistent +/- 1 second within and between machines. More detective work required, I guess. And any "Me Too"s very gratefully received. Fergus -- 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: Syntax for sed .. altered?
>>> find dirname -type f | xargs sed -i 's/string1/string2/g' >>> .. just hangs. >> sed is unchanged from at least 2013, so it must be something else. > Is is possible that this is related to a change in the Cygwin library? Thank you very much for your interest. I was premature in my assertion that sed "hangs". But it takes a crazy crazy time. I was working on a directory of 6000 text files when I reported as above. This is what happened with a directory of <90 files: ~> find archive -type f | wc 87 871698 ~> time find archive -type f | xargs sed -i 's/string1/string2/g' real1m2.587s user0m1.200s sys 0m12.884s More than a minute for 90 files is just extraordinary. Anybody else having a similar experience? (Thank you again.) Fergus -- 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
Syntax for sed .. altered?
For ages I have been able to run through all the files under a directory changing occurrences of string1 to string2 with the command find dirname -type f | xargs sed -i 's/string1/string2/g' It used to take no time at all for say 6000 files. Now the same command just hangs. The files are all text files, no binaries or anything awkward. Just don't understand it. (By contrast find dirname -type f | xargs md5sum still works just fine. 6000 files in less than a second.) Fergus -- 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
Consequences of mount -c
I have set /bin/mount -c "/" in ~/.bashrc with many subsequent easements in use. In /usr/share/fonts/microsoft/ there are unfortunately multiple links referring to files in /cygdrive/c/Windows/Fonts/; all broken. Similarly in /etc/, several links pointing to files in /cygdrive/c/Windows/System32/drivers/etc/; all broken. I've only just noticed this. I don't much want to remove the mount -c instruction. Is there anything else that can be done to correct things? Fergus -- 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
timestamp 1462839105 iso-codes missing under release/
The latest setup.ini refers to new updates under release/iso-codes but the files and the entire subdirectory including [orev] files is missing on at least 3 mirrors that I tried. Fergus Sent from my BlackBerry 10 smartphone. -- 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
setup.ini.sig failing to verify, timestamp 1458038415
Probably a temporary glitch, same on three mirrors, probably all will be fine at the next update. But it's the first time this has happened AFAIK. Just sharing. Fergus -- 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
Fw: libtermcap.a
Is there a package that includes /lib/libtermcap.a? I've tried Search Packages with nil response so I'm not hopeful but reckoned it worth asking. Thank you. Fergus -- 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: Updated: setup.exe (Release 2.872)
I always install / update Cygwin from a x86/release/ directory located on my hard drive, and kept up to date. The new setup-x86.exe requires setup.ini.sig located in x86/ as well as setup.ini. Easy to manage, but is this additional requirement intentional? Fergus -- 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
