Re: Updated: setup.exe (Release 2.867)
On 10/02/15 09:39, Luke Kendall wrote: On 06/02/15 21:23, Corinna Vinschen wrote: On Feb 6 13:05, Luke Kendall wrote: On 06/02/15 05:07, Corinna Vinschen wrote: Hi folks, A new version of Setup, release 2.867, has been uploaded to https://cygwin.com/setup-x86.exe (32 bit version) https://cygwin.com/setup-x86_64.exe (64 bit version) The changes compared to 2.864 are mostly not visible: - There's one fix to the output when mistyping a command line option. - More importantly, Setup now understands SHA512 checksums additionally to MD5 checksums. We're going to switch to using SHA512 checksums in the setup.ini files in a couple of weeks and this requires all of you to use the newer Setup version. Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com. Have fun, Corinna I was just wondering, will you be dropping the md5.sum files from the package directories at the same time? The md5.sum files are created for all ftp dirs on sourceware.org, not only for the Cygwin dirs. Right now we still need the md5.sum files to support people who haven't upgraded setup yet. If the files get removed (not created anymore) at one point is up to the overseers crew. Just this week I noticed that cygwin64-gcc-4.8.3-4-src.tar.xz's md5 checksum in its md5.sum file was incorrect (but its md5 in setup.ini was of course correct). Of course? In fact upset (the script creating the setup.ini files) reads the content of md5.sum and uses the checksums in there if available to create the setup.ini entry. It only computes its own checksum if the md5.sum file is missing the info. So, afaics, in border cases in which a file gets replaced, there is a chance that the setup.ini checksum is incorrect as well. In theory that's not supposed to happen because replacing a distro package should always include bumping the subversion, thus creating a new file and just removing the old one. Hmm, that's interesting. I based what I said on my experience; I've tried to work out how it fits together by looking at the files we get via rsyncing from mirrors. It's not like I've read some reference that describes the Cygwin packaging and release process and procedures (I have a feeling that such a reference would be setup.exe's source code, by I may also be quite mistaken about that). But the mismatches have been so common, and persisted so long, that I (perhaps wrongly) came to the conclusion that relying on the md5.sum file was bad, simply because in all the mismatches I've seen over the last several months (I'm guessing something like six), setup.ini has been correct and the package md5.sum has been wrong; and the error has persisted for many, many days. I suppose another possibility is that we *think* we're rsyncing nightly, and we're not, and it's only the automated consistency check that's really running each night! I'll check into that possibility. Just to close this off: this was indeed the answer. We had rsync-ed -src and debuginfo packages at one point, but they were being excluded those from the nightly updates. (I was unaware of that.) So I was wrong. I apologise for the mistake. luke luke Corinna -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: setup.exe (Release 2.867)
On 06/02/15 21:23, Corinna Vinschen wrote: On Feb 6 13:05, Luke Kendall wrote: On 06/02/15 05:07, Corinna Vinschen wrote: Hi folks, A new version of Setup, release 2.867, has been uploaded to https://cygwin.com/setup-x86.exe (32 bit version) https://cygwin.com/setup-x86_64.exe (64 bit version) The changes compared to 2.864 are mostly not visible: - There's one fix to the output when mistyping a command line option. - More importantly, Setup now understands SHA512 checksums additionally to MD5 checksums. We're going to switch to using SHA512 checksums in the setup.ini files in a couple of weeks and this requires all of you to use the newer Setup version. Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com. Have fun, Corinna I was just wondering, will you be dropping the md5.sum files from the package directories at the same time? The md5.sum files are created for all ftp dirs on sourceware.org, not only for the Cygwin dirs. Right now we still need the md5.sum files to support people who haven't upgraded setup yet. If the files get removed (not created anymore) at one point is up to the overseers crew. Just this week I noticed that cygwin64-gcc-4.8.3-4-src.tar.xz's md5 checksum in its md5.sum file was incorrect (but its md5 in setup.ini was of course correct). Of course? In fact upset (the script creating the setup.ini files) reads the content of md5.sum and uses the checksums in there if available to create the setup.ini entry. It only computes its own checksum if the md5.sum file is missing the info. So, afaics, in border cases in which a file gets replaced, there is a chance that the setup.ini checksum is incorrect as well. In theory that's not supposed to happen because replacing a distro package should always include bumping the subversion, thus creating a new file and just removing the old one. Hmm, that's interesting. I based what I said on my experience; I've tried to work out how it fits together by looking at the files we get via rsyncing from mirrors. It's not like I've read some reference that describes the Cygwin packaging and release process and procedures (I have a feeling that such a reference would be setup.exe's source code, by I may also be quite mistaken about that). But the mismatches have been so common, and persisted so long, that I (perhaps wrongly) came to the conclusion that relying on the md5.sum file was bad, simply because in all the mismatches I've seen over the last several months (I'm guessing something like six), setup.ini has been correct and the package md5.sum has been wrong; and the error has persisted for many, many days. I suppose another possibility is that we *think* we're rsyncing nightly, and we're not, and it's only the automated consistency check that's really running each night! I'll check into that possibility. luke Corinna -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: setup.exe (Release 2.867)
On 06/02/15 17:56, Andrey Repin wrote: Greetings, Luke Kendall! A new version of Setup, release 2.867, has been uploaded to https://cygwin.com/setup-x86.exe (32 bit version) https://cygwin.com/setup-x86_64.exe (64 bit version) The changes compared to 2.864 are mostly not visible: - There's one fix to the output when mistyping a command line option. - More importantly, Setup now understands SHA512 checksums additionally to MD5 checksums. We're going to switch to using SHA512 checksums in the setup.ini files in a couple of weeks and this requires all of you to use the newer Setup version. Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com. Have fun, Corinna I was just wondering, will you be dropping the md5.sum files from the package directories at the same time? I'd be happy to see them disappear from the mirrors - they're an internal thing, right? Just this week I noticed that cygwin64-gcc-4.8.3-4-src.tar.xz's md5 checksum in its md5.sum file was incorrect (but its md5 in setup.ini was of course correct). You're not the first one to notice occasional mirror desyncs. This question has been raised at least once already. Though I'm probably the only person on the planet who cares. :-) It's just an idle question. That's just a desync in mirror. Normally fixes itself in a matter of hours. Actually, our experience is that the errors generally last weeks or even months. E.g. the one I mentioned above has been over a week now. Maybe we simply have bad luck picking mirror sites. :-) P.S. Would be wonderful, if you teach your mail agent to insert proper threading headers. Hopefully that happened simply because I replied to the message on the Announce list, rather than the one from this ML. So this email should be okay. (I'm using TB 31.4, so I think it knows how to do it.) Sorry about that. luke -- WBR, Andrey Repin (anrdae...@yandex.ru) 06.02.2015, 09:50 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
Re: Updated: setup.exe (Release 2.867)
On 06/02/15 05:07, Corinna Vinschen wrote: Hi folks, A new version of Setup, release 2.867, has been uploaded to https://cygwin.com/setup-x86.exe (32 bit version) https://cygwin.com/setup-x86_64.exe (64 bit version) The changes compared to 2.864 are mostly not visible: - There's one fix to the output when mistyping a command line option. - More importantly, Setup now understands SHA512 checksums additionally to MD5 checksums. We're going to switch to using SHA512 checksums in the setup.ini files in a couple of weeks and this requires all of you to use the newer Setup version. Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com. Have fun, Corinna I was just wondering, will you be dropping the md5.sum files from the package directories at the same time? I'd be happy to see them disappear from the mirrors - they're an internal thing, right? Just this week I noticed that cygwin64-gcc-4.8.3-4-src.tar.xz's md5 checksum in its md5.sum file was incorrect (but its md5 in setup.ini was of course correct). Though I'm probably the only person on the planet who cares. :-) It's just an idle question. Regards, luke -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On 27/10/14 23:39, Corinna Vinschen wrote: On Oct 27 09:28, Luke Kendall wrote: On 24/10/14 21:37, Corinna Vinschen wrote: On Oct 24 17:35, Luke Kendall wrote: On 24/10/14 02:43, Corinna Vinschen wrote: [snip] Sure, and I thought you'd prefer the American, but I'm happy to see British spelling. So, so, it's always fun to wake up people with an unusual word [...] And the anwser is, yes, just as on Linux or other UNIXy systems. You have one primary group (None on non-domain machines, default Domain Users on domain machines), and an arbitrary number of supplementary groups. Have a look into the output of `id'. Thanks! 'Cygwin process tree, which[ever?] first process' Hmm. Sounds bad, right? Um, awkward and not quite clear, yes. What I'm trying to say is, if the first process of a process tree found cygserver isn't started, it will not try to ask cygserver again, and it will propagate the lack of cygserver to the child processes, so they will neither try to contact cygserver. If you have a catchy way to phrase this in less words, I'd be quite happy. Btw. In the document I'm talking of the first process of a Cygwin process tree throughout. Is it clear at all what that means? I think your description is reasonably clear. For a Cygwin Terminal session that would be the mintty process. If you have this: Cygwin process 1 starts Cygwin process 2 Cygwin process 2 starts CMD.EXE CMD.EXE starts Cygwin process 3 Cygwin process 3 starts Cygwin process 4 Then you have two Cygwin process trees with Cygwin process 1 and Cygwin process 3 being the first processes in a Cygwin process tree. Is there a better way to phrase this in English? Would it make more sense to use parent or grandparent for the first process? Or any other expression? Hmm. Well, you open the section by saying: The information fetched from file or the Windows account database is cached by the process. The cached information is inherited by child processes. What about if you said: The information fetched (from file or from the Windows account database), is cached by the first process in the process tree. This cached information is inherited by every child process. Uh, that wouldn't be quite right. Every process calling getpwuid and friends caches the account information it got. So if process A starts B, and B starts C, process C inherits the combined cached account information from A and B. Ah. A little later you say: If cygserver is running it will provide passwd and group entry caching for all processes in a Cygwin process tree, which first process has been started after cygserver. Maybe: If cygserver is running, it will provide passwd and group entry caching for all processes in every Cygwin process tree started after cygserver. Sounds much better. But what I hadn't realised until I read your reply, above, was that if you're not running cygserver, that if a Cygwin process is started from a Windows command in a Cygwin process tree, that new Cygwin process is the root of a new Cygwin process tree. I wonder if the opening sentence should therefore say something like: The information fetched from file or the Windows account database is cached by the process. The cached information is inherited by child /Cygwin/ processes. (A Cygwin process invoked from a Windows command, such as CMD.exe, will start a fresh process tree unless /cygserver/ is running.) BTW, you could say root of the process tree, but root tends to get confused with (superuser) root quite easily, so care would be needed. I think first process is pretty clear. Ok, cool. I rephrased the above a bit different: The information fetched from the Windows account database or the /etc/passwd and /etc/group files is cached by the process. The cached information is inherited by Cygwin child processes. A Cygwin process invoked from a Windows command, such as CMD.exe, will start a new Cygwin process tree and the caching starts from scratch (unless cygserver is running, but read on). Is that ok? Yep, it's good and clear IMHO. 'If both[,] files and db are specified' There is a comma already. Or am I looking into the wrong line? Sorry, I was too terse: the comma should be removed: If both files and db are specified... Isn't that ambiguous? What I was trying to say is: If both settings, files and db are specified... Without the comma, the expression both files seems to refer to the passwd and group files, not the setting I'm talking about, and then I'm stumbling over the ... and db I hadn't considered parsing it that way, and you're right. But your phrasing 'If both settings, files and db are specified' is both unambiguous and also reads very naturally. I hope the above is of some help. Very much so. I'm very happy if you guys really care for the documentation. As a developer and as a non-native speaker
Fish 2.1.0 aborted
Sorry, I tried but I couldn't repeat this crash of fish, when I tried it today for the first time. But the diagnostic output from fish was reasonable, so it may help. BTW, startup of fish took at least 30 seconds before anything started happening. luke@PCname:/home/luke $ fish Welcome to fish, the friendly interactive shell Type help for instructions on how to use fish bind: Key with name 'dc' does not have any mapping bind: Key with name 'ppage' does not have any mapping bind: Key with name 'npage' does not have any mapping luke@CID ~ ls _gimp1.2/ [...] wk/ # Next, I typed nf (maybe: nfRETURN) and this is what happened: luke@CID ~ nWarning: exec_subshell called off of main thread. Break on debug_thread_error to debug. luke@CID ~ nf pthread_mutex_unlock(lock_obj) failed on line 2243 in file common.cpp: 2 (No such file or directory) Aborted luke@PCname:/home/luke $ fish luke@CID ~ ls [...] wk/ # But I was unable to reproduce the crash, as you can see: luke@CID ~ nWarning: exec_subshell called off of main thread. Break on debug_thread_error to debug. luke@CID ~ nf fish: Unknown command 'nf' luke@CID ~ nWarning: exec_subshell called off of main thread. Break on debug_thread_error to debug. luke@CID ~ nWarning: exec_subshell called off of main thread. Break on debug_thread_error to debug. luke@CID ~ nWarning: exec_subshell called off of main thread. Break on debug_thread_error to debug. luke@CID ~ nWarning: exec_subshell called off of main thread. Break on debug_thread_error to debug. luke@CID ~ nf-config $ fish --version fish, version 2.1.0 This is on a 32 bit version of Cygwin (installed from about the Oct 2 2014 version of Cygwin). I just thought I'd report this, FWIW. luke -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On 24/10/14 21:37, Corinna Vinschen wrote: On Oct 24 17:35, Luke Kendall wrote: On 24/10/14 02:43, Corinna Vinschen wrote: On Oct 22 20:57, Tom Schutter wrote: On Wed 2014-10-22 11:23, Corinna Vinschen wrote: For your convenience I wrote new documentation. Since this is a TEST [snip] 'Logon SIDs: The own[huh? owner's? user's?] LogonSid is converted' The logon SID of the current session. I rephrased this now to: Logon SIDs: The LogonSid of the current user's session is converted ... That's clear. 'if the AD administrators chose an unreasonable[unreasonably] small' 'which keeps an analogue value of the trustPosixOffset' -- 'which keeps an analog of the trustPosixOffset' British vs. American English... Sure, and I thought you'd prefer the American, but I'm happy to see British spelling. But the main point was to drop the word value. A is an analog of B, not an analog /value/ of B. 'how do we uniquely differ[distinguish] between them by name?' 'very costly (read: slow) sea[r]ch operations' (By the way, if you want to belong to multiple groups, is the only way to do this via an /etc/group file? You mean via the gr_mem field? That's not evaluated anymore. Group membership is stored in SAM or AD. No, I was just wondering: does AD allow you to be in multiple groups? It must, I suppose. (It was an idle question, not really on the subject of the documentation.) Also, it occurs to me that another way to store the unix home dir, etc., would be a 'partial passwd' file that omitted the fields for the parts supplied easily by AD (SID, GID)? That's just an idle thought.) But that means you have to read the files again. Thre's not much of an advantage to having full passwd and group files then for the user, nor for Cygwin itself. Plus, you have to implement two different reading algos per file type. True. Forget it, dumb idea. 'Cygwin process tree, which[ever?] first process' Hmm. Sounds bad, right? Um, awkward and not quite clear, yes. What I'm trying to say is, if the first process of a process tree found cygserver isn't started, it will not try to ask cygserver again, and it will propagate the lack of cygserver to the child processes, so they will neither try to contact cygserver. If you have a catchy way to phrase this in less words, I'd be quite happy. Btw. In the document I'm talking of the first process of a Cygwin process tree throughout. Is it clear at all what that means? I think your description is reasonably clear. For a Cygwin Terminal session that would be the mintty process. If you have this: Cygwin process 1 starts Cygwin process 2 Cygwin process 2 starts CMD.EXE CMD.EXE starts Cygwin process 3 Cygwin process 3 starts Cygwin process 4 Then you have two Cygwin process trees with Cygwin process 1 and Cygwin process 3 being the first processes in a Cygwin process tree. Is there a better way to phrase this in English? Would it make more sense to use parent or grandparent for the first process? Or any other expression? Hmm. Well, you open the section by saying: The information fetched from file or the Windows account database is cached by the process. The cached information is inherited by child processes. What about if you said: The information fetched (from file or from the Windows account database), is cached by the first process in the process tree. This cached information is inherited by every child process. A little later you say: If cygserver is running it will provide passwd and group entry caching for all processes in a Cygwin process tree, which first process has been started after cygserver. Maybe: If cygserver is running, it will provide passwd and group entry caching for all processes in every Cygwin process tree started after cygserver. But what I hadn't realised until I read your reply, above, was that if you're not running cygserver, that if a Cygwin process is started from a Windows command in a Cygwin process tree, that new Cygwin process is the root of a new Cygwin process tree. I wonder if the opening sentence should therefore say something like: The information fetched from file or the Windows account database is cached by the process. The cached information is inherited by child /Cygwin/ processes. (A Cygwin process invoked from a Windows command, such as CMD.exe, will start a fresh process tree unless /cygserver/ is running.) BTW, you could say root of the process tree, but root tends to get confused with (superuser) root quite easily, so care would be needed. I think first process is pretty clear. 'If both[,] files and db are specified' There is a comma already. Or am I looking into the wrong line? Sorry, I was too terse: the comma should be removed: If both files and db are specified... 'Cygwin will always try the files first, then the db. ' -- is that because the db will always be more trustworthy than the files? It's
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On 24/10/14 02:43, Corinna Vinschen wrote: On Oct 22 20:57, Tom Schutter wrote: On Wed 2014-10-22 11:23, Corinna Vinschen wrote: For your convenience I wrote new documentation. Since this is a TEST prerelease, the new documentation is not part of the official docs yet. Rather have a look at https://cygwin.com/preliminary-ntsec.html machine is no domain member - machine is not a domain member Thanks, I applied this as patch. Corinna Obviously, all the URLs for the section called “Mapping Windows accounts to POSIX accounts” will become correct when the file is renamed from preliminary-ntsec.html to ntsec.html. But in the section where you talk about the 'problem with the definition of a correct ACL which disallows mapping of certain POSIX permissions cleanly', previously the URL referenced immediately after that text appeared as 'the section called The POSIX permission mapping leak ', but now it's yet another reference to 'the section called “Mapping Windows accounts to POSIX accounts”' -- Is that a mistake? Other suggestions/notes: 'One of them is that the idea to have always small files is flawed.' -- 'One of them is that the idea that these files will always be small, is flawed.' 'so we rely on some mechanism to convert SIDs to uid/gid values and vice versa' -- 'so we need a mechanism to convert SIDs to uid/gid values and vice versa' 'It allows [us] to generate uid/gid values ' 'Read /etc/passwd and /etc/group files [if they exist], just as in the olden days' 'If [the passwd or group] files are present, they will be scanned on demand' 'Logon SIDs: The own[huh? owner's? user's?] LogonSid is converted' 'if the AD administrators chose an unreasonable[unreasonably] small' 'which keeps an analogue value of the trustPosixOffset' -- 'which keeps an analog of the trustPosixOffset' 'how do we uniquely differ[distinguish] between them by name?' 'very costly (read: slow) sea[r]ch operations' (By the way, if you want to belong to multiple groups, is the only way to do this via an /etc/group file? Also, it occurs to me that another way to store the unix home dir, etc., would be a 'partial passwd' file that omitted the fields for the parts supplied easily by AD (SID, GID)? That's just an idle thought.) 'Cygwin process tree, which[ever?] first process' 'is not running a[t] the time' 'via an undocumented API[,] an applications[application] can fetch' 'When Cygwin stat's[stats, or: stat()s] files' 'If both[,] files and db are specified' 'Cygwin will always try the files first, then the db. ' -- is that because the db will always be more trustworthy than the files? BTW, the POSIX permission mapping leak used to have a section heading; it's now just unmarked, inside the File Permissions section. (I'm just pointing that out.) Hope this helps! You've obviously put a lot of thought and effort into all this: thanks. luke -- 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: pngquant md5 mismatch?
On 14/07/14 12:15, Christopher Faylor wrote: On Mon, Jul 14, 2014 at 11:05:48AM +1000, Luke Kendall wrote: For a few days now, mirrors.kernel.org has had a mismatch in the md5sum for the component pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 in the pngquant package in the x86_64 architecture: $ grep pngquant-2.0.20130820+git1e28372-1-src.tar.bz [path-omitted]/cygwin-nightly/x86_64/setup.ini source: x86_64/release/pngquant/pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 205502 ddf6b09472bb55ca46ab90f1f965572c $ md5sum [path-omitted]/cygwin-nightly/x86_64/release/pngquant/pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 2c12df64c780640f38c7e4f78ee9 [path-omitted]/cygwin-nightly/x86_64/release/pngquant/pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 I just downloaded the file manually and don't see any problem. The md5sum is correct. You're right. We seem to have an interesting problem at our end, for that single file. (We have the x86 component duplicated in the x86_64 for that single file only: size, date, data.) Thanks, Christopher. luke -- 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: pngquant md5 mismatch?
On 15/07/14 00:20, Christopher Faylor wrote: On Mon, Jul 14, 2014 at 06:33:14PM +1000, Luke Kendall wrote: On 14/07/14 12:15, Christopher Faylor wrote: On Mon, Jul 14, 2014 at 11:05:48AM +1000, Luke Kendall wrote: For a few days now, mirrors.kernel.org has had a mismatch in the md5sum for the component pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 in the pngquant package in the x86_64 architecture: $ grep pngquant-2.0.20130820+git1e28372-1-src.tar.bz [path-omitted]/cygwin-nightly/x86_64/setup.ini source: x86_64/release/pngquant/pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 205502 ddf6b09472bb55ca46ab90f1f965572c $ md5sum [path-omitted]/cygwin-nightly/x86_64/release/pngquant/pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 2c12df64c780640f38c7e4f78ee9 [path-omitted]/cygwin-nightly/x86_64/release/pngquant/pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 I just downloaded the file manually and don't see any problem. The md5sum is correct. You're right. We seem to have an interesting problem at our end, for that single file. (We have the x86 component duplicated in the x86_64 for that single file only: size, date, data.) In case it isn't obvious, your nonstandard use of Cygwin mirrors is not something that should be debugged in this mailing list. If you have problems running setup*.exe then those will need to be fixed. Otherwise, please don't send problem reports like this here unless you can confirm that they actually affect people who are attempting to install Cygwin in the standard way. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Sigh. Yes, I know it's unusual to check a regular Cygwin rsync through an automated process rather than via a manual, GUI-driven method. Thank you for taking the time to investigate in this instance. It did not occur to me that one file out of 12,000 might have been copied to the wrong location, so I *assumed* it would be a problem that would affect people who attempted to install Cygwin via setup.exe. You're quite right, I should also have checked the mirror directly, as you did. luke -- 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
pngquant md5 mismatch?
For a few days now, mirrors.kernel.org has had a mismatch in the md5sum for the component pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 in the pngquant package in the x86_64 architecture: $ grep pngquant-2.0.20130820+git1e28372-1-src.tar.bz [path-omitted]/cygwin-nightly/x86_64/setup.ini source: x86_64/release/pngquant/pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 205502 ddf6b09472bb55ca46ab90f1f965572c $ md5sum [path-omitted]/cygwin-nightly/x86_64/release/pngquant/pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 2c12df64c780640f38c7e4f78ee9 [path-omitted]/cygwin-nightly/x86_64/release/pngquant/pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 Has the x86 source component been copied into the x86_64 directory? It matches the md5 sum for the source .tar.bz2 from the x86 directory: $ grep pngquant-2.0.20130820+git1e28372-1-src.tar.bz [path-omitted]/cygwin-nightly/x86/setup.ini source: x86/release/pngquant/pngquant-2.0.20130820+git1e28372-1-src.tar.bz2 172075 2c12df64c780640f38c7e4f78ee9 Regards, luke -- 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: Observations about Cygwin's md5 checksums
On 07/07/14 20:05, Marco Atzeri wrote: On 07/07/2014 06:38, Luke Kendall wrote: Here are five observations about md5 checksums in Cygwin. I share it in case it may be of some small interest to a few people. Please note that I may be wrong; if so, I'm happy to be corrected. 1) For each package, Cygwin stores the md5sum for the components of the main parts of the package in the setup.ini file. The exception is the setup.hint file: its md5 sum is not recorded in setup.ini. setup.ini is built using the setup.hint's of the several packages. No further usage outside the www.cygwin.com server. Thanks for the explanation, Marco. Can I check what you mean? I think you're saying that setup.hint has no function once setup.ini has been created. (You're not saying setup.ini shouldn't be used for other purposes.) 2) In each zip file for each package, an md5.sum file is almost always provided. But not always. (*) 3) These md5.sum files list all the components of the package (including setup.hint), but these md5 sums are not reliable: they often don't match the actual md5 checksum (of the file itself, or of course the md5 stored for it in setup.ini).(**) during upload of new files the creation of md5.sum is out of sync with the directory content. Md5.sum is updated 1 time per hour If the mirror sync before the creation of the md5sum it has still the old version. Does that mean that if the md5.sum file were created at the same time that the package contents were updated, there would be no possible way for out-of-sync md5.sum files to be provided? Do you think the current process could be improved? I have observed that the errors in the mirrors persist for weeks or more. Anyway, by changing our checking process to use the information in setup.ini instead of the md5.sum files which can be wrong (for many weeks), we can bypass the incorrect md5.sum files. 4) The most common file to have the wrong md5 checksum is setup.hint 5) It's not rare for files to be mentioned in a package's md5.sum which are be absent from the package itself.(***) I'm curious about the purpose of having the md5.sum file in each package. Is it a relic of a previous system? The above observations are based on a few weeks of mirroring and automatically checking the md5 sums of what we downloaded. The main site we used was aarnet.edu.au (IIRC); recently we changed to mirrors.kernel.org, but from my ad hoc checks there wasn't much difference between the two). Regards, luke (*) For mirrors.kernel.org last night: Worrying: X11/khronos-opengl-registry has no md5.sum file Worrying: X11/xlaunch has no md5.sum file Worrying: cygwin64-gcc/cygwin64-gcc-debuginfo has no md5.sum file Worrying: git/git-oodiff has no md5.sum file Worrying: git/stgit has no md5.sum file Worrying: git/tig has no md5.sum file Worrying: man has no md5.sum file Worrying: python/python-paramiko has no md5.sum file some of this directory does not exist anymore on www.cygwin.com Fair enough. But from what you explained above, it seems strange that no md5.sum file exists. Is it another problem caused by not providing the updated md5.sum file at the same time that a package is updated? I wonder if there's a race condition: files in the package are updated, one by one, the md5.sum file removed, the new md5 sums computed and the file written - and in the meantime, someone may have mirrored the partially-updated package? (**) $ grep FAILED [path-omitted]/x86/cygwin-archive-incomplete.txt | wc 55 1101463 $ grep ^setup.hint: FAILED [path-omitted]/x86/cygwin-archive-incomplete.txt | wc 28 56 560 (***) $ wc -l [path-omitted]/x86/cygwin-archive-all-missing-files.txt 406 Regards MArco -- 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 Thanks for taking the time to explain, Marco. regards, luke -- 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
Observations about Cygwin's md5 checksums
Here are five observations about md5 checksums in Cygwin. I share it in case it may be of some small interest to a few people. Please note that I may be wrong; if so, I'm happy to be corrected. 1) For each package, Cygwin stores the md5sum for the components of the main parts of the package in the setup.ini file. The exception is the setup.hint file: its md5 sum is not recorded in setup.ini. 2) In each zip file for each package, an md5.sum file is almost always provided. But not always. (*) 3) These md5.sum files list all the components of the package (including setup.hint), but these md5 sums are not reliable: they often don't match the actual md5 checksum (of the file itself, or of course the md5 stored for it in setup.ini).(**) 4) The most common file to have the wrong md5 checksum is setup.hint 5) It's not rare for files to be mentioned in a package's md5.sum which are be absent from the package itself.(***) I'm curious about the purpose of having the md5.sum file in each package. Is it a relic of a previous system? The above observations are based on a few weeks of mirroring and automatically checking the md5 sums of what we downloaded. The main site we used was aarnet.edu.au (IIRC); recently we changed to mirrors.kernel.org, but from my ad hoc checks there wasn't much difference between the two). Regards, luke (*) For mirrors.kernel.org last night: Worrying: X11/khronos-opengl-registry has no md5.sum file Worrying: X11/xlaunch has no md5.sum file Worrying: cygwin64-gcc/cygwin64-gcc-debuginfo has no md5.sum file Worrying: git/git-oodiff has no md5.sum file Worrying: git/stgit has no md5.sum file Worrying: git/tig has no md5.sum file Worrying: man has no md5.sum file Worrying: python/python-paramiko has no md5.sum file (**) $ grep FAILED [path-omitted]/x86/cygwin-archive-incomplete.txt | wc 55 1101463 $ grep ^setup.hint: FAILED [path-omitted]/x86/cygwin-archive-incomplete.txt | wc 28 56 560 (***) $ wc -l [path-omitted]/x86/cygwin-archive-all-missing-files.txt 406 -- 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: how to select all src packages too?
On 02/18/2014 08:26 PM, Andrey Repin wrote: Greetings, Luke Kendall! It's great that Cygwin has so many packages. And setup.exe makes it easy to select the packages you want. But it seems quite difficult to also select all the corresponding source packages as well, simply because there are so many packages! In the worst case, where you want every package, and all the source packages too, surely you don't have to scroll and click 3,000-odd times in the UI to select them all? But I haven't found a way to do it through setup. Sorry if this is a dumb question. I have searched, but couldn't find an answer. This is a known deficiency of a Cygwin setup. However, how many source packages you ACTUALLY, REALLY need to download? -- WBR, Andrey Repin (anrdae...@yandex.ru) 18.02.2014, 13:24 Sorry for my terrible english... I imagine others have suggested that the UI for the missing functionality could be as simple as a checkbox to include source package for all packages selected. We actually, really needed to download all the source packages, because we need to be able to check the licenses, and the licenses can often only be found by looking in the source packages. We worked around the problem by rsync-ing the whole thing, in the end. Thanks for confirming that it wasn't a dumb question, Andrey! Regards, luke -- 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: how to select all src packages too?
It's great that Cygwin has so many packages. And setup.exe makes it easy to select the packages you want. But it seems quite difficult to also select all the corresponding source packages as well, simply because there are so many packages! In the worst case, where you want every package, and all the source packages too, surely you don't have to scroll and click 3,000-odd times in the UI to select them all? But I haven't found a way to do it through setup. Sorry if this is a dumb question. I have searched, but couldn't find an answer. luke -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.28-2
On 02/10/2014 07:34 AM, Corinna Vinschen wrote: The 64 bit Cygwin distribution doesn't yet come with as many packages as the 32 bit version, but more packages will be available over time. You're going to be repeating that same message for some time, I reckon, Corinna! The following small idea might add some interest, show the approaching tipping point, and might even motivate some people to help with some 64 bit packages. Assuming you have the number of packages handy, you could replace the above wording with something like this: The 64 bit Cygwin distribution now has $num_pk_64 packages, compared with $num_pk_32 in the 32 bit version. Regards, luke -- 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's 'Retrieve' package selection option?
By experimentation, I worked out how to do something I wanted to do, which involved using the Retrieve option when selecting packages in Cygwin. But I couldn't find any documentation for Retrieve in: https://sourceware.org/cygwin/cygwin-ug-net/setup-net.html http://cygwin.com/faq/ Is there somewhere else I should have looked? A Google search of Cygwin setup retrieve, also didn't turn up anything useful that I could see. In case it helps, below are the notes I made for myself for the task I needed to perform. Cheers, luke How to get an updated package set - To get an updated set of Cygwin packages based on an earlier installed set, run setup and choose Download from Internet. If you have Curr selected and click on View, you get different views. One of these is a view that just shows what is available for upgrade. Choosing all those, and clicking the src box to also get the source is sensible. (Source is required because many packages don't include the license files in the binary packages, only in the src package.) However, that's not enough: doing the above will omit all the packages that don't have a new version to install. For convenience of automated license checking, it's best to do the above (since that's quite clear, simple, and straightforward), but then to click on View until you get a slightly longer view (maybe twice as long), that shows you a whole bunch of packages which will be marked as Keep. It does that since they're already downloaded. However, because the automated license checker unpacks source files and the binary packages, you don't want to rely on merging a pristine copy of the older Cygwin download set with the newer set: it's clearly safer to just down a fresh set of everything that you need. So you need to run down all the packages in this view, too, and click on Keep until you have chosen Retrieve instead. Also click on the src box after that to include the source too, as usual. Then proceed to download. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: cygcheck-dep-1.1-1
On 11/15/2013 09:06 AM, Mikhail Usenko wrote: * A warning is printed out if an installed package denotes a required package which is not installed. I assume this means: a warning is printed if an installed package depends on a required package that is not installed. I assumed setup installed required packages for all the packages you'd selected, so I'm curious. luke -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: New package: openjpeg-1.5.0-1
Yaakov (Cygwin/X) wrote: The following packages have been added to the Cygwin distribution: *** openjpeg-1.5.0-1 *** libopenjpeg1-1.5.0-1 *** libopenjpeg-devel-1.5.0-1 The OpenJPEG library is an open-source JPEG 2000 codec written in C language. I'm no expert, but I thought any JPEG 2000 implementation required use of patented technologies. Do the implementers make some statement about the patent situation for openjpeg? Regards, luke -- 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: Contributing license information?
Christopher Faylor wrote: On Mon, Oct 31, 2011 at 04:27:17PM +1100, Luke Kendall wrote: Those are further reasons I think it's more elegant to add the license info to the setup.ini file. But is the setup.ini creation currently automated? If so there will be some occasions where the license info can't be automatically updated (and will require some human thought to fill in details). What do you think? I'm not interested in trying to figure out an automated way to add a new field to setup.ini I don't know enough about setup.ini to understand why that's hard (my script can already do it), but I accept it. and I'm not interested in modifying setup.exe to deal with the new field. Although it sounds easy to me (since the info's not for setup and so setup should ignore the extra info), I don't know how setup's written, and you're the boss, so what you say, goes! One of the above is a showstopper so you're going to have to do what others have suggested and put the information in the packages. cgf Okay, that's blunt but quite clear. So we'll go ahead with the other approach. luke -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem 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: Contributing license information?
David Sastre wrote: On Tue, Oct 25, 2011 at 03:50:45PM +0200, Corinna Vinschen wrote: On Oct 25 12:00, Luke Kendall wrote: Corinna Vinschen wrote: On Aug 19 11:09, Luke Kendall wrote: Soon, I will have prepared a list of the location of every license file in every Cygwin package. My motivation is to make it easy for people to find the license information, if they need it. (Preparing this information has required a lot of work on my part, so I would be happy if something could be done to make it easy to keep the information up to date as packages are added and modified.) What is the best way to contribute the license-location information so it can be integrated into Cygwin? Just create a new package for the distro which keeps the information and maintain it. Somebody will have to keep the information up to date anyway. Is usr/share/doc/common-licenses/ within the base-files package, supposed to be the place where all license information is collected? Should I just use that instead of creating a new package? Sure, why not, if that's ok with David. You can also rip out the usr/share/doc/common-licenses directory from base-files and create a licenses package with all licenses. Just as you two want it. There's also another solution: include licensing information within base-files, and co-mantain it. It's already under version control. Luke, if it's ok with you, I'd go this way. Maybe. Before I agree, let me be frank and say that I would still prefer for the license information to be stored in the setup.ini information for each package in a licenses: section, and I would love to see the Cygwin package submission process to include the adding of the license information as an explicit step. But, if that's not possible/acceptable, then I think the above proposal is a reasonable workaround, even though it means more work overall, especially ongoing work. I also don't look forward to maintaining the information, but I'm prepared to wait and see how much work it is. If I can automate the effort required for updates, then that would be a good result. So, I agree with Dave's suggestion. Should we try to clarify what we mean by licensing information? I think it includes: 1) (Each version of) the licenses themselves (in whatever form they are provided: .txt, PDF, ...) 2) Information about what licenses are used in each package (including which version of the license) 3) To achieve (2), that means we have to have some way (a name) to refer to each license. Let's also think about how and when the license information gets updated. It may need updating when any package is updated, since it is possible that the license can change as part of a version change. (The change could be a change to the wording, or it could be a shift to a new version of a license, or the inclusion of other sub-components with their own license, etc. etc.) But that means base-files may need to change on a daily basis. There will probably be a time lag in updating the license info if it is not updated at the same time that setup.ini is updated with the new packages. Is setup.ini re-created automatically when a package is updated? The problem gets more complex if you consider that setup.ini can refer to multiple package versions, and there may have been license changes between the versions. Those are further reasons I think it's more elegant to add the license info to the setup.ini file. But is the setup.ini creation currently automated? If so there will be some occasions where the license info can't be automatically updated (and will require some human thought to fill in details). What do you think? Regards, luke -- 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
base-files license?
In the base-files package, what license applies to the small number of
*actual shell scripts and skeleton files* under
etc/{defaults,postinstall, preremove}?
Is it, perhaps, one of the common licenses that are collected together
and stored in base-files? If so, which one?
Regards,
luke
--
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: Contributing license information?
Corinna Vinschen wrote: On Aug 19 11:09, Luke Kendall wrote: Soon, I will have prepared a list of the location of every license file in every Cygwin package. My motivation is to make it easy for people to find the license information, if they need it. (Preparing this information has required a lot of work on my part, so I would be happy if something could be done to make it easy to keep the information up to date as packages are added and modified.) What is the best way to contribute the license-location information so it can be integrated into Cygwin? Just create a new package for the distro which keeps the information and maintain it. Somebody will have to keep the information up to date anyway. Corinna Is usr/share/doc/common-licenses/ within the base-files package, supposed to be the place where all license information is collected? Should I just use that instead of creating a new package? Regards, luke -- 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: Contributing license information?
Corinna Vinschen wrote: On Oct 20 14:48, Luke Kendall wrote: Corinna Vinschen wrote: On Aug 19 11:09, Luke Kendall wrote: Soon, I will have prepared a list of the location of every license file in every Cygwin package. My motivation is to make it easy for people to find the license information, if they need it. (Preparing this information has required a lot of work on my part, so I would be happy if something could be done to make it easy to keep the information up to date as packages are added and modified.) What is the best way to contribute the license-location information so it can be integrated into Cygwin? Just create a new package for the distro which keeps the information and maintain it. Somebody will have to keep the information up to date anyway. Corinna Is usr/share/doc/common-licenses/ within the base-files package, supposed to be the place where all license information is collected? Should I just use that? It's a good place for this, yes. I only today noticed http://www.cygwin.com/ml/cygwin-apps/2004-06/msg00275.html I believe usr/share/doc/common-licenses/ lists many licenses that are not used in the base-files package. That was not the intention. The intention was to collect licenses used by the sum of Cygwin distro packages. Okay. So in reply to your later email, I will plan to provide the added information about licenses into the base-files package, instead of creating a new one. (I hope I have understood you correctly!) Can I ask a related question: for the few shell scripts and /etc files provided in base-files: what license are they under? The package contains lots of licenses, as we've been discussing, but I couldn't find any indication of which license applies to the actual non-license files in base-files itself! Regards, luke Corinna -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Contributing license information?
Corinna Vinschen wrote:
On Aug 19 11:09, Luke Kendall wrote:
Soon, I will have prepared a list of the location of every license
file in every Cygwin package. My motivation is to make it easy for
people to find the license information, if they need it.
(Preparing this information has required a lot of work on my part,
so I would be happy if something could be done to make it easy to
keep the information up to date as packages are added and modified.)
What is the best way to contribute the license-location information
so it can be integrated into Cygwin?
Just create a new package for the distro which keeps the information
and maintain it. Somebody will have to keep the information up to date
anyway.
Corinna
Is usr/share/doc/common-licenses/ within the base-files package,
supposed to be the place where all license information is collected?
Should I just use that?
I only today noticed
http://www.cygwin.com/ml/cygwin-apps/2004-06/msg00275.html
I believe usr/share/doc/common-licenses/ lists many licenses that are
not used in the base-files package. I say that because it contains over
a dozen licenses, even though base-files otherwise just contains a few
shell scripts and skeleton files from etc/{defaults,postinstall, preremove}.
What do you think?
Regards,
luke
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin now licensed under GPLv3+
Corinna Vinschen wrote: Hi Cygwin friends and users, I'm happy to announce that, effective immediately, Red Hat has relicensed Cygwin from GNU Public License version 2 (GPLv2) to GNU Public License version 3 or later (GPLv3+). What does that mean in terms of Cygwin components? Each component normally has its own license, so does the above statement mean that things like the Cygwin DLL and other Cygwin-only components are under GPLv3? Is there an explicit list or a precise description of what parts of Cygwin are covered by GPLv3? Regards, luke The Open Source Licensing Exception persists, as well as the availability of the Cygwin Alternative License, as described on http://cygwin.com/licensing.html This shouldn't affect a lot of you, but if you're concerned that this change in the Cygwin license might affect you and your projects, see http://www.gnu.org/licenses/ in the first place. You can also ask questions on the cygwin or cygwin-licensing mailing list, but be aware that we can't give valid legal advice. It's always better to ask a lawyer who's specialized in licensing questions. Have fun, Corinna *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: More on Cygwin package naming
Buchbinder, Barry (NIH/NIAID) [E] wrote:
Luke Kendall wrote on Sunday, September 04, 2011, at 11:16 PM
In my previous mail I may have used the wrong term (package): the term
package seems to refer to each .tar.bz2 file (for the source and
install files of each version). So perhaps I should instead be talking
about @-names - the name that appears after an @ in setup.ini.
Anyway, this is all related to me trying to determine the licenses for
each Cygwin @-name. What I've found so far is that:
- Most cygwin @-names are simply the upstream vendors project name.
- But it's not rare for the name not to match at all. This seems to
happen when a parent Freshmeat project is split into several cygwin
@-named pieces: in that situation, I can't find any automatable way to
tie the child names back to the parent. E.g. libncurses9 is a cygwin
item from within the ncurses freshmeat project; or libintl,
libintl{2,3,8} in cygwin, which are all part of the gettext project on
Freshmeat. Currently I'm resorting to human inspection.
I'd love to know if there's some way to determine this kind of
parent-child relationship. Is there some setup.hint or upset or genini
file or info lurking around (where?) that I could scrape such
information out of?
The directory structure of the download release directory might help.
It is in the install line. Using your gettext/libintl example:
install: release/gettext/libintl8/libintl8-0.18.1.1-1.tar.bz2 24375
bf501b540c768d63358426686c615530
Here's a start:
cat setup.ini | \
sed -e '/^install: /!d'\
-e '/\/_obsolete\//d' \
-e 's,^install: release/,,' \
-e 's,/[^/]*$,,' \
-e 's,^GNOME/,,' \
-e 's,^KDE/,,' \
-e 's,^X\.Org/,,' \
-e 's,^X11/,,' | \
tr / ' ' | \
sort -u
Ah, I see - thank you. I hadn't imagined it could be that simple! Using
it to assess what see package groups besides GNOME etc. need to be
included in the regexps, it looks like just db, libggi, and mingw - does
that seem right?
: [luke@calixa] .../cygwin-rc; cat setup.ini | sed -e '/^install: /!d'
-e '/\/_obsolete\//d' -e 's,^install: release/,,' -e 's,/[^/]*$,,' -e
's,^GNOME/,,' -e 's,^KDE/,,' -e 's,^X\.Org/,,' -e 's,^X11/,,' | tr / ' '
| sort -u | grep ' .* '
db db2 libdb2
db db2 libdb2-devel
db db3.1 libdb3.1
db db3.1 libdb3.1-devel
db db4.1 libdb4.1
db db4.1 libdb4.1-devel
db db4.2 libdb4.2
db db4.2 libdb4.2-devel
db db4.3 libdb4.3
db db4.3 libdb4.3-devel
libggi libggi2 libggi2-devel
libggi libggi2 libggi2-display-aa
libggi libggi2 libggi2-display-file
libggi libggi2 libggi2-display-terminfo
libggi libggi2 libggi2-display-x
libggi libggi2 libggi2-samples
libggi libggimisc2 libggimisc2-devel
libggi libggimisc2 libggimisc2-samples
libggi libggiwmh0 libggiwmh0-devel
libggi libggiwmh0 libggiwmh0-display-x
libggi libggiwmh0 libggiwmh0-samples
libggi libgii1 libgii1-devel
libggi libgii1 libgii1-input-x
mingw mingw-bzip2 mingw-libbz2_1
And you've also improved my sed knowledge - I'd never noticed the
/regexp/! construct before!
- Barry
Disclaimer: Statements made herein are not made on behalf of NIAID.
Thanks!
luke
--
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
More on Cygwin package naming
In my previous mail I may have used the wrong term (package): the term
package seems to refer to each .tar.bz2 file (for the source and
install files of each version). So perhaps I should instead be talking
about @-names - the name that appears after an @ in setup.ini.
Anyway, this is all related to me trying to determine the licenses for
each Cygwin @-name. What I've found so far is that:
- Most cygwin @-names are simply the upstream vendors project name.
- But it's not rare for the name not to match at all. This seems to
happen when a parent Freshmeat project is split into several cygwin
@-named pieces: in that situation, I can't find any automatable way to
tie the child names back to the parent. E.g. libncurses9 is a cygwin
item from within the ncurses freshmeat project; or libintl,
libintl{2,3,8} in cygwin, which are all part of the gettext project on
Freshmeat. Currently I'm resorting to human inspection.
I'd love to know if there's some way to determine this kind of
parent-child relationship. Is there some setup.hint or upset or genini
file or info lurking around (where?) that I could scrape such
information out of?
Charles Wilson suggested it's safer to find licenses by looking in the
source, but a minor problem is that to do that I must either download
all the source just in case (doubling the download), or else I have to
further complicate things to download on demand if I discover the
install package doesn't contain any licenses.
(So far I have only downloaded Cygwin by using setup.exe: perhaps I can
do a wget of extra -src packages outside setup.exe, as needed. I've
been developing all this license discovery automation under Linux,
though it should work from an installed Cygwin too, I think.)
Another minor worry is that a closer reading of
http://cygwin.com/setup.html's description of package naming, is
talking more about .tar.bz2 version naming. I couldn't find anything
that directly spoke about how the name after the @ in setup.ini is chosen.
It would be /nice/ if someone could confirm that the upstream project
name is used for the @-names, or at least that cygwin does not use any
existing Freshmeat project name and apply it to different software.
BTW, Charles Wilson thought:
Also, gettext group is similar; some of the libs and apps are GPL, and
some of the apps and libs are LGPL. Fortunately, they are segregated in
the cygwin packages:
libasprintf0: LGPL
libintl8: LGPL
libgettextpo0: GPL
gettext:LGPL
gettext-devel GPL
But FYI, when I looked at Freshmeat, a comment from 2007 said gettext
changed to GPL3, while noting that the libintl libraries remain at LGPLv2.
Regards,
luke
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin package naming?
Larry Hall (Cygwin) wrote: On 8/31/2011 9:43 PM, Luke Kendall wrote: Can someone with some official Cygwin standing tell me how the Cygwin package names correspond with the official names of the packages, chosen by the package owners? In other words, how are the Cygwin package names determined? (My hope is that the official name is used, possibly with cygwin added to it in some form.) Sorry, I have no badge and gun but perhaps I will do. I'm asking because I'm finding Cygwin packages that contain no license information, at least in the compiled form (e.g. gawk, libiconv2). So I'm thinking that in such cases, I can modify my Cygwin license-finding script to look up the package by name on freshmeat and try to find the license from there. But that is pointless if the Cygwin package name may have the same name as a freshmeat package, but is in fact some other software. How about http://cygwin.com/setup.html? Thanks! Yes, I think that should be enough (it certainly looks like a public statement of Cygwin's package naming policy, so that's good enough for me): Package file naming Package naming scheme: use the vendor's version plus a release suffix for ports of existing packages Aside: I had to muster all my strength to keep from using the phrase Use the source Luke! I expect you never tire of that. ;-) Ah, yes, very true. Not to mention when I eat with my fingers (Use the forks, Luke!). Thanks, Larry! luke -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin package naming?
Charles Wilson wrote: On 8/31/2011 9:43 PM, Luke Kendall wrote: I'm asking because I'm finding Cygwin packages that contain no license information, at least in the compiled form (e.g. gawk, libiconv2). None of the dll packages contain license files; they are supposed to only contain the dll itself. Usually the license files wind up in the main package, or a -doc package. Thanks, I'll bear that in mind. Though gawk didn't have one. But I'll have a bit more of a look around inside the tarballs, manually. However I think your BEST bet would be to do the following...get setup.ini from $favorite_mirror. Every record beginning with '@ package' will have one or more 'source:' entries -- except for some _obsolete packages, but we don't care about those because they will just be empty tarballs, so no source necessary. Multiple '@ package' will refer to the same 'source:' So, basically I think you're saying I should look inside the source: instead of the install: (which is where I've *been* looking). Because I have to use a mix of algorithm and *heuristics* to find the license files, I'd prefer to try the heuristics on the install: tar file, just because the search space (no. of files) is much smaller. Thanks for the suggestion, though, it sounds sensible - I'll have a manual look inside gawk's at least and see if that looks promising, and if so I'll modify the script to look inside the source: as a fallback. With some judicious coding (*), you should be able to flip that around, and create a database that represents the information the other way: some source entry-VER-N @ package 1-VER-N @ package 2-VER-N @ package 3-VER-N some source entry-VER-M [same package, different version] @ package 1-VER-M @ package 2-VER-M @ package 3-VER-M another source entry-VER-P @ package 4-VER-P @ package 5-VER-P I don't think I need to do that inversion - currently if I find the source licenses in package 1, and it's also used for package 2, then the script will automatically find the licenses for package 2. I doubt the license would often change between versions of the same package, but it HAS been known to happen. Sure. At the moment, I'm only looking in the most recent version, too. I think looking in the source is more likely to find it if there's no license in the install: tarball. I can't imagine someone deliberately stripping the license files out of a package. That'd be just weird. Now, you can find the packages for which you can't identify the license, and either (a) find another package in the same family -- e.g. derived from the same source -- for which you DO know the license. WIN! If *all* of the child packages of a given source have an unknown license, well -- then you can get the -src package itself and troll around in it, or check freshmeat. Usually the -src packages are named pretty simply: upstream name-upstream ver-cygwin release-src.tar.* Watch out for this: some packages have different licenses for different pieces. The libiconv group of packages specifies that the *libraries* are LGPL, but the *app* is GPL. This means: libcharset1:LGPL libiconv2: LGPL libiconv: GPL Also, gettext group is similar; some of the libs and apps are GPL, and some of the apps and libs are LGPL. Fortunately, they are segregated in the cygwin packages: libasprintf0: LGPL libintl8: LGPL libgettextpo0: GPL gettext:LGPL gettext-devel GPL Tell me about it. base-files and cygwin are two good examples. :-) Fortunately, that sort of structure is rare. (*) Maybe borrow from genini, or upset? -- Chuck -- 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 Thanks for all that! Regards, luke -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin package naming?
Can someone with some official Cygwin standing tell me how the Cygwin package names correspond with the official names of the packages, chosen by the package owners? In other words, how are the Cygwin package names determined? (My hope is that the official name is used, possibly with cygwin added to it in some form.) I'm asking because I'm finding Cygwin packages that contain no license information, at least in the compiled form (e.g. gawk, libiconv2). So I'm thinking that in such cases, I can modify my Cygwin license-finding script to look up the package by name on freshmeat and try to find the license from there. But that is pointless if the Cygwin package name may have the same name as a freshmeat package, but is in fact some other software. Regards, luke -- 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: Contributing license information?
Corinna Vinschen wrote: On Aug 19 11:09, Luke Kendall wrote: Soon, I will have prepared a list of the location of every license file in every Cygwin package. My motivation is to make it easy for people to find the license information, if they need it. (Preparing this information has required a lot of work on my part, so I would be happy if something could be done to make it easy to keep the information up to date as packages are added and modified.) What is the best way to contribute the license-location information so it can be integrated into Cygwin? Just create a new package for the distro which keeps the information and maintain it. Somebody will have to keep the information up to date anyway. Corinna Okay. At some stage, then, I'll look into how to create a Cygwin package. luke -- 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
Contributing license information?
Soon, I will have prepared a list of the location of every license file in every Cygwin package. My motivation is to make it easy for people to find the license information, if they need it. (Preparing this information has required a lot of work on my part, so I would be happy if something could be done to make it easy to keep the information up to date as packages are added and modified.) What is the best way to contribute the license-location information so it can be integrated into Cygwin? I have *imagined* that it would be by adding a field to every package in setup.ini, something like: license: relative-path-to-first-license relative-path-to-another-license ... relative-path-to-last-license That seems neat to me, since the information is per-package, and AFAIK per-package information is stored only in sestup.ini. If the right way is to modify setup.ini to hold the license info, would the new setup.ini require a new setup.exe, or does setup.exe ignore information in setup.ini that it doesn't know about? But I gather that setup.ini is created from other data sources via a program called upset. Anyway, what is the right way to contribute this information? Regards, luke -- 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: IFS not fixing carriage returns
Eric Blake eblake at redhat.com writes: On 03/25/2011 10:35 AM, Tim McDaniel wrote: Although it's not documented in man bash on the latest Cygwin, I did find set -o igncr and it seems to work well. I documented it in the cygwin bash release notes, so it is in /usr/share/doc/Cygwin/bash.README. Patches welcome if you want to see it somewhere else like the man page, because that takes more effort. But I'm just curious about why my first attempt didn't work. IFS only affects word splitting _after words have been parsed and expansions performed_. Bash does _not_ ignore CR in the input stream while parsing words, regardless of the IFS settings. Let's use a simpler example: If you set IFS=., then echo a.b will still only echo the one word a.b and not split into two words a and b, because '.' is not special in determining word boundaries (a.b is a single word), and there was no expansion going on. And it would be prohibitively expensive to make shells honor random IFS while parsing out words, so bash _only_ uses space, tab, and newline to determine word boundaries, not carriage return. That's why igncr is more powerful than IFS - it strips the CR prior to the point that bash is even trying to parse the line into words. Can I urge this option be added into the upstream bash, so it's available under Linux versions too? I want to run scripts that work with some text files that have come from Windows and it would be extremely useful. If I use it now however, in bash version 4.0.33(1)-release (i486-pc-linux-gnu) I get: + set -o igncr set: 1: Illegal option -o igncr So the script is not portable between Windows and Linux. luke -- 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
Four license questions that affect commercial use of Cygwin
The URL http://cygwin.com/licensing.html (in summary) says that most Cygwin software is licensed under GNU GPL, X11 copyright (not sure how that's a license), and some are public domain. I'm just wondering what's the recommended way to check that use of Cygwin internally at a company (no re-distribution) complies with all the licenses. Obviously, if Cygwin (Red Hat?) provided answers to the above questions, it would save an enormous amount of repeated legal work. (N hours per license per company that uses Cygwin.) 1. Is there a complete list of all the licenses used by all the packages (rather than the above broad statement about an incomplete set of the licenses)? 2. Do you provide a statement that the licenses are compatible with each other? 3. Do you provide a statement that no package is licensed under terms that disallow commercial use? 4. Does each package have a license? (If not, I don't understand how someone could legally use it - is there some implied license if none is provided?) To be fair, apart from a Yes to question 2 for Debian/Ubuntu, I don't know the answers to questions 1, 3 4 for Linux distributions, either. Hopefully, luke -- 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: Four license questions that affect commercial use of Cygwin
Corinna Vinschen wrote: On Sep 29 19:18, Luke Kendall wrote: The URL http://cygwin.com/licensing.html (in summary) says that most Cygwin software is licensed under GNU GPL, X11 copyright (not sure how that's a license), and some are public domain. I'm just wondering what's the recommended way to check that use of Cygwin internally at a company (no re-distribution) complies with all the licenses. Obviously, if Cygwin (Red Hat?) provided answers to the above questions, it would save an enormous amount of repeated legal work. (N hours per license per company that uses Cygwin.) First of all, it might depend on the selection of packages you made since, obviously, licenses of packages which you don't use are no concern for you. Of course. But assuming one chooses to install everything ... Um, and assuming that we found a list of packages that had no licenses, and a list of packages with licenses that we can't accept, is there any way to supply setup with a pre-defined list of packages to include or exclude? Or would everyone installing Cygwin at our company have to read through a list of disallowed-by-our-company packages and deselect each one (after first clicking on All)? So, sure, Red Hat *could* do that, but that would mean to take over responsibility for something which is in the responsibility of the user in the first place. Eventually only a lawyer can make sure you comply, but, apart from the responsibility, the job of a lawyer isn't exactly for free. So this is a job to redirect to *your* legal department. I don't think my four questions asked for legal advice, they were about asking if someone had done the groundwork to enable legal checks to be of only normal difficulty. By that I mean, normally you get the license(s) text, you don't have to hunt for that. As an engineer, it seems inefficient if every company that wants to use Cygwin first has to spend several days/weeks finding all the licenses across 2000(?) packages, distilling the license files down into a set, find any that forbid commercial use, checking that the remaining licenses are compatible with each other, and *then, finally* checking each unique license in the usual way. A list of licenses used in Cygwin packages is in the cygwin-docs package, plus, every package with a non-standard license typically provides it under /usr/share/doc/packagename. Thanks, that's very helpful, and is an excellent example of how some collected information can save a lot of companies a lot of work to check they can use Cygwin. Using your information, I can create a script that produces a list of all the licenses. I guess if the license files themselves have varying names (ideally they'd all be just license.txt), I may need to then add some heuristics to pick the license file out. From that I can then create something that produces just a set of the unique licenses. And then I can pass that to our legal department. I can also diff it against new Cygwin releases to identify changes to licenses and new licenses added for new packages. However, there's no guarantee that the list is complete. Erk, that sounds scary. Does that mean the process for adding new packages doesn't include adding the license information into the license list? Would that be a process improvement that could be considered for the future? As for licenses with commercial exceptions, personally (IANAL, and I'm not speaking for Red Hat, nor for the Cygwin community at large, nor did I actually search for it) I think there is none in the distro, except for the Cygwin license itself. I can't see anything in http://cygwin.com/licensing.html that says Cygwin can't be used for commercial purposes (thank goodness!). Maybe you meant something else. And that only applies to exceptions from the GPL. Other than that, licensing questions should better go to the cygwin-licensing mailing list. I didn't know it existed. Sorry. I'd better subscribe to it, and I'll take my questions there, and stop troubling this list. Thanks again, luke Corinna -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Four license questions that affect commercial use of Cygwin
Corinna Vinschen wrote: On Sep 29 20:32, Luke Kendall wrote: Corinna Vinschen wrote: So, sure, Red Hat *could* do that, but that would mean to take over responsibility for something which is in the responsibility of the user in the first place. Eventually only a lawyer can make sure you comply, but, apart from the responsibility, the job of a lawyer isn't exactly for free. So this is a job to redirect to *your* legal department. I don't think my four questions asked for legal advice, In a way, yes. Licensing is dangerous territory. If we claim there's no exception from A and somebody find that exception, it's a sure way to be sued. I, for one, can do without that. As an engineer, [...] As a lawyer, [...] :-) I'm with you on the engineering side, since I hate to reinvent the wheel same as you do. However, this isn't technical, this is legal and as such I stay away as much as possible. Fair enough! As for licenses with commercial exceptions, personally (IANAL, and I'm not speaking for Red Hat, nor for the Cygwin community at large, nor did I actually search for it) I think there is none in the distro, except for the Cygwin license itself. I can't see anything in http://cygwin.com/licensing.html that says Cygwin can't be used for commercial purposes (thank goodness!). Maybe you meant something else. And that only applies to exceptions from the GPL. You ignored the above sentence, which was the important one. I confess I didn't ignore it, I just couldn't understand it. Trying again now, I think you meant that there were no exceptions that applied only in commercial situations, except some exceptions relating to the GPL (looking at the license, I think it's related to redistribution of code that depends on GPL stuff). I don't think you mean it is saying you are not allowed to use Cygwin within a company, Cygwin is only for personal or scientific non-commercial research, and I'm happy that I can't see that. :-) luke Corinna -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Four license questions that affect commercial use of Cygwin
Stephen Bennett wrote: Um, and assuming that we found a list of packages that had no licenses, and a list of packages with licenses that we can't accept, is there any way to supply setup with a pre-defined list of packages to include or exclude? Or would everyone installing Cygwin at our company have to read through a list of disallowed-by-our-company packages and deselect each one (after first clicking on All)? If you're in search of a centralised approach, it's a fairly easy exercise to run your own internal mirror, containing only those packages that you've verified as acceptable. We do just that here for different reasons -- we need to patch certain packages for various reasons. Once that has been set up, then everyone can simply install from there and be sure that they're not getting any packages with legal problems. You'd still need someone to do that checking in the first place, though. Good suggestion, that'd work. Thanks! luke Accelrys Limited (http://accelrys.com) Registered office: 334 Cambridge Science Park, Cambridge, CB4 0WN, UK Registered in England: 2326316 -- 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: Bizarre Cygwin/Explorer/paths problem half-solved
On 4 Aug, Gary R. Van Sickle wrote:
Hi Luke,
I discovered today that if I try to run Windows Explorer from
the Cygwin command line, and give it a pathname with spaces,
it fails, but if I give the same command line to a cmd.exe
command line, Explorer works!
I.e. from Bash, explorer fails with an error message like
The path '/e,c:\temp\space dir' does not exist or is not a
directory.
I've tried every quote combo I can. If I leave off the /e
option then it does open the directory, but without the side
pane (which is what you'd expect with the /e option omitted).
I've had this little gem in my .bash_profile for ages, and it's never failed
me regardless of the craziness of the path:
# Easy Explorer here command
x()
{
if [ ${1} = ];
then
XPATH=.;
else
XPATH=$(cygpath -w ${1});
fi
explorer $XPATH disown %-
}
No tree view though. Lessee what happens if I add a /e,:
# Easy Explorer here command with tree control on the left
x()
{
if [ ${1} = ];
then
# No parameter given, open Explorer in the current bash
directory.
XPATH=.;
else
# Open the given path.
XPATH=$(cygpath -w ${1});
fi
explorer /e,$XPATH disown %-
}
...yep, that works like a charm too.
True, and thanks, that's interesting!
Don't try this variant, though, since it doesn't work:
explorer /e,$XPATH disown %-
What happens if you try that innocuous-looking variant is that Cygwin
(or bash?) normalises the path /e,... to a windows path first, producing
\e,...
Well, I though that snippet of info interesting enough to share.
Regards,
luke
--
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: Fresh install of Cygwin, not working
On 7 Aug, Larry Hall (Cygwin) wrote:
Oliver Jones wrote:
Can anyone tell me why the latest version of Cygwin will not work?
I have downloaded the complete version from my local mirror, which is on the
mirrors list. When I install, I do not get the X Server icon, or any of the
X applications that normally appear, on my desktop (fresh Windows XP
install).
Nor does the Cygwin.bat shortcut, placed on my desktop after the install,
work. When running from the Windows cmd shell, it reports Bad command -
bash.
I've tried to download from other mirrors, often with the same result. It
seems that if I want to actually *use* Cygwin, I'll have to see if I can dig
up a version I saved on CD-ROM, because none of the mirrors work anymore.
Anyone else experiencing this issue?
Clearly, this is not a wide-spread issue, otherwise you'd see the list
swamped by complaints like this.
My suggestion is to read and follow the problem reporting guidelines found
here - http://cygwin.com/problems.html. This will give folks on this list
that wish to help some basic information on which to start a meaningful
dialog. Absent that, my WAG is that your postinstall scripts didn't run
for some reason. Check '/etc/postinstall' to see if there are any scripts
that don't have a .done suffix. If there are, you can try rerunning
'setup.exe' again. It should run the remaining postinstall scripts. If
that doesn't help or isn't the obvious issue, a look at /var/log/setup.log*
may provide some insight (if the postinstall scripts failed), assuming you
haven't rerun 'setup.exe' again since the initial install failure.
Well, we know that frequently the mirror(s) we use are bad, because
after we rsync from them to a local disc for use on our intranet, it
fails the MD5 checks of the files. I wrote this script to make the
check nightly, after the rsync.
I just wish all the mirrors did this routinely, so we didn't need to
discover it after the rsync.
luke
md5cygchk --
#!/bin/sh
#
# Check all the md5 signatures for a Cygwin mirror.
#
# Author: Luke Kendall
#
CYG_BAD=cygwin-archive-incomplete.txt
CYG_GOOD=cygwin-archive-okay.txt
ECHO=echo
MD5ARG=
MIRROR=/u/mirror/cygwin/release
MYNAME=`basename $0`
RECORD=false
TMP=/tmp/md5cyg$$
USAGE=Usage: $MYNAME [-q] [--record] [cygwin-mirror-directory]
Where:
-q means quiet.
--recordmeans record a success or failure indicator in the
the directory above the mirror directory, by making
$CYG_GOOD $CYG_BAD files
appear or disappear (so even DOS batch scripts can test
the archive's goodness).
You have to have write permission for this to work.
cygwin-mirror-directory
this should be the directory where you find setup.bz2,
setup.exe, and setup.ini.
Success/failure files are created in the directory
above this, if the --record option is used.
Defaults to /u/mirror/cygwin/release.
E.g.:
$MYNAME --record -q /u/mirror/cygwin/release
NOTE: running md5 over 2GB of files is best done on the host
machine, to avoid hammering our network.
(Use 'df -k \$MIRROR' to discover what machine
hosts \$MIRROR, that you should slogin to,
to run this $MYNAME.)
trap 'rm -f $TMP; exit 1' 0 1 2 3 15
usage()
{
# sed, so that if they specified a mirror, it's used in the usage message.
echo $USAGE | sed s|\$MIRROR|$MIRROR| 2
exit 1
}
while [ $# -ge 1 ]
do
case $1 in
-q)
MD5ARG=--status
ECHO=:
;;
--record)
RECORD=true
;;
-*)
usage
;;
*)
MIRROR=$1
shift
break
;;
esac
shift
done
if [ $# != 0 ]
then
usage
fi
cd $MIRROR || exit 1
if [ ! -s ../setup.bz2 ]
then
echo $MYNAME: Not a cygwin download (no file setup.bz2 in $MIRROR parent)
2
exit 1
fi
WHERE=`pwd`
find . -type d -print | \
while read dir
do
(
cd $dir
if [ -s md5.sum ]
then
$ECHO $dir:
if md5sum $MD5ARG --check md5.sum
then
:
else
{
echo
echo In $WHERE/$dir:
md5sum --check md5.sum 21 | grep -v OK
} $TMP
fi
elif [ `ls -l | grep ^- | wc -l` = 0 ]
then
:
else
echo Worrying: $dir has no md5.sum file 2
echo Worrying: $dir has no md5.sum file $TMP
fi
cd $WHERE # Really, the shell popping via (...) does this.
)
done
if $RECORD
then
if [ ! -w $WHERE/.. ]
then
echo $MYNAME: you don't have write permission on $WHERE/.. 2
RECORD=false
else
# Remove them both, temporarily, in case
RE: Bizarre Cygwin/Explorer/paths problem half-solved
On 4 Aug, Buchbinder, Barry (NIH/NIAID) [E] wrote:
Luke Kendall wrote on Monday, August 04, 2008 4:18 AM:
I discovered today that if I try to run Windows Explorer from the
Cygwin command line, and give it a pathname with spaces, it fails,
but if I give the same command line to a cmd.exe command line,
Explorer works!
I.e. from Bash, explorer fails with an error message like The path
'/e,c:\temp\space dir' does not exist or is not a directory.
I've tried every quote combo I can. If I leave off the /e option
then it does open the directory, but without the side pane (which is
what you'd expect with the /e option omitted).
Bash shell:
$ mkdir c:/temp/space dir
$ explorer /e,c:\\temp\\space\ dir
$ # NBG^
$ explorer /e,c:\\temp
$ # GOOD^
$ explorer c:\\temp\\space\ dir
$ # GOOD^ (but no side pane)
$ explorer /e,c:\temp\space dir
$ # NBG^
$ explorer /e,\c:\temp\space dir\
$ # NBG^
DOS shell:
cexplorer /e,c:\temp\space dir
crem GOOD^
cexplorer /e,c:\temp\space dir
crem GOOD^
cexplorer /e,'c:\temp\space dir'
crem NBG^
cexplorer /e,c:\temp\space dir
crem NBG^
Until I tried the same stuff under the DOS shell, I assumed it was
explorer.exe that was busted. Now I'm just confused.
I find this quite bizarre. Any suggestions? Is bash or Cygwin
guessing the /e option is part of a path, and doing some extra
quoting of its own or something?
I just tried an strace on bash, and it looks like this guess is
correct:
140 4166625 [main] bash 5696 spawn_guts: null_app_name 0
(c:\WINDOWS\explorer.exe, c:\WINDOWS\explorer.exe
/e,c:\temp\space dir)
It's collected all the arguments and put them inside double quotes,
and if I do that in a DOS shell too I get the exact same failure.
If the directory contains no spaces, then bash does this, in contrast:
12217 33394057 [main] bash 5284 spawn_guts: 5284 = spawn_guts
(/cygdrive/c/WINDOWS/explorer, c:\WINDOWS\explorer.exe /e,c:\temp)
Is there some way to tell Bash/Cygwin not to do this? Or is it
simply that my bash is too old?
$ bash --version
GNU bash, version 3.2.9(10)-release (i686-pc-cygwin) Copyright (C)
2005 Free Software Foundation, Inc.
As a work-around, you might try the -x or --explore option of cygstart.
I use it in the following script (which I cal explore), though a
shell function might be better if you use this a lot.
[ cut ]
#!/bin/bash
/bin/cygstart --explore ${1:-.}
[ cut ]
${1:-.} makes explorer open in the current working directory run
without an argument.
If this does not do what you want, you could always try launching
explorer with cygstart (without -x, giving you control of explorer's
command line arguments) or cmd /c start. And one way to get rid of
spaces is to go to that directory. You could just
$ pushd /cygpath/c/temp/space\ dir
$ explorer /e,.
$ popd
I'd have to cygpath it to Unix format first ...
I found your cygstart suggestion a nicer approach - thanks! It works
well, except that none of the options to prevent the window from taking
focus work when explorer is the thing that gets started. That's
annoying when I run my script to restore bash/Explorer/Internet Explorer
session (i.e. windows) in interactive mode, but I can live with it.
Thanks again!
luke
Good luck!
- Barry
- Disclaimer: Statements made herein are not made on behalf of NIAID.
--
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/
Bizarre Cygwin/Explorer/paths problem half-solved
I discovered today that if I try to run Windows Explorer from the Cygwin command line, and give it a pathname with spaces, it fails, but if I give the same command line to a cmd.exe command line, Explorer works! I.e. from Bash, explorer fails with an error message like The path '/e,c:\temp\space dir' does not exist or is not a directory. I've tried every quote combo I can. If I leave off the /e option then it does open the directory, but without the side pane (which is what you'd expect with the /e option omitted). Bash shell: $ mkdir c:/temp/space dir $ explorer /e,c:\\temp\\space\ dir $ # NBG^ $ explorer /e,c:\\temp $ # GOOD^ $ explorer c:\\temp\\space\ dir $ # GOOD^ (but no side pane) $ explorer /e,c:\temp\space dir $ # NBG^ $ explorer /e,\c:\temp\space dir\ $ # NBG^ DOS shell: cexplorer /e,c:\temp\space dir crem GOOD^ cexplorer /e,c:\temp\space dir crem GOOD^ cexplorer /e,'c:\temp\space dir' crem NBG^ cexplorer /e,c:\temp\space dir crem NBG^ Until I tried the same stuff under the DOS shell, I assumed it was explorer.exe that was busted. Now I'm just confused. I find this quite bizarre. Any suggestions? Is bash or Cygwin guessing the /e option is part of a path, and doing some extra quoting of its own or something? I just tried an strace on bash, and it looks like this guess is correct: 140 4166625 [main] bash 5696 spawn_guts: null_app_name 0 (c:\WINDOWS\explorer.exe, c:\WINDOWS\explorer.exe /e,c:\temp\space dir) It's collected all the arguments and put them inside double quotes, and if I do that in a DOS shell too I get the exact same failure. If the directory contains no spaces, then bash does this, in contrast: 12217 33394057 [main] bash 5284 spawn_guts: 5284 = spawn_guts (/cygdrive/c/WINDOWS/explorer, c:\WINDOWS\explorer.exe /e,c:\temp) Is there some way to tell Bash/Cygwin not to do this? Or is it simply that my bash is too old? $ bash --version GNU bash, version 3.2.9(10)-release (i686-pc-cygwin) Copyright (C) 2005 Free Software Foundation, Inc. Regards, luke PS: NBG = No Good! -- 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: diff: Resource temporarily unavailable
Larry Hall (Cygwin) wrote: Luke Kendall wrote: Hi We're using a version of Cygwin that's at least a year old. Someone found today that he can't diff two large files (200MB each) across the network using Cygwin. The error we get is: $ diff //samba/damita-nobackup/chitra/SWFILES/OIP/RF_Testing/OIP01_SWRF_IO.txt //samba/damita-nobackup/chitra/3F01/OIP/RF_Testing/OIP01_HWRF_IO.txt diff: //samba/damita-nobackup/chitra/SWFILES/OIP/RF_Testing/OIP01_SWRF_IO.txt: Resource temporarily unavailable If we copy the files across the network using Cygwin cp and then diff locally, it does work. I had a look at http://cygwin.com/faq/faq.using.html#faq.using.bloda but I don't think we fall into that situation. I've included a small portion of an strace - is this an interesting bug, or something that's been fixed a while ago? Why not install a new cygwin (and diff if necessary) package and check it out for yourself? As long as you have the original versions for the newer package(s), you can always reinstall them if you don't like what you see. Okay. grumbleNow to find a mirror with a complete Cygwin. Sadly, one must download the whole Cygwin mirror and then check it, because no mirror site runs the md5cygchk script I posted here a year or two ago./grumble Hmm, maybe it's not too bad using rsync - we may just be able to fetch the missing few dozen files. Hmm, if that does work, we should be able to automate to rsync from several servers routinely, to construct a union from several sites that are each 99% complete. luke -- 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/
Checking a mirror is complete (Was: Re: diff: Resource temporarily unavailable)
On 10 Jun, luke wrote: Larry Hall (Cygwin) wrote: [...snip] Why not install a new cygwin (and diff if necessary) package and check it out for yourself? As long as you have the original versions for the newer package(s), you can always reinstall them if you don't like what you see. Okay. grumbleNow to find a mirror with a complete Cygwin. Sadly, one must download the whole Cygwin mirror and then check it, because no mirror site runs the md5cygchk script I posted here a year or two ago./grumble Hmm, maybe it's not too bad using rsync - we may just be able to fetch the missing few dozen files. Hmm, if that does work, we should be able to automate to rsync from several servers routinely, to construct a union from several sites that are each 99% complete. Yes, this is what we'll try: - rsync, *not* additively (i.e. with deletions) from our chosen main mirror site (currently incomplete for about 2 months), - run md5cycgchk on our local mirror - if that shows an incomplete mirror: - rsync *additively* from another site - run md5cygchk on the result. - Maybe repeat once or twice with other sites if still needed (i.e. mirror still incomplete). This way obsolete packages will eventually get pruned when the main mirror site gets corrected, and even if one or a few sites don't mirror properly from cygwin.com, even for a long time, we can still create a complete mirror (with high probability). luke PS: md5cygchk is just a script that checks if all packages are present and correct according to the md5sum files, and records the result in a success or fail text file that can be checked for: even from a dumb Windows batch file. -- 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/
diff: Resource temporarily unavailable
Hi We're using a version of Cygwin that's at least a year old. Someone found today that he can't diff two large files (200MB each) across the network using Cygwin. The error we get is: $ diff //samba/damita-nobackup/chitra/SWFILES/OIP/RF_Testing/OIP01_SWRF_IO.txt //samba/damita-nobackup/chitra/3F01/OIP/RF_Testing/OIP01_HWRF_IO.txt diff: //samba/damita-nobackup/chitra/SWFILES/OIP/RF_Testing/OIP01_SWRF_IO.txt: Resource temporarily unavailable If we copy the files across the network using Cygwin cp and then diff locally, it does work. I had a look at http://cygwin.com/faq/faq.using.html#faq.using.bloda but I don't think we fall into that situation. I've included a small portion of an strace - is this an interesting bug, or something that's been fixed a while ago? (Fixed a while ago and therefore an indication we should once more go looking for a working Cygwin mirror - rsync.planetmirror.com has been broken for about 2 months now - and try a test install of the latest version and check everything we depend on still works as it used to, or else plan how to change our systems to work.) luke 149319 253053 [main] diff 2192 fhandler_base::raw_read: ReadFile //samba/damita-nobackup/chitra/SWFILES/OIP/RF_Testing/OIP01_SWRF_IO.txt(0x704) failed, Win32 error 1450 142 253195 [main] diff 2192 seterrno_from_win_error: /ext/build/netrel/src/cygwin-1.5.23-1/winsup/cygwin/fhandler.cc:273 windows error 1450 1025 254220 [main] diff 2192 geterrno_from_win_error: windows error 1450 == errno 11 55 254275 [main] diff 2192 __set_errno: void seterrno_from_win_error(const char*, int, DWORD):310 val 11 57 254332 [main] diff 2192 fhandler_base::read: returning -1, binary mode 56 254388 [main] diff 2192 readv: -1 = readv (3, 0x22C8A0, 1), errno 11 420 254808 [main] diff 2192 sig_send: sendsig 0x70C, pid 2192, signal -34, its_me 1 68 254876 [main] diff 2192 sig_send: wakeup 0x6F8 65 254941 [main] diff 2192 sig_send: Waiting for pack.wakeup 0x6F8 62 255003 [sig] diff 2192 wait_sig: signalling pack.wakeup 0x6F8 73 255076 [main] diff 2192 sig_send: returning 0x0 from sending signal -34 110 255186 [main] diff 2192 fhandler_base::write: binary write diff: 351 255537 [main] diff 2192 sig_send: sendsig 0x70C, pid 2192, signal -34, its_me 1 60 255597 [main] diff 2192 sig_send: wakeup 0x6F8 108 255705 [main] diff 2192 sig_send: Waiting for pack.wakeup 0x6F8 70 255775 [sig] diff 2192 wait_sig: signalling pack.wakeup 0x6F8 69 255844 [main] diff 2192 sig_send: returning 0x0 from sending signal -34 100 255944 [main] diff 2192 fhandler_base::write: binary write SWFILES/OIP/RF_Testing/OIP01_SWRF_IO.txt 370 256314 [main] diff 2192 sig_send: sendsig 0x70C, pid 2192, signal -34, its_me 1 60 256374 [main] diff 2192 sig_send: wakeup 0x6F8 61 256435 [main] diff 2192 sig_send: Waiting for pack.wakeup 0x6F8 59 256494 [sig] diff 2192 wait_sig: signalling pack.wakeup 0x6F8 68 256562 [main] diff 2192 sig_send: returning 0x0 from sending signal -34 119 256681 [main] diff 2192 fhandler_base::write: binary write : Resource temporarily unavailable 204 256885 [main] diff 2192 sig_send: sendsig 0x70C, pid 2192, signal -34, its_me 1 59 256944 [main] diff 2192 sig_send: wakeup 0x6F8 61 257005 [main] diff 2192 sig_send: Waiting for pack.wakeup 0x6F8 67 257072 [sig] diff 2192 wait_sig: signalling pack.wakeup 0x6F8 67 257139 [main] diff 2192 sig_send: returning 0x0 from sending signal -34 100 257239 [main] diff 2192 fhandler_base::write: binary write 509 257748 [main] diff 2192 close: close (0) 60 257808 [main] diff 2192 fhandler_base::close: closing handle 0x160 62 257870 [main] diff 2192 close: 0 = close (0) 379 258249 [main] diff 2192 close: close (1) 51 258300 [main] diff 2192 fhandler_base::close: closing handle 0x164 57 258357 [main] diff 2192 close: 0 = close (1) 408 258765 [main] diff 2192 close: close (2) 51 258816 [main] diff 2192 fhandler_base::close: closing handle 0x7D8 56 258872 [main] diff 2192 close: 0 = close (2) 220 259092 [main] diff 2192 do_exit: do_exit (512), exit_state 0 56 259148 [main] diff 2192 void: 0x0 = signal (20, 0x1) 53 259201 [main] diff 2192 void: 0x0 = signal (1, 0x1) 52 259253 [main] diff 2192 void: 0x0 = signal (2, 0x1) 52 259305 [main] diff 2192 void: 0x0 = signal (3, 0x1) 52 259357 [main] diff 2192 fhandler_base::close: closing //samba/damita-nobackup/chitra/SWFILES/OIP/RF_Testing/OIP01_SWRF_IO.txt handle 0x704 727 260084 [main] diff 2192 fhandler_base::close: closing //samba/damita-nobackup/chitra/3F01/OIP/RF_Testing/OIP01_HWRF_IO.txt handle 0x6FC 536 260620 [main] diff 2192 sigproc_terminate: entering 46 260666 [main] diff 2192 sig_send: sendsig 0x70C, pid 2192, signal -42, its_me 1 45 260711 [main] diff 2192 sig_send: Not waiting for sigcomplete. its_me 1 signal -42 38 260749 [main] diff 2192 sig_send: returning 0x0 from
Re: Directory existence prevents .exe execution
Larry Hall (Cygwin) wrote: Luke Kendall wrote: Larry Hall (Cygwin) wrote: On 04/18/2008, Luke Kendall wrote: It looks like something has stat()ed /opt/bin/ici and then decided it's been asked to execute that, and refusing (which makes a kind of sense), and bailing out with an error (*that* step seems wrong to me). Well, didn't you ask to execute '/opt/bin/ici'? After all, that's what you typed. I don't see how it could be wrong to report back what you asked to execute is a directory. I thought that bash treated the first word on the line (after optional assignments to environment variables a la FRED=x run-some-command) as a command to execute, passing the remaining words on the line to the command as arguments? (Leaving aside things like backtic execution and variable expansion.) So I still think I asked for /opt/bin/ici to be executed by bash. I'd be interested to know if I've misunderstood. I think you did as well. And so does bash. But it's not going to allow you to execute a directory, which is what your invocation matches exactly. So it tells you that you made a mistake by trying to execute a directory. I guess we're in violent agreement that you got what you asked for. Well, not violent, but clear disagreement. :-) I think that given I can type foo to execute foo or foo.exe, why does having a directory called foo make bash decide that I want to do the impossible: namely, execute the directory? Why is it written to assume that the user is trying to do something that makes no sense? I suspect it won't become clear until I have time to grab the bash source and probably the exec source and read them through myself. I also checked that bash doesn't work this way under Linux. I created a directory called ici (with execute permission, obviously), in the first directory in my PATH. I then ran ici from bash, and it did not tell me that ici was a directory and bail out - it executed the first ici executable it found later in my PATH. Well here you're not comparing the same thing at all. You can't put a file/binary named ici in the same spot as a directory you have named ici. So you've already changed the rules. But try the exact same thing you just did under Linux on Cygwin and you'll see the same behavior as Linux. I had to move the Ici directory aside, but I confirmed that you're correct. So it looks like you understand what's going on better than I do, since I don't understand why and you do. :-) The point is that Windows allows you to do something you can't do in Linux. You can have the name of an executable match the name of a directory, if you ignore the extension. In addition you can run an executable by only providing part of its name (i.e. not the extension). You can't do this under Linux. And why would you want to. Quite! But if you try to put that same-named executable and directory under the one directory and then run the executable from there without providing the full name, you're being imprecise. Cygwin's bash lets you know this. You can't compare this behavior to Linux because you'd never get into that situation. True, but given that Cygwin is designed to allow the user to be imprecise (drop the .exe suffix) when asking for a command to be executed, why have that logic (designed to improve usability because of the interesting decision to identify executables by suffix) decide that if the name matches a directory, then the user is really trying to execute a directory. One thing we agree on, is that it makes no sense to try to execute a directory. Don't confuse any of this with an executable named ici.exe in one directory in your path and a directory named ici in another (also in your path). This isn't a general issue that will bite you every time you want to run ici.exe in this configuration. In this scenario, the only time running ici.exe as ici would cause you to get the complaint that ici is a directory is if you were trying to run it from the parent directory of ici-the-directory. Well, I'm getting the problem regardless of what directory I try to run the command from. I don't get the problem only if I'm trying to run ici when my current directory is /opt/bin. Unless you mean that the problem only occurs when I specify the full pathname, and that pathname is a directory of that name and there is a .exe file there based on the same name, too. Which would make sense because in that case the search down PATH is not done, where it looks for a command with the right name (maybe with .exe or .lnk extension) to run... Which makes me think that exec() (or execve or whatever is the exec() that searches down the PATH) is the place where the check for .exe with rejection of directories, makes sense. That change would fix the problem in all shells, too, not just bash. And I'm sorry if you are now tearing your hair out wondering why I don't get it,still. :-( And if you take that parent directory
Re: Directory existence prevents .exe execution
Corinna Vinschen wrote: On Apr 16 16:42, Luke Kendall wrote: Suppose that when it does a stat() on fred, before it decides that it's found the right file to exec, it should check that fred isn't a A stat() call can't know for what purpose it has been called. Calling stat on foo, it will return the information for foo first, if it exists. Only if it not exists it tries foo.exe or foo.lnk. Sure, that makes sense. The stat() call can't know, but the exec() certainly does know that it's trying to execute. So I meant that exec() could call stat(), and if the file exists but is a directory, reject it as a possible thing to execute, and continue with what I assume is the existing Windows-specific logic to look for foo.exe or foo.lnk. What do you think, does the idea make sense? Regards, luke Corinna -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Directory existence prevents .exe execution
Mark J. Reed wrote: I still don't understand why you would put the ici dir in the same place as the ici script. You can't do that on Unix, so why do it on Cygwin? The creator did this because simply it seemed a convenient way to keep all the ici components together and easy to install and uninstall, and it also caused no problems for the Windows cmd.exe shell. cmd doesn't try to execute directories as if they were programs. ici has been around for about 25 years, so it wasn't designed with Cygwin in mind. luke On 4/16/08, Luke Kendall [EMAIL PROTECTED] wrote: On 15 Apr, Dyck, David wrote: how much control do you have on unix side? (you could create a symlink from ici.exe to ici on unix. True. And I suppose there are only rare programs that would suffer this problem. what about creating a new name for ici.exe and ici that could be found on both. Umm, I don't think I understand. Then we'd have to modify every script to change the #!/opt/bin/ici, wouldn't we? directories need to have 'x' attribute to be searchable (on unix) but I would also ask about your path why do you need an /opt/bin/ici directory on windows when if /opt/bin/ici was a directory on unix, where would the shell be finding ici executable? On Unix, it would be finding it under /opt/ici-3.0.1/lib/ici3. Since it should also work under Windows natively, we can't rely on using mount points under Cygwin, since they just wouldn't be visible. But maybe we could do something along those lines. It does seem like a corner case (in bash or in the exec call), that Cygwin would be better for handling. This corner case can't happen in Unix because Unix doesn't have implicit suffixes on commands: you can't have a directory and an executable in the same directory with the same name. (If you have a command called fred.sh, you type fred.sh to execute it, not fred.) I assume exec() stat()s a file, and then presumably does some special magic to change fred to fred.exe if it can't find fred. Suppose that when it does a stat() on fred, before it decides that it's found the right file to exec, it should check that fred isn't a directory. If it is a directory, it should consider that not found and the logic would flow through into the checking for .exe and whatever other arcane Windows executable-file suffixes make sense. But having not looked at the source, I confess I'm just guessing. Thanks, luke -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luke Kendall Sent: Tuesday, April 15, 2008 9:44 PM To: cygwin@cygwin.com Subject: Directory existence prevents .exe execution We have the Ici scripting language installed on Windows. Ici expects a directory called ici to exist alongside, where various libraries are installedd to provide extra functionality. Unfortunately, under Cygwin, if w try to run the command ici we get the error ici: command not found, because Cygwin chooses to try to execute the directory instead of the .exe: $ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr bash: /opt/bin/ici: is a directory $ ls -ld /opt/bin/ici drwxr-xr-x 1 luke Domain Users 0 Oct 17 2005 /opt/bin/ici $ ls -ld /opt/bin/ici.* -rwxr-xr-x 1 luke Domain Users 233503 Apr 18 2000 /opt/bin/ici.dll -rwxr-xr-x 1 luke Domain Users 24576 Jan 29 2003 /opt/bin/ici.exe I tried naming the ici directory Ici but it made no difference. The directory /opt/bin is mounted like so: $ mount \\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system (textmode,exec) Using binmode doesn't help. Is this a bug, that bash tries to execute a directory even when there's an executable (with an implicit .exe suffix, naturally) of the same name in existence ? If not, can anyone suggest a workaround? I can't just append a .exe to the #!/opt/bin/ici shell wrapper since then the scripts wouldn't run from Unix. Is there a bash option that controls this, maybe (I couldn't see one)? Regards, luke -- 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/ This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq
Re: Directory existence prevents .exe execution
Igor Peshansky wrote: On Wed, 16 Apr 2008, Luke Kendall wrote: We have the Ici scripting language installed on Windows. Ici expects a directory called ici to exist alongside, where various libraries are installedd to provide extra functionality. Unfortunately, under Cygwin, if w try to run the command ici we get the error ici: command not found, because Cygwin chooses to try to execute the directory instead of the .exe: This behavior (preferring the unadorned file name to the .exe) has been in existence for a while (at least a year). Interesting. Do you mean that exec() prefers the unadorned file name to the .exe? Or do you mean bash or something else changed to prefer the unadorned name? From what you say below, I think you mean bash changed. We relied on the old behavior by having a script and a .exe with the same name (and expecting the .exe to be invoked on Windows/Cygwin). I remember we've had to work around this issue when the change happened, by prepending the following to our script: [ -x $0.exe ] exec $0.exe $@ Our olden approach, maybe 5-10 years ago, we wrote a script that examined the 1st line of some target script to generate a C program (that was compiled to a .exe of the same name) that invoked the named interpreter on the target script. This was needed for U/Win. Then we changed over to Cygwin and discovered we didn't need to do this: Cygwin supported #! magic. But some time ago it stopped working in this corner case and I finally got around to asking about it. To follow the approach you took for your case, we could convert all our ici scripts to shell scripts and um, what, set ICI to either /opt/bin/ici or /opt/bin/ici.exe depending on whether we detect the script is on Windows and then: exec $ICI -f - $@ 'some-eof-mark' But that wouldn't work, would it, since we'd still have to backslash escape any backtic character in the script? Shudder. $ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr bash: /opt/bin/ici: is a directory $ ls -ld /opt/bin/ici drwxr-xr-x 1 luke Domain Users 0 Oct 17 2005 /opt/bin/ici $ ls -ld /opt/bin/ici.* -rwxr-xr-x 1 luke Domain Users 233503 Apr 18 2000 /opt/bin/ici.dll -rwxr-xr-x 1 luke Domain Users 24576 Jan 29 2003 /opt/bin/ici.exe I tried naming the ici directory Ici but it made no difference. Try also CYGWIN=$CYGWIN check_case:strict (while the code is still in the DLL) or managed mounts... The latter won't work unless ici.exe is a Cygwin program. Thanks for the suggestion, but it didn't help: $ echo $CYGWIN nobinmode $ CYGWIN=$CYGWIN check_case:strict $ ici -help bash: ici: command not found $ /opt/bin/ici -help bash: /opt/bin/ici: is a directory $ whiches ici /opt/bin/ici.exe /opt/bin/ici.dll /cygdrive/x/bin/ici.exe /cygdrive/x/bin/ici.dll $ type ici bash: type: ici: not found $ which ici ici: Command not found. $ CYGWIN=nobinmode $ ici -help bash: ici: command not found $ /opt/bin/ici -help bash: /opt/bin/ici: is a directory The directory /opt/bin is mounted like so: $ mount \\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system (textmode,exec) Using binmode doesn't help. Is this a bug, that bash tries to execute a directory even when there's an executable (with an implicit .exe suffix, naturally) of the same name in existence ? No, this is expected behavior (if you search through bash release announcements, you should be able to see the exact point at which the change happened). I had a look, but couldn't find the release notes. Do you mean, the release notes for each of the bash updates announced on the mailing list? Or do you mean the full release notes - if so, any idea where I'd find them? I looked at the release notes for all the mailing list announcements for bash over the last few years, and searched for unadorned and exec. Sorry for asking. If not, can anyone suggest a workaround? Other than renaming the directory or using a wrapper script, no. I can't just append a .exe to the #!/opt/bin/ici shell wrapper since then the scripts wouldn't run from Unix. How do these scripts *ever* run from Unix? Unix would definitely not be aware of the .exe suffix, and would always attempt to execute /opt/bin/ici, which, as you say, is a directory. Do you have a /opt/bin/ici script as well? No, ici on Unix looks elsewhere for its libraries, since it can't use such a simple system as having the directory alongside the .exe with the same name but the suffix stripped, for obvious reasons. In any case, whatever solution you use to make it work from Unix should work on Cygwin as well. True. We can modify the ici source to also have a directory search path for the libraries, and move the ici directory somewhere else that's off the PATH search path, and that will solve this problem. I guess that's what we'll do. But we'll then have the problem that Windows native compiled ici won't be able to open any named scripts that aren't given
Re: Directory existence prevents .exe execution
Larry Hall (Cygwin) wrote: On 04/17/2008, Luke Kendall wrote: Mark J. Reed wrote: I still don't understand why you would put the ici dir in the same place as the ici script. You can't do that on Unix, so why do it on Cygwin? The creator did this because simply it seemed a convenient way to keep all the ici components together and easy to install and uninstall, and it also caused no problems for the Windows cmd.exe shell. cmd doesn't try to execute directories as if they were programs. ici has been around for about 25 years, so it wasn't designed with Cygwin in mind. Everything didn't have to be named ici though. But that's besides the point. And that will probably have to be the solution. Cygwin doesn't attempt to execute directories. What do you mean by Cygwin, in this case? Bash? Cygwin's implementation of exec()? It uses stat() to find out what type of thing foo is. Then it uses that information to decide how to handle foo. This is why I'm saying that something that handles the invocation of programs under Cygwin tries to execute directories: $ /opt/bin/ici -help bash: /opt/bin/ici: is a directory $ whiches ici /opt/bin/ici.exe /opt/bin/ici.dll /cygdrive/x/bin/ici.exe /cygdrive/x/bin/ici.dll $ ls -ld /opt/bin/Ici drwxr-xr-x 1 luke Domain Users 0 Oct 17 2005 /opt/bin/Ici It looks like something has stat()ed /opt/bin/ici and then decided it's been asked to execute that, and refusing (which makes a kind of sense), and bailing out with an error (*that* step seems wrong to me). I assumed that the logic which invokes foo.exe when you type foo should not be trying to execute a directory called foo. It's never right to try to execute a directory. I'm suggesting that instead of trying to do that and reporting an error and failing, the code should just skip past that as obviously wrong and fall through to the rest of its logic, which would in fact do the right thing - even if the foo.exe was in some other directory entirely, later on the PATH! Cheers, luke -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Directory existence prevents .exe execution
Larry Hall (Cygwin) wrote: On 04/18/2008, Luke Kendall wrote: Larry Hall (Cygwin) wrote: What do you mean by Cygwin, in this case? Bash? Cygwin's implementation of exec()? In this case, bash. Try it from, say, csh, and you'll see something a bit different. $ /opt/bin/ici -help CORRECT/opt/bin/Ici -help (y|n|e|a)? no /opt/bin/ici: Command not found. $ /opt/bin/ici -help CORRECT/opt/bin/Ici -help (y|n|e|a)? yes /opt/bin/Ici: Permission denied. Yep, it's no better. It even specifically offers me the optio to try to execute the directory. It uses stat() to find out what type of thing foo is. Then it uses that information to decide how to handle foo. This is why I'm saying that something that handles the invocation of programs under Cygwin tries to execute directories: $ /opt/bin/ici -help bash: /opt/bin/ici: is a directory $ whiches ici /opt/bin/ici.exe /opt/bin/ici.dll /cygdrive/x/bin/ici.exe /cygdrive/x/bin/ici.dll $ ls -ld /opt/bin/Ici drwxr-xr-x 1 luke Domain Users 0 Oct 17 2005 /opt/bin/Ici It looks like something has stat()ed /opt/bin/ici and then decided it's been asked to execute that, and refusing (which makes a kind of sense), and bailing out with an error (*that* step seems wrong to me). Well, didn't you ask to execute '/opt/bin/ici'? After all, that's what you typed. I don't see how it could be wrong to report back what you asked to execute is a directory. I thought that bash treated the first word on the line (after optional assignments to environment variables a la FRED=x run-some-command) as a command to execute, passing the remaining words on the line to the command as arguments? (Leaving aside things like backtic execution and variable expansion.) So I still think I asked for /opt/bin/ici to be executed by bash. I'd be interested to know if I've misunderstood. I also checked that bash doesn't work this way under Linux. I created a directory called ici (with execute permission, obviously), in the first directory in my PATH. I then ran ici from bash, and it did not tell me that ici was a directory and bail out - it executed the first ici executable it found later in my PATH. That's all I was hoping that Cygwin's bash would do, too. zsh under Cywgin is worse, though: $ /opt/bin/ici -help zsh: no such file or directory: /opt/bin/ici I assumed that the logic which invokes foo.exe when you type foo should not be trying to execute a directory called foo. It's never right to try to execute a directory. True enough. Hence the message. The directory isn't being executed here. I'm suggesting that instead of trying to do that and reporting an error and failing, the code should just skip past that as obviously wrong and fall through to the rest of its logic, which would in fact do the right thing - even if the foo.exe was in some other directory entirely, later on the PATH! If you ask for 'foo' or '/path/to/foo' and that's a directory, going beyond that looking for something else when you've found an exact match is a bit dangerous. You don't want to be taking too many liberties with the exe magic. Things could get ugly fast. That said, if you want an executable to be named foo and not foo.exe, you can do that on NT-based platforms. But again, here you're back to a situation where you won't be able to have a same-named directory right beside the executable. But that matches *nix. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Directory existence prevents .exe execution
On 15 Apr, Dyck, David wrote: how much control do you have on unix side? (you could create a symlink from ici.exe to ici on unix. True. And I suppose there are only rare programs that would suffer this problem. what about creating a new name for ici.exe and ici that could be found on both. Umm, I don't think I understand. Then we'd have to modify every script to change the #!/opt/bin/ici, wouldn't we? directories need to have 'x' attribute to be searchable (on unix) but I would also ask about your path why do you need an /opt/bin/ici directory on windows when if /opt/bin/ici was a directory on unix, where would the shell be finding ici executable? On Unix, it would be finding it under /opt/ici-3.0.1/lib/ici3. Since it should also work under Windows natively, we can't rely on using mount points under Cygwin, since they just wouldn't be visible. But maybe we could do something along those lines. It does seem like a corner case (in bash or in the exec call), that Cygwin would be better for handling. This corner case can't happen in Unix because Unix doesn't have implicit suffixes on commands: you can't have a directory and an executable in the same directory with the same name. (If you have a command called fred.sh, you type fred.sh to execute it, not fred.) I assume exec() stat()s a file, and then presumably does some special magic to change fred to fred.exe if it can't find fred. Suppose that when it does a stat() on fred, before it decides that it's found the right file to exec, it should check that fred isn't a directory. If it is a directory, it should consider that not found and the logic would flow through into the checking for .exe and whatever other arcane Windows executable-file suffixes make sense. But having not looked at the source, I confess I'm just guessing. Thanks, luke -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luke Kendall Sent: Tuesday, April 15, 2008 9:44 PM To: cygwin@cygwin.com Subject: Directory existence prevents .exe execution We have the Ici scripting language installed on Windows. Ici expects a directory called ici to exist alongside, where various libraries are installedd to provide extra functionality. Unfortunately, under Cygwin, if w try to run the command ici we get the error ici: command not found, because Cygwin chooses to try to execute the directory instead of the .exe: $ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr bash: /opt/bin/ici: is a directory $ ls -ld /opt/bin/ici drwxr-xr-x 1 luke Domain Users 0 Oct 17 2005 /opt/bin/ici $ ls -ld /opt/bin/ici.* -rwxr-xr-x 1 luke Domain Users 233503 Apr 18 2000 /opt/bin/ici.dll -rwxr-xr-x 1 luke Domain Users 24576 Jan 29 2003 /opt/bin/ici.exe I tried naming the ici directory Ici but it made no difference. The directory /opt/bin is mounted like so: $ mount \\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system (textmode,exec) Using binmode doesn't help. Is this a bug, that bash tries to execute a directory even when there's an executable (with an implicit .exe suffix, naturally) of the same name in existence ? If not, can anyone suggest a workaround? I can't just append a .exe to the #!/opt/bin/ici shell wrapper since then the scripts wouldn't run from Unix. Is there a bash option that controls this, maybe (I couldn't see one)? Regards, luke -- 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/ This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately. -- 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/
Directory existence prevents .exe execution
We have the Ici scripting language installed on Windows. Ici expects a directory called ici to exist alongside, where various libraries are installedd to provide extra functionality. Unfortunately, under Cygwin, if w try to run the command ici we get the error ici: command not found, because Cygwin chooses to try to execute the directory instead of the .exe: $ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr bash: /opt/bin/ici: is a directory $ ls -ld /opt/bin/ici drwxr-xr-x 1 luke Domain Users 0 Oct 17 2005 /opt/bin/ici $ ls -ld /opt/bin/ici.* -rwxr-xr-x 1 luke Domain Users 233503 Apr 18 2000 /opt/bin/ici.dll -rwxr-xr-x 1 luke Domain Users 24576 Jan 29 2003 /opt/bin/ici.exe I tried naming the ici directory Ici but it made no difference. The directory /opt/bin is mounted like so: $ mount \\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system (textmode,exec) Using binmode doesn't help. Is this a bug, that bash tries to execute a directory even when there's an executable (with an implicit .exe suffix, naturally) of the same name in existence ? If not, can anyone suggest a workaround? I can't just append a .exe to the #!/opt/bin/ici shell wrapper since then the scripts wouldn't run from Unix. Is there a bash option that controls this, maybe (I couldn't see one)? Regards, luke -- 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: Possible Defect: Long delay in some progam executions
Gregory Rosensteel wrote: Hello, I performed a fresh install of cygwin on windows XP. I am seeing that some commands take a really long time to execute, I was wondering if anyone else is experience this. For example, the 'which' command takes 2s while the 'pwd' command runs just fine. Please see my sample output below and if you have encountered this before, let me know what's up! $ time which Usage: which [options] [--] COMMAND [...] Write the full path of COMMAND(s) to standard output. --version, -[vV] Print version and exit successfully. --help, Print this help and exit successfully. --skip-dot Skip directories in PATH that start with a dot. --skip-tilde Skip directories in PATH that start with a tilde. --show-dot Don't expand a dot to current directory in output. --show-tilde Output a tilde for HOME directory for non-root. --tty-only Stop processing options on the right if not on tty. --all, -aPrint all matches in PATH, not just the first --read-alias, -i Read list of aliases from stdin. --skip-alias Ignore option --read-alias; don't read stdin. --read-functions Read shell functions from stdin. --skip-functions Ignore option --read-functions; don't read stdin. Recommended use is to write the output of (alias; declare -f) to standard input, so that which can show aliases and shell functions. See which(1) for examples. If the options --read-alias and/or --read-functions are specified then the output can be a full alias or function definition, optionally followed by the full path of each command used inside of those. Report bugs to [EMAIL PROTECTED]. real0m2.082s user0m0.030s sys 0m0.000s [EMAIL PROTECTED] ~ $ time pwd /home/Greg real0m0.001s user0m0.000s sys 0m0.000s pwd is a shell built-in, which must be searched for along your $PATH. You could check if any of the early paths in $PATH are network shares (which would obviously be slower). It gets especially bad if some of those network shares drop off the network - you have to wait for a timeout, to proceed to the next $PATH element. luke -- 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: Login shell?
On 18 Jan, Thorsten Kampe wrote: * Luke Kendall (Thu, 18 Jan 2007 18:03:33 +1100 (EST)) On 17 Jan, Thorsten Kampe wrote: * Luke Kendall (Wed, 17 Jan 2007 13:29:31 +1100 (EST)) I just want to confirm, that the traditional Cygwin way of achieving this same result is still to modify cygwin.bat on a PC-by-PC basis (assuming one user per PC), rather than to take the traditional Unix way and change the shell field in /etc/passwd? If you want to change your login shell you modify the passwd file. That's what we do, yes, because our modified cygwin.bat runs shell.exe, not bash. Well, that's not what you do. If you login (via ssh for instance) cygwin.bat doesn't get executed. Good, so it's just the desktop startup for the shells that might have a neater solution. cygwin.bat is just a target for the shortcut. But doesn't cygwin.bat run bash (not the shell specified in /etc/passwd)? That correct. I think the zsh maintainer has a batch file that creates links to start zsh instead of bash. That sounds like it doesn't use /etc/passwd. mkzsh just creates a zsh.bat Perhaps Michael should have called shell.exe login.exe :-) shell.c is only 60-odd lines long. Just to be quite explicit, here is our modified cygwin.bat: @echo off C: chdir C:\cygwin\bin shell It seems neater to me than the current approach. The neat approach is to check if your problem still exists and trying to solve it. I think the current approach would be fine if the desktop shortcuts were named bash (or zsh for zsh.bat), rather than Cygwin. But for commands like rxvt, xterm, Cygwin, it seems neater not to hard-code the choice of shell when the choice of shell has been defined in /etc/passwd. Sorry, I don't think I can explain the appeal any better than that. luke -- 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: Login shell?
On 17 Jan, Thorsten Kampe wrote: * Luke Kendall (Wed, 17 Jan 2007 13:29:31 +1100 (EST)) I just want to confirm, that the traditional Cygwin way of achieving this same result is still to modify cygwin.bat on a PC-by-PC basis (assuming one user per PC), rather than to take the traditional Unix way and change the shell field in /etc/passwd? If you want to change your login shell you modify the passwd file. That's what we do, yes, because our modified cygwin.bat runs shell.exe, not bash. cygwin.bat is just a target for the shortcut. But doesn't cygwin.bat run bash (not the shell specified in /etc/passwd)? I think the zsh maintainer has a batch file that creates links to start zsh instead of bash. That sounds like it doesn't use /etc/passwd. Perhaps Michael should have called shell.exe login.exe :-) shell.c is only 60-odd lines long. Just to be quite explicit, here is our modified cygwin.bat: @echo off C: chdir C:\cygwin\bin shell It seems neater to me than the current approach. I'd like to propose making it an official part of Cygwin. But I can't do that since it's not my code: Michael Wardle wrote it (and submitted it to this list). luke -- 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: Changed handling of ! in /bin/sh?
On 17 Jan, Christopher Faylor wrote: On Wed, Jan 17, 2007 at 06:14:27PM -0500, Buchbinder, Barry (NIH/NIAID) [E] wrote: Eric Blake wrote on Tuesday, January 16, 2007 10:18 PM: According to Luke Kendall on 1/16/2007 6:53 PM: Or, copy /bin/ash.exe to replace /bin/sh.exe. Not recommended. The reason cygwin moved to bash as /bin/sh was to avoid ash bugs. I thought that it was more to avoid all the complaints that sh did not behave like bash, which is what many people expected. You're right that was also a reason. Wow, I'm really showing my age, aren't I? :-) luke -- 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: Changed handling of ! in /bin/sh?
Executive summary: thanks to Eric's reply and information, I have a couple of workable soultions. Thanks, Eric! For people who want the details, see below. On 16 Jan, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Luke Kendall on 1/15/2007 9:34 PM: On 15 Jan, Eric Blake wrote: SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:monitor There you go. You have history enabled in SHELLOPTS, which is a non-POSIX extension, and explains why /bin/sh is not doing what you expected. Your shell scripts are inheriting interactive behavior, and trying to do history expansion when they encounter !. Ah! I'm not setting that - it comes for free. :-) Yes, bash always has a read-only variable named SHELLOPTS. The difference is whether it is exported to the environment, or local to the shell. Any idea how to turn it off? set +o history Ah, okay. But I'm still hoping for a solution that won't require me to edit 200+ scripts (e.g. to add set +o history 2 /dev/null). I grepped in /etc/* and /etc/profile.d/* for SHELLOPTS but didn't find it. And you won't, because by default the cygwin base files don't currently export SHELLOPTS, for the very reason that it tends to interfere with non-interactive scripts. Although, as you imply, some of the options are specifically to control some behaviours of non-interactive scripts. In the System Env Vars in Windows I define SHELLOPTS to be igncr (only). There you go - that is the action that exported it into the environment, instead of leaving it shell-local. Yes, because I need a way to affect all the non-interactive scripts for all the Cygwin users who access the shared drive with the scripts on it, or who cvs checkout a local copy of scripts. But thanks for explaining the operation. If I echo %SHELLOPTS% in a cmd.exe window it's set to igncr only. What's defining the other things? bash, as part of it's normal operation, makes SHELLOPTS track all shell options, not just the ones requested at startup. Thanks for that explanation, too. It's a readonly env variable, isn't it? I.e. I don't think I can correct it from within a bash shell? You can correct it in bash indirectly by setting shell options. Do you mean, like adding set +o history into /etc/profile? Er, but that would turn it off for interactive use. And if I set igncr so that everything can see it then it has a side effect of exporting the SHELLOPTS, so then the automatically set options are of course in the env so they affect every sub shell. Ouch! It seems like I'm in a catch 22 situation. Unless I'm still misunderstanding? We are working in a heterogeneous environment, and use CVS for source code (and script) management, so that's why we want to allow CR/LF in script files. Have you considered using text mounts for your script files instead? I intentionally ordered my recommendations in the release announcement in the order that I thought were most supported; and setting SHELLOPTS is a lower-rated feature (in my mind) than using proper line endings or proper mount points. The other day I mailed that this was no longer working. Some more investigation just now clarifies it: I misunderstood. (For reference, I wrote Re: CR/LF problems after upgrade With a freshly-installed Cygwin from a mirror that's a few days old, and with c:\cygwin\bin mounted textmode and a network share directory of bash scripts also mounted in textmode, using scripts that had CR/LF endings, each blank line in the script caused an error, and there were other errors too. In short, I don't think the text mounts are doing their magic correctly at the moment. (The scripts mentioned above did work correctly in much older Cygwins using text mounts.) ) I have \\samba\x mounted as X:, a textmode mount. But (to avoid having x:/cygnus in my :-separated PATH), I have //samba/x/cygnus in my PATH. I assumed (wrongly) that because of the text mount of that share that it would do the CR/LF mapping. I think a solution is therefore to mount x: in textmode and *also* mount //samba/x in text mode. I just tried this, below, and it does indeed fix the problem. So that's one solution - thanks, Eric! mkdir /var/samba-x-mountpoint mount -tfx //samba/x /var/samba-x-mountpoint Well, I think we have to use it to define igncr. And all bash users who use it for interactive shells would expect to have a history, yes! Then write wrappers around your development tools that disable igncr, or write a script and set BASH_ENV pointing to that script that only sets igncr if the current shell is interactive (if $- contains i), rather than setting SHELLOPTS. Or use /bin/sh instead of /bin/bash as your shell. Sorry, let me see if I understand. We want igncr enabled, not disabled (or the text mount idea
Login shell?
A long time ago, we had the weird problem that Cygwin users who used zsh as their main shell, would find that the .zprofile (or whatever it's called) would not be run at login - but only if their home directory had been created by Cygwin's mkdir! (It *would* run if their $HOME directory had been created by Windows explorer!) Despite examining closely with Windows GUI tools and getfacl/setfacl, we couldn't resolve the problem. But Michael Wardle, a subscriber on this list, kindly provided shell.c (on Mar 24 2005, I think), which opened /etc/passwd, found the user's preferred shell, and started that (falling back to /bin/bash by default in case of problems). So I changed our Cygwin startup .bat file to run shell.exe instead of the hard-coded bash --login -i, and all was well. I just want to confirm, that the traditional Cygwin way of achieving this same result is still to modify cygwin.bat on a PC-by-PC basis (assuming one user per PC), rather than to take the traditional Unix way and change the shell field in /etc/passwd? Or has some other system been instituted? Sorry, I'm a bit out of touch. luke -- 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: Changed handling of ! in /bin/sh?
On 16 Jan, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Luke Kendall on 1/16/2007 6:53 PM: Do you mean, like adding set +o history into /etc/profile? Er, but that would turn it off for interactive use. And if I set igncr so that everything can see it then it has a side effect of exporting the SHELLOPTS, so then the automatically set options are of course in the env so they affect every sub shell. Ouch! It seems like I'm in a catch 22 situation. Yes, unless I can come up with a patch that makes bash smarter about which SHELLOPTS options it will pay attention to when started non-interactively. Okay, then I understand. But you've also given us two or three other solutions, too! I have \\samba\x mounted as X:, a textmode mount. But (to avoid having x:/cygnus in my :-separated PATH), I have //samba/x/cygnus in my PATH. Why not put /cygdrive/x/cygnus in your path, then? Good question! :-) It's mainly because we might use other Unix environments too (Uwin or MKS or MS SFU shudder), and we'd like everything as far as possible to use common names. Sorry, let me see if I understand. We want igncr enabled, not disabled (or the text mount idea above). By developer tools do you mean all the scripts? I just read up on BASH_ENV: so I could have its script say: if expr $- : .*i /dev/null then : else set +o history fi Or, more efficiently (fewer processes, and fewer lines): case $- in *i*) ;; *) set +o history ; esac Neat! Or, copy /bin/ash.exe to replace /bin/sh.exe. Not recommended. The reason cygwin moved to bash as /bin/sh was to avoid ash bugs. Okay, so that's out. Please let me restate, to check I understand what you mean by you ran bash interactively first: you simply mean, I started an interactive shell? (So that sees SHELLOPTS in the env because I put it there, then the interactive shell options get set, which conflict with POSIX.) Yes - the fact that you ran bash interactively, and from that shell started the non-interactive scripts, explains why the non-interactive scripts inherited the SHELLOPTS set with interactive options. If you use /bin/sh as your login shell, then fewer options will be set in SHELLOPTS automatically. Do you mean, change /etc/passwd so it's /bin/sh, and then change .profile to exec bash? Or even change cygwin.bat to invoke sh instead of bash, if you use the default cygwin.bat created when you installed cygwin. Anyway, I think I now have a few workarounds, thanks to your patient explanations. I hope that the BASH_ENV option works out for you. I personally don't use CRLF line endings, so I don't have to worry about igncr in my daily use. I'm actually planning to make sure all the PATH elements are mounted text mode, since it seems more efficient (since there'd be a little less overhead in forking shells). Thanks again, luke -- 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/
Changed handling of ! in /bin/sh?
I have a script that starts #!/bin/sh which has occasional things like the use of an exclamation mark in a string, or a case statement to accept an exclamation mark to throw a shell, which has stopped working now that I've upgraded to a non-ancient Cygwin (i.e. now that sh == bash). It seems that /bin/sh is now trying to interpret ! as bash would! How can I make /bin/sh work like a Bourne shell, globally? The same script works fine if run by ash instead of bash, and it also works fine under Linux (where sh is bash), so it seems like there's some problem with bash's emulation of sh under Cygwin. I assume from the discussion about making sh == bash back in 2005, that when invoked as sh it's supposed to be a drop-in replacement for sh, right? Any advice? We have over 200 scripts that will need alteration, otherwise. Any idea what I'm doing wrong? luke -- 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: Changed handling of ! in /bin/sh?
On 15 Jan, Eric Blake wrote:
According to Luke Kendall on 1/15/2007 7:39 PM:
I have a script that starts #!/bin/sh which has occasional things like
the use of an exclamation mark in a string, or a case statement to
accept an exclamation mark to throw a shell, which has stopped working
now that I've upgraded to a non-ancient Cygwin (i.e. now that sh ==
bash).
Simple test case, please?
Here's one example (the script is called yorn):
#!/bin/sh
#
# yorn query: loops until y or n, returns for if
#
while true
do
printf $* (y, n, or !) ? /dev/tty
read ans
case X$ans in
Xy*|XY*)
exit 0
;;
Xn*|XN*)
exit 1
;;
X!|Xsh)
echo Command level escape - hit CTRL-D when finished. /dev/tty
exec /dev/tty 21
PS1='$$ ' sh -i
echo
;;
*)
echo Please answer yes or no (or ! to temporarily escape to Unix):
/dev/tty
;;
esac
done /dev/tty
I also just wrote this which fails with a line 2: !: event not found:
#!/bin/sh
echo Hello world!
It seems that /bin/sh is now trying to interpret ! as bash would!
How can I make /bin/sh work like a Bourne shell, globally?
You can't. Bourne shell is obsolete (unless you are on Solaris, and are a
die-hard to use their /bin/sh instead of /usr/xpg4/bin/sh), because it
lacks functions, ${} command substitution, and other useful features of
modern shells. Rather, you can make /bin/sh behave like a POSIX shell -
you do that by invoking bash as /bin/sh instead of /bin/bash (ie. you are
ALREADY getting POSIX behavior).
POSIX behaviour would be close enough. Note that the same script runs
okay under Linux, so I agree that by simply having the #!/bin/sh at the
start it should also work under Cygwin.
ash was slowly moving in this direction,
but had its own set of bugs. If your legacy scripts don't behave properly
with /bin/sh, then most likely, it is a bug in your script according to
the rules of POSIX, that just happened to work with ash because of a
matching bug in ash.
Well, please see what you think from the example above.
The same script works fine if run by ash instead of bash, and it also
works fine under Linux (where sh is bash), so it seems like there's
some problem with bash's emulation of sh under Cygwin.
That's a pretty harsh claim without a sample script to back it up. I try
very hard to make Cygwin's /bin/sh exactly like Linux's /bin/sh.
Sorry, I didn't mean to sound harsh. Please let me know if you need
any kind of cygcheck output. FWIW:
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:monitor
Thanks, Eric.
Regards,
luke
--
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: Changed handling of ! in /bin/sh?
On 15 Jan, Eric Blake wrote: SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:monitor There you go. You have history enabled in SHELLOPTS, which is a non-POSIX extension, and explains why /bin/sh is not doing what you expected. Your shell scripts are inheriting interactive behavior, and trying to do history expansion when they encounter !. Ah! I'm not setting that - it comes for free. :-) Any idea how to turn it off? I grepped in /etc/* and /etc/profile.d/* for SHELLOPTS but didn't find it. In the System Env Vars in Windows I define SHELLOPTS to be igncr (only). If I echo %SHELLOPTS% in a cmd.exe window it's set to igncr only. What's defining the other things? It's a readonly env variable, isn't it? I.e. I don't think I can correct it from within a bash shell? We are working in a heterogeneous environment, and use CVS for source code (and script) management, so that's why we want to allow CR/LF in script files. I still hope to find time to getting around and trying to teach bash which options in SHELLOPTS should be ignored when starting a non-interactive session. In the meantime, I would recommend turning history off, or at least changing the history expansion character, if you absolutely must set SHELLOPTS. Well, I think we have to use it to define igncr. And all bash users who use it for interactive shells would expect to have a history, yes! Are the extra options being turned on automatically only for interactive shells? Do you mean that if I want POSIX behaviour from shell scripts then I can't have history for interactive shells? And if all else fails, and you are still running scripts with history enabled, then according to bash documentation, the only way to bypass the history character is to quote it, but that in double quotes, \! preserves the \, so you have to write something like: echo Hello world\! Sure, I know. Doing that for 200 scripts will be a pain, especially since they will then execute with literal \!s when the same scripts are run from Linux. As in (yes, I just tried): Hello world\! Perhaps a simple workaround is to replace /bin/sh with /bin/ash? I'm puzzled that others haven't found the same problem, so I still suspect there must be something unusual about my setup. Cygwin and Linux should run the same shell scripts the same way (the simplest example being the Hello world example). Hmm, let's see, I have: Linux script: braceexpand:hashall:interactive-comments:posix Linux interactive: braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor:posix Cygwin script: braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:monitor:posix Cygwin interactive braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:monitor:posixbraceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:monitor So I think I understand the problem (SHELLOPTS are set differently under Linux and Cygwin) but I don't know how to control the definition of SHELLOPTS to make them the same. I can't change it in a bash script because it's readonly. Any advice? Regards, luke -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problem of cygwin X fixed
On 25 Nov, Emacs Rocky wrote: Dear: I just sent a mail to complain I can't start X in cygwin. Now, I fount the solution in old mail-list. Anybody experienced the same problem can refer to http://sourceware.org/ml/cygwin-xfree/2006-10/msg00051.html the key point is : You need to mount the /usr/X11R6/lib/X11/fonts with binary mode. but , I don't know why it worked well in another machine without the mount for /usr/X11R6/lib/X11/fonts . anyway. thanks to all you guys. Rocky This used to be broken in Cygwin for a while, then it was fixed. I reinstalled from a snapshot from Jan 3rd 2007 and the problem had returned. I had no mount point for X at all, so I don't know why the problem occurred. I did have a warning from setup saying that setup.ini indicated it was newer than the version setup was expecting to install. I re-ran setup a couple more times, re-installing the fonts (no complaints about possibly mismatched setup.ini file this time), with no luck. Anyway, because I had no mount of the X fonts directory at all, I did this to create one: $ mount -b c:\cygwin\usr\lib\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts and re-ran setup to reinstall the fonts yet agai, and yes, X could now start, the problem is fixed. luke -- 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/
Re: CR/LF problems after upgrade
On 5 Jan, fschmidt wrote: 3. Cygwin text mounts automatically work with either line ending style, because the \r is stripped before bash reads the file. If you absolutely must use files with \r\n line endings, consider mounting the directory where those files live as a text mount. However, text mounts are not as well tested or supported on the cygwin mailing list, so you may encounter other problems with other cygwin tools in those directories. I don't know what mounts are, or how to use them. With a freshly-installed Cygwin from a mirror that's a few days old, and with c:\cygwin\bin mounted textmode and a network share directory of bash scripts also mounted in textmode, using scripts that had CR/LF endings, each blank line in the script caused an error, and there were other errors too. In short, I don't think the text mounts are doing their magic correctly at the moment. (The scripts mentioned above did work correctly in much older Cygwins using text mounts.) philosophy I wonder how many centuries of human endeavour has been absorbed because of the decision to use CR+LF as line endings in DOS? /philosophy luke -- 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: Updated: suite3270-3.3.4p7-1, c3270-3.3.4p7-1, pr3287-3.3.4p7-1 , s3270-3.3.4p7-1, tcl3270-3.3.4p7-1, x3270-3.3.4p7-1
On 8 Feb, Peter A. Castro wrote: This is an update for the suite3270 packages based on version 3.3.4p6 plus patch 07 for c3270, s3270, tcl3270 and x3270 yielding 3.3.4p7 suite3270-3.3.4p7-1.tar.bz2 c3270-3.3.4p7-1.tar.bz2 pr3287-3.3.4p7-1.tar.bz2 s3270-3.3.4p7-1.tar.bz2 tcl3270-3.3.4p7-1.tar.bz2 x3270-3.3.4p7-1.tar.bz2 This release contains Paul Mattes's latest code and fixes to the suite, which include: - several bug fixes and infrastructure changes. - support for SSL. - DBCS and East Asian languages support. NOTE: The Cygwin release does not currently incorporate DBCS or East Asian languages support (yet). Once my porting work for ICU is completed, suite3270 will be re-released with full DBCS and East Asian languages support. I would welcome a short sentence describing what they actually are! luke -- 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/
An interesting tidbit
Cygwin has certainly grown in leaps and bounds thanks to the hard work of the developers, and all the numerous contributors and porters. I chanced to notice that a download I had from July 2001 was 175MB, a download from March 2005 was 2.5GB! luke -- 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: Updated: libungif-4.1.4-1
On 5 Nov, Yaakov S (Cygwin Ports) wrote: The following packages have been updated in the Cygwin distribution: *** libungif-4.1.4-1 +++ libungif4-4.1.4-1 (NEW) Libungif is a library for manipulating GIF files, without the patent-encumbered LZW compression code. Are there still countries left, in which this patent has not yet expired? luke -- 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: CYGWIN Installation Help Needed
On 14 Oct, S.Sunil Kumar wrote:
I would like to install CYGWIN in my WIN-XP-HE PC.
I have downloaded the CYGWIN Program from one of the
FTP site by running the SETUP.EXE file.
But I would like to know about how to install it in
the XP System.
There's a mailing list where questions like these can be answered.
I have CC-ed my reply to your question there. I'm surprised you asked
us directly.
Anyway, it sounds like all you need to do is run setup.exe on your home
PC. If that's what you meant, see http://cygwin.com/faq/faq.setup.html
The complete Cygwin download these days is about 2GB. If instead you
meant that you want to transfer that download to your home PC, then see
http://cygwin.com/faq/faq.setup.html#faq.setup.cd
In addition, here's something you can use that makes it easier to pick
out just the current version of each package (instead of every
version of the packages). It assumes you have used rsync to get a
mirror - so there should be a setup.exe, .bz2, and .ini file along with
a release directory.
It's actually excerpted from a slightly longer script, but there's no
point sending that since it depends on other things we do (like
automatically checking the MD5 signatures of all packages to make sure
the download is complete).
FWIW, here it is. With this, the download can usually fit on a CD.
#!/bin/sh
dst=$HOME/cygwin-for-CD
test -s setup.bz2 || exit 1
test -d $dst || exit 1
echo setup.exe
echo setup.bz2
echo setup.ini
bzip2 -cd setup.bz2 | awk '
BEGIN {
package = 0;
}
# Look for start of package block
/^@/ {
package = 1;
next;
}
# If inside a package block, look for a line beginning with install:
package /^install: / {
print $2;
package = 0;
}'
) | cpio -pdmuv $dst
luke
--
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: cygwin forgets CTRL key press
On 16 Sep, Dave Korn wrote: I suspect it may be the keyboard or perhaps the KVM switch Bingo. That'll be it. It cancels keypresses to prevent state getting stuck when you switch from one machine to another. Yes, after trying (and failing to reproduce the problem here on other PCs), it occurred to me it might be the KVM switch. If I use the laptop keyboard, there is no such problem. It hadn't occurred to me to try a non-Cygwin program like notepad (a great suggestion, Brooks), and of course the same problem occurs there. Thanks! luke -- 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/
cygwin forgets CTRL key press
Has anyone else noted that in vi (either in a plain Cygwin window or in an rxvt window, in an X session or not, also in xterm), that if you hold down the CTRL key and press keys at intervals (like F to page down through a file), and wait four seconds before another key press it's as if you don't have CTRL pressed at all? You have to release it and press afresh. The same applies to more: hold CTRL down and press f, and it beeps at you to indicate that's invalid; still hold CTRL down, wait 4 seconds, then press f again, and it pages forward. This behaviour has been present for years, BTW, it's not new. luke -- 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: cygwin forgets CTRL key press
On 15 Sep, Igor Pechtchanski wrote: On Fri, 16 Sep 2005, Luke Kendall wrote: Has anyone else noted that in vi (either in a plain Cygwin window or in an rxvt window, in an X session or not, also in xterm), that if you hold down the CTRL key and press keys at intervals (like F to page down through a file), and wait four seconds before another key press it's as if you don't have CTRL pressed at all? You have to release it and press afresh. The same applies to more: hold CTRL down and press f, and it beeps at you to indicate that's invalid; still hold CTRL down, wait 4 seconds, then press f again, and it pages forward. This behaviour has been present for years, BTW, it's not new. I suspect it's not Cygwin-related. This sounds like the Windows sticky keys accessibility feature -- if any modifier key is held for some period of time (more than 8 seconds, I think), Windows offers to turn on sticky keys. Even if the feature is disabled, the 8-second timer may be started every time the key is pressed. I wouldn't be surprised if this is the cause of the behavior you observe... Igor I checked, but found that I have Sticky keys turned off in the control panel accessibility options. Also, I've timed it roughly and it's close to 4 seconds, not 8. And if it's due to this, wouldn't Larry have been able to reproduce it?? I'm now checking with other Cygwin users here to see if we can see what controls the reproducibility. I'll let you know the results. (BTW, FWIW I'm running Windows XP sp1.) Regards, luke -- 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: slogin and problems with network shares
On 8 Sep, Larry Hall wrote: Certainly slogin asks me for my password. Could it do this if there was some way the password synchronisation between the Unix and Windows parts of our network had changed? I've attached some debug ssh output, in case that helps. Looks OK. Did this work before with the same install? If so, I would suspect something outside the Cygwin realm as the cause for this problem. It worked a long time ago. As I've updated Cygwin from time to time, sshd stopped working entirely. The recent update at least allows slogin to work, again, out of the box (well, just by running ssh-host-config). luke -- 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: About Cygwin announcements
On 8 Sep, Corinna Vinschen wrote: What's different in this approach in relation to having an announcement mailing list archive? Well, except for double bookkeeping. I'm trying to think of a way to improve the quality of the announcements. Several times I've found out about cool new features from discussions of problems on the mailing list. Checking back into the announcements, the cool new feature was never announced. So I'm trying to think of ways to make it easier to remember the cool new features, to make the announcers' job easier and less reliant on memory. If somebody forgets to announce (and the head maintainers forget to kick this somebody), then the same would happen with the CVS entry, wouldn't it? I'm hoping it's less likely. E.g. if the CVS commit template is currently something like: CVS: -- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Modified Files: CVS:some-filename CVS: -- then I'm thinking that changing it to something like this might help remind the developer to make a note for the announcer to use: CVS: --- Is this change worth noting in the package changelog? - CVS: CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Modified Files: CVS:some-filename CVS: -- Do you see what I mean? luke -- 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: slogin and problems with network shares
On 8 Sep, Larry Hall wrote: At 11:14 PM 9/7/2005, you wrote When I slogin to WIndows now, and enter my password, the network shares seem to behave differently. Access is denied. $ net use L: '\\cisra\share' Enter the user name for 'cisra\share': System error 1223 has occurred. The operation was canceled by the user. The password is invalid for \\cisra\share. I get this if I try the above after sshing with pubkey authentication. Works fine with password auth. I'm using the same versions of ssh and Cygwin as you list. Are you sure you've logged in with password auth? How would I check? Certainly slogin asks me for my password. Could it do this if there was some way the password synchronisation between the Unix and Windows parts of our network had changed? I've attached some debug ssh output, in case that helps. luke ; slogin -v -v doyle OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug2: ssh_connect: needpriv 0 debug1: Connecting to doyle [10.14.5.245] port 22. debug1: Connection established. debug1: identity file /u/luke/.ssh/identity type -1 debug1: identity file /u/luke/.ssh/id_rsa type -1 debug2: key_type_from_name: unknown key type '-BEGIN' debug2: key_type_from_name: unknown key type 'Proc-Type:' debug2: key_type_from_name: unknown key type 'DEK-Info:' debug2: key_type_from_name: unknown key type '-END' debug1: identity file /u/luke/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.1 debug1: match: OpenSSH_4.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server-client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 120/256 debug2: bits set: 1015/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'doyle' is known and matches the RSA host key. debug1: Found key in /u/luke/.ssh/known_hosts:53 debug2: bits set: 1038/2048 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /u/luke/.ssh/identity debug1: Trying private key: /u/luke/.ssh/id_rsa debug1: Offering public key: /u/luke/.ssh/id_dsa debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug1: Next authentication
Re: file not working on executables?
On 7 Sep, Corinna Vinschen wrote: Oh well, why are you still using textmode? We should drop this choice from setup.exe entirely. The logic went: 1) Under Windows, most of the programs we use are native Windows ones, so we choose DOS style line endings during Cygwin install. 2) I assume that Unix text processing programs like sed, awk, troff, etc. prefer to see LF rather than CR-LF. I've just now re-read http://cygwin.com/cygwin-ug-net/using-textbinary.html. (I can't begin to imagine how much pain this CR/LF issue must cause you guys!) Did you give the advice above because basically all the Cygwin programs that treat lines as records, now open the file in text mode; and all other Cygwin programs open files in binary mode? (Including file.exe, now, thank you!) The URL above may need an update, then? (BTW, there's a reference in the URL to points a-e which should be points 1-5 to agree with the rest of the text). file doesn't cope with textmode right now. I'll fix it to use always binmode. Thanks very much for that, Corinna. Regards, luke -- 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/
About Cygwin announcements
Despite reading all the Cygwin announcement emails assiduously, I'm occasionally surprised to learn of significant improvements that weren't mentioned in the announcements. No one has a perfect memory, so I can easily see how it'd be easy to overlook mentioning some great new feature, in an announcement. Can anyone think of a way to make it easier to produce announcement emails that faithfully reveal all the great work that's gone on? What about storing a changelog file in cvs for each package, and encouraging people to update the changelog (say, by altering the default text that CVS shows you when you commit a change?). Just thinking out loud ... luke -- 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/
slogin and problems with network shares
When I slogin to WIndows now, and enter my password, the network shares seem to behave differently. Previously, I could do this to restore all the network connections: if [ ! -z $SSH_CONNECTION ] then echo Logged in via ssh: now restoring any network connections net use | \ sed -n s/^Unavailable[ \t]*\(.:\)[ \t]*\(.*\\\[^ ]*\) *Microsoft Windows Network/net use \1 '\2'/p \ | sh /dev/null 21 # NB: the output is useless. fi Which turns the output from net use: $ net use New connections will be remembered. Status Local RemoteNetwork --- Unavailable L:\\cisra\share Microsoft Windows Network Unavailable P:\\abba\planning Microsoft Windows Network Unavailable U:\\samba\luke Microsoft Windows Network Unavailable W:\\samba\install\win32 Microsoft Windows Network Unavailable Y:\\samba\photorec Microsoft Windows Network Unavailable Z:\\zoom\adaytumMicrosoft Windows Network OK \\handel\dMicrosoft Windows Network The command completed successfully. into this: net use L: '\\cisra\share' net use P: '\\abba\planning' net use U: '\\samba\luke' net use W: '\\samba\install\win32' net use Y: '\\samba\photorec' net use Z: '\\zoom\adaytum' But that no longer works. Below, you'll see that the drive mapping for X: has *not* been performed. $ net use handel\\d x: The command completed successfully. $ net use New connections will be remembered. Status Local RemoteNetwork --- Unavailable L:\\cisra\share Microsoft Windows Network Unavailable P:\\abba\planning Microsoft Windows Network Unavailable U:\\samba\luke Microsoft Windows Network Unavailable W:\\samba\install\win32 Microsoft Windows Network Unavailable Y:\\samba\photorec Microsoft Windows Network Unavailable Z:\\zoom\adaytumMicrosoft Windows Network OK \\handel\dMicrosoft Windows Network The command completed successfully. $ ls -l x:/ ls: x:/: No such file or directory And the commands seem to fail in odd ways even when typed manually: $ net use samba\\luke u: System error 5 has occurred. Access is denied. $ net use L: '\\cisra\share' Enter the user name for 'cisra\share': System error 1223 has occurred. The operation was canceled by the user. The password is invalid for \\cisra\share. $ net use U: '\\samba\luke' Enter the user name for 'samba': System error 1223 has occurred. The operation was canceled by the user. The password is invalid for \\samba\luke. $ net use U: samba\\luke Enter the user name for 'samba': System error 1223 has occurred. The operation was canceled by the user. The password is invalid for \\samba\luke. If I run a cmd.exe shell from inside bash under ssh and try this, it fails in an interesting way (note that it seems to try to read input from somewhere other than stdin or the terminal, and reject the (empty) password that it appeared to read: D:\home\lukenet use x: \\handel\d /user:cisra\luke net use x: \\handel\d /user:cisra\luke Enter the password for 'cisra\luke' to connect to 'handel': Enter the password for 'cisra\luke' to connect to 'handel': System error 5 has occurred. Access is denied. The password is invalid for \\handel\d. The system is running Windows XP SP1. cygcheck -s attached. Any ideas? Would this be a Cygwin/OpenSSH change, or a Windows service pack thing, or a Samba problem, or ...? What should I do to try to track down why this no longer works? I've rebooted, which hasn't made a difference. luke Cygwin Configuration Diagnostics Current System Time: Thu Sep 08 13:08:31 2005 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: \\samba\syncopt\microsoft.x86.win\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\Tcl\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\nsr\bin C:\cygwin\bin x:\bin c:\mysql\bin c:\jdk1.3.1_01\jre\bin\hotspot D:\home\MediaPortal\mp\build\win32\bin c:\Program Files\Common Files\Adaptec Shared\System c:\Program Files\Canon\MediaPortal\bin c:\Program Files\Rational\common c:\Program Files\Adobe\Illustrator CS\Plug-ins\CAT c:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT
Re: Administrator vs Administrators
On 6 Sep, Igor Pechtchanski replied to: Can someone correct my understanding if I've got this wrong? I think Administrator means the administrator account on the local machine, Administrators means the administrative account for the machine in the domain (workgroup). Nope, Administrator is a local user; Administrators is a local *group*. Windows allows groups to act as users: own files, etc. Ah, okay, thanks. (Until we added the 's' we were getting permission problems in installing, updating and removing Cygwin if the user had admin rights but wasn't the person who'd installed it. On my PC running cygwin I can execute the command properly. So I have no idea what's going on here! Windows doesn't care about the names of users/groups -- it goes by SIDs. Cygwin uses /etc/passwd to map names into SIDs. The information for the Administrators group is probably missing from /etc/passwd on Iain Templeton's machine -- mkpasswd -g /etc/passwd could fix that, though this is supposed to be done automatically. Done automatically by the base-passwd package? Ah! Thanks for that info too. As part of our post-install process, because no domain users used to be added at all, I do mkpasswd -l /etc/passwd # Add system accounts. mkpasswd -d /etc/passwd So that's my fault. I didn't know about the -g for groups, so that explains that. So as to not miss out on any special stuff done by setup, it looks like I need to do something like: cat /etc/passwd xxx # Preserve any special accounts. mkpasswd -l xxx # Add system accounts. mkpasswd -d xxx sort -u xxx /etc/passwd The cygcheck output shows that the base-passwd package is 1.1-1. This is likely to be the reason for the above -- the latest is 2.2-1. I'd update base-files too -- he's a full major version out of date. Did he use a stale mirror? In a way. His version, from memory, is probably over a year old. Many people here don't like to take a risk and install the latest stuff. E.g. he likes to use zsh, and it took hours of his time to discover that its profile wouldn't source unless the user's home directory had been created by Windows Explorer rather than Cygwin's mkdir. Once he got things working for his purposes, he was happy to stay with that. [...] -rw-r--r-- 1 Administrators SYSTEM 8686596 Sep 2 18:00 xxx Heh, and here we thought fortune was dirty... :-) [scratches head] Because of the xxx? Anyway, thanks again Igor, luke -- 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/
Does setup.exe ignore setup.hint md5 checksum?
I only ask because setup didn't appear to notice that libgcrypt's setup.hint md5 checksum didn't match the md5.sum file. luke -- 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: Does setup.exe ignore setup.hint md5 checksum?
On 6 Sep, Corinna Vinschen wrote: Not on cygwin.com. The md5sum is correct there. Sure, sure, I didn't mean to imply that. We've found a mirror site that wasn't broken, as of last night. Setup.exe doesn't know about setup.hint. It only gets the data from the top-level file setup.ini which contains the assembled setup.hint contents of all packages. Okay, so if setup ignores the package setup.hint files, my mirror download integrity checker script will ignore them too! Thanks, Corinna, luke -- 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: Administrator vs Administrators
On 6 Sep, Dave Korn wrote: Your policy is that the *domain user account* for a user has *local* administrative rights over that user's own pc. True. I stand corrected. Your policy could not conceivably under any circumstances be to give every user domain admin group membership! True. Now re-analyse the problem! Igor pointed out that the system groups must not exist in /etc/passwd, and he was correct. Thanks, luke -- 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/
file not working on executables?
I installed the latest Cygwin a couple of days ago. file now produces no information for binary executables. Anyone else seeing this problem? (I checked that file is /usr/bin/file.) $ file /usr/bin/ls.exe /usr/bin/ls.exe: $ file /cygdrive/c/WINDOWS/system32/net.exe /cygdrive/c/WINDOWS/system32/net.exe: $ file /etc/profile /etc/profile: ASCII English text $ file ~/.profile /home/luke/.profile: Bourne shell script text executable A bit odd that it got /etc/profile wrong, too. cygcheck -s is attached. I think my magic files are okay. Here's part of an strace of ls /usr/bin/ls.exe 52 294897 [main] file 2168 __set_errno: int stat_worker(const char*, __stat64*, int):1040 val 2 65 294962 [main] file 2168 stat_worker: -1 = (/home/luke/.magic, 0x22EE60) 128276 423238 [main] file 2168 open: open (/usr/share/file/magic.mgc, 0x0) 89 423327 [main] file 2168 normalize_posix_path: src /usr/share/file/magic.mgc 50 423377 [main] file 2168 normalize_posix_path: /usr/share/file/magic.mgc = normalize_posix_path (/usr/share/file/magic.mgc) 51 423428 [main] file 2168 mount_info::conv_to_win32_path: conv_to_win32_path (/usr/share/file/magic.mgc) 57 423485 [main] file 2168 set_flags: flags: text (0x200) 51 423536 [main] file 2168 mount_info::conv_to_win32_path: src_path /usr/share/file/magic.mgc, dst C:\cygwin\usr\share\file\magic.mgc, flags 0x208, rc 0 313 423849 [main] file 2168 symlink_info::check: not a symlink 50 423899 [main] file 2168 symlink_info::check: 0 = symlink.check (C:\cygwin\usr\share\file\magic.mgc, 0x22E360) (0x208) 57 423956 [main] file 2168 path_conv::check: this-path(C:\cygwin\usr\share\file\magic.mgc), has_acls(1) 57 424013 [main] file 2168 build_fh_pc: fh 0x61155E50 237 424250 [main] file 2168 fhandler_base::open: (C:\cygwin\usr\share\file\magic.mgc, 0x10) 166 424416 [main] file 2168 fhandler_base::set_flags: flags 0x10, supplied_bin 0x2 53 424469 [main] file 2168 fhandler_base::set_flags: filemode set to text 48 424517 [main] file 2168 fhandler_base::open: 0 = NtCreateFile (0x728, 8010, C:\cygwin\usr\share\file\magic.mgc, io, NULL, 0, 7, 1, 20, NULL, 0) 55 424572 [main] file 2168 fhandler_base::open: 1 = fhandler_base::open (C:\cygwin\usr\share\file\magic.mgc, 0x10) 53 424625 [main] file 2168 fhandler_base::open_fs: 1 = fhandler_disk_file::open (C:\cygwin\usr\share\file\magic.mgc, 0x0) 60 424685 [main] file 2168 open: 3 = open (/usr/share/file/magic.mgc, 0x0) 122 424807 [main] file 2168 get_file_attribute: file: C:\cygwin\usr\share\file\magic.mgc 156 424963 [main] file 2168 cygpsid::debug_print: get_sids_info: owner SID = S-1-5-32-544 51 425014 [main] file 2168 cygpsid::debug_print: get_sids_info: group SID = S-1-5-18 74 425088 [main] file 2168 get_info_from_sd: ACL 1E8, uid 544, gid 18 90 425178 [main] file 2168 fhandler_base::fstat_helper: 0 = fstat (, 0x22EB30) st_atime=4317C819 st_size=902784, st_mode=0x81E8, st_ino=34923, sizeof=96 57 425235 [main] file 2168 fstat64: 0 = fstat (3, 0x22EB30) 64 425299 [main] file 2168 mmap64: addr 0, len 902784, prot 3, flags 2, fd 3, off 0 148 425447 [main] file 2168 fhandler_disk_file::mmap: BA = MapViewOfFileEx (h:704, access:1, 0, off:0, len:902784, addr:0) 75 425522 [main] file 2168 mmap64: BA = mmap() succeeded 50 425572 [main] file 2168 close: close (3) 52 425624 [main] file 2168 fhandler_base::close: closing /usr/share/file/magic.mgc handle 0x728 $ ls -l /usr/share/file/magic* -rwxr-x--- 1 Administrators SYSTEM 419946 Aug 27 08:51 /usr/share/file/magic -rwxr-x--- 1 Administrators SYSTEM 902784 Aug 27 08:51 /usr/share/file/magic.mgc -rwxr-x--- 1 Administrators SYSTEM 30955 Aug 27 08:51 /usr/share/file/magic.mime -rwxr-x--- 1 Administrators SYSTEM 43904 Aug 27 08:51 /usr/share/file/magic.mime.mgc luke Cygwin Configuration Diagnostics Current System Time: Wed Sep 07 14:35:30 2005 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: \\samba\syncopt\microsoft.x86.win\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\Tcl\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\nsr\bin C:\cygwin\bin x:\bin c:\mysql\bin c:\jdk1.3.1_01\jre\bin\hotspot D:\home\MediaPortal\mp\build\win32\bin c:\Program Files\Common Files\Adaptec Shared\System c:\Program Files\Canon\MediaPortal\bin c:\Program Files\Rational\common c:\Program Files\Adobe\Illustrator CS\Plug-ins\CAT c:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT c:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin c:\Program Files\Microsoft Visual Studio\Common\Tools c:\Program Files\Microsoft Visual Studio\VC98\bin \\handel\d\cygnus\cisra \\samba\script
Odd transient error about __impure_ptr
On a freshly (re?)installed copy of Cygwin from September 2004, a weird thing happened that I thought I'd mention. We use Michael Wardle's excellent shell.c program that queries the password file to find the user's default shell, to start that (instead of running bash --login), run from inside a .bat file with a shortcut on the desktop. I *think* I may have compiled this with a later version of Cygwin. Anyway, when we recently dusted off and installed the Sept '04 Cygwin, trying to run shell.exe lead to a failure, with the message that cygwin1.dll did not provide __impure_ptr. So I recompiled it from the freshly-installed stable release. It failed the same way. Then I ran it from inside a Cygwin shell (inside rxvt), and it worked! I then changed the .bat file for the shortcut back the way it had been, and it also worked! Does that make sense to anyone? It's no big deal, just something weird that I thought someone more knowledgeable than I might understand. luke -- 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/
Administrator vs Administrators
Our policy is that for their PC, users have administrator rights in the network domain, so they can install and uninstall software. I had someone report this error today from a script I'd written: On 6 Sep, Iain Templeton wrote: Replacing /bin/shell.exe with newer one from //handel/d/cygnus/cisra chown: `Administrators.SYSTEM': invalid user I think you have an extra s in the user name :-) (I have an Administrator user, but no Administrators user). Can someone correct my understanding if I've got this wrong? I think Administrator means the administrator account on the local machine, Administrators means the administrative account for the machine in the domain (workgroup). (Until we added the 's' we were getting permission problems in installing, updating and removing Cygwin if the user had admin rights but wasn't the person who'd installed it. On my PC running cygwin I can execute the command properly. So I have no idea what's going on here! $ ls -l xxx -rw-r--r-- 1 luke Domain Users 8686596 Sep 2 18:00 xxx $ chown administrators xxx $ ls -l xxx -rw-r--r-- 1 Administrators Domain Users 8686596 Sep 2 18:00 xxx $ chown Administrators.SYSTEM xxx $ ls -l xxx -rw-r--r-- 1 Administrators SYSTEM 8686596 Sep 2 18:00 xxx I've attached a cycheck -s from the machine in question. luke Cygwin Configuration Diagnostics Current System Time: Tue Sep 06 04:34:14 2005 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: u:\bin D:\home\iain\bin \\samba\syncopt\microsoft.x86.win\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\sbin C:\cygwin\sbin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\local\bin C:\cygwin\sbin C:\cygwin\usr\sbin C:\cygwin\usr\local\sbin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 \\handel\d\cygnus\cisra \\samba\script C:\cygwin\usr\local\bin x:\bin\script x:\bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 12147(iain) GID: 10513(Domain Users) 10513(Domain Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 12147(iain) GID: 10513(Domain Users) 0(root) 544(Administrators) 545(Users)1003(Debugger Users) 14869(ACDSee6)13879(Adobe_Acrobat_Std) 13998(Adobe_Illustrator) 14003(Adobe_Photoshop) 17195(All_CISRA) 17184(Cranite) 10513(Domain Users) 13893(MS_Visio_Pro) 13876(MS_VisualStudio)14874(Xwin32) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS CYGWIN = ` nobinmode' HOME = `D:\home\iain' MAKE_MODE = `unix' PWD = `/home/iain/apaf/sw' USER = `iain' Use `-r' to scan registry a: fd N/AN/A c: hd NTFS 14692Mb 83% CP CS UN PA FC d: hd NTFS 20002Mb 59% CP CS UN PA FC data e: cd N/AN/A f: cd N/AN/A i: net NTFS5833Mb 89% CP CSPAdatasets l: net NTFS 26505Mb 10% CP CS UN PA FC DATA p: net NTFS 127754Mb 90% CP CSPAhome u: net NTFS1455Mb 82% CP CSPAiain x: net NTFS4698Mb 25% CP CS UN PA FC D Drive y: net NTFS 25294Mb 71% CP CSPAhome C:\cygwin / system textmode D:\home/home system textmode C:\cygwin/bin /usr/bin system textmode C:\cygwin/lib /usr/lib system textmode C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode .. /cygdrive system textmode,cygdrive Found: C:\cygwin\bin\awk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: \\samba\syncopt\microsoft.x86.win\bin\cpp.exe Found: C:\cygwin\bin\cpp.exe Found: x:\bin\cpp.exe Found: C:\cygwin\bin\find.exe Found: C:\cygwin\bin\gcc.exe Found: C:\cygwin\bin\gdb.exe Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\mv.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe 61k 2003/08/09 C:\cygwin\bin\cygbz2-1.dll 54k 2002/01/27 C:\cygwin\bin\cygbz21.0.dll 18k 2004/07/06 C:\cygwin\bin\cygcharset-1.dll 7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll 841k 2004/03/17 C:\cygwin\bin\cygcrypto-0.9.7.dll 645k 2003/04/11 C:\cygwin\bin\cygcrypto.dll 617k 2004/03/22 C:\cygwin\bin\cygcurl-2.dll 22k 2004/02/10 C:\cygwin\bin\cygcygipc-2.dll 380k 2002/07/24 C:\cygwin\bin\cygdb-3.1.dll 831k 2003/09/20 C:\cygwin\bin\cygdb-4.1.dll 895k 2004/04/28 C:\cygwin\bin\cygdb-4.2.dll 326k 2002/06/26 C:\cygwin\bin\cygdb2.dll 487k 2002/07/24 C:\cygwin\bin\cygdb_cxx-3.1.dll 1080k 2003/09/20 C:\cygwin\bin\cygdb_cxx-4.1.dll
Re: Odd transient error about __impure_ptr
On 5 Sep, Igor Pechtchanski wrote: Hard to say without a proper problem report[*], but it sounds like you have another version of cygwin1.dll in the PATH. Windows looks for cygwin1.dll in the directory of the program before it looks at the PATH, and the standard cygwin.bat runs bash from /bin, so it finds the new DLL. If your shell.exe is in another directory, the older DLL in the PATH will take precedence. That's along the lines of what I thought. What puzzled me was how it just went away without even me having to logg out, let alone reboot. I think I'll just put it down as one of those weird Windows things. Thanks, luke -- 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/
Problems with a fresh install
I just installed a fresh version of Cygwin from a mirror site. Despite installing All, and running ssh-host-config there were no /etc/ssh* files created. After the install I tried to chown files to the Administrators group so that other people could update the Cygwin installation if desired. I got many, many errors like this: chown: changing ownership of `/usr/share/doc/lynx/lynx_help/COPYING': No such file or directory $ ls -l /usr/share/doc/lynx/lynx_help/COPYING lrwxrwxrwx 1 luke Users 47 Sep 2 13:48 /usr/share/doc/lynx/lynx_help/COPYING - /tmp/install/INSTALL/usr/share/doc/lynx/COPYING $ ls -l /tmp/install/INSTALL/usr/share/doc/lynx/COPYING ls: /tmp/install/INSTALL/usr/share/doc/lynx/COPYING: No such file or directory $ ls -l /tmp/install ls: /tmp/install: No such file or directory $ ls -l /tmp total 0 Cygwin seems to be running extraordinarily slowly too. Even an ls takes a long time: $ time ls -l /tmp total 0 real0m3.897s user0m0.020s sys 0m0.060s Also, the real time reported from /bin/time is wrong: $ /bin/time /bin/ls /tmp 0.07user 0.03system 0:01.64elapsed 6%CPU (0avgtext+0avgdata 14528maxresident)k 0inputs+0outputs (907major+0minor)pagefaults 0swaps since I timed that via a watch at over 4 seconds. This suggests that /bin/time also took about two seconds for its part of the process. Later, though, the missing files do indeed exist, and speed is okay. Any idea what on earth is going on? Why the failed chmods? Likewise, running ssh-host-config (later) creates the ssh files. It's almost like lots of the files hadn't actually been flushed through onto the filesystem, which seems like crazy talk. Is there some background task which runs after setup.exe has finished, that is still going? luke -- 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/
libgcrypt md5sum mismatch and setup
When checking the md5 integrity of an rsync copy of a cygwin mirror, should I specifically *not* check the integrity of the setup.hint files? A month or two ago we noticed that libgcrypt's md5.sum file did not check out against the actual setup.hint file. This is now true of a few mirror sites we've tried. $ md5sum --check md5.sum libgcrypt-1.2.0-2-src.tar.bz2: OK libgcrypt-1.2.0-2.tar.bz2: OK libgcrypt-1.2.1-1-src.tar.bz2: OK libgcrypt-1.2.1-1.tar.bz2: OK setup.hint: FAILED md5sum: WARNING: 1 of 5 computed checksums did NOT match $ ls -l total 2452 -rw-rw-r-- 13 mirror technic 1088056 Oct 1 2004 libgcrypt-1.2.0-2-src.tar.bz2 -rw-rw-r-- 13 mirror technic 277027 Oct 1 2004 libgcrypt-1.2.0-2.tar.bz2 -rw-rw-r-- 13 mirror technic 821466 Jul 10 14:35 libgcrypt-1.2.1-1-src.tar.bz2 -rw-rw-r-- 13 mirror technic 293868 Jul 10 14:35 libgcrypt-1.2.1-1.tar.bz2 -rw-rw-r-- 13 mirror technic 293 Jul 13 09:07 md5.sum -rw-rw-r-- 14 mirror technic 222 Jul 12 06:02 setup.hint $ grep setup md5.sum 4c7da7e26a083aa01ef7345840c17203 setup.hint $ md5sum setup.hint c628190b107c291d751216192515b6f5 setup.hint $ cat setup.hint sdesc: A general purpose crypto library based on the code from GnuPG. ldesc: Libgcrypt is a general purpose crypto library based on the code used in GnuPG. category: Libs requires: cygwin libgpg-error _update-info-dir Interestingly, setup.exe (with All packages chosen to install) only complained of an incomplete download on t1lib, not on libgcrypt. (NB: FWIW, we noticed that t1lib also failed its md5 check for the chosen mirror site.) luke -- 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/
minor md5sum output difference
Cygwin md5sum puts a space then an asterisk in front of filenames, Linux version puts two spaces. E.g.: Linux$ echo | md5sum 68b329da9893e34099c7d8ad5cb9c940 - Cywgin$ echo | md5sum 68b329da9893e34099c7d8ad5cb9c940 *- I see md5sum -c accepts either two spaces or space plus asterisk. Why the difference in output formats? Does it matter? luke -- 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/
Download Incomplete. Try again?
I'm currently trying to find out why a recent copy of a cygwin mirror causes the Download Incomplete. Try again? error in setup.exe. The md5 checksums on each file within the download is good (we check them against the md5.sum file in each package directory). But still we get the above error. Is there a way to test if a downloaded cygwin will cause the Download Incomplete. Try again? error, except by running setup.exe? By looking through the mailing list archives, I got the impression that this happened when the setup.ini file got out of sync with the collection of packages - but Christopher explained that setup.ini only gets updated occasionally. And I can confirm that: many of the package versions in setup.ini don't match the versions of the packages present, even in stable and installable cygwin mirrors. Is that because setup.ini gets updated manually? Would you like me to try to design an easy system to regenerate it automatically when packages are updated? (I'm imagining a tree of per-package description parts which change infrequently, and a script which adds the file size and md5 sig automatically. Perhaps it should even be a Makefile.) I'm thinking of this email from the Cygwin-xfree list: From: Harold L Hunt II Subject: Re: Trouble with DDD download via cygwin setup Date: Wed, 17 Dec 2003 09:53:35 -0500 To: cygwin-xfree@cygwin.com Reply-To: cygwin-xfree@cygwin.com Thanks Ton. I fixed it by uploading the slightly updated binary file that I had created. Harold Ton van Overbeek wrote: I found out what the problem is trying to download ddd via Cygwin setup: the filesize and md5sum given in setup.ini for ddd-3.3.8-1.tar.bz2 do not match. In setup.ini: size 1435787, md5sum f3244afe271984c1fc1855203cb92300 After manual download: size 1435585, md5sum 86cc2b9dff9a4f794dfc6bbe49bf2bbc Hence the download incomplete, try again? message in setup. Harold, could you please fix your setup.ini, so ddd can be downloaded via setup? Thanks in advance. Ton van Overbeek But is that the cause of the problem? If not, does anyone know what the real problem is? If the only way is by running setup.exe, is that unlikely to damage an older, working Cygwin install? luke -- 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: Download Incomplete. Try again?
On 25 Jul, Igor Pechtchanski replied to: Is there a way to test if a downloaded cygwin will cause the Download Incomplete. Try again? error, except by running setup.exe? Yes, there is. There is no magic in setup.exe (well, not much, in any case). Check the filenames, file sizes and md5sums against setup.ini, not the md5.sum files. Really?! I modified my md5cychk script to perform that check. Our old, stable, working Cygwin mirror installs and runs fine, and all the md5.sum files check correctly against the package files. But 53 of the package files differ in their version against the setup.ini file. Ah, wait! Should I only check md5s if a package filename (and hence version) in setup.ini matches against a file in the package directory? Does setup.exe only complain if setup.ini files are a *subset* of the files in the package directory? At the moment I'm checking for perfect congruence. E.g.: Pkg X-startup-scripts: checksum mismatch vs setup.ini Pkg fontconfig: checksum mismatch vs setup.ini Pkg libfontconfig-devel: checksum mismatch vs setup.ini Pkg libfontconfig1: checksum mismatch vs setup.ini Pkg gd: checksum mismatch vs setup.ini Pkg xterm: checksum mismatch vs setup.ini Pkg a2ps: checksum mismatch vs setup.ini Pkg automake-devel: checksum mismatch vs setup.ini Pkg bzip2: checksum mismatch vs setup.ini [...] In /u/install/win32/cygwin/release/./X11/X-startup-scripts: Pkg X-startup-scripts: checksum mismatch vs setup.ini diff of setup.ini's data vs X-startup-scripts's: 0a1,4 3e5ba8a0c74efc0784cfb281c8bc7b8d X-startup-scripts-1.0.4-1-src.tar.bz2 ac7df29735b5cd2a005bfae7a22f067a X-startup-scripts-1.0.4-1.tar.bz2 73274cafa8be97c22819b774e8ec1ff8 X-startup-scripts-1.0.5-1-src.tar.bz2 e9e13454d75bab7214524556abd3493a X-startup-scripts-1.0.5-1.tar.bz2 --- == /tmp/md5cyg16373.md5.top == 7f0d9fffe50e455017027a005face0af X-startup-scripts-1.0.6-1-src.tar.bz2 dd904397cac9f70fc4d8c1d4e3ccb1b3 X-startup-scripts-1.0.6-1.tar.bz2 d622b56c7d1c7898bc4a298945f748f6 X-startup-scripts-1.0.7-1-src.tar.bz2 0168dd4200f2d9fdf5a5589873c31f1f X-startup-scripts-1.0.7-1.tar.bz2 By looking through the mailing list archives, I got the impression that this happened when the setup.ini file got out of sync with the collection of packages - but Christopher explained that setup.ini only gets updated occasionally. Exactly. And I can confirm that: many of the package versions in setup.ini don't match the versions of the packages present, even in stable and installable cygwin mirrors. Is that because setup.ini gets updated manually? Probably yes. If the mirroring process catches the main Cygwin repository in a state where a package is uploaded, but setup.ini hasn't been updated, the repository will be in an inconsistent state. Can setup.ini be out of date for long periods, because it is updated manually? Would you like me to try to design an easy system to regenerate it automatically when packages are updated? (I'm imagining a tree of per-package description parts which change infrequently, and a script which adds the file size and md5 sig automatically. Perhaps it should even be a Makefile.) Eh? There's more to it than that -- setup.ini also has versions, etc. Oh! But when we mirror a site, we only see a single setup.ini file. [snip email about setup.ini size/md5sum mismatch (with raw e-mail addresses, I might add)] [Oh: the cygwin-xfree address itself? Sorry. :-( ] But is that the cause of the problem? Yes. If not, does anyone know what the real problem is? If the only way is by running setup.exe, is that unlikely to damage an older, working Cygwin install? If you run setup in download mode, you will not affect the existing install. HTH, Igor I think it does: the download would fail with the above error message, so you would know not to proceed? I think I'm starting to understand. (With some gaps, though.) luke -- 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/
MD5 checksum question
Does it matter that the top-level setup.ini (that duplicates the MD5 checksums of each package's md5.sum file), does *not* do the same thing for the setup.hint file in each package directory? I assume the duplication is to allow the detection of the race condition (mentioned below). I only noticed while updating my md5cygchk mirror-checker, to detect the case where all package md5.sum files are correct but the top-level setup.ini file is out of sync with the packages below. (This happens if you rsync a mirror site while the site is being updated. It leads to the setup.exe error: Download Incomplete. Try again?) I'm assuming the lack of a setup.hint line in each package's entry in setup.ini doesn't matter. Regards, luke -- 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: Cygwin df -l option has wrong sense?
On 30 Sep, Igor Pechtchanski wrote: Usage: df [OPTION]... [FILE]... Show information about the filesystem on which each FILE resides, or all filesystems by default. [...] -l, --local limit listing to local filesystems [...] Report bugs to bug-fileutils@gnu.org. $ uname -a CYGWIN_NT-5.1 DOYLE 1.5.10(0.116/4/2) 2004-05-25 22:07 i686 unknown unknown Cygwin Have I misunderstood? luke This is a problem with how fileutils tests for drives being local. And, it has been reported before (with a patch to fix it) -- see the thread starting at http://cygwin.com/ml/cygwin/2002-09/msg00945.html. Igor P.S. The mount type fix is still on my TODO list :-( And I see it's been fixed now - thanks! luke -- 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: Updated: inetutils-1.3.2-29
On 19 Apr, Corinna Vinschen wrote: - When updating inetutils, take care that syslogd.exe, inetd.exe and subsequent processes don't run anymore. Otherwise the update will fail. Does setup.exe take care of stopping them before updating them, or do you mean that topping them must be done manually? luke -- 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/
Control and shift key timeouts
Hi Apologies for not mentioning this years ago, but ... In vi, if I hold down the shift or the control key and then move through the file (e.g. repeated CTRL-B or SHIFT-W use), and then hit no fresh keys for 5 seconds (i.e. just sit there with the CTRL or Shift key depressed), and then continue pressing B or W or whatever, the fact that the key is depressed seems to get lost. I have to lift that finger and press the key down again. This happens inside an rxvt window or inside a Cygwin window. It happens whether or not X is running. It happens inside an xterm. It also happens outside vi: e.g. if you're just editing a bash command line. Has anyone else noticed this? Regards, luke -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem running xgettext after compiling gettext 0.14.1 with gc c 3.3.3
On 25 Feb, Igor Pechtchanski wrote: The application failed to initialize properly (0xc022). Click on OK to terminate the application Ah, right, 0xc022 is access denied, and 0xc005 is access violation (i.e., SEGV), most likely inside DllMain. Sorry, got confused for a moment. One thing you could try is set breakpoints in all of the DllMain functions, and trace through... Is the program installed on an NTFS file system? I seem to recall someone mentioning some special permission/privilege needed for a file to be allowed to execute from NTFS. luke -- 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: Are two installs still needed?
On 6 Apr, Larry Hall wrote: Is that double install process still needed? No, that's been fixed for a while now. Great, I'll change my cyginst.bat script. luke -- 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: zsh startup oddity
On 4 Apr, Christopher Faylor wrote: The web page that you are referring to has this at the beginningr: This document deals with contributions to the Cygwin DLL and Cygwin utilitites. Contributions to other packages contributed by Cygwin are also welcome and some of the principles involved are the same. However, most of the specific instructions here will not be applicable to utilities like bash, gawk, apache, etc., which are generally found in linux releases. If you have a patch for any of those, send it along to the cygwin mailing list and the appropriate package maintainer will respond. i.e., it has nothing to do with any of the non-cygwin-specific packages so it is not applicable here. Sorry, I thought Michael was proposing it as a new Cywin utility, to be used by cygwin.bat. I agree it has nothing to do with the general Unix packages, but thought the contribution guidelines might apply to Cygwin specific stuff. luke -- 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: zsh startup oddity
On 6 Apr, Peter A. Castro wrote: I like the sound of Michael's shell.c because you don't need a separate ..bat file to start up each different shell. I guess I don't understand how you are starting the shell, really. All you need to do is change cygwin.bat to run 'zsh -l -i' instead of 'bash --login' and it will run as a login shell. /zsh.bat is simply a convenient bat file which does this. It seems like overkill to run a cygwin shell wrapper which just does an exec of another shell, but to each their own. If it works for you, so much the better. Well, it's more like Unix. I.e. if more than one person uses the PC (especially common for laptops), it just works automatically. It seems esthetically neater - if all the Unix shells were installed, it'd be ugly to have 20 different shell .bat files. luke -- 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: zsh startup oddity
On 1 Apr, Michael Wardle wrote: By what mechanism are you ensuring zsh is invoked as a login shell rather than a non-login shell? I think we were starting it via the cygwin shortcut (cygwin.bat), which as you have said, just runs bash --login. IIRC, the way we were starting zsh was via an exec inside the user's .profile. The trouble was, the .profile was not being run if Cygwin's mkdir created the /home mount point directory instead of Windows. Does $- include i? Does setopt show that interactive is on? With Cygwin 1.5.13, zsh 4.2.4-1 and the simple shell invocation utility posted to this list on March 24 [EMAIL PROTECTED] (which sets argv[0] to -zsh), zsh recognizes that it is a login shell and correctly sources .zprofile. Ah! Looks perfect! Thanks, Michael, we'll give that a try. You've probably already checked these things, but I'd be surprised if this behavior was due to file permissions. We weren't surprised - we were flabbergasted! Anyway, we'll give your excellent shell.c a try and see how that goes. Peter Castro replied to: But /etc/passwd would source $HOME/.zprofile if /home had been created by Windows Explorer. I am unable to reproduce this. Are you using the zsh.bat file provided or a custom startup bat file or just running the shell by itself? Please make sure you are using the '-l' option to force a login shell. zsh has greatly changed in a years time. Please consider upgrading to a later release. No, we weren't using zsh.bat. Where does that get installed? I can't find it, though I see I have zsh 4.2.4 installed from my very recent complete re-install. I like the sound of Michael's shell.c because you don't need a separate ..bat file to start up each different shell. Thanks for the suggestions, luke luke -- 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/
