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
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
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
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
Following update to XWin or xorg-server: changed syntax to get a xterm terminal window
For ages I used XWin -nolock -nolisten local -multiwindow xterm -display localhost:0.0 to get a xterm terminal. Following recent updates I get a fatal error: Cannot establish any listening sockets. In the past, updates to XWin have sometimes led to similar difficulties, but I have always managed to iterate to a new successful joint syntax XWin arguments xterm arguments but this time I am totally stymied. Can anybody offer me a working syntax please? Thank you. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Recurrent error message on exiting setup: 0p_000_autorebase.dash exit code 1
Windows 7, Cygwin-32. Lately the error message below occurs on every completion (otherwise successful) of setup-x86. Package: 0/Perpetual 0p_000_autorebase.dash exit code 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: Recurrent error message on exiting setup: 0p_000_autorebase.dash exit code 1
Such a good hint, thank you! I re-installed rebase (and _autorebase) and the problem has gone away. Fergus -Original Message- From: Andrey Repin [mailto:anrdae...@yandex.ru] Sent: 13 April 2015 15:15 To: Fergus Daly; cygwin@cygwin.com Subject: Re: Recurrent error message on exiting setup: 0p_000_autorebase.dash exit code 1 Greetings, Fergus Daly! Windows 7, Cygwin-32. Lately the error message below occurs on every completion (otherwise successful) of setup-x86. Package: 0/Perpetual 0p_000_autorebase.dash exit code 1 What is in logs? -- With best regards, Andrey Repin Monday, April 13, 2015 17:14:48 Sorry for my terrible english... -- 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
md5sums in setup.ini setup-timestamp: 1428012611
Just done a check on md5sums in setup.ini setup-timestamp: 1428012611 Usually the entries are of the style filename filesize md5sum but in setup.ini setup-timestamp: 1428012611 (and also I see earlier, so this is not entirely recent) there are entries of the form install: x86/release/dos2unix/dos2unix-7.2.1-1.tar.xz 218200 d873 . . . . 54c3 (128 characters) source: x86/release/dos2unix/dos2unix-7.2.1-1-src.tar.xz 409100 5db5 . . . . 6c6d (128 characters) Has the checksum convention in setup.ini altered? 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
Compiling nano from source
The editor nano-2.4.0 comes with Cygwin. But recently a patch to nano-2.4.0 has been made available on nano-devel which I would like to try on a Cygwin platform. I'll need to patch nano from source. So I downloaded the source direct from the nano site. Starting with ./configure works fine. Then make proceeds quite energetically for a while but then fails as follows: gcc -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\/usr/local/share/locale\ -DSYSCONFDIR=\/usr/local/etc\ -D_XOPEN_SOURCE=600 -g -O2 -Wall -MT text.o -MD -MP -MF .deps/text.Tpo -c -o text.o text.c text.c: In function 'do_alt_speller': text.c:2667:5: error: unknown type name '__time_t' __time_t timestamp; ^ Makefile:411: recipe for target 'text.o' failed make[2]: *** [text.o] Error 1 make[2]: Leaving directory '/home/user/nano-2.4.0/src' Makefile:395: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/user/nano-2.4.0' Makefile:333: recipe for target 'all' failed make: *** [all] Error 2 It is possible that I have not installed enough of Cygwin: I installed gcc-core and any dependencies but stopped there. (In the past I have had to be explicit about . bison, flex . and some others.) Can anybody offer advice on what package in Cygwin Devel (or other) I might be missing that is preventing compilation of nano from source? Or is there a tweak to the script Makefile that I need to attend to? (Actually it's not obvious to me that src/text.o exists.) 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: Altered behaviour of grep
grep -Pl \xmn used to find files containing the ASCII character mn. For instance grep -PL \x0d or \x0a or usefully \x00. ^ I did mean grep -Pl in both cases. 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
Altered behaviour of grep
grep -Pl \xmn used to find files containing the ASCII character mn. For instance grep -PL \x0d or \x0a or usefully \x00. This seems to have been lost with the current version. Is this an error? If not, can anybody tell me what new syntax will recover the old behaviour? 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
Build script using gcc fails - missing ncurses?
A build script I have used forever containing the line
gcc -o execname ./{various.a} -lncurses
has failed in a new installation today of Cygwin, with the error message
ld: cannot find -lncurses
collect2: error: ld returned 1 exit status
The installation script to build Cygwin has not altered, taking the form
setup-x86 -P (list of packages}
unchanged between old installation, not more than 3 months old and new
installation, today
But a comparison of new installed.db with old installed.db shows that the new
installation lacks various library components that the old installation
possesses, including all of
libncurses10 libncurses10-5.9-20150307-1.tar.bz2 0
libncurses8 libncurses8-5.5-10.tar.bz2 0
libncurses-devel libncurses-devel-5.9-20150307-1.tar.bz2 0
libncursesw-devel libncursesw-devel-5.9-20150307-1.tar.bz2 0
(and a few others besides).
Although the {list of packages} called for the installation 3 months ago and
the installation today is unchanged, something has led to the reduced
provision. Can anybody help me recover whatever is necessary to make the line
gcc ... -lncurses
work as it used to?
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: Build script using gcc fails - missing ncurses?
A build script I have used forever containing the line
gcc -o execname ./{various.a} -lncurses
has failed in a new installation today of Cygwin, with the error message
ld: cannot find -lncurses
collect2: error: ld returned 1 exit status
The installation script to build Cygwin has not altered, taking the form
setup-x86 -P (list of packages}
unchanged between old installation, not more than 3 months old and new
installation, today
PS Adding ',ncurses' to {list of packages} has made no difference: still
getting error message .. cannot find -lncurses.
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
fdisk -l is mute
If util-linux is installed then $ /usr/sbin/fdisk returns a list of options as expected; but choosing one of them $ /usr/sbin/fdisk -l is mute. In the past this has returned filesystem summaries as expected. Windows 7, all up to date. Anybody else? 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
Changed syntax for rename
Following (I think) the recent update of the dll cygwin1.dll it seems that rename old new * no longer works and the cause is the wildcard. You have to use something like rename old new f* and the command might need several invocations with minor variants to achieve all the required changes. Is this change intended? Was the update to cygwin1.dll the cause? Any other consequences that users have found? 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 links
Just noticed the following missing links (and they are quite recent, presumably following some update or other). The last one listed seems particularly weird (redundant?). /usr/i686-pc-mingw32/lib/crt1.o - /usr/i686-pc-mingw32/sys-root/mingw/lib/crt1.o /usr/i686-pc-mingw32/lib/dllcrt1.o - /usr/i686-pc-mingw32/sys-root/mingw/lib/dllcrt1.o /usr/i686-pc-mingw32/lib/gcrt1.o - /usr/i686-pc-mingw32/sys-root/mingw/lib/gcrt1.o /usr/share/man/man1/csh.1 - tcsh.1 /usr/share/man/man1/red.1 - ed.1 /usr/share/terminfo/6a/jfbterm - ../6b/kon /usr/share/terminfo/terminfo - ../share/terminfo 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
Mismatch [1.5] [1.7]: lzip-1.8-1
Two messages sent from the usual home address in the past 24 hourse using Thunderbird have failed to arrive at cygwin at, with no reason for their pushback autodespatched by your postmaster. Interesting: either I have unwittingly changed my TB setup, or (now using AVG) its OK to send accolade is causing some kind of barrier. (Anybody with experience of AVG able to comment?) So here from my work address is the 2nd of the 2. (You are losing nothing by not getting the 1st.) Fergus In setup.ini timestamp 1258779760 install: release/lzip/lzip-1.8-1.tar.bz2 101110 bca3c8d04c4fc90d576b264aaa0a08b7 source: release/lzip/lzip-1.8-1-src.tar.bz2 68215 305bd012b1137907eb41972111d36def In setup-2.ini timestamp 1258809078 install: release/lzip/lzip-1.8-1.tar.bz2 66427 a9edda6f8c04cc644897f8adc5323ce3 source: release/lzip/lzip-1.8-1-src.tar.bz2 68198 12dbe475f1b28bede603bdfac091331b Same version number, different versions? 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
Viewing the file and directory structure in a .iso file
The recent inclusion of cdrkit in Cygwin is marvellous, thank you.
Is there a way that one can view from within Cygwin the file/ directory
structure within a .iso file? In Linux it would be
mkdir {viewingdir}
mount {isofile} -o loop {viewingdir}
find {viewingdir}
or equivalent, but in Cygwin loop is an invalid option to mount.
Thank you.
Fergus
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Many changed md5sum's between timestamps 1207665039 and 1207706406
Hello, There seem to have been many changed md5sum's recently (timestamps above) under _obsolete/ but also under GNOME/, automake/, jpeg/, pkgconfig/. The replacement *.bz2 files are identical (of size 46 with md5sum c616cffee0f344c37fd4e045a7a87054). All ok? Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Old favourite: Terminate batch job (Y/N)?
.. but if your {commandlist 2} contains unmount commands
then it would certainly appear in the bash session
as though the mount commands had never happened, since
they will have been unmounted by the time you get to do
anything in bash.
Exactly right. I thought there was somebody standing behind me all this
time. Creepy.
If you change it to start /wait bash then you should get the
desired
behavior of waiting for the bash process to terminate before
continuing
in the batch file.
Thank you very much. I'll use this next.
A second solution offered in the archives is
.. {as before}
set CYGWIN=tty
bash
.. {as before}
and this certainly seems to work, in that (a) the invitation to
Terminate .. no longer appears; and (b) the preceding {sequence of
mount instructions} survives in the bash process.
But several persons offering this solution also provide gloomy but not
very specific warnings that it is or can be dangerous, causing other
behaviours to be altered. Again, can anybody comment on this as a
solution? (It is now months and in some cases years since the original
postings.)
Thank you.
Fergus
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Byte-order in od -x (Win2K)
Exactly the other way round ... ~ echo abcd | od -tx1 000 61 62 63 64 0a 005 is nice; and, for some purposes ~ echo abcd | od -An -tx1 61 62 63 64 0a (or od -An -tx1 filename) is nicer still. (od -x .. outputs the strange transposition of bytes that you have referred to.) Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Updating more than one copy of Cygwin on the same machine: cautionary note
I hesitate to offer this posting as an instruction or even as a piece of advice, and maybe somebody high in the Cygwin echelons will be able to give it a quality stamp; alternatively having written it down I can see that it might quite likely be obvious to everybody but me. But having been caught out a few times before I recognised what was happening, here goes: If like me you ever have more than one installation of Cygwin hanging off the same machine (say on drives g: and h: where either or both or neither might be portable; or in different locations g/ and h/ on the same drive) then care needs to be taken when updating them. I have discovered through bitter experience that if you update g/ in the usual way by making it the Root Install Directory in setup, and then later seek to update h/ by making it the Root Install Directory in setup _without_first_unmounting_ g/, then immediately (and I don't really know why) the file h/etc/setup/installed.db is overwritten by the existing g/etc/setup/installed.db. As a consequence, your attempt to update h/ will fail with a Nothing needed message. You need to unmount g/ before updating h/ successfully. Moral: use setup only to update the currently mounted installation or to mount a new or existing installation from scratch, never to swap from one current installation to another. (If you do it not once but twice or more too often, then you can all too easily have Cygwin installations all with local files /etc/setup/installed.db reporting them to be up-to-date, when I fact none of them is.) If this is obvious (and having written it down it seems to me something every child would know) I am sorry for wasting your time. I checked it just now by inventing a location h/ where using setup I attempted a new Cygwin build without first unmounting my current installation. It turned out that h/ (containing precisely nothing) was reported as fully up to date, and needing nothing. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup problem persistent?
There was a hint on this list to first install it without the X11 stuff. This indeed seems to work partially. However, when I install everything except the X11 section, some postinstall scripts will complain about missing DLLs. This is not nice. Since the recent emergence of xorg-related problems I've achieved complete glitchless installations in two stages as (i) Base (Default) followed immediately by (ii) the rest (click on Default to change to Install). There's no need to choose anything, worry about dependencies (or even think). Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: A vexing installation problem
Probably a false alarm. Is '.' in your $PATH? No. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
xpdf: error messages
I assume this is the place to comment on the recent provision of xpdf (not cygwin@). Thanks for this. One minor irritation. It doesn't matter what .pdf I choose to view (I've tried many) it turns out that on quitting the successful viewing and before the resumption of the Cygwin prompt, six identical error messages are presented as follows: Warning: XtRemoveGrab asked to remove a widget not on the list Warning: XtRemoveGrab asked to remove a widget not on the list Warning: XtRemoveGrab asked to remove a widget not on the list Warning: XtRemoveGrab asked to remove a widget not on the list Warning: XtRemoveGrab asked to remove a widget not on the list Warning: XtRemoveGrab asked to remove a widget not on the list The version of xpdf provided is v.3.00 Copyright 1996-2004 Glyph Cog LLC. As it happens I have v.2.02p11 from the same source. This is huge (8MB, Goodness knows why) and takes a long time to load but does not present the error msgs after viewing. My fix is to use the command structure xpdf filename.pdf 2/dev/null which effectively mutes the error messages but this is not quite optimal. Thanks. Fergus
Re: How to check your local mirror
Too hasty: the file chk.us that I attached assumes your local file setup.ini and your local directory release/ are both located at /f/Cyg0. Sorry. (Luke's approach looks much more sophisticated.) Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question about moving cygwin to another dirve
Change the mount information in the registry Or, if you are nervy about editing your registry, 1. It looks as though your mount points are still located on c: not g:? At the bash prompt you could try mount just to see what the mount points are. If still c:/.. then try mount -m /bin/mnt.log and then exit Cygwin. To be honest I'm not certain from what you have said whether the file mnt.log will have ended up in the directory c:\Cygwin\bin\ or g:\Cygwin\bin\ but in any case find it, and move to that directory. From there, and in a command window using any editor, change all mentions of c: in the file mnt.log to g:. Then, still in the command window .\umount -c .\umount -A .\bash mnt.log should set your mount points correctly on g: not c:. Or 2. I think you should still find umount in either c:\Cygwin\bin\ or g:\Cygwin\bin\ and from a command window move there and run .\umount -c .\umount -A to get rid of all confusions about where you might or might not be mounted. Then call up http://cygwin.com/setup.exe, press Open not Save, and when the default c:\cygwin is offered change it to g:\cygwin and then proceed to the end of setup. (You might or might not be offered updates, that you can accept or not.) This will recover your mount points. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure: snapshot 20040525
I'm sorry that I can't provide cygcheck output or anything helpful: the entire application (both bash and rxvt -e bash) failed even to start. FYI: start a CMD.EXE, cd c:\cygwin\bin (replace c:\cygwin by the root of your Cygwin installation), and run .\cygcheck.exe. Igor, Thanks. But adopting this approach and running .\cygcheck with 20040525 gave exactly the same Windows-generated error message. I tried your approach with 20040520 and things are fine. Gulp. When I posted the problem I was expecting precisely one me too from somebody before we were ticked off for me tooing. From your helpful suggestion, I conclude that what fails for me works for you, which is a bit of a downer. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Install problem
Can't get list of download sites. Make sure your network settings are correct and try again. After years of successful Cygwin installs/updates both at home and work I moved yesterday to a new workplace and got just this message on attempting a new installation on the office-supplied LAN zero-privilege* God-knows-what machine. I changed from Direct connection to Use IE5 settings at the appropriate point during setup, and everything went smoothly thereafter. (* I can't even format my own USB memory stick.) Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: VIM in rxvt syntax highlighting
The recent installation of vim lacks the default startup file that earlier vesions had. So: place in your home directory (/home/alec/ or whatever) a file called .vimrc (note the dot) containing set nocompatible set backspace=indent,eol,start set backup set history=50 set ruler set background=dark set showcmd set incsearch syntax on set hlsearch or, to make it accessible to all users, put these lines in a file called vimrc (no dot) in the /usr/share/vim/ directory. Hope this helps. (I don't know which lines cause the syntax hghlighting -- probably just line -1? -- but the other lines seem to make vim work in the way I'm used to, anyway.) Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
