Re: rsync failing to see drive path
> >> $ rsync --dry-run --delete -uvxhir "/cydrive/m/Music Converted" > >> /cygdrive/G/ > >> sending incremental file list > >> rsync: change_dir "/cydrive/m" failed: No such file or directory (2) [...] > $ rsync --dry-run --delete -uvxhir /cydrive/m/Music\ Converted /cygdrive/G/ > sending incremental file list > rsync: change_dir "/cydrive/m" failed: No such file or directory (2) I see "cygdrive" misspelled as "cydrive" in a couple places. What happens when that's corrected? ..mark -- 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: rsync failing to see drive path
On 9/4/2013 3:41 PM, Mike Cappella wrote: Hi Folks, I'm trying to use rsync on a USB (fat) drive, but it fails on the cygdrive path: $ rsync --dry-run --delete -uvxhir "/cydrive/m/Music Converted" /cygdrive/G/ sending incremental file list rsync: change_dir "/cydrive/m" failed: No such file or directory (2) and I'm not sure why as it does indeed exist: $ ls -l /cygdrive/m/Music\ Converted total 12532 -rwxr-xr-x+ 1 MrC 12568746 Sep 4 11:42 Database.mpl drwxr-xr-x+ 1 MrC 0 Sep 4 11:41 Music drwxr-xr-x+ 1 MrC 0 Sep 4 11:42 Playlists Any ideas? $ uname -a CYGWIN_NT-6.1 zion 1.7.25(0.270/5/3) 2013-08-31 20:37 x86_64 Cygwin I see "cygdrive" misspelled as "cydrive" in a couple places. What happens when that's corrected? ..mark Oh, dear god. It's official - I'm now old. (I misspelled this in an alias, which is one I use elsewhere just fine, because it is spelled correctly elsewhere.) Thanks. Have a nice day. -- 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: abort: address space needed by 'cygXcursor-1.dll ... is already occupied
Today I rebooted, started Cygwin, X and got FOUR terminals correctly with no error message. Still, I would be happy to understand the previous error. On 9/4/13, Adam Dinwoodie wrote: > Don't do that then. Dumping a binary file to terminal rarely ends well. :-) But it was an accident! > Did you try searching for the error message? Yes. > While we're at it, what is the error message? abort: address space needed by 'cygXcursor-1.dll ... is already occupied (That's not the complete message. BTW, why doesn't copy/paste work in the main Cygwin window?) Chen Qi wrote: > maybe you have install some packages recently but not yet running a > rebase command. No, I have installed no packages recently. The only significant "change" I am aware of is the xterm that ending in a bad state 2 days ago as described. BTW, that was the "login" xterm. -- 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
iodbc always in error
Hello, I'm trying to make iodbc work with cygwin, but I'm always getting errors. I've installed « libiodbc2 », « iodbctest », « iodbcadm-gtk » and the sqlite driver « odbc-sqlite3 ». When I wan to check the configuration, I've got the following session : $ iodbctest mysqlite iODBC Demonstration program This program shows an interactive SQL processor Driver Manager: 03.52.0812.0326 1: SQLDriverConnect = [iODBC][Driver Manager]Driver's SQLAllocEnv() failed (0) SQLSTATE=IM004 1: ODBC_Connect = [iODBC][Driver Manager]Driver's SQLAllocEnv() failed (0) SQLSTATE=IM004 Have a nice day. The configuration file is here and works when I test it on Debian : [ODBC Data Sources] mysqlite = SQLite [mysqlite] Driver = /usr/lib/cygsqlite3odbc.dll Description = My sqlite test database Database= /home/user/databases/mytest.db ; optional lock timeout in milliseconds Timeout = 2000 [ODBC] Trace = 1 TraceAutoStop = 0 TraceFile = sql.log Debug = 1 DebugFile = sql_debug.log I've first suspected something wrong in the sqlite driver and recompiled it from sources, but I still get the same error, so I now think there is a problem in the iodbc library. The iodbc log are here : http://pastebin.com/mzDLUC3x Can you help me to understand what happen ? Thanks ! (I'm not registered on the ml, please cc me in your answer.) -- Sébastien -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bug report: 64-bit cygwin setup crashes under Wine
On Thursday, September 05, 2013 at 4:28 AM, Warren Young wrote: I purposefully said "and licensing" though, because the Windows license swamps the hardware costs. It can be true about the SSD and RAM costs but it's not the same kind of sandbox too (Wine vs VM). But about the licensing costs I can't understand it. Unless you are a cygwin developer that needs to use cygwin mandatory I can't see the purpose on using a solution that involves a Virtual Machine running a Cygwin installation inside a Windows Guest in a Mac as Host Machine. Doesn't it has a lot more sense to install linux on the Virtual Machine? No licensing costs at all. Unless I'm missing something and cygwin includes something that is not available on linux. -- 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: Fwd: INFO issues [partially SOLVED]
NOTE: I'm replying from the digest, so in case the list does not hook up the appropriate reference pointers, here they are: 1. http://cygwin.com/ml/cygwin/2013-09/msg00024.html 2.http://cygwin.com/ml/cygwin/2013-09/msg00031.html On Tue, Sep 3, 2013 at 5:18 PM, wrote: > From: Ken Brown > To: cygwin AT cygwin DOT com > Cc: > Date: Mon, 02 Sep 2013 20:29:27 -0400 > Subject: Re: Fwd: INFO issues > On 9/2/2013 11:36 AM, Thiers Botelho wrote: >> >> Hi all, >> >> I'm a new user of CygWin and a former user of some Linux distros. >> >> I'm having the following issue with the 'info' command: >> >> thiers@Win-Samsung ~ >> $ info >> info: dir: No such file or directory >> >> I did some searches, but really... searching stuff where 'info' is the >> keyword is bound to, and DOES, return a lot of useless 'info'... >> >> I've searched the CygWin mailing list; what I've got is the >> not-so-clear suspicion that I need to 'install' something. Here are >> the closest leads I've got - they're 13 years old: >> >> https://sourceware.org/ml/cygwin/2000-05/msg5.html >> ### this guy had the same issue I'm having. >> >> https://sourceware.org/ml/cygwin/2000-05/msg00126.html >> ### then this guy suggested running some kind of hand-made script (not >> really meaningful to me) around the install-info command (which indeed >> exists in my CygWin folder) >> >> https://sourceware.org/ml/cygwin/2000-05/msg00184.html >> ### and this other guy suggested using command 'gen-dir-node' (which I >> didn't find in my CygWin build). >> >> So what I'd like to know is, are there any clear instructions >> somewhere about how to make the 'info' command work properly under >> Cygwin ?? > > > There's a postinstall script called 'update-info-dir.sh' which is supposed to > get run automatically by setup.exe to create the info directory. If this > didn't happen for some reason, you can run it manually. (Look for it in > /etc/postinstall.) In case you don't have it, here are the contents: > > #!/bin/bash > rm -f /usr/info/dir.info /usr/share/info/dir.info /usr/info/dir > /usr/share/info/dir > for d in /usr/info /usr/share/info; do > for f in $d/*; do > case "$f" in > *\**) > ;; > */dir|*/dir.info*) > ;; > *-[0123456789]*) > ;; > *) > install-info --quiet $f /usr/share/info/dir || > install-info --quiet --entry="* $f ($f): $f" $f > /usr/share/info/dir > ;; > esac > done > done >/dev/null 2>&1 > > Ken > Thx a lot Ken - that did it. INFO command now works properly ! And now that begs a follow-up question... After some digging around about how the post-install scripts work in CygWin, and doing some complementary testing, it seems that, every time that CygWin Setup runs, the script will be run once and then renamed with a '.done' suffix. So that, if I want the script to run every time that Setup runs, I have to remember to manually rename it back to '.sh' after each setup run, which is, erm, sub-optimal. Any ideas about getting around this repeated manual renaming ??? Thx and cheers Thiers -- 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: INFO issues [partially SOLVED]
It would be nice to know if yours is a x86_64 version of cygwin because I think there is something wrong in x86_64 version and this must be a bug somewhere. Don't know exactly where (the texinfo package?). I have a x86_64 and I can confirm the update-info-dir post install script is not available in the x86_64 version of cygwin. I can copy the script from a x86 version and run it manually and info command starts working but still with problem. For example when you run 'info ttt' using something that is not a valid value for the info command, instead of getting the top info page you get a "segmentation fault" error. In x86 something like info tt instead of a segmentation fault will trigger the info top page showing on the bottom the error "the node ttt doesn't exist". -- 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: config.guess and config.sub older than new Cygwin64
On Wed, Sep 4, 2013 at 6:13 PM, Charles Wilson wrote: > On 9/4/2013 5:43 PM, Earnie Boyd wrote: >> >> Just a note to those of you using Cygwin64 to build packages. You >> will need to most likely replace the config.guess and config.sub files >> in those packages with newer ones from >> ftp://ftp.gnu.org/pub/gnu/config/ because it won't guess your system >> correctly. >> >> Twice now I've seen on config-patches a report submitted because of this. >> > > The versions installed into /usr/share/automake-X.Y/ have all been modified > to be the latest upstream as of mid-July -- for all X.Y from 1.4 to 1.14. > > Also, cygport itself ships with an identical copy, and modifying your script > to call 'gnuconfigize' during src_compile() will update them as well. That's fine if the user is using cygport but from the two I've seen on config-patches is that the user is executing a package configure where the package has an 11 year old config.guess and is not using cygport at all. -- Earnie -- https://sites.google.com/site/earnieboyd -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bug report: 64-bit cygwin setup crashes under Wine
On 04/09/2013 7:09 PM, Christopher Faylor wrote: On Wed, Sep 04, 2013 at 03:26:10PM -0600, Warren Young wrote: This bug could well be Wine's, rather than Cygwin's. Wine can always play the "It's not documented to work that way card" but the bottom line is still that it is not a "platform" that we are interested in devoting time to. One wonders what stack alignment would be found if a breakpoint were set at the same place under a native windows setup... if it's not 16-byte aligned then this is a Cygwin bug that flew under the radar. Aligned stack? Chalk it up to Wine. Ryan -- 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: config.guess and config.sub older than new Cygwin64
On 05/09/2013 8:08 AM, Earnie Boyd wrote: On Wed, Sep 4, 2013 at 6:13 PM, Charles Wilson wrote: On 9/4/2013 5:43 PM, Earnie Boyd wrote: Just a note to those of you using Cygwin64 to build packages. You will need to most likely replace the config.guess and config.sub files in those packages with newer ones from ftp://ftp.gnu.org/pub/gnu/config/ because it won't guess your system correctly. Twice now I've seen on config-patches a report submitted because of this. The versions installed into /usr/share/automake-X.Y/ have all been modified to be the latest upstream as of mid-July -- for all X.Y from 1.4 to 1.14. Also, cygport itself ships with an identical copy, and modifying your script to call 'gnuconfigize' during src_compile() will update them as well. That's fine if the user is using cygport but from the two I've seen on config-patches is that the user is executing a package configure where the package has an 11 year old config.guess and is not using cygport at all. I would think that cygwin64 is the least of your worries if you're using an 11 year-old config.guess... $0.02 Ryan -- 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: config.guess and config.sub older than new Cygwin64
On Thu, Sep 5, 2013 at 8:24 AM, Ryan Johnson wrote: > On 05/09/2013 8:08 AM, Earnie Boyd wrote: >> >> On Wed, Sep 4, 2013 at 6:13 PM, Charles Wilson wrote: >>> >>> On 9/4/2013 5:43 PM, Earnie Boyd wrote: Just a note to those of you using Cygwin64 to build packages. You will need to most likely replace the config.guess and config.sub files in those packages with newer ones from ftp://ftp.gnu.org/pub/gnu/config/ because it won't guess your system correctly. Twice now I've seen on config-patches a report submitted because of this. >>> The versions installed into /usr/share/automake-X.Y/ have all been >>> modified >>> to be the latest upstream as of mid-July -- for all X.Y from 1.4 to 1.14. >>> >>> Also, cygport itself ships with an identical copy, and modifying your >>> script >>> to call 'gnuconfigize' during src_compile() will update them as well. >> >> That's fine if the user is using cygport but from the two I've seen on >> config-patches is that the user is executing a package configure where >> the package has an 11 year old config.guess and is not using cygport >> at all. > > I would think that cygwin64 is the least of your worries if you're using an > 11 year-old config.guess... Yes, especially since the output of config.guess suggests using a new version giving the ftp URI to use and the user blindly copies and pastes that output to email without first trying to use a more current version. It is the mindset of ISJWWP. ISJWWP - It should just work without problems -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: config.guess and config.sub older than new Cygwin64
On 9/5/2013 8:24 AM, Ryan Johnson wrote: On 05/09/2013 8:08 AM, Earnie Boyd wrote: On Wed, Sep 4, 2013 at 6:13 PM, Charles Wilson wrote: On 9/4/2013 5:43 PM, Earnie Boyd wrote: Just a note to those of you using Cygwin64 to build packages. You will need to most likely replace the config.guess and config.sub files in those packages with newer ones from ftp://ftp.gnu.org/pub/gnu/config/ because it won't guess your system correctly. Twice now I've seen on config-patches a report submitted because of this. The versions installed into /usr/share/automake-X.Y/ have all been modified to be the latest upstream as of mid-July -- for all X.Y from 1.4 to 1.14. Also, cygport itself ships with an identical copy, and modifying your script to call 'gnuconfigize' during src_compile() will update them as well. That's fine if the user is using cygport but from the two I've seen on config-patches is that the user is executing a package configure where the package has an 11 year old config.guess and is not using cygport at all. I would think that cygwin64 is the least of your worries if you're using an 11 year-old config.guess... $0.02 Ryan That is what you get if you pull a source tar ball off the source tree. Sometimes there is a clue on a next step along a path to accomplish an update and sometimes not. Robert McBroom -- 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
Gold star request - Re: rsync failing to see drive path
On Thu, Sep 05, 2013 at 07:02:03AM +, Mark Geisert wrote: >> >> $ rsync --dry-run --delete -uvxhir "/cydrive/m/Music Converted" >> >> /cygdrive/G/ >> >> sending incremental file list >> >> rsync: change_dir "/cydrive/m" failed: No such file or directory (2) >[...] >> $ rsync --dry-run --delete -uvxhir /cydrive/m/Music\ Converted /cygdrive/G/ >> sending incremental file list >> rsync: change_dir "/cydrive/m" failed: No such file or directory (2) > >I see "cygdrive" misspelled as "cydrive" in a couple places. What happens >when that's corrected? Sheesh. I should have caught that! Thanks Mark. Can we get a gold star for Mark for being observant? cgf -- 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: previously reported test case does not work in Cygwin 1.7.18
Le 30/08/2013 23:32, Christopher Faylor a écrit : > On Fri, Aug 30, 2013 at 04:40:44PM +0200, Andreas Steenpa? wrote: >> I would like to bring the issue described below up again. I have just >> tested this with Cygwin 1.7.24, and it shows the same behaviour as >> before, so it seems that this bug still persists. >> >> My system is: >> $ uname -a >> CYGWIN_NT-6.1-WOW64 zoppo 1.7.24(0.269/5/3) 2013-08-15 11:55 i686 Cygwin > This should be fixed in the most recent snapshot. I confirm that this works in Cygwin 1.7.25. Thank you for fixing this. Best regards, Andreas -- 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: Trying to resolve my cygheap base mismatch issue [ SOLVED !]
!! PROBLEM SOLVED with gracious support from Ian H. and Katy B. at Avecto.com. See below Tony, The issue with the Base Address with Cygwin is a known issue that we patched with the following release: http://support.avecto.com/_Temp/PG_3_6_245.zip This is a client only release so you wont need to update your management console. Can you download and apply this release which will resolve the base address issue. Ian When I installed this update on my Win XP SP3 32Bit, I could see Avecto rebased PGHook.dll such that it was no longer conflicting address wise with cygwin1.dll. My shell is back and all is good :) Thank you Larry , Et Al. for the responses and inputs. !! -- 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: abort: address space needed by 'cygXcursor-1.dll ... is already occupied
Greetings, Septimus Stevens! > Today I rebooted, started Cygwin, X and got FOUR terminals correctly > with no error message. Still, I would be happy to understand the > previous error. > On 9/4/13, Adam Dinwoodie wrote: >> Don't do that then. Dumping a binary file to terminal rarely ends well. > :-) But it was an accident! cat'ing a binary file is a bad idea in general. >> Did you try searching for the error message? > Yes. >> While we're at it, what is the error message? > abort: address space needed by 'cygXcursor-1.dll ... is already occupied > (That's not the complete message. BTW, why doesn't copy/paste work > in the main Cygwin window?) Copy/paste works just fine, both in mintty and native console. Probably, you need to clarify, what you mean by "main cygwin window", if you need further help with it. > Chen Qi wrote: >> maybe you have install some packages recently but not yet running a >> rebase command. > No, I have installed no packages recently. The only significant "change" > I am aware of is the xterm that ending in a bad state 2 days ago as described. > BTW, that was the "login" xterm. -- WBR, Andrey Repin (anrdae...@yandex.ru) 06.09.2013, <02:17> 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: Fwd: INFO issues [partially SOLVED]
On 9/5/2013 7:03 AM, Thiers Botelho wrote: NOTE: I'm replying from the digest, so in case the list does not hook up the appropriate reference pointers, here they are: 1. http://cygwin.com/ml/cygwin/2013-09/msg00024.html 2.http://cygwin.com/ml/cygwin/2013-09/msg00031.html On Tue, Sep 3, 2013 at 5:18 PM, wrote: From: Ken Brown To: cygwin AT cygwin DOT com Cc: Date: Mon, 02 Sep 2013 20:29:27 -0400 Subject: Re: Fwd: INFO issues On 9/2/2013 11:36 AM, Thiers Botelho wrote: Hi all, I'm a new user of CygWin and a former user of some Linux distros. I'm having the following issue with the 'info' command: thiers@Win-Samsung ~ $ info info: dir: No such file or directory I did some searches, but really... searching stuff where 'info' is the keyword is bound to, and DOES, return a lot of useless 'info'... I've searched the CygWin mailing list; what I've got is the not-so-clear suspicion that I need to 'install' something. Here are the closest leads I've got - they're 13 years old: https://sourceware.org/ml/cygwin/2000-05/msg5.html ### this guy had the same issue I'm having. https://sourceware.org/ml/cygwin/2000-05/msg00126.html ### then this guy suggested running some kind of hand-made script (not really meaningful to me) around the install-info command (which indeed exists in my CygWin folder) https://sourceware.org/ml/cygwin/2000-05/msg00184.html ### and this other guy suggested using command 'gen-dir-node' (which I didn't find in my CygWin build). So what I'd like to know is, are there any clear instructions somewhere about how to make the 'info' command work properly under Cygwin ?? There's a postinstall script called 'update-info-dir.sh' which is supposed to get run automatically by setup.exe to create the info directory. If this didn't happen for some reason, you can run it manually. (Look for it in /etc/postinstall.) In case you don't have it, here are the contents: #!/bin/bash rm -f /usr/info/dir.info /usr/share/info/dir.info /usr/info/dir /usr/share/info/dir for d in /usr/info /usr/share/info; do for f in $d/*; do case "$f" in *\**) ;; */dir|*/dir.info*) ;; *-[0123456789]*) ;; *) install-info --quiet $f /usr/share/info/dir || install-info --quiet --entry="* $f ($f): $f" $f /usr/share/info/dir ;; esac done done >/dev/null 2>&1 Ken Thx a lot Ken - that did it. INFO command now works properly ! And now that begs a follow-up question... After some digging around about how the post-install scripts work in CygWin, and doing some complementary testing, it seems that, every time that CygWin Setup runs, the script will be run once and then renamed with a '.done' suffix. So that, if I want the script to run every time that Setup runs, I have to remember to manually rename it back to '.sh' after each setup run, which is, erm, sub-optimal. Any ideas about getting around this repeated manual renaming ??? There's no need for manual renaming except when something goes wrong. In general, update-info-dir.sh should get run whenever it's needed. There's a bug that's currently preventing this from happening; cgf has stated that he's working on it: http://cygwin.com/ml/cygwin-apps/2013-09/msg9.html Ken -- 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: Fwd: INFO issues [partially SOLVED]
On Thu, Sep 05, 2013 at 10:58:17AM -0400, Ken Brown wrote: >There's no need for manual renaming except when something goes wrong. >In general, update-info-dir.sh should get run whenever it's needed. >There's a bug that's currently preventing this from happening; cgf has >stated that he's working on it: > > http://cygwin.com/ml/cygwin-apps/2013-09/msg9.html Thanks, for pointing this out Ken. I'm in the middle of a revamp of "upset" to deal with issues like this and to better handle the x86/x86_64 repositories. I thought I'd have it done this week but I will probably need the weekend to finish. cgf -- 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: INFO issues [more or less fully SOLVED]
Hi all...
... replying from the list archives. Relevant backward references are:
http://cygwin.com/ml/cygwin/2013-09/msg00091.html from myself
http://cygwin.com/ml/cygwin/2013-09/msg00092.html from fernando
http://cygwin.com/ml/cygwin/2013-09/msg00099.html from Ken Brown
http://cygwin.com/ml/cygwin/2013-09/msg00100.html from Christopher Faylor
@ fernando...
| It would be nice to know if yours is a x86_64 version of cygwin
because I think there is something wrong in x86_64 version and this
must be a bug somewhere.
Indeed. I'm running setup-x86_64.exe .
| Don't know exactly where (the texinfo package?).
Well, I see at least TWO issues here, so that the answer to 'where'
doesn't seem very clear:
1. Whatever package (maybe setup itself ?) who'd be responsible for
making the 'update-info-dir' script available is NOT doing it. I'm
working with an in-house hand-made
version - source was courtesy of Ken Brown.
2. segfaults - see below.
| I have a x86_64 and I can confirm the update-info-dir post install
script is not available in the x86_64 version of cygwin.
Ditto here, as I've said above.
| ... when you run 'info ttt' using something that is not a valid
value for the info command, instead of getting the top info page you
get a "segmentation fault" error.
An example of mine from a freshly-updated setup follows:
thiers@Win-Samsung ~
$ info help
Segmentation fault (core dumped)
thiers@Win-Samsung ~
$
It should be remarked that the 'normal' functions that INFO expects DO
work normally, from the (very few) tests I've done.
@ Ken Brown...
| There's no need for manual renaming except when something goes
wrong. In general, update-info-dir.sh should get run whenever it's
needed.
Well, that MIGHT become the case whenever 'update-info-dir.sh' starts
to materialize 'by itself' in the user build. As it's currently my
case, I'm supplying it
on my own - courtesy of yourself couple days ago.
Since the script itself is missing, for the moment it's a bit hard for
me to fully trust your statement about 'should get run whenever it's
needed'...
| There's a bug that [ . . . ] cgf has stated that he's working on ...
Well, while cgf works on it, I became concerned that, whatever
(temporary ??) fix comes around, it might somehow BREAK the half-baked
solution I had prepared.
Therefore this half-noob's neurons here started working by themselves
and came up with a more flexible solution... see below.
@ALL...
Well folks this is the slightly broader solution I've come up with,
which I've tested a few times and covers a few bases (MINUS the core
dump of course):
1. Inside /etc/postinstall , my previously named 'update-info-dir.sh'
is now named 'update-info-dir_provisional_hack_thiers_2013.09.05_A.sh'.
So that, whenever CygWin starts to supply the real
'update-info-dir.sh', my own hack will remain in place and working
properly. It might then start to
REPEAT the same actions done by 'update-info-dir.sh' - I see no harm
here other than some wasted cycles of CPU & I/O. I might also detect
somehow that CygWin's
own script is finally doing its thing, and then retire my hack.
2. My .bashrc now has the following gem:
# HACK for reviving a temporarily missing postinstall script...
SCRIPT_TO_RESSURRECT=/etc/postinstall/update-info-dir_provisional_hack_thiers_2013.09.05_A.sh.done
SCRIPT_RESSURRECTED=/etc/postinstall/update-info-dir_provisional_hack_thiers_2013.09.05_A.sh
if [ -e "${SCRIPT_TO_RESSURRECT}" ]
then
echo
echo "* HACK from .bashrc(THIERS) *"
echo
mv -nvT ${SCRIPT_TO_RESSURRECT} ${SCRIPT_RESSURRECTED}
echo
echo "File EXISTED and was RENAMED. Covering temporary absence
& behavior of proper CygWin postinstall script."
echo
#else
#echo "I DONT see the file."
fi
Thx to all & cheers
Thiers
--
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
