Re: /usr/bin/find: . changed during execution of /usr/bin/find
I seem to have the same problem as you.
It was not there last time I ran updatedb which was a while ago (I do not
have it running automatically).
If anyone remembers, in Windows 95 and 98 if you worked with files on floppy
there was a good chance that windows would keep checking the floppy drive
every time you opened some program. That seemed to have been dealt with but
now on my XP machine, it has returned. If I terminate explorer.exe then
restart it, it whirls the drive. I am hoping a restart later will fix that.
I am convinced that restart (or a couple) is a universal solution to all
problems in windows :-).
More to the problem at hand, if I do 'ls /cygdrive', I get an floppy access,
same with find / -name xxx or find /cygdrive -name xxx
The problem seems to come from /cygdrive directory. Using find anywhere else
does not create a problem (e.g. find ~ -name xxx).
My solution to the updatedb problem was editing /usr/bin/updatedb to add
/cygdrive in the PRUNEPATHS list like so:
: ${PRUNEPATHS=/cygdrive /tmp /usr/tmp /var/tmp /afs}
I suppose you could also specify this on the command line for updatedb.
- Original Message -
From: Alexander Enchevich [EMAIL PROTECTED]
To: cygwin [EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 11:02 AM
Subject: /usr/bin/find: . changed during execution of /usr/bin/find
Hi all
This is the third time I am posting this problem and I got no response so
far so I am getting desperate. I guess next time I should try some idiotic
subject like help or question - these seem to draw attention... :)
Anyway here's the problem:
-
When I run 'updatedb' it exits immediately with this message:
/usr/bin/find: . changed during execution of /usr/bin/find
Output from cygcheck.exe -v -s -r -c is attached...
--
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/
???
- Original Message -
From: Alexander Enchevich [EMAIL PROTECTED]
To: cygwin [EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 11:02 AM
Subject: /usr/bin/find: . changed during execution of /usr/bin/find
Hi all
This is the third time I am posting this problem and I got no response so
far so I am getting desperate. I guess next time I should try some idiotic
subject like help or question - these seem to draw attention... :)
Anyway here's the problem:
-
When I run 'updatedb' it exits immediately with this message:
/usr/bin/find: . changed during execution of /usr/bin/find
Output from cygcheck.exe -v -s -r -c is attached...
--
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/
--
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 gcc 3.4 and cygwin
The latest message in gcc-announce http://gcc.gnu.org/ml/gcc-announce/2003/msg1.html says that i?86-*-win32 target will be deprecated as from gcc 3.4 (no date set). The only win32 target on the list of supported platforms http://gcc.gnu.org/install/specific.html is the cygwin one. Will there be no more official cygwin gcc port as of 3.4? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: please try the latest snapshot
It does fix the slow pipes on my machine when seti@home is running. - Original Message - From: Christopher Faylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 17, 2003 4:52 PM Subject: please try the latest snapshot The latest snapshot should fix some /etc handling problems (thanks to ideas and code from Pierre Humblet), like the dreaded BSOD. It may also solve the pipes are slow problem. There are also all of the fixes accumulated since 1.3.18, of course. If I don't hear too many whines about this snapshot, it may become 1.3.19. cgf -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
possible cygwin bug: delays when using pipes
Seemingly, whenever I use a pipe in bash the cygwin freezes for a long time. For example: 'echo a | cat' takes about 10 seconds to execute, 'bash -l -i' takes about a minute. I am not sure when the problem appeared. Might have been last cygwin dll release but I am not sure. First time I noticed was running 'bash -l -i'. I changed the cygwin.bat recently so for a while I thought it was my meddling but as far as I can see that is not the case. Right now the cygwin is quite unusable since any non-trivial command line takes a long time to execute. My startup script: @echo off set HOME=D:\DEV\CYGWIN\home\eugene set TERM=ansi rem D: rem chdir \dev\cygwin\bin IF NOT x%1 == x ( cd %1 ) ELSE ( cd %HOME% ) d:\dev\cygwin\bin\bash --login -i Here are the results for strace -f -m thread bash -i -l of which I can not make out much at all apart from the fact that certain combination of calls (read_pipe followed WFMO message) takes 10 seconds each : 84618461 [main] bash 3692 cygthread::cygthread: name sig, id 0xF20 54541 63002 [main] bash 3692 cygthread::cygthread: name proc, id 0xF54 17409 80411 [main] bash 3692 cygthread::cygthread: name read_pipe, id 0x9B0 9713344 9793755 [main] bash 3692 cygthread::detach: WFMO returns 0, id 0x0 1395 9795150 [main] bash 3692 cygthread::cygthread: name read_pipe, id 0xD04 9982585 1935 [main] bash 3692 cygthread::detach: WFMO returns 1, id 0xD04 10042750 29820485 [main] bash 3692 cygthread::cygthread: name read_pipe, id 0xD04 9958336 39778821 [main] bash 3692 cygthread::detach: WFMO returns 1, id 0xD04 212 39779033 [main] bash 3692 cygthread::cygthread: name read_pipe, id 0xD04 5883 39784916 [main] bash 3692 cygthread::detach: WFMO returns 1, id 0xD04 39658 39824574 [main] bash 3692 cygthread::cygthread: name read_pipe, id 0xD04 10007110 49831684 [main] bash 3692 cygthread::detach: WFMO returns 1, id 0xD04 2207 49833891 [main] bash 3692 cygthread::cygthread: name read_pipe, id 0xD04 5329 49839220 [main] bash 3692 cygthread::detach: WFMO returns 0, id 0xD04 84618461 [main] bash 3692 cygthread::cygthread: name sig, id 0xF20 54541 63002 [main] bash 3692 cygthread::cygthread: name proc, id 0xF54 17409 80411 [main] bash 3692 cygthread::cygthread: name read_pipe, id 0x9B0 9713344 9793755 [main] bash 3692 cygthread::detach: WFMO returns 0, id 0x0 1395 9795150 [main] bash 3692 cygthread::cygthread: name read_pipe, id 0xD04 9982585 1935 [main] bash 3692 cygthread::detach: WFMO returns 1, id 0xD04 10042750 29820485 [main] bash 3692 cygthread::cygthread: name read_pipe, id 0xD04 9958336 39778821 [main] bash 3692 cygthread::detach: WFMO returns 1, id 0xD04 212 39779033 [main] bash 3692 cygthread::cygthread: name read_pipe, id 0xD04 5883 39784916 [main] bash 3692 cygthread::detach: WFMO returns 1, id 0xD04 39658 39824574 [main] bash 3692 cygthread::cygthread: name read_pipe, id 0xD04 10007110 49831684 [main] bash 3692 cygthread::detach: WFMO returns 1, id 0xD04 2207 49833891 [main] bash 3692 cygthread::cygthread: name read_pipe, id 0xD04 5329 49839220 [main] bash 3692 cygthread::detach: WFMO returns 0, id 0xD04 Also, when finally in bash, results of 'echo a | strace -f -m syscall,thread cat' where the delay is in read_pipe then WMFO pair: 62876287 [main] cat 2432 normalize_posix_path: src /etc/passwd 7457032 [main] cat 2432 symlink_info::check: not a symlink 947126 [main] cat 2432 symlink_info::check: 0 = symlink.check (D:\dev\cygwin\etc\passwd, 0x22F7C8) (0xA) 5227648 [main] cat 2432 normalize_posix_path: src /etc/group 4158063 [main] cat 2432 symlink_info::check: not a symlink 788141 [main] cat 2432 symlink_info::check: 0 = symlink.check (D:\dev\cygwin\etc\group, 0x22F7A8) (0xA) 4078548 [main] cat 2432 _cygwin_istext_for_stdio: _cygwin_istext_for_stdio (0) 578605 [main] cat 2432 _cygwin_istext_for_stdio: _cifs: fd not open 348639 [main] cat 2432 _cygwin_istext_for_stdio: _cygwin_istext_for_stdio (1) 338672 [main] cat 2432 _cygwin_istext_for_stdio: _cifs: fd not open 328704 [main] cat 2432 _cygwin_istext_for_stdio: _cygwin_istext_for_stdio (2) 318735 [main] cat 2432 _cygwin_istext_for_stdio: _cifs: fd not open 4079142 [main] cat 2432 cygthread::cygthread: name sig, id 0xD4C 7049846 [main] cat 2432 normalize_posix_path: src /dev/piper 264 10110 [main] cat 2432 fhandler_base::set_flags: filemode set to binary 3083 13193 [main] cat 2432 normalize_posix_path: src /home/eugene/strace.txt 481 13674 [main] cat 2432 symlink_info::check: not a symlink 98 13772 [main] cat 2432 symlink_info::check: 0 = symlink.check (D:\dev\cygwin\home\eugene\strace.txt, 0x22F488) (0xA) 191 13963 [main] cat 2432 fhandler_base::set_flags: filemode set to binary 177 14140 [main] cat 2432 normalize_posix_path: src /dev/conout 305 14445 [main] cat 2432 tty_min::set_ctty: attached tty1073741824 sid 2432, pid 2432, tty-pgid 0, tty-sid 2432 2873 17318 [main] cat
Re: possible cygwin bug: delays when using pipes
Your guess is correct, I do run seti@home in the background and stopping it gets rid of the problem. Very unfortunate situation since this makes cygwin virtually unusable in certain software configurations. - Original Message - From: Randall R Schulz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 16, 2003 3:54 AM Subject: Re: possible cygwin bug: delays when using pipes Eugene, Cygwin 1.3.18 + Cygwin pipes + background, low-priority CPU load = Long delays in Cygwin pipe I/O Are you running SETI@home? That seems to be the most popular. It runs at the lowest priority, but still produces this symptom. I've been ignored every time I pointed this out. I guess those of us who run Cygwin as well as background CPU-soaker apps will have to choose one or the other (or develop considerable patience while using Cygwin). Randall Schulz -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Setup glitch
Had an unexpected problem with setup updating my cygwin installation. There were a couple of updates, one of them postgresql. I decided to uninstall postgresql (first time I tried to uninstall something this way I think), update others. Setup quit with the 'Download complete' message box straight away. When I chose to update all the packages, as I usually do, everything behaving as normal, setup proceeding to download the packages. Except from the log: 2002/12/08 00:00:22 Starting cygwin install, version 2.249.2.5 2002/12/08 00:00:22 Current Directory: D:\Dev\cygwin 2002/12/08 00:00:26 source: download 2002/12/08 00:00:27 Selected local directory: D:\dev\cygwin 2002/12/08 00:00:28 net: IE5 2002/12/08 00:00:32 site: ftp://mirror.aarnet.edu.au/pub/cygwin 2002/12/08 00:00:43 compress_bz::error called 2002/12/08 00:00:43 compress_bz::error called 2002/12/08 00:01:16 mbox note: Download Complete -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Setup glitch
Correction, my mistake. The packages were already downloaded which is why no action was taken. The uninstall still flailed. Once I chosen to download packages I had already the setup must have discovered the local copies. Would be nice for setup to provide a check for local copies in its download caches and provide a visual clue to that extent to avoid embarassment for people like me... :) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] xwinclip Test 04 (Cygwin/XFree86 and Windows clipboard integration)
Explanation and fix for the ms-tnef attachments: http://help.netscape.com/kb/consumer/19981102-1.html - Original Message - From: Brian Gallew [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, June 12, 2002 11:20 PM Subject: RE: [ANNOUNCEMENT] xwinclip Test 04 (Cygwin/XFree86 and Windows clipboard integration) Harold L Hunt said: Eric Peabody's messages are getting bounced by the list server. Apparently his mail server is changing the format of the message somehow. Anyway, his reply is below. Most likely he's using MS Outlook and/or MS Exchange. They're famouns for adding ms-tnef bits to messages. It *can* be disabled, but I have no idea how to do it myself. I just know that the vendors who still do business with me have all figured out how to do it. The ones who couldn't figure it out no longer do business with me.
Re: Trivial Feature Request: beep()
On my system the I get the beep through the speakers. The default beep is enabled in the control panel. The funny thing though, similarly to Harold I get different pitches, I get a high-pitched beep from the cmd.exe that sounds like a pc speaker but is coming from soundcard but from bash I get the sound I defined in the control panel. There was a thread on this before in cygwin list and more than once. Does not really relate to the XFree but I thought I'd mention it, maybe it is related somehow. There is one with Subject: 'Beeping' from 16/03/2002 on how to turn beeping OFF for readline (echo set bell-style none ~.inputrc), for vi (:set vb) and HKEY_CURRENT_USER\Control Panel\Sound\Beep registry key which I think would be toggled by the control panel anyway but still would not hurt to check. My rxvt does not beep because I run it with -vb option (no visual bell). There is same option for xterm. Could this be somehow related to the problem? I cannot check because my xfree is older than the packaged ones and does not beep at all. Eugene. - Original Message - From: Brian Gallew [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 11, 2002 11:59 PM Subject: Trivial Feature Request: beep() Is it possible to make the X11 bell work? xset q tells me the bell should be ringing, but I can't seem to get it to work.
Re: Missing terminfo data in XFree86 4.2.0
Good observation. I never really missed the xterm entries, but now that you mentioned it, they are not there. I noticed it also because of the handy script from Alan Dobkin (re ncftp missing libs). The original files are in terminfo-5.2-1 package. The setup text (in the Xinstall.sh) states that new termcap entries are needed to take advantage of some new features of xterm, whatever they are. There is a way to generate most of those entries from the /usr/X11R6/lib/X11/etc/xterm.termcap: captoinfo /usr/X11R6/lib/X11/etc/xterm.termcap /usr/X11R6/lib/X11/etc/xterm.terminfo, line 90, terminal 'xterm-color': enter_alt_charset_mode but no acs_chars /usr/X11R6/lib/X11/etc/xterm.terminfo, line 90, terminal 'xterm-color': exit_alt_charset_mode but no acs_chars /usr/X11R6/lib/X11/etc/xterm.terminfo, line 144, terminal 'xterm-sco': enter_alt_charset_mode but no acs_chars /usr/X11R6/lib/X11/etc/xterm.terminfo, line 144, terminal 'xterm-sco': exit_alt_charset_mode but no acs_chars These will generate all missing files except for xtermm. Comparing these files to their backed up namesakes shows that they are different. Could these be the files that were intended to be generated originally by setup? I do not know anything about mechanics of xterminfo to be able to go beyond the mechanical regeneration of the files. I am not even sure what the errors mean. Something to do with acsc@ part of the definition which man terminfo mentiones but even then I am not sure what the manpage is talking about. - Original Message - From: Michael [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 06, 2002 12:48 AM Subject: Missing terminfo data in XFree86 4.2.0 Hi I ran into the following problem with the current XFree86 distribution, but could not find any mention of any solution here or elsewhere. SYMPTOMS * vt102 terminal setting (TERM) in xterm windows instead of xterm * WARNING: terminal is not fully functional error messages from /bin/les s * Missing /usr/share/terminfo/x/xterm and other terminfo data files CAUSE - 1. The current XFree86 for Cygwin distribution is missing the file xterm.terminfo (but not xterm.termcap) in Xlib.tgz. (However this is not true for other distributions, eg FreeBSD.) It is missing in the distribution available from the Cygwin mirrors and the distribution available directly from XFree86. 2. After unpacking the distribution files, the script Xinstall.sh asks the user whether to update the terminfo entries. The default is no, but the blurb notes that new features will be unavailable otherwise. If the user says yes: 3. The script moves a number of existing terminfo entries to *.bak 4. The script tries to run tic on /usr/X11R6/lib/X11/etc/xterm.terminfo to replace them 5. Since this file is not present, tic fails 6. The following terminfo files are subsequently effectively missing: xterm, xterms, xterm-24, xterm-vi, xterm-65, xterm-bold, xtermm, xterm-boldso, xterm-ic, xterm-r6, xterm-old, xterm-r5, vs100 INTERIM SOLUTIONS - During install (pre-emptive): * Do not elect to update terminfo entries After install (treatment): * Setting the TERM variable to another value such as cygwin or ansi is a temporary workaround * Moving the renamed files back to their original names reverses the damage (mv xterm.bak xterm etc) DISTRIBUTION FIX? - Include the file or change the installation script QUESTIONS - * Is there some reason xterm.terminfo is missing, or is this an error? * Is it possible to use e.g. the FreeBSD distribution's xterm.terminfo file? * Is it advised against updating the terminfo data? * If so, then what about updating termcap entries (suggested by Xinstall.h)? * What is lost by not using the new terminfo data? Thanks Michael
Re: cx-logos
It is a good point that maybe just CX is not enough and it should be Cygwin + X logos but nupur's logo is also much easier on the eye than Chris's. Vivid red and green on a bright blue background - that is violent on the eyes. Long ago in the time of eight-color displays there were no other options but now we have more range to work with. Maybe some sort of compromise between the two? Nupur's color scheme was simple but, I thought, good.
Re: Invisible X client window borders
not much help from me but I had the same problem with TWM myself, no border when resizing. I think I had border when I was moving but I am not sure it was a while ago. I downloaded and compiled Blackbox and the problem doesn't show up under that. - Original Message - From: Dwight Schauer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 25, 2002 2:26 PM Subject: Invisible X client window borders I'm not sure if this is an Xserver problem or a a window manager on. In TWM and in Afterstep I don't get the rectangle or grid when moving or resizing client windows. The proper window decoration does show up on the x clients. I have an Nvidia GeForce II MX and Windows XP. (On an Athlon Thunderbird). I installed the latest Cygwin and Xfree a few days ago. I'm running AfterStep v. 1.8.11 compiled and running under Cygwin/XFree. I did the same at work a week ago on a different machine, and resizing, placing, and moving windows is fine. (I don't have window contents shown on resize or move, and I use manual window placement if there is no room to display the window). At work on Cygwin/XFree the grid/rectangle shows up correctly in Afterstep, as it does on a native Linux XFree86 server. Apart from that, XFree and Afterstep seem to be running fine on Cygwin. I can't get aterm to work, (it compiles and run and can get as far as displaying the shell prompt, but then it locks up) so I'm using the cygwin provided rxvt instead and it runs fine under X.
Re: Not all mans available
I once asked along same lines and I was told that originally in GNU info was going to be the replacement to man system... Why I am not sure but that must have not worked out really well since half the stuff info digs up seems to be manpages but without the eyecandy (highlighting and underline). Even when at the bottom of the manpage it says, see info for complete documentation, info still digs up same old manpage. The hypertext abilities are nice to have of course, if there is a lot of cross-references and see-also's. More directly to your query, I don't think there are any spare manpages or info files anywhere. There is also documentation in /usr/doc but you will not find diff there. Documentation to diff is in info format but I was unable to get to it through the top menu of info. 'info diff' doesn't work either, info --file=diff works. I think I am missing out on something very basic here because this doesn't seem very natural to me (after 'man', I guess). As for 'read' thats a bash inbuilt command and it is part of the bash manpage or info page. Here info vindicates itself, navigating to the right section is much easier through hyperlinks than linear text of manpage. - Original Message - From: Robert Mark Bram [EMAIL PROTECTED] To: Cygwin [EMAIL PROTECTED] Sent: Tuesday, March 19, 2002 3:35 PM Subject: Not all mans available Hi all! When I try man read or man diff I am told by Cygwin No manual entry for read or No manual entry for diff. Was there a setup option with Cygwin I didn't include in order to get all the manuals? Is there a way for to download them? Thanks! Rob :) :-} ;- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Newbie.. Please help!
ps -W shows all processes on the machine ps -h shows all available options There is no man page for ps though. cd c:/ or cd /cygdrive/c/ gets you to c: drive. type 'mount' to display all Windows drives mountings - Original Message - From: Vladimir Kostine [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 02, 2002 7:11 PM Subject: Newbie.. Please help! Re, My company recently moved to Windows XP hence forced me to run it as my desktop machine. I've installed VSHELL to access the box as well as CYGWIN, however, cannot figure out how to merge tcsh will Windows environment. ps shows only processes running under cygwin, I cannot chdir to c:\ and end up being locked in cygwin's root directory. My main gold is to be able to view Window's running processes and kill/restart them. Perhaps this questions has already been addressed numerous time. Your patience and help are both highly appreciated. V. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl reports different cwd() value
Not really sure why you want to work around a standard way to express paths but, if you need to, maybe something like this? perl -e 'use Cwd;$path=cwd();print [,$path,]\n;$winpath = `cygpath -w $path`;print [,$winpath,]\n;$winpath=~ tr/\\/\//;print [,$winpath,]\n;' Excuse any bad perl, I am at hello world level with it. - Original Message - From: Timothy Canham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 02, 2002 8:38 AM Subject: Perl reports different cwd() value If you are in: c:/temp (alternate way to address drives under cygwin) and you perform perl -e use Cwd; cwd(); you get: /cygdrive/c/temp. Any way to work around this? Version 1.3.9 -- Timothy K. Canham Jet Propulsion Laboratory Pasadena, CA [EMAIL PROTECTED] MDS Flight Software -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Child died with signal 13
Hmm, it worked for me. I assume out of the documentation that tar will spawn gzip -d filename and pipe it into itself. So, if 13 is the system error from tar, which is EACCES, permission denied so maybe there is a problem accessing the file? The listing shows that file is owned by Administ(rator?) and prompt says Administrator so it seems correct but if you substitute filename for nonexistent one then you get tar: Child died with signal 2 -- 2 being 'file not found' error so it seems that there is a problem with permissions? Eugene. - Original Message - From: Volker Quetschke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 26, 2002 9:38 PM Subject: tar: Child died with signal 13 Hi, recently I found a problem when I try to untar some tar.gz archives under cygwin. The tar.gz at this link is ca. 1,5kb http://www.scytek.de/expat.pat.tar.gz . It is just one example, it is taken from OpenOffice641C. On my Windows 2K machine, cygwin updatet a few minutes ago, I get: Administrator@LISI ~/tartest $ tar -tzf expat.pat.tar.gz pat/ pat/xmlparse/ pat/xmlparse/hashtable.h.pat pat/xmlparse/xmlparse.h.pat pat/xmltok/ tar: Child died with signal 13 tar: Error exit delayed from previous errors Administrator@LISI ~/tartest $ la total 6 dr-xr-xr-x2 Administ Kein0 Feb 26 10:02 . drwxr-xr-x6 Administ Kein 4096 Feb 26 10:02 .. -r-xr-xr-x1 Administ Kein 1435 Sep 20 2000 expat.pat.tar.gz I get this error in both cases, with CYGWIN=ntsec tty and CYGWIN=tty. I also get this error on Cygwin on our Windows 2K server, but there I can't change the environement ;-) If I do an gunzip first, and then a tar -tf foo.tar I get no error. I also don't get an error doing the tar -tzf on cygwin on Windows98SE or Linux. Only few *.tar.gz files have this problem, but some have. I have three more examples, but they are not so short as the one mentioned above. Any ideas? Volker -- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
tar -f behaviour
Looking at tar I noticed a small oddity in its behaviour, as compared to what I would have thought was 'normal' When dealing with files, using dash before options, the 'f' option has to be the last one in the option string, e.g. tar -tfz tarball.tar.gz works while tar -ftz tarball.tar.gz doesn't reporting that file 'tz' does not exist. It seems that 'f' anything after the 'f' option is considered to be the archive filename. tar -f tarball.tar.gz -tz works. When dash is absent the oddity is absent too, tar ftz tarball.tar.gz works with options f, t and z in any combination whatsoever. There is no tar manpage on my system. I looked at 'tar --help' for option explanation which didn't offer anything and I compared with linux tar behaviour. The linux version doesn't exhibit any pickiness about position of 'f' option when dash is being used. I do not have any experience with unix command line parsing but I wonder if the presence of this behaviour only when there is a dash indicates it has got something to do with getopt() or popt? I do not seem to have manpage for getopt() either even though it is references in popt manpage. In conclusion, is this a bug or a feature? PS I checked the package listing on http://cygwin.com, there is no man page with tar distribution. There is tar.texi in the source package. Maybe there should be manpage in the binary package. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Re[2]: Core dumped just only with strcat!
Dani, You should really give us more info about the fault like say, the actual line number. Compile with -g option, run in gbd, it should tell you where it crashes, send us as much info as possible. I do not have experience in mysql but I did have a look at the code. If you are crashing in teh mysql call maybe you not allocating and initialising the MYSQL *base_de_datos structure? Are you calling mysql_init() as per http://www.mysql.com/documentation/mysql/bychapter/manual_Clients.html#mysql _init? Another thing: mysql expects you to put ';' at the end of every SQL query, thats in their docs too. Eugene. - Original Message - From: Pavel Tsekov [EMAIL PROTECTED] To: Dani P. [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, February 19, 2002 10:44 PM Subject: Re[2]: Core dumped just only with strcat! Lots of stuff omitted... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
