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 ttttttt' 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
