Re: Bash / cygwin process spawning (?) performance very slow
On 24/09/2015 18:24, lit...@null.net wrote: >> On 24/09/2015 11:57, lit...@null.net wrote: >>> Obviously something is. The FAQ entry does not mention performance, but >>> real failures. >>> How to further diagnose this? > > I took the plunge and spent almost a full day trying to find the cause. > > 1. Booting into Safe Mode gave a huge performance boost > 2. By eliminating all services and programs in Normal Mode, one-by-one, I > found the offender: > > turns out that Comodo Firewall (Free version) loads a DLL in each process > that is the cause of the delay. > Although I only use the Firewall, and do not use any "AntiVirus" features, > still it causes delay during startup of a process. > > However, after disabling it -- which did speed up process spawning in Bash -- > I encountered the other problem I already had much more often. > For now I consider the issue of slow spawning to be solved > (although it would have been nice if there was an easier way to diagnose it, > maybe with tracing?) Comodo firewall pro is listed in https://cygwin.com/faq/faq.html#faq.using.bloda. Looks as if the free version should be listed too. -- 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: cp -rup fails if a file/directory exists
On 06/09/2015 22:16, Arthur Schwarz wrote: > cp -rup dir /h/ works for version 8.23-4 but for version 8.24-1 it produces > an error " cannot create directory '/h/dir': File exists", where 'dir' is a > directory and '/h/' is a flash drive. > > Is there something I can do to force a save? I do not want to delete then > save, I'd rather update a file/dir that exists or create a file/dir that > doesn't. > > I've unsuccessfully looked for the cp update notice. I think these are what you were looking for: https://cygwin.com/ml/cygwin/2015-08/msg00472.html https://cygwin.com/ml/cygwin/2015-08/msg00485.html coreutils version 8.24-3 probably fixes your problem. -- Cliff -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sed anomaly in bash script
On 14/11/2014 17:20, cyg Simple wrote: $ TEST=`echo 'c:\windows' | sed -e s.\\..g` $ echo $TEST c:\\windows file name=sed.sh TEST=`echo 'c:\windows' | sed -e s.\\\.\.g' echo $TEST /file $ bash -x sed.sh ++ echo 'c:\windows' ++ sed -e 's.\.\g' sed -e expression #1, char 7: unterminated 's' command + TEST= + echo CYGWIN_NT-6.1 HOSTNAME 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin Does anyone have a suggestion on turning c:\windows into c:\\windows? Try: TEST=$(echo 'c:\windows' | sed -e 's.\\..g') echo $TEST -- Cliff -- 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: Too many mailing lists
I for one am finding this discussion rather boring and would prefer it be moved elsewhere. I can't see any changes happening - only one vote in favour apart from the OP, and that's someone who's views, as a result of his earlier behaviour, are likely to receive less weight than he'd like. I'm mildly against making any change - but I don't want or expect my view to be considered. -- Cliff -- 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: Missing strings.exe in binutils
On 02/06/2014 00:01, Jeff Hubbs wrote: I have a script within a very complex software package that uses the strings command. Everything I Googled/read suggests that strings.exe comes from the binutils package. The problem is that neither of the available versions of binutils seem to actually contain strings.exe. It's not in /usr/bin; find can't turn it up under /usr at all. There's even this: $ cygcheck -p strings.exe Found 19 matches for strings.exe x86/binutils/binutils-2.24.51-2 x86/binutils/binutils-2.24.51-3 And if I go to https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86%2Fbinutils%2Fbinutils-2.24.51$ this appears: 2014-05-29 02:01 709661 usr/bin/strings.exe Yet there's no strings.exe. I've even tried binutils packages from a few different mirrors. If there's no fixed binutils package available, can someone shoot me a strings.exe I can just fly into place for the time being? strings.exe certainly is in the binutils package I have installed. Either you haven't actually installed binutils or something has gone wrong with the installation. I suggest you rerun setup.exe and install or reinstall binutils, and if that doesn't help follow the problem reporting guidelines at http://cygwin.com/problems.html - in particular attach the requested cygcheck output. -- Cliff -- 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: Bash silently truncates the Command Line when called programatically via CreateProcess as MAXPATHLEN was reduced to 8192 from 16384
On 31/05/2014 14:28, Abhijit Bhattacharjee wrote: ... Qs/Stmt: Possibly setting the CYGWIN environment variable to noglob might cause things to work as desired. Ans: I am yet to test this, but I trust your answer. I am yet to figure out as to how I can set the environment variables CYGWIN with multiple values i.e. I need to set it with nodosfilewarning and noglob. I was trying to read though your code environ.cc and seems to me I can simply separate it with a delimiter. Your documentation is silent about it. If you know it off hand, please let me know, that will reduce some effort for me to read and debug though your code :-) Hmm - you didn't look very hard. Why not read the Cygwin User manual - in particular this section: https://cygwin.com/cygwin-ug-net/using-cygwinenv.html where it clearly says the items are space-separated. -- Cliff -- 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: $PATH contains dot but unclear where it comes from
On 19/02/2014 19:32, Larry Hall (Cygwin) wrote:
On 2/19/2014 2:10 PM, Andrey Repin wrote:
Greetings, Larry Hall (Cygwin)!
From the Windows Run... or Search programs and files edit box,
type cmd.exe. From the console window that opens as a result, type
the following.
echo %PATH%
c:\cygwin64\bin\bash --norc --noprofile -lix
echo $PATH
Larry, we walked through exactly this process, but he denied any
investigation
by cutting the output of the first echo command.
You're right Andrey. You were covering much the same ground with Robert.
It's strange that he cut off the part of the results that was the key.
My original inclination was to not step into this thread in the first
round. I don't know why I changed my mind for the second. ;-)
I think the point of Robert's original inquiry was to find out where/how
the . could get added if it was happening in Cygwin. Given the ground
covered (at least once) in this thread, I think we've provided all the
information that should be needed to track this down. If not, the
remainder of the where? and how? questions really aren't Cygwin-
specific so I think this thread is really off-topic.
Perhaps I shouldn't wade in here, but I think the discussion so far has not
focussed on exactly what the OP said. I also don't understand why he chose
to cut his interesting output to 80 chars, but if you can believe what he says,
which I'll repeat here, there is something odd happening:
He appears to have generated a log file almost as asked - first echoing %PATH%
in
a cmd shell, and then appending an invokation of bash with args --login -x -i
His result (cut) was:
$ head -10 log | cut -c 1-80
PATH=C:\PROGRAM FILES (X86)\NVIDIA CORPORATION\PHYSX\COMMON;C:\PROGRAM FILES
(X8
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
+ PATH='/usr/local/bin:/usr/bin:/cygdrive/c/PROGRAM FILES (X86)/NVIDIA
CORPORATI
+ MANPATH=/usr/local/man:/usr/share/man:/usr/man:
+ INFOPATH=/usr/local/info:/usr/share/info:/usr/info:
++ id -un
+ USER=rklemme
+ ORIGINAL_TMP=/cygdrive/c/Users/rklemme/AppData/Local/Temp
+ ORIGINAL_TEMP=/cygdrive/c/Users/rklemme/AppData/Local/Temp
OK - so useless for us - but he goes on to say...
The first line does not contain the dot. The fourth line contains the
dot at the end:
$ sed -nre '4s#^(.{20}).*(.{80})$#\1...\2#p' log
+
PATH='/usr/local/b...Intel/WirelessCommon:/cygdrive/c/Users/rklemme/Applications/SysinternalsSuite:.'
So there is no dot at the end of PATH as seen in cmd - and (I assume, since
this was also discussed)
no duplicated semicolons or trailing semicolon at the end of the cmd PATH. But
the very first
PATH printed by bash does contain a trailing dot. I assume this is before bash
has sourced any
startup scripts - so where does it come from? Could a trailing unprintable (eg
CR) in the path
somehow cause Cygwin dll or bash to add the dot?
I'd suggest if Robert does want to pursue this he (a) reads
http://cygwin.com/problems.html, and
submits his cygcheck output (I may have missed it but I don't recall seeing
it), and (b) repeats
his diagnostic attempts without cutting, and showing us the full results (not
cut or elided).
-- Cliff
--
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: Reduce noise in dependency declaration during uninstall in setup.exe
On 23/01/2014 14:36, Warren Young wrote: On 1/22/2014 18:13, Christopher Faylor wrote: If you were actually volunteering to do something then it wasn't made clear by your long email or in your lack of response to Larry's SHTDI. I'm not going to volunteer until I have some concept of the scope of work, and some idea of how you'd want the problem solved. That's why it would have been better if your reply had given me some guidance. Maybe I should be flattered that you think I can just jump into the middle of the single most complicated part of setup.exe, its very core, and not only figure out a way to solve my issue, but to actually solve it in a way that's going to be accepted. I'm sure I'll be corrected if I'm wrong, but I suspect the problem with maintenance/extension of setup.exe is twofold: firstly, it's a non-Cygwin program and secondly it is large and not well structured. Also, the original implementer/maintainer has long since left the Cygwin community. One solution to this would be to reimplement it as two separate parts - a non-Cygwin envelope (which could even be installed as an msi) and a Cygwin-based package maintainer. The Cygwin-based part would be a completely separate Cygwin installation, with its own cygwin1.dll, and a minimal set of utilities, and would not interfere with the main installation. The non-cygwin wrapper would simply install/update this mini-Cygwin system and invoke the Cygwin-based package maintainer. The package maintainer would be based on the existing setup.exe, and would benefit from being able to take advantage of the Cygwin layer - in particular that would remove the need to back-port Cygwin knowledge into the various filesystem-related components of setup.exe such as tar. Indeed, the package maintainer need not have a built-in tar as it could use (a private copy of) the main Cygwin tar utility. As I see it the main downside of this is the problem of implementing a windows GUI in a Cygwin program without the overhead of using X. It would be a lot of work to get there - but once in place I imagine there would be a lot more volunteer effort to maintain/improve it. And no - sorry, I'm not offering to do any of the work. It would be fun but I just haven't the time. -- Cliff -- 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: http://cygwin.com/setup*.exe
On 22/07/2013 16:23, Christopher Faylor wrote: We have updated the setup.exe executables on cygwin.com in preparation for the upcoming release of Cygwin 1.7.22. ... I hit a couple of problems using the new 32-bit setup yesterday - during which it managed to break my installation. System is XP SP3 32-bit - no BLODA issues encountered before. I usually have no problems upgrading Cygwin - I normally stop any Cygwin processes if necessary to ensure the update can complete without a reboot, but even if I don't the fixup-on-reboot mechanism works fine. However, setup V2.814 (32 bit) didn't behave as well - it popped up a dialog box warning of processes in use, but no processes were listed. Clicking on Stop processes didn't stop any processes, and the dialog was redisplayed. Clicking on Continue allowed the install to complete, but after a reboot I had a broken installation - investigation showed several dlls (including cygwin1.dll) in /usr/bin and an exe in /usr/sbin had not been updated, and the new ones were still there with extension .new. Manually deleting and renaming fixed this issue - but clearly this shouldn't have happened! A look at setup.log showed nothing amiss - setup reported that it couldn't update the dlls/exes, and that a reboot was necessary - so it should have scheduled the renames for reboot. A second problem I hit was that I had a system crash (unrelated to Cygwin) while setup was downloading updated packages. This lost cached disk data, so when setup was restarted it detected several corrupt packages (MD5 sumchecks failed). It offered the choice of installing anyway or omitting the affected packages - but I couldn't see a way to make setup re-download them. Selecting reinstall didn't work - that would reinstall the old version but updating again complained of a corrupt new package (and choosing the install anyway option is *not* a good idea as it tries to use the corrupt package and fails to unpack). Manually deleting the affected packages from my install directory fixed this - but am I missing a better way? I also had a problem with cygports - I use the setup -K option - and yesterday the cygports site was missing the setup .ini/.bz2 files - but today I see that's fixed :-) -- Cliff -- 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 with _WIN32 preprocessor symbol and libusb
The libusb package uses the presence of _WIN32 to determine which calling convention to use for the library externals - if _WIN32 is defined it uses WINAPI. [See /usr/include/libusb-1.0/libusb.h.] There is of course the question of whether it is/was sensible to use WINAPI when the package is compiled for Cygwin, but (as the header points out) this doesn't really matter as long as the same is used for compiling the library and compiling user applications. Unfortunately the default has been changed recently. _WIN32 used to be defined by default in the Cygwin environment (so the current libusb package is using WINAPI), but some time between last December and now this was changed so _WIN32 is no longer defined. I see from mail archives this was intentional - but it has unfortunately broken usage of libusb. I assume the absence of _WIN32 is permanent, in which case libusb needs to be reissued. Note - there is of course a trivial workaround until libusb is reissued - simply define _WIN32 explicitly in any source including libusb.h. -- Cliff -- 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: Problem during C source code compilation
On 06/09/2012 13:40, Fausto Arinos Barbuto wrote: Christopher Faylor writes: On Wed, Sep 05, 2012 at 07:49:57PM +, Fausto Arinos Barbuto wrote: Hello, I'm trying to compile a simple C source code but I'm getting the following error(s): $ gcc -o struct struct.c Start here: http://cygwin.com/problems.html Didn't help a whole lot, but thanks anyway. Peering into the mailing list I found out that someone had had a barely similar problem and was suggested to reinstall binutils. I did that and it didn't work. I also tried the FAQ -- to no avail. Still have the problem. But you didn't follow the advice in that link. You said you were going to warmly appreciate any advice - not ignore it! One of the key parts, (and it is in bold) is: Run cygcheck -s -v -r cygcheck.out and include that file as an attachment in your report. Please do not compress or otherwise encode the output. Just attach it as a straight text file so that it can be easily viewed. -- Cliff -- 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: False BLODA warning concerning cygusb?
On 17/08/2012 10:39, Corinna Vinschen wrote: I have no problems with occassional false postives. The detect_bloda option is meant for diagnostic purposes only. It's not meant to used all the time. It slows down *every* thread start up! Thanks. I was only reporting it as I thought I remembered a request for false positives to be reported. I think that's why I turned the detect_bloda option on in the first place. I must admit I was also slightly curious - what is an open-source library (libusb) built under Cygwin doing that makes it look like BLODA? [Of course I could spend time looking at the source to find out, but time is in short supply, so I guess I'll just have to stay curious.] -- Cliff -- 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
False BLODA warning concerning cygusb?
I am seeing the following when invoking a utility which uses libusb to drive a USB JTAG interface dongle: Potential BLODA detected! Thread function called outside of Cygwin DLL: C:\cygwin1.7\bin\cygusb-1.0.dll I've had CYGWIN=detect_bloda set for some time (months), and the utility (developed locally) has never triggered this before, so I think a recent Cygwin update has triggered this. (Note cygusb has not changed since last year.) I'll happily submit full cygcheck details if that would prove useful - the relevant details (AFAICS) are: Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 15 Stepping 0, AuthenticAMD' 73k 2011/08/16 C:\cygwin1.7\bin\cygusb-1.0.dll - os=4.0 img=1.0 sys=4.0 cygusb-1.0.dll v0.0 ts=2011/8/16 21:45 2789k 2012/07/20 C:\cygwin1.7\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2012/7/20 21:55 Cygwin DLL version info: DLL version: 1.7.16 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 262 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 libusb1.0 1.0.8+git20110720-1 OK libusb1.0-devel 1.0.8+git20110720-1 OK -- Cliff -- 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: Side-by-side configuration is incorrect reported as permission denied
On 13/08/2012 13:51, Earnie Boyd wrote: On Mon, Aug 13, 2012 at 4:24 AM, Herbert Stocker wrote: Hi, Imho, EACCESS is indeed a bit misleading because it suggests permission problems. Better would be to have an EFAIL as a generic error. Actually i was missing an EFAIL several times when my programs needed to return an error code that did not match well with what i found in errno.h . You may think it is misleading but http://pubs.opengroup.org/onlinepubs/009604499/functions/exec.html states that EACCESS is the correct value. Well, for a start that's an POSIX V1. Here's a link to V2 exec: http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html I don't see in the description for EACCES [Note - one S, not two] that it should be returned when there is a missing runtime component. Also, see this general page on errors. The errors documented for a particular function aren't intended to be exhaustive. An implementation can return others as long as it is consistent. http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_03 In any case Cygwin's primary aim is to provide a Linux-like environment, not pure POSIX. Linux exec/execve manpages list many more error codes. -- Cliff -- 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: Side-by-side configuration is incorrect reported as permission denied
On 11/08/2012 20:22, Christopher Faylor wrote: On Sat, Aug 11, 2012 at 10:32:13AM -0700, Andrew DeFaria wrote: On 08/10/2012 07:32 PM, Larry Hall (Cygwin) wrote: On 8/10/2012 7:31 PM, Andrew DeFaria wrote: I use Cygwin a lot. And I kick off Windows processes a lot. Recently I've been having a problem with my system but from Cygwin all I see is permission denied: Ltsdo-adefaria:cd /cygdrive/c/Program\ Files/IBM/RationalSDLC/Clearquest Ltsdo-adefaria:ls -l clearquest.exe -rwxr-xr-x+ 1 Administrators clearusers 245760 Jun 2 2011 clearquest.exe* Ltsdo-adefaria:clearquest bash: ./clearquest: Permission denied Ltsdo-adefaria: However if I use cmd the real error message comes out: Ltsdo-adefaria:cmd /c clearquest The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail. I know that this side-by-side configuration is incorrect is a configuration error on my machine and I need to fix it, but shouldn't Cygwin's exec(2) report the side-by-side error instead of the more erroneous Permission denied error? Cygwin doesn't report Windows error codes. It reports POSIX ones. I have no idea why there would be a POSIX error code for side-by-side errors but if there were, then reporting that is more appropriate. I thought that perhaps Cygwin would report back error *messages* not just error *codes*... Cygwin emulates Linux. Permission denied is an error message associated with a specific errno. Neither Cygwin nor Linux know anything about a side-by-side configuration problem. I imagine there are many Windows errors which Cygwin has to interpret internally and present as POSIX errors to the user. It looks like this Windows7 error may mean that some Windows runtime components are missing - in which case wouldn't ELIBACC or ELIBEXEC be more appropriate? Permission denied suggests that changing the access permissions, or running as a user with greater privileges would solve the problem. -- Cliff -- 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: AW: line.exe is missing
On 22/07/2012 14:33, Paul Maier wrote: I found out, that line.exe is in the package util-linux-2.17.2-1. (http://cygwin.com/packages/util-linux/util-linux-2.17.2-1) But I automatically got the newer version util-linux-2.21-1 from the mirror, where line.exe is _not_ included: http://cygwin.com/packages/util-linux/util-linux-2.21-1 Ok, I will downgrade to util-linux-2.17.2-1 to get line.exe. May I ask you to have a look at this to save line.exe for future releases? The line utility has been deprecated for a while, and now appears to have been removed from the util-linux package - you should switch to using the head utility instead. Note this is not Cygwin-specific! -- Cliff -- 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: length in gawk returns wrong value
On 19/07/2012 17:16, Aaron Schneider wrote: Looking at /etc/profile.d/lang.csh if ( $?LC_ALL == 0 $?LC_CTYPE == 0 $?LANG == 0 ) setenv LANG `/usr/bin/locale -uU` I wonder why in my system the setenv command does not exist: $ setenv -bash: setenv: command not found and why the if structure is not followed if (test for true) then command ; fi On the other side, /etc/profile.d/lang.sh seems to be ok. I think you'll find the clue is the .csh extension. That syntax is for the C-shell, not bash. -- Cliff -- 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: length in gawk returns wrong value
On 19/07/2012 17:53, Aaron Schneider wrote: I can't find such csh or cshell on my system, I've searched from packages and I only see scsh, slsh, posh, mosh, tcsh, zsh, mksh that I don't have installed in my system any of them, unless csh comes with the system. How do I run the csh? tcsh is the C shell - as indeed it says in the description setup.exe shows you. -- Cliff -- 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: 1.7.15: periodically losing network interfaces under Win7 x64
On 04/07/2012 22:30, Ed wrote: Under normal circumstances, I have 9 network interfaces (between VPN, wireless, etc). These show up when I first start a bash shell with ipconfig /all. However, periodically cygwin seems to be losing access to all network interfaces. When this happens, I only see the basic Windows IP Configuration header with my hostname DNS information. I've tried starting the bash session as administrator with the same result. Not even sure how to debug this one. Any help is appreciated. What reasons do you have for thinking this is a Cygwin problem? Network connections are managed by Windows, not Cygwin, and ipconfig is a MS Windows application. [You will see the same running it under the MS command shell.] -- Cliff -- 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: 64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
On 22/05/2012 20:06, Matt Seitz (matseitz) wrote: From: Cygwin-L On Behalf Of Warren Young I would say that the vast majority of the packages in the Cygwin distribution could not reasonably make use of 64-bit data spaces. However, one of your arguments in this thread cuts both ways: the fact that there are a few packages that reasonably can do so means you cannot say we don't need it. If someone wants a 64-bit version of a packages in the distribution, then how about they build a 64-bit version of the package and report the results? That would give the distribution maintainers actual data about the costs and benefits. Hear hear. Well said. Perhaps we can drop this tedious thread now, or else TITTTL. IMHO it has shown rather lamentable knowledge of both compiler technology and RISC/CISC architecture from at least one responder. -- Cliff -- 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: date command shows time 20 minutes into future
On 27/01/2012 12:48, Corinna Vinschen wrote: On Jan 27 10:50, David Balažic wrote: Hi! I'm running an up to date version of cygwin (update a week ago or so) on Windows XP Pro SP3. Today I noticed the date command prints the wrong time: - actual wall clock time: 10:47 - date output: Fri Jan 27 11:07:38 CEST 2012 - date -u: Fri Jan 27 10:08:01 UTC 2012 - windows system time (as in systray) : 10:48 Any clue? I don't know where you get the CEST from, but other than that the time problem should be at least partially solved in the snapshots. The difference from system time shouldn't become more than 40 ms. I think the CEST comes from Windows. If you don't have TZ set, I think Cygwin turns the timezone names Windows provides into abbreviated names by taking the leading letters. So Windows Central European Standard Time = CEST and Central European Daylight Time = CEDT I've never liked this - arguably Windows is wrong to use non-standard naming for the timezones. It's even worse for us in the UK - we get GMTST and GMTDT - ugh. [UK may be a little unusual, but perfectly reasonable in using GMT and BST.] You can see the Windows names in registry entry HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones -- Cliff -- 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: 1.7.9: static const std::string initialization lost in child process when using fork, dlopen
On 21/08/2011 17:50, Christopher Faylor wrote:
On Sun, Aug 21, 2011 at 01:48:21PM +0200, wh...@web.de wrote:
Hello,
??
it seems that a child process does not see the initialization of a
static const std::string variable if it is defined in a dll. Instead this
corrupt variable
lead to a STATUS_ACCESS_VIOLATION.
??
The following 4 example files demonstrate this behaviour:
Am I the only person who sees lots of strange characters in the examples
below where, presumably there is supposed to be whitespace?
cgf
1) dllif.h: ?? ?? ??(define the dll's interface)
#include string
class cTestIf {
public:
?? virtual std::string get() = 0;
};
??
??
...
Well, I'm afraid my mind-reading skills aren't good enough to answer that,
but my mail client doesn't show them (TB under Windows).
However, it didn't take long to find out that they are UTF-8 C2 A0
sequences, which is the code for a non-breaking white space.
The mime header does have Content-Type: text/plain; charset=UTF-8, so
it looks like your email client may be to blame.
-- Cliff
--
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 1.7: why there is a directory E/cygwin/dev in the tree of cygwin ?
Eric Blake wrote: [reviving an old thread, relevant to today's current bash postinstall failures] ... I'm building a new bash package now that should fix all this mess, by using the same means as 000-cygwin-post-install.sh to populate necessary entries into /dev. Splendid! Just for the record, I noticed this over a year ago: http://cygwin.com/ml/cygwin/2009-07/msg00944.html So, proof that we don't need a bug tracker - mailing lists work fine! The change to check postinstall exit codes is likely to throw up a few more buglets yet, but looks like it will be well worth the pain. [Now, I'm just waiting for something completely different: http://cygwin.com/ml/cygwin/2009-12/msg00298.html ] -- Cliff -- 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: Problem with select() on console
Christopher Faylor wrote: On Thu, Jul 15, 2010 at 01:44:19AM +0100, Cliff Hones wrote: When select() is used to test for input availability on the standard cygwin console in normal (cooked) mode, it indicates input is available as soon as any key is pressed. However, a call to read(0,...) will (correctly) block until a terminating RETURN is entered. select() should only indicate input is available when a call to read would *not* block - ie when a read call will immediately return at least one character or an error such as EOF. ... Since, AFAIK, Windows has no way to do this, I don't see how it could be done easily. You could, I guess, pull characters into a buffer until a newline was found but that would be pretty error-prone and any use of select() would potentially invalidate console i/o for subprocesses. So, I don't see this changing anytime soon. Hmm. Having looked further, it's not just select() which is affected. If you set the NONBLOCK flag on the console, and perform a read(), you get error EWOULDBLOCK/EAGAIN until a key is hit. When a key is hit, the read blocks until RETURN is entered. I must look at the console source - but it seems from behaviour and what you are saying that Windows provides a way for the user to determine that console input has started (since read() and select() behaviour changes when a key is pressed) but no way to determine in advance that a call to input a complete line will block because an incomplete line is present. I'm surprised this hasn't come up more frequently. In my case, I have an app which needs to respond to user input line-based commands, but also does other processing. I don't want the app to block every time the user starts to enter a command. Of course I could use threads, but that's an unnecessary change (at least unnecessary on Linux etc). And I could insist users use mintty, but that's rather presumptuous. -- Cliff -- 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: Problem with select() on console
Cliff Hones wrote: I must look at the console source... And now I have, and I see that fhandler_console does its own line editing, so is perfectly aware of the input line state. So blocking as soon as any key is typed seems a shortcoming of cygwin, not windows? I see there may be a difficulty with storing incomplete lines, or with synchronizing processing of new console events seen by different cygwin threads/processes, and it may be deemed unworthwhile (especially as it doesn't seem to be a frequently raised question), but to it seems doable. -- Cliff -- 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 with select() on console
When select() is used to test for input availability on the standard
cygwin console in normal (cooked) mode, it indicates input is available
as soon as any key is pressed. However, a call to read(0,...)
will (correctly) block until a terminating RETURN is entered.
select() should only indicate input is available when a call
to read would *not* block - ie when a read call will immediately
return at least one character or an error such as EOF.
The behaviour of the following test case illustrates this. When run
in a console window typing a single key causes the program to wait
for the whole line. When run under mintty or on Linux the
select() calls will continue to return no input until RETURN is
entered.
#include stdio.h
#include stdlib.h
#include sys/io.h
#include sys/time.h
#include string.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include errno.h
#include stdarg.h
int main(void)
{
fd_set rs;
struct timeval tv;
char buff[100];
while (1)
{
sleep(1);
printf(Calling select\n);
FD_ZERO(rs);
FD_SET(0, rs);
tv.tv_sec = tv.tv_usec = 0;
int k = select(1, rs, NULL, NULL, tv);
if (k 0)
perror(Error calling select);
else if (FD_ISSET(0, rs))
{
printf(Input available\n);
int n = read(0, buff, sizeof(buff));
printf(read returned %d\n, n);
}
}
return 0;
}
-- Cliff
--
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 mirror
James Miller wrote: We have raised a new mirror available at http://cygwin.parentinginformed.com/ and physically located in Canada. The contact point for this mirror is me, James Miller at jmil...@parentinginformed.com. I am not sure whether it should got to this list or not - it is far from being evident because the instructions say I should contact sourcemaster, but none of the list descriptions explicitly mentions which one the sourcemaster is in :) I think it means you should email sourcemas...@cygwin.com -- Cliff -- 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 mirror
Christopher Faylor wrote: I think it means you should email sourcemaster... ARGH. Please don't use raw email addresses in your messages. So far sourcemaster has remained relatively spam-free. I'd like to keep it that way. Oops - how silly of me - very sorry. So easy to overlook that when it is actually the email address which you are trying to convey. Of course that would explain why the cygwin mirror page does not explicitly mention the mail domain to use either. And unless we use inline images I doubt there's any way to convey an email address without circumlocution which can't be scraped by spammers. -- Cliff -- 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: timezone setting ?
Nellis, Kenneth wrote: You can set the time zone by setting environment variable TZ to a file path relative to /usr/share/zoneinfo, e.g., export TZ=America/New_York I'm less clear on how it determines the time zone when TZ is not set. My guess is that TZ=posixrules is the default. Corrections are encouraged. Well, around 5 years ago I looked into this, as I found that the default timzone names used on UK installations were wrong. Here's what I posted back then: http://cygwin.com/ml/cygwin/2005-08/msg00126.html Since then the zoneinfo implementation has been added, but it appears that if you don't explicitly set TZ the default is still taken from your Windows timezone setting, so I still get GMTST and GMTDT, which are somewhat unconventional and confusing for UK users. Needless to say, a UK Linux installation correctly defaults to GMT and BST. I suppose setup.exe could be trained to convert the windows timezone into a sensible global TZ setting - or possibly it could just present the timezone list for a manual choice, as most attended Linux installs do. -- Cliff -- 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 1.7: why there is a directory E/cygwin/dev in the tree of cygwin ?
Eric Blake wrote: On 03/17/2010 02:19 AM, rolandc wrote: I do not understand why the postinstall script bash.sh is so complex DEVDIR=$(cygpath -au C:/$(cygpath -am /dev/) | sed 's|/c/\(.\):/|/\1/|') mkdir -p $DEVDIR || result=1 it would be simple (too simple?) to mkdir -p /dev || result=1 Yes, it would be too simple. /dev already exists, so the mkdir would fail to do anything useful. We REALLY want to create the underlying Windows directory at the same location at where /dev would be mounted, and to do that, we really do want to know the windows location (drive letter and all) of /. Then, by using mkdir of that fancy windows path that happens to live at the same place as where /dev normally resolves to, then we can guarantee that /dev/stdin gets created as an actual symlink in the windows heirarchy (since it does NOT resolve via the /dev magic mount point), and that tab-completion can see any contents placed into the windows counterpart directory. Eric, are you sure bash post-install needs to bother to make /dev? When this was raised last July, Corinna said: What this postinstall script should do is just this: mkdir -p /dev || result=1 or to drop the mkdir entirely since the /dev/ dir has been already created by the 000-cygwin-post-install.sh script. -- Cliff -- 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 1.7: why there is a directory E/cygwin/dev in the tree of cygwin ?
Andy Koppe wrote:
Christopher Faylor:
rolandc:
I have installed cygwin 1.7 in e:\cygwin1.7
After installation, there is a strange directory :
/E/cygwin1.7/dev/ (posix path)
E:\cygwin1.7\E\cygwin1.7\dev (win32 path)
What is the role of this directory?
It is /dev.
/dev would be E:\cygwin1.7\dev, not E:\cygwin1.7\E\cygwin1.7\dev.
Looks like a bug to me, and the finger of blame points at
/etc/postinstall/{00,}bash.sh:
DEVDIR=$(cygpath -au C:/$(cygpath -am /dev/) | sed 's|/c/\(.\):/|/\1/|')
mkdir -p $DEVDIR || result=1
I haven't stared at the sed magic long enough to work out exactly what
it does or why, but it looks suspiciously like it assumes that Cygwin
is installed on the C drive.
This looks to be the same as the following problem:
http://cygwin.com/ml/cygwin/2009-07/msg00944.html
-- Cliff
--
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: Missing documentation on bash
Paul McFerrin wrote: I can't seemed to find any man pages for bash or other documentation. I'm having terriable problems is getting my .bat/.sh script working and I'm thinking changing shells. I normally use the same routine for all .bat scripts. It's not difficult to find bash documentation. Did you try the obvious? http://lmgtfy.com/?q=bash+user+manual -- Cliff -- 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: Problem Updating using cygwin.exe
Mitch wrote: This note reports my problem in updating cygwin January 5, 2010. I chose to update cygwin because of problems with spawning Xterm windows from a remote login to our main computer. I can run some CAD sW ( Cadence ) and not others nedit remotely. Window appears but when a the focus is on the new Xterm window and I enter any kb letter the window disappears. In any event the problem I am currently reporing concerns updating cygwin. Please find:Problem description and attempts to solve it, Setup.log.full and excerpts setup.log for 12/22/09 successful first install and 1/5/10 unsuccessful install. - Thanks Mitch Newcomer Problem: Can not update Cygwininstalled ~Dec 22, 2009 1. Installed several fresh copies of setup.exe ( 2.573.2.3 ) Well, there's your problem. 2.573.2.3 is not fresh. Pick up the latest from the website - and check you don't have some faulty cache somewhere serving you up an old one. It would be helpful if (as well as not repeating yourself) you laid out your text more readably! -- Cliff -- 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: Need more instructions in setup.exe
Paul McFerrin wrote: How does one get to the util-linux package. I can't find that category using the standard setup.exe? I keep seeing this category in setup.ini but know where else. Paul, Simplest way is to click the View button on the package page - you will then see all the packages displayed in alphabetical order. Click View some more to select other package views! -- Cliff -- 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: UTF-8 in Cygwin console on 1.7
Andy Koppe wrote: 2009/12/8 Cliff Hones: Is UTF-8 character output fully supported in the standard Cygwin console ($TERM=cygwin) under Cygwin 1.7? Yes (except it's limited to the Basic Multilingual Plane). You need to select a Unicode-capable font in the console properties though. Basically, anything but the default Raster Font. Ah - yes, I should have thought to look at the console window font! Lucida and Consolas both display euro correctly. However, font selection does not affect the incorrect handling of NUL. Perhaps setup.exe should offer to generate a shortcut (as well as .bat and .ico) with, say, the Lucida font selected? I have just checked Cygwin 1.5 and this aslo mishandles NUL, so I guess it is a long-standing problem (or Microsoft oddity, or workaround for something else...). It is showing up as an error when I use telnet in a cygwin console window - it seems telnet must run in binary mode for UTF-8 to be passed successfully, but then telnet passes on the NUL in the \r NUL sequence and you get a space at the start of each line. [This could be considered a telnet bug - but independent of Cygwin NUL handling.] -- 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: UTF-8 in Cygwin console on 1.7
Andy Koppe wrote: 2009/12/8 Cliff Hones: .. I have just checked Cygwin 1.5 and this aslo mishandles NUL, so I guess it is a long-standing problem (or Microsoft oddity, or workaround for something else...). I don't know what the story behind that is, but a (trivial) fix is attached. It also changes the handling of SI (0xF) in the same way. I think you missed attaching your fix - or else it has got lost. I would guess the change is to file cygwin/fhandler_console.cc, and is simply to remove line 1616 [ cursor_rel (1, 0); ] (after case NULL:) -- Cliff -- 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: Odd directory created when installing 1.7
Cliff Hones wrote:
.. One further possibly useful piece
of informaion - the create timestamps on the odd directories are all the
same, and 14 seconds later than the timestamp on the correct dev directory.
Looking at the install log, I see this timestamp matches the time the
bash.sh postinstall was run, so it would have been this snippet which
did it, I imagine:
# Install /dev/fd, /dev/std{in,out,err}. The bash builtin test was compiled
# to assume these exist, so use /bin/test to really check.
DEVDIR=$(cygpath -au C:/$(cygpath -am /dev/) | sed 's|/c/\(.\):/|/\1/|')
mkdir -p $DEVDIR || result=1
--
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: Odd directory created when installing 1.7
Corinna Vinschen wrote:
On Jul 28 14:43, Cliff Hones wrote:
Cliff Hones wrote:
.. One further possibly useful piece
of informaion - the create timestamps on the odd directories are all the
same, and 14 seconds later than the timestamp on the correct dev
directory.
Looking at the install log, I see this timestamp matches the time the
bash.sh postinstall was run, so it would have been this snippet which
did it, I imagine:
# Install /dev/fd, /dev/std{in,out,err}. The bash builtin test was
compiled
# to assume these exist, so use /bin/test to really check.
DEVDIR=$(cygpath -au C:/$(cygpath -am /dev/) | sed
's|/c/\(.\):/|/\1/|')
mkdir -p $DEVDIR || result=1
Hmm, this looks kind of fragile. Not to say it looks wrong.
$ cygpath -am /dev/
C:/cygwin/dev
Ok.
$ echo C:/$(cygpath -am /dev/)
C:/C:/cygwin/dev
Huh?
$ cygpath -au C:/$(cygpath -am /dev/)
/cygdrive/c/C:/cygwin/dev
Huh^2?
$ echo $(cygpath -au C:/$(cygpath -am /dev/) | sed 's|/c/\(.\):/|/\1/|')
/cygdrive/C/cygwin/dev
That's ok again, but is it always right? I can't believe it.
No - it's not right with my setup - where I have C:\ mounted as /C.
With Cygwin 1.5 (which has exactly the same bash.sh) I get
DEVDIR=/C/c:/cygwin/dev, and with 1.7 I get /C/C:/cygwin1.7/dev.
Interestingly, the 1.7 install seems to have detected my 1.5
mount points and preserved them - I wasn't expecting that.
I guess this must have been broken on 1.5 for ages, but did no harm
as the create would fail as : was invalid in filenames.
Already using the fixed C:/ in the expression is incorrect, given
that everybody is free to install Cygwin to a non-C: drive.
Would it have been a workaround for buggy cygpath or setup.exe in
the past?
What this postinstall script should do is just this:
mkdir -p /dev || result=1
or to drop the mkdir entirely since the /dev/ dir has been already
created by the 000-cygwin-post-install.sh script.
Quite.
--
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
Odd directory created when installing 1.7
I installed 1.7 today for the first time, having deliberately waited until near the end of beta testing out of cowardice (no; actually because my use of Cygwin isn't that great at the moment, is not particularly unusual, and unfortunately I've not had the time I'd like to devote to tracking down bleeding-edge problems). I must say I was very impressed - it installed with no obvious problems and everything seems to be running well. I know a lot of hard work has gone into this, both from the core developers and the many package maintainers. Well done to all. Just one minor quirk I've noticed so far. Pardon me if it's known; I didn't spot it in the mail archives. I installed in parallel with an existing 1.5 installation, so installed with root set to C:\Cygwin1.7. After the installation completed, I had a directory named C: at the the top level of my C drive, and under it directory Cygwin1.7\dev (which was empty). dev has also been correctly created under the real root. I see nothing relevant in the install logs, nor cygcheck output, though I'll gladly supply these if useful. -- 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: [OT] RE: liblrdf
Dave Korn wrote: John Emmas wrote on 08 October 2008 15:06: - Original Message - From: Dave Korn John Emmas wrote on 08 October 2008 13:37: Dave, you must be psychic. I knew you were going to say that. /rimshot LOL - sadly, my elation proved to be short-lived. What was actually in cygwin-ports was l i b r d f (spaces for easier legibility) - instead of:- l i b l r d f which is what I actually need. Ah, then it wasn't a typo first time round, I was forseeing the future![*] cheers, DaveK [*] - This is how real psychics work... And to add to the fun, John's host has the wrong timezone set (GMT not BST) so his posts are listed by my mail client *after* the replies from Dave. -- Cliff -- 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: Attack against Cygwin?
Martha Adams wrote: Hi, I'm a Cygwin user for some time past; and I check my machine frequently using Grisoft AVG Free. On Aug 10 my AVG found something called Obfustat.GCD (not Obfustated.GCD) which it said had infested several files with particular focus on Cygwin. I have Googled on 'Obfustat.GCD' and today one hit came up: minkara.carview.co.jp/userid/299856/blog/5808766/ which is in Japanese but Google does a translation of sorts. This apparently was posted Aug 8, and the writer mentions Cygwin. On Aug 9 my AVG found 'Win32/Polycrypt' as seven or so *.dll files including Byte\Byte.dll, CN\CN.dll, and EBCDIC\EBCDIC.dll. Two attacks in two days, gets my attention. Does it deserve yours, and a general warning? No - they are almost certainly false positives, and it has already been noted here. AVG was reporting Polycrypt and/or Obfustat on various Cygwin files from Aug 8th to Aug 13th, but the current virus data files seem ok. -- Cliff -- 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: Attack against Cygwin?
Martha Adams wrote: Hi, I'm a Cygwin user for some time past; and I check my machine frequently using Grisoft AVG Free. On Aug 10 my AVG found something called Obfustat.GCD (not Obfustated.GCD) which it said had infested several files with particular focus on Cygwin. I have Googled on 'Obfustat.GCD' and today one hit came up: minkara.carview.co.jp/userid/299856/blog/5808766/ which is in Japanese but Google does a translation of sorts. This apparently was posted Aug 8, and the writer mentions Cygwin. On Aug 9 my AVG found 'Win32/Polycrypt' as seven or so *.dll files including Byte\Byte.dll, CN\CN.dll, and EBCDIC\EBCDIC.dll. Two attacks in two days, gets my attention. Does it deserve yours, and a general warning? No - they are almost certainly false positives, and it has already been noted here. AVG was reporting Polycrypt and/or Obfustat on various Cygwin files from Aug 8th to Aug 13th, but the current virus data files seem ok. -- Cliff -- 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: print from xfig
Steven Woody wrote: On 12/14/06, Davies, Roger [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bengt-Arne Fjellner Sent: Thursday, December 14, 2006 2:33 AM To: cygwin@cygwin.com Subject: Re: print from xfig Steven Woody skrev: thank you. but the FAQ only explained how to print if one know the printer's network share name. i think my problem firstly is find out the printer name, that is not explained in the FAQ. does anyone get know how to know a printer's share name if the printer is shared via Windows's domain? i am sorry for such a question, but the printer is automatically installed on my computer, might via a network startup script, so i lose the chance to get know the details. the only thing i can do now is to play with the printer's properties dialog. Presuming you have access to the shared printer through the windows control panel, the standard naming convention displayed in the control panel looks something like printername on servername. So, all you'd need to do is lpr -P//servername/printername yourfile and with luck you'd have output. the problem is, it only has a 'printname' and with no servername on it. that's what makes me confusion and i think the MS-Windows domain plays a role here. another guess is, because the printer is a network printer, it has it's own ethenet connector, so it does not connect to any server. In that case, you could try installing it as a local printer under Windows. Go to Add printer, select local printer, choose create a new port, select Standard TCP/IP port, and fill in your printer's hostname. If you make this printer sharable, you should be able to print to it using the windows name you've given it. -- Cliff -- 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: How do I install files dc.exe and file.exe needed for GODI (Ocaml compiler) installation
Dan wrote: I have already installed cygwin on my windowsxp machine. I am lacking the files dc.exe, file.exe and others which are supposed to reside in /bin if you are trying to install GODI (used for Ocaml compiler). I would like to install these .exe files and have (unsuccessfully) searched cygwin.com site to see if they are mentioned anywhere. I also ran setup again to see if they are referenced anywhere. Until I get them, I cannot install GODI. If anybody knows what I should do, I would greatly appreciate you letting me know. Use the package search utility on the Cygwin home page to find which packages you need, and then run setup again, and select those packages. -- Cliff -- 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: rsync over ssh hang issue understood
Dave Korn wrote:
On 26 April 2006 17:01, Corinna Vinschen wrote:
On Apr 26 11:51, Peter Keitler wrote:
For the script to run, a sshd has to started on the local machine and
the user name has to be adapted within the script. Could some of you
please run the script twice (the error only occurs when the files
already exist on the client side) in order to see if the script also
hangs? [...] #!/bin/bash
COMPSERV_USER=peter
COMPSERV_SERVER=localhost
RSYNC_PARAMS=--recursive --progress
# Create large amount of files on the server
mkdir ~/testdir_clnt
ssh [EMAIL PROTECTED] 'mkdir -p ~/testdir_srv; for
((i=0;i300;i++)) ; do dd if=/dev/random of=~/testdir_srv/file${i}.lst
bs=1 count=5000; done' # Sync files to client rsync -vv
$RSYNC_PARAMS [EMAIL PROTECTED]:testdir_srv/*
~/testdir_clnt/
I just tried it a couple of times. http://cygwin.com/acronyms/#WJFFM
Doesn't even run once for me. Creating all the files over ssh works fine
but the rsync invocation fails with
(Client) Protocol versions: remote=1919251285, negotiated=29
protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
Is there something I need to do to make your testcase work? (By 'work', of
course, I mean 'break'!)
cheers,
DaveK
--
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: can't install rpm
René Berber wrote: Tasica Mabaya wrote: I have an quastion regarding RPM instalation. I'm trying to install tinyos on cygwin, and after downloading the neccesary packets I got a message: bash: rpm: command not found I I wanted to install rpm, and I found it on http://sourceforge.net/projects/cygwin-rpm/ but when I download it I cannot open .tar.tar file. I tried to change to .tar.gz but it doesn't work. Am I on the rght path? Could somebody please help me to install rpm on cygwin? No. There are two points here: 1. You can install the rpm command from the Cygwin distribution, you don't need an external package, just use setup.exe and choose rpm to install. 2. Your original quest, installing tinyos, will probably fail. I don't know what tinyos is but if the rpm package has any compiled code in it, it is compiled for a certain operating system and processor, most probably linux/intel and will not run under Cygwin/intel. If the contents are java (code and/or jars) then it probably works. Why don't you install the Cygwin specific package? (i.e. tinyos-cygwin-1.1.zip) I think the OP is probably following the directions on the tinyos download pages for windows. It should all work once the official Cygwin version of rpm is installed using setup. The rpm packages in question do appear to be cygwin-specific, so point 2 above does not apply. If further problems do occur, the appropriate forum to ask for further advice would be the tinyos help mailing list. -- Cliff -- Cliff -- 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: can't install rpm
René Berber wrote: Cliff Hones wrote: [snip] Why don't you install the Cygwin specific package? (i.e. tinyos-cygwin-1.1.zip) ---^ This is the TinyOS distribution for Cygwin. I think the OP is probably following the directions on the tinyos download pages for windows. It should all work once the official Cygwin version of rpm is installed using setup. The rpm packages in question do appear to be cygwin-specific, so point 2 above does not apply. No, the directions for installing under Cygwin don't direct the user to use rpm, they have 2 options: use a Windows installer or unzip the package. I did have a look at the TinyOS pages before posting. Sorry, but I beg to differ. I suspect we are looking at different pages, but here's what I was referring to: http://www.tinyos.net/tinyos-1.x/doc/install.html#windows -- Cliff. -- 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: Need information about data and bss segment address access in cygwin
[Note TOP posting is not the preferred way on this group. I can't be bothered
to reformat it all - so look back on the thread for the full context.]
Sudhahar wrote:
Thanks Cliff/Dave. I could not find the code where the dll data/bss
segments address are updated in cygwin. But in the fork code we are
doing a copy for all linked and loaded dlls data/bss segments by
giving the address as
for (dll *d = dlls.istart (DLL_LINK); d; d = dlls.inext ())
{
debug_printf (copying data/bss of a linked dll);
if (!fork_copy (pi, linked dll data/bss, d-p.data_start,
d-p.data_end,
d-p.bss_start, d-p.bss_end,
NULL))
goto cleanup;
}
and
for (dll *d = dlls.istart (DLL_LOAD); d; d = dlls.inext ())
{
debug_printf (copying data/bss for a loaded dll);
if (!fork_copy (pi, loaded dll data/bss, d-p.data_start,
d-p.data_end,
d-p.bss_start,
d-p.bss_end,
NULL))
goto cleanup;
}
And also please let me know if there exist any document which gives
some idea about this.
Brian Dessent wrote:
There is no code to update them. As the other replies have already
said, they act like labels and are established by the linker via the
linker script. When the program runs, they contain the address, that's
it. The values in the per_process struct are filled in by the startup
code in _cygwin_crt0_common.cc.
The 'ld' manual, section 3.5.3.
Sudahar wrote:
Brian,
From your comments I understand that dll data/bss segment
address is same as that of process data/bss segment
address(data_start, data_end, bss_start and bss_end) when the process
is loaded. Is that right
[I am not 100% confident I'm right her, but...] Each cygwin dll has its own
separate data and bss segments, and the linker generates _data_start__ etc
symbols for the dll when the dll is linked, just as it does for a normal
.exe. The dll initialisation code, which you will find in
winsup/cygwin/dcrt0.cc, copies the addresses of these symbols into
the dll structures (d-...) which is used during fork as you quoted above.
Hope that helps.
-- Cliff
--
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: clean_setup.pl website disappeared ? does anyine have the latest and greates clean_setup.pl version?
Urs Rau wrote: So, if anybody does have version 1.0700 (or newer) please let me know. I have a copy, which I shall mail you. Is there any interest in putting this somewhere more permanent? -- Cliff -- 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: clean_setup.pl website disappeared ? does anyine have the latest and greates clean_setup.pl version?
Igor Peshansky wrote: On Sat, 21 Jan 2006, Cliff Hones wrote: Urs Rau wrote: So, if anybody does have version 1.0700 (or newer) please let me know. I have a copy, which I shall mail you. Is there any interest in putting this somewhere more permanent? Like the cygwin-apps cvs repository? Igor Sorry, I've never heard of that. A Google found some messages dating from 2000, but I don't see any details that one was ever set up. Where is it hiding? For some reason I've never quite understood, cygwin-apps is subscriber-only. If anyone subscribed to cygwin-apps would like to put it in the repository, I will be happy to send a copy. However, I have no contact with the original author (Michael A Chase) and I have no idea if he would be happy with this arrangement. -- Cliff -- 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: clean_setup.pl website disappeared ? does anyine have the latest and greates clean_setup.pl version?
Cliff Hones wrote: For some reason I've never quite understood, cygwin-apps is subscriber-only. If anyone subscribed to cygwin-apps would like to put it in the repository, I will be happy to send a copy. However, I have no contact with the original author (Michael A Chase) and I have no idea if he would be happy with this arrangement. How strange - a search for cygwin apps cvs repository searching the cygwin list found nothing useful. After posting this, I read further down the mailing lists, and there I did see references to the cygwin-apps cvs repository. So pardon the above - I see it exists now, but as I'm not subscribed to the cygwin-apps list I don't suppose I could submit anything. I can send clean_setup to anyone who would like to put it in the repository, or I can make it available on a private website. -- Cliff -- 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: lseek + read = ENOENT
Eric Blake wrote: [I wrote] This seems to be a bug in gcc. The off_t argument to lseek is a 64-bit type, but instead of being sign-extended to 64 bits, the value passed (-sizeof(data)) passed is only extended to 32-bits, so is actually +4294967292. [This is OT for Cygwin, and probably only of interest to Language Lawyers.] No, it is not a bug in gcc. Read a good book on C, please. Hmm, I wonder why this mailing list seems to encourage throw-away comments like that? I said seems to be as I had a suspicion that the type promotion rules of C may be to blame. I should have *read* the good book I have (the ISO C spec, as it happens). However, I would say that this is one of the areas where I think the C spec is wrong, as it leads to quite unintuitive semantics in cases like this. Contrast this with Ada, where (roughly) expression components are coerced to the required type of the whole expression before arithmetic operators are applied, and also where intrinsic operations like sizeof yield unconstrained values (ie they are not considered to be 32-bits, 64-bits or whatever until the value is needed for a subsequent operation). If you write: int n = -sizeof(data); lseek(fd, n, SEEK_END); it works as expected. Mostly right, because there you are promoting a signed 32-bit number to a signed 64-bit number, which sign-extends. However, that approach is risky - if you have a file that is bigger than 2 GB, you will not get the correct result, because negation of an unsigned greater than 2GB results in a positive signed 32-bit value less than 2GB, instead of the intended negative 64-bit value with absolute value greater than 2GB. Indeed, you too were mostly right. The size of the file is nothing to do with this - it's the size of the object data which matters. My expression can indeed go wrong if the size of data (in bytes) is between 2**31 and 2**32, which is a trifle unlikely (but perhaps not so in the future). The C spec states that the result of sizeof() is of type size_t, which must be an unsigned integer type defined in stddef.h. I don't see any requirement for it to be 32 bits (just that it must be capable of holding at least 65535), so if the gcc implementation had chosen to make size_t 64 bits, the original code would have worked. The safer fix is to call: lseek(fd, -(off_t)sizeof(data), SEEK_END); -- Cliff -- 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: Building Cygwin from CVS
Christopher Faylor wrote: On Thu, Jan 19, 2006 at 08:53:26PM -0800, Joshua Daniel Franklin wrote: . The FAQ info describing how to run the tests is wrong. It worked for me when I ran make check in the i686-pc-cygwin/winsup subdirectory of my build directory. OK, I'll fix that. Before we do that can we please find out WHAT is actually wrong? There is no description of the problem beyond the above. I run the testsuite several times a day by cd'ing to winsup/testsuite so I know that works. Lets not make changes that may only be a cockpit error from one user and, especially lets not document actual bugs. Fair enough. My setup is as follows: Directory cygbuild (in my home dir). cygbuild/src checked out of CVS as per the FAQ. I chose to make my build directory at the same level as src, rather than a subdirectory of it. [The FAQ just says build must not be the same as src, though the example does have it as a subdirectory.] So for my build I did: cd cygbuild/build mkdir /install (../src/configure --prefix=/install -v; make) If I cd to src/winsup/testsuite and do make check, I get: [EMAIL PROTECTED] ~/cygbuild/src/winsup/testsuite $ make check make: *** No rule to make target `check'. Stop. which is hardly surprising, as there is no Makefile there: [EMAIL PROTECTED] ~/cygbuild/src/winsup/testsuite $ ls CVS ChangeLog Makefile.in README config configure configure.in cygload cygrun.c libltp winsup.api So that seems to be the problem. Should there have been a Makefile in CVS, should configure have made one, or is the FAQ wrong? I'm afraid I don't know enough detail about the way the Cygwin build is set up to answer this myself, but I realise it was a little rash of me to assume it was the FAQ in error. I suppose having build parallel to src rather than a subdirectory could have a bearing - in which case the FAQ should say that build *has* to be immediately under src. Or even possibly that when I ran configure I didn't have dejagnu or cocom installed. -- Cliff -- 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: Need information about data and bss segment address access in cygwin
Sudhahar wrote: Thanks Dave your reply answered the question where they declared. But how does these variables get the segment address of data and bss for a running process to make a copy to the child process? This is the questions which is a puzzle to me. The linker places these variables at the start and end of the data and bss segments. The application can then find the addresses of the segments by taking the address of the variables (eg __data_start__). They aren't strictly variables in the C sense, inasmuch as trying to read or assign to them may corrupt your application or cause a segmentation error. Look in winsup/cygwin/lib/_cygwin_crt0_common.cc -- Cliff -- 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/
Oddities with cygcheck
Looking through the cygcheck output I attached to an earler message http://cygwin.com/ml/cygwin/2006-01/msg00799.html I noticed strange output concerning kill.exe: Found: C:\WINNT\kill.exe Found: C:\cygwin\bin\kill.exe Warning: C:\WINNT\kill.exe hides C:\cygwin\bin\kill.exe Now, I do, as it happens, have a KILL.EXE (note capitalization) in my WINNT, but it doesn't hide the Cygwin one. I do not have C:\WINNT ahead of my \bin on my path. Indeed, I can run the different kills in various ways: [EMAIL PROTECTED] ~ $ kill kill: usage: kill [-s sigspec | -n signum | -sigspec] [pid | job]... or kill -l [sigspec] That, of course, is the bash builtin. [EMAIL PROTECTED] ~ $ KILL Usage: KILL [-f] [-signal] [-s signal] pid1 [pid2 ...] KILL -l [signal] Send signals to processes further usage deleted And that is the Cygwin kill from /bin - capitals avoids the builtin, and it is found on the path in preference to the WINNT version [EMAIL PROTECTED] ~ $ /c/WINNT/KILL missing pid or task name And that's the one in WINNT (some old Microsoft version from WinNT3.5, I think, which I didn't even know was there). So, two minor problems - cygcheck is wrong to say the WINNT kill hides the Cygwin one, and cygcheck doesn't output the WINNT file name in the correct case. Just thought I'd mention it here for reference. -- Cliff -- 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: Oddities with cygcheck
Dave Korn wrote: Cliff Hones wrote: Looking through the cygcheck output I attached to an earler message http://cygwin.com/ml/cygwin/2006-01/msg00799.html I noticed strange output concerning kill.exe: Found: C:\WINNT\kill.exe Found: C:\cygwin\bin\kill.exe Warning: C:\WINNT\kill.exe hides C:\cygwin\bin\kill.exe Now, I do, as it happens, have a KILL.EXE (note capitalization) in my WINNT, but it doesn't hide the Cygwin one. I do not have C:\WINNT ahead of my \bin on my path. Well, you did when you ran that cygcheck: ---msg00799.html--- Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\WINNT\system32 C:\WINNT C:\WINNT\System32\Wbem Output from C:\cygwin\bin\id.exe (nontsec) ---msg00799.html--- Huh? Looks to me like C:\WINNT is behind C:\cygwin\bin to me! I've not changed PATH - it echoes in bash as: $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/C/WINNT/system32:/C/WINNT:/C/WINNT/System32/Wbem and, as I demonstrated, the Cygwin kill is found first. -- Cliff -- 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: lseek + read = ENOENT
Sam Steingold wrote: I cannot read the last 4-byte word in a file using lseek + read: /* file foo exists and is large enough - say, 4 MB */ int fd = open(foo,O_RDONLY|O_BINARY); uint32 data; /* this succeeds and correctly returns the size of file foo minus 4 */ lseek(fd,-sizeof(data),SEEK_END); /* this returns 0 -- instead of the expected 4 -- and sets errno to ENOENT */ read(fd,data,sizeof(data)); if I run this under gdb and type lseek(fd,-sizeof(data),SEEK_END); read(fd,data,sizeof(data)); several times, eventually read() starts to return 4 and set data to the value I actually wrote into foo last. I observe this on linux, cygwin and solaris -- what am I doing wrong? This seems to be a bug in gcc. The off_t argument to lseek is a 64-bit type, but instead of being sign-extended to 64 bits, the value passed (-sizeof(data)) passed is only extended to 32-bits, so is actually +4294967292. If you write: int n = -sizeof(data); lseek(fd, n, SEEK_END); it works as expected. -- Cliff -- 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/
Intermittent cygwin heap allocation problem
I occasionally see the following heap allocation problem. This typically happens when a bash window has been left idle at its prompt for several hours (eg overnight), and occurs on the first command causing an executable to be run. It is independent of the command (as far as I can tell - it has happened with ls, cat, make, ...). Repeating the command invariably succeeds, and I am then not troubled again until after another lengthy idle period. [EMAIL PROTECTED] ~ $ ls 6 [main] ? (2604) C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x48, top 0x4A, reserve_size 126976, allocsize 131072, page_const 4096 98 [main] bash 2160 child_copy: stack write copy failed, 0x22E960..0x23, done 0, windows pid 2287764, Win32 error 5 bash: fork: No error I have seen this (or something very similar) with several versions of the Cygwin DLL, but haven't reported it before as I find it nothing more than an inconvenience and haven't researched it myself. Further, the problem comes and goes suggesting that it is dependent on the resource state of the Windows OS (and that it could be rather tricky to debug). It is still present after upgrading to 1.5.19-2. Searching the mailing list I found several similar reports, but none mentioning the error occuring on the first invocation of the day. I have not tried changing the registry heap_chunk_in_mb setting, which is mentioned in some reports (I currently have no such key set) as I'm not convinced it's relevant here. My setup is W2000+SP4+current updates. The bash window is a standard cmd window (and CYGWIN env variable is not set). cygcheck output attached. As I said above, this isn't a great concern to me - this isn't a cry for help - but I am willing to help track the problem down if that is thought useful (and I would appreciate useful suggestions of how best to do this). Looking at the Cygwin source, I see that the error is caused by Windows VirtualAlloc responding with Invalid Address error, yet the area being allocated (base 48, top 4a, size 128MB) looks ok to me. Am I right in thinking this means Windows thinks (part of) this area is already in use in the forkee? Presumably not a rebase problem, as it is transitory, so any ideas as to what can make Windows do this? -- Cliff Cygwin Configuration Diagnostics Current System Time: Wed Jan 18 13:43:54 2006 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\WINNT\system32 C:\WINNT C:\WINNT\System32\Wbem Output from C:\cygwin\bin\id.exe (nontsec) UID: 1002(cliff)GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1002(cliff)GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINNT\system32 WinDir: C:\WINNT USER = 'cliff' PWD = '/C/cliff' HOME = '/C/cliff' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\cliff' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\cliff\Application Data' HOSTNAME = 'CliffW' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 10 Stepping 0, AuthenticAMD' WINDIR = 'C:\WINNT' TEXDOCVIEW_txt = 'cygstart %s' CVSROOT = ':pserver:[EMAIL PROTECTED]:/cvs/src' TEXDOCVIEW_dvi = 'cygstart %s' OLDPWD = '/C/cliff/cygbuild' USERDOMAIN = 'CLIFFW' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users.WINNT' OS2LIBPATH = 'C:\WINNT\system32\os2\dll;' TEMP = '/C/WINNT/TEMP' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'cliff' TEXDOCVIEW_pdf = 'cygstart %s' PROCESSOR_LEVEL = '6' SYSTEMDRIVE = 'C:' TEXDOCVIEW_html = 'cygstart %s' USERPROFILE = 'C:\Documents and Settings\cliff' PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\CLIFFW' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin\bin' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\WINNT\system32\cmd.exe' TMP = '/C/WINNT/TEMP' SYSTEMROOT = 'C:\WINNT' PRINTER = 'Phaser 8400 - Upstairs' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0a00' TEXDOCVIEW_ps = 'cygstart %s' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '1' COMPUTERNAME = 'CLIFFW' _ = '/usr/bin/cygcheck' POSIXLY_CORRECT = '1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags =
Re: Intermittent cygwin heap allocation problem
Dave Korn wrote: Cliff Hones wrote: 6 [main] ? (2604) C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x48, top 0x4A, reserve_size 126976, allocsize 131072, page_const 4096 98 [main] bash 2160 child_copy: stack write copy failed, 0x22E960..0x23, done 0, windows pid 2287764, Win32 error 5 bash: fork: No error appreciate useful suggestions of how best to do this). Looking at the Cygwin source, I see that the error is caused by Windows VirtualAlloc responding with Invalid Address error, yet the area being allocated (base 48, top 4a, size 128MB) looks ok to me. Am I right in thinking this means Windows thinks (part of) this area is already in use in the forkee? It is, as you guessed, already in use. It relates to the little bit of extra data that cygwin keeps in memory allocated immediately after each .dll that is loaded in an image. The code that allocates these is flexible, and if it can't allocate space immediately after the dll it will work its way up in memory until it succeeds. Sometimes, when a dll is loaded in a forked child, the allocated block ends higher up in memory than it did in the parent, and when that happens, it forces the next dll to be loaded to end up at a much higher base address. I've spent a good deal of time looking at it in the past but it's fairly obscure. I should probably have another go at it. (I can see how applications that LoadLibrary a new .dll after they've already been running for a long time and allocated lots of heap might be particularly prone to these remapping failures too). I'm not sure I understand what you're saying here. The parent (the bash shell) has been running (and idle) a long time, but the new child which is being forked is presumably a new windows process. The error relates to the virtual mapping in the new process, so Windows appears to be allocating DLLs or their info blocks at different addresses during the initialisation of two new processes, both started by the same (old) bash process. I also find the sleep(2000) in heap.cc when the mapping error is detected rather suspicious - is this to avoid a race condition with the parent? Fortunately, the 'Just try again' workaround almost always works. Since the error seems to be reliably detected by both parent and child, if this strange allocation by windows is often transitory, there could be a workaround: if a fork fails in this way, try it (once) more. -- Cliff -- 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: Intermittent cygwin heap allocation problem
Dave Korn wrote: Cliff Hones wrote: The parent (the bash shell) has been running (and idle) a long time, but the new child which is being forked is presumably a new windows process. The error relates to the virtual mapping in the new process, so Windows appears to be allocating DLLs or their info blocks at different addresses during the initialisation of two new processes, both started by the same (old) bash process. Nope. The mismatch is between the parent and the child, not between two children. However you're right about the problem relating to things being mapped to different addresses in the two. Yes - I know the mismatch is between parent and child. I was referring to the fact that when you try again the invocation of the second child works, so Windows is presumably doing something different, though presumably the parent (bash) started both in exactly the same way. When I was investigating, I found cases where the .dll was mapped at the exact same base address, but for some reason the trailing info block had been allocated higher up in memory in the child than the parent, and it had crossed over a granularity boundary and therefore forced the /next higher/ dll to be loaded 64k above the position it had occupied in the parent. Odd. I'm not familiar with the info block - maybe I'll take a look. I also find the sleep(2000) in heap.cc when the mapping error is detected rather suspicious - is this to avoid a race condition with the parent? Dunno, suspect it may have been something experimental. Take a look at when it arrived in the CVS and check the associated changelog entry. Aha - only just added (Boxing day!) and something to do with ctrl/c problems. I'm not sure how it helps, but it's not relevant to the problem I'm seeing. -- Cliff -- 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: Intermittent cygwin heap allocation problem
Christopher Faylor wrote: On Wed, Jan 18, 2006 at 03:16:27PM -, Dave Korn wrote: Cliff Hones wrote: [main] ? (2604) C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x48, top 0x4A, reserve_size 126976, allocsize 131072, page_const 4096 [main] bash 2160 child_copy: stack write copy failed, 0x22E960..0x23, done 0, windows pid 2287764, Win32 error 5 bash: fork: No error appreciate useful suggestions of how best to do this). Looking at the Cygwin source, I see that the error is caused by Windows VirtualAlloc responding with Invalid Address error, yet the area being allocated (base 48, top 4a, size 128MB) looks ok to me. Am I right in thinking this means Windows thinks (part of) this area is already in use in the forkee? It is, as you guessed, already in use. It relates to the little bit of extra data that cygwin keeps in memory allocated immediately after each .dll that is loaded in an image. The code that allocates these is flexible, and if it can't allocate space immediately after the dll it will work its way up in memory until it succeeds. Actually, this kind of error is more likely to be caused by a thread starting prior to cygwin initialization and grabbing cygwin's heap area to use for its stack. I moved things around a bit in 1.5.19 to try to avoid that but I guess it was for naught. Can this explain failures to initialize executables which don't use threads? I don't know, but I wouldn't have thought 'ls' uses threads. -- Cliff -- 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: Intermittent cygwin heap allocation problem
Christopher Faylor wrote: ... One scenario that I have seen is that a thread gets started when someone hits CTRL-C while a forked process is starting up. Since only one thread can execute at a time when a process is in DLL initialization, the other thread's stack gets allocated but it hangs while cygwin vainly tries to complete its initialization. I say vainly because the initialization is doomed to fail since the other thread's stack has often been allocated in cygwin's heap area. Attempts to move the heap elsewhere just result in other collisions. I spent some time looking into the NT-specific functions which allow one to turn off the serialization of the startup code, to allow cygwin to break out of the code during startup and let other threads complete their dirty work but the big flashing warning signs and threats of doom that accompanied every discussion about these functions sort of scared me off. 1.5.19 may have aggravated this problem since Corinna's changes to mmap now use VirtualAlloc'ed space for privately mmapped areas. For some inexplicable reason, this causes more of this type of collision. I would swear that once a program uses a memory area in a parent, windows is much more likely to use that memory for system-like things in the forked/execed child. Since it seems that there's no solution to this, once Windows has pinched some of the heap area (for whatever reason), could my partly facetious suggestion for the parent to have another go actually be a useful way to go? The borked child would have to be able to exit cleanly without generating an error message, and the parent would need to detect this case (which I guess could be a problem). -- Cliff -- 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/
Building Cygwin from CVS
It's rather a long time since I tried building my own cygwin from CVS. With the new release out, I thought I'd give it a try, as I imagine HEAD is very close to 1.5.19-2. I followed the instructions in the FAQ: http://cygwin.com/faq/faq.programming.html#faq.programming.building-cygwin A few comments: . It would be useful to mention in the FAQ which packages need to be installed to perform the build. I expect everyone will realise make, gcc, binutils etc. are required, but I found I needed cocom (for shilka) which I'd not come across before, and dejagnu in order to run the tests. . The FAQ info describing how to run the tests is wrong. It worked for me when I ran make check in the i686-pc-cygwin/winsup subdirectory of my build directory. . When I ran the tests, I got five unexpected failures (devdsp, msgtest, pthread-cancel1, semtest and shmtest). Is this to be expected :-). Could I suggest the FAQ is updated? -- Cliff -- 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: Building Cygwin from CVS
Dave Korn wrote: Cliff Hones wrote: . When I ran the tests, I got five unexpected failures (devdsp, msgtest, pthread-cancel1, semtest and shmtest). Is this to be expected :-). Is the smiley there to indicate that you already understand perfectly well that these tests would require cygserver to be running and CYGWIN=server to be defined in the environment? Actually, no - I'd not looked at what the tests were doing. My smiley was in case these tests should have been in the expected failures category, with core developers knowing these tests failed, but noone had yet got round to updating the test suite. Such horrors have been known to happen, but I'm glad to see not with Cygwin. Now I know I'd say it's yet another useful addition to the FAQ. PTC, I know - I guess I could take a look at what's involved in generating a patch, though it would take me far longer than anyone already familiar with updating the FAQ. -- Cliff -- 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: Building Cygwin from CVS
Brian Dessent wrote:
Cliff Hones wrote:
. It would be useful to mention in the FAQ which packages need to be
installed
to perform the build. I expect everyone will realise make, gcc, binutils
etc.
are required, but I found I needed cocom (for shilka) which I'd not come
across
before, and dejagnu in order to run the tests.
Since the generated devices.cc is stored in CVS you shouldn't need
shilka unless you modify devices.{in.h}.
Well, maybe it is a timestamp problem, but the make did fail trying to
regenerate
devices.cc using the gendevices script. After I'd installed cocom it worked,
and overwrote devices.cc in the src/winsup/cygwin directory. This seems
wrong by the way - a separated build shouldn't alter anything in src.
This was with a pristine CVS head checkout taken earlier today.
-- Cliff
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Setup.exe parse error while reading .ini file setup.bz2
Frank Adrian wrote: Seems to be fixed now. Thanks whomever... faa -Original Message- From: Frank Adrian Sent: Wednesday, January 04, 2006 4:17 PM To: 'cygwin@cygwin.com' Subject: Setup.exe parse error while reading .ini file setup.bz2 I am running on a WXP Pro system. Today I tried to grab an application using setup.exe. While downloading the .ini file setup.bz2, I received a dialog having the following error message: (null) line 10196: syntax error, unexpected $undefined, expecting $STRING I downloaded the latest version of setup.exe, as well as trying other download archives, but continued getting the same error. I haven't had any problems with downloading apps previously, so my supposition is that there was some sort of error in creating the source of the ini file and that this bad file was pushed out to the mirror sites Frank A. Adrian Indeed, and no supposition was required - just a quick scan of this list would have revealed the previous thread error parsing setup.bz2 in setup.exe: http://cygwin.com/ml/cygwin/2006-01/msg00164.html Perhaps we need a cron job to inject that link into the list periodically for a few days. -- Cliff -- 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: test -e cannot distinguish between foo and foo.exe
Volker Quetschke wrote: I noticed the following behaviour: (found by my favorite testcase ;) ) $ rm -rf foo* ; touch foo.exe $ test -e foo echo found foo found foo $ test -e foo.exe echo found foo.exe found foo.exe Hmm, how can I test if foo exists without also looking at foo.exe? Does this count as a bug in test? My current workaround is $ find . -maxdepth 1 -name foo -exec echo _XfoundX_ \; | grep _XfoundX_ /dev/null echo found foo but that is a bit ugly. Much simpler than that: test -e foo. echo found foo. The trailing dot excludes the .exe magic and is ignored on translation to windows filename. -- Cliff -- 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: Timezone names
Joshua Daniel Franklin wrote: On 8/4/05, Cliff Hones wrote: I was curious as to why, under Cygwin, the default UK timezone names (eg as displayed by date) are different from the standard names. [Standard UK names are GMT and BST, while Cygwin displays GMTST and GMTDT.] So I did some source digging. Forgive me if the following info is already readily available - but I couldn't find it. Note that the Cygwin FAQ admits to being out of date: http://cygwin.com/faq/faq_3.html#SEC85 Thanks, Cliff! Do you mind if I use this for the new FAQ text? Not at all, but the registry fiddling may not be advisable to mention, and I'd prefer to be more definite about the effect of explicitly setting TZ, but I didn't have time to look into the posixrules stuff. [Cygwin has a small file called, if I remember correctly, posixrules.c, which consists of the precompiled TZ data recorded as a hex vector. I've no idea how it's used or if it's up to date. Is this documented anywhere - does cgf or Corinna possibly know?] -- Cliff -- 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/
Timezone names
I was curious as to why, under Cygwin, the default UK timezone names (eg as displayed by date) are different from the standard names. [Standard UK names are GMT and BST, while Cygwin displays GMTST and GMTDT.] So I did some source digging. Forgive me if the following info is already readily available - but I couldn't find it. Note that the Cygwin FAQ admits to being out of date: http://cygwin.com/faq/faq_3.html#SEC85 Cygwin does not use the Newlib version of tzset - there is a Cygwin-specific implementation in localtime.cc. Unlike the Newlib tzset, if environment TZ is not set, the Cygwin version uses Windows API GetTimeZoneInformation. The timezone names as seen by Cygwin are set using just the the capital letters in the Windows timezone names (which, for the UK, are GMT Standard Time and GMT Daylight Time). Of course, this affets other timezones too; most US zones translate to their standard names, but Central America will generate CAST/CADT rather than CST/CDT. To get the more standard names, one can, of course, set the TZ environment variable explicitly (eg to GMT0BST). There is logic to complement the TZ setting info with default info from built in posixrules, but it's not clear to me if this will set the daylight saving on/off points correctly. An alternative solution, which will use the Windows daylight saving info as before is to update the Windows timezone database directly. I believe there is a tzedit tool to do this in Windows resource kits, but it is easy to do using the registry [ok, I know this is frowned on]. The timezone names (in NT/2K/XP) are in HKLM\Software\Microsoft\Windows NT\Current Version\TimeZones\yourzone (eg ..\GMT Standard Time for UK). The keys Std and Dlt specify the zone names - I changed mine to be Greenwich Mean Time and British Summer Time. After the change, to make it effective, use the Windows Adjust Date/Time dialog to reselect your timezone. OBLIGATORY WARNING - Do not modify registry settings unless you are confident you know what you are doing, and know how to restore previous settings if your system subsequently malfunctions. A possibly better solution, one day, would be for the localtime implementation to be implemented for Cygwin, with zone files in /usr/share/zoneinfo. -- Cliff -- 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: Is the Cygwin installation process likely to change significantly anytime soon?
Dave Korn wrote: Original Message From: Herb Martin Sent: 26 July 2005 05:29 - Name of setup utility: setup.exe I doubt this will change. [ ... ] I'd say the name 'setup.exe' is here to stay. There are much better choices however -- many people will store such downloads in a generic download directory and having no mention of the actual program/system name in the file is a nuisance (understandable, but a nuisance.) Take a look at the icon for it in an explorer window. It makes identification a cinch. Doesn't help you tell which version of setup.exe you have, though. I usually rename my setup.exe to include the version number. It still doesn't help me discover whether the Install Cygwin now link would give me a more recent version. Indeed, the lack of info on version numbers and snapshots usually causes me to do the following whenever I upgrade after a lengthy pause: . Try to remember the setup snapshot URL. . Cuss if the directory is unreadable, and try searching the mailing list. . Download the latest snapshot if/when found. . Downoad Install Cygwin now just in case. . Invoke downloaded Install Cygwin now, copy down its version and exit. . Rename it to include the version (or delete it if I already have it). . Now, finally, choose a suitable version of setup and invoke it. The Cygwin home page prominently displays the latest Cygwin DLL version. Could it not also display the latest setup.exe version and also a link to the setup.exe snapshots? -- Cliff -- 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: gcc-core and g++ source
James McLaughlin wrote: I've been wondering about why functions such as strcpy return char*, instead of being void, so I thought I'd look at the source for this function and see if there were any informative comments. However, while I've got the g++ and gcc-core source, I can't find the source for the standard string.h functions - can anyone tell me which file to look in? In fact, is there any sort of document detailing where to find the source for the functions defined in , say, header ?.h? (organised by header)? If not, are there any plans to include such a document in the Cygwin docs? The C specification ISO/IEC 9899:1999 (2nd Edition) is, I believe, the definitive documentation for the string.h functions - these are part of the C standard library which any conforming implementation must provide. [You can download a pdf of this standard from www.iso.ch for a small fee.] Looking at sources such as newlib or glibc will only show you how it is implemented, not why the specification was chosen to be that way. Note also that gcc knows about a number of C library functions, including the string ones, and (depending on the target platform and the selected level of optimisation) may generate inline code rather than call the library routine. -- Cliff -- 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: Is the Cygwin installation process likely to change significantly anytime soon?
Igor Pechtchanski wrote: On Tue, 26 Jul 2005, Cliff Hones wrote: Doesn't help you tell which version of setup.exe you have, though. [snip] The Cygwin home page prominently displays the latest Cygwin DLL version. Could it not also display the latest setup.exe version That would be a good idea, IMO. and also a link to the setup.exe snapshots? And this wouldn't. It doesn't link to the Cygwin DLL snapshots for the same reason ... /pantomime on Oh yes it does. [See the Snapshots link under Contributing in the left panel.] /pantomime off -- those aren't ready for most people to try. People who are willing to try the latest snapshot version, warts and all, and are prepared to properly report bugs can easily Google for cygwin setup snapshots and get there. Well, for a while the holding directory was nom-browseable, so you had to know the full name of the snapshot you wanted - but I guess that was unintentional. That said, the latest release version of setup.exe is encoded in setup.ini on any up-to-date mirror. Simply run your old copy, and it'll warn you if a newer version of setup.exe is available -- no need for the download dance. Agreed, but you have to go through the rigmarole of several mouse clicks to get that far. -- Cliff -- 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: What's in it for Redhat?
fergus wrote: ... I had to spend a lot of time sharpening my hair. What does this mean? (Sorry for asking, I'm English.) A reference to Dilbert's pointy-haired manager, I imagine. -- Cliff -- 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: egrep disappeared?
zzapper wrote: On Tue, 12 Jul 2005 04:53:43 -0700, wrote: zzapper wrote: Since last downloads (basefiles?) egrep has disappeared. egrep is just an alias or link to grep.exe of course. I have added my own alias as a work around. Looks fine to me: http://cygwin.com/packages/grep/grep-2.5-1. Brian Funny thing which finds egrep in /usr/bin /bin etc they are also in my path. bash: /usr/bin/egrep: /bin/sh: bad interpreter: No such file or directory Well, there's your answer - it's /bin/sh which you have missing, not egrep. In Cygwin egrep is a shell script rather than a symlink. I believe there was a window during the recent changeover of /bin/sh from ash to bash where the update could cause /bin/sh to be deleted. Just copy /usr/bin/bash to /usr/bin/sh and all should be well. -- Cliff -- 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: egrep disappeared?
zzapper wrote: On Tue, 12 Jul 2005 14:17:02 +0100, wrote: Funny thing which finds egrep in /usr/bin /bin etc they are also in my path. bash: /usr/bin/egrep: /bin/sh: bad interpreter: No such file or directory Well, there's your answer - it's /bin/sh which you have missing, not egrep. In Cygwin egrep is a shell script rather than a symlink. I believe there was a window during the recent changeover of /bin/sh from ash to bash where the update could cause /bin/sh to be deleted. Just copy /usr/bin/bash to /usr/bin/sh and all should be well. -- Cliff Cliff, thnx that solved it!! Was it most likely just a glitch on my update? Yes - a short-lived bug in the postinstall scripts. See: http://sourceware.org/ml/cygwin/2005-07/msg00224.html -- Cliff -- 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: mirror site
Christopher Faylor wrote: On Tue, Jul 12, 2005 at 10:18:07AM -0400, Igor Pechtchanski wrote: I'm preparing a letter to the mayor now. Well, you know what they'll say -- WJM, PTC. Well, they keep taking down my hand-written signs that say Dunkin Donuts around corner so I don't think Pittsburgh is truly interested in P. Ah, but did you include the change log? Are those chickens I hear? -- Cliff -- 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: How to make DLLs in cygwin for MSVC and BCB
Max Kaehn wrote: On Thu, 2005-06-23 at 18:18 +0100, Dave Korn wrote: Sorry, but why isn't that 4k at the *TOP* of the stack? It sure looks that way to me, unless cygwin stacks grow upward! You're mixing the metaphors. :-) The top of a stack is where you push something down onto the stack. The bottom of the stack is at the other end. There happens to be an implementation detail of stacks growing downward in memory, so the bottom of the stack is at the top of the memory allocated to the stack. I always found that puzzling, too... Reminds me of the probably apocryphal WWII story about a new type of tank shell. Normal shells are always crated with the sharp-end up, but the new ones were unsafe stored that way. The boxes were marked To avoid confusion, the bottom of these crates has been marked TOP. -- Cliff -- 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: Compiling memtest from sources on cygwin
[EMAIL PROTECTED] wrote: I try to make memtest86 from sources on cygwin and have the following error: $ make as -32 -o head.o head.s head.s: Assembler messages: head.s:623: Error: unknown pseudo-op: `.previous' head.s:694: Error: can't handle non absolute segment in `ljmp' head.s:917: Error: unknown pseudo-op: `.previous' head.s:923: Error: unknown pseudo-op: `.previous' head.s:929: Error: unknown pseudo-op: `.previous' make: *** [head.o] Error 1 I suspect, that this is not right forum to ask, but I do not know where to look for the answer. My question is: what is '.previous' pseudo-op, and where should I look for assembler (GNU?) documentation. Not really on topic, and a quick google finds this: http://docs.sun.com/app/docs/doc/817-5477/6mkuavhre?a=view so .previous is accepted by Sun's x86 assembler. I can't see any reference to .prefix in the Gnu assembler manual however (google for gnu gas manual) - so I guess the memtest86 people may well be using Sun's. Since .previous just reselects the previous section it wouldn't be difficult to edit the source (head.S) to manually reselect the section. BTW - the makefile uses head.s and head.S as separate files - so to work under Cygwin you will need to use a managed mount. -- Cliff -- 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: launch windows program from shell according to its extension
Peter Mutsaers wrote: Hello, I have largely replaced usage of windows explorer with a cygwin shell. One thing is cumbersome however: when I encounter, say, a .doc file in a directory, it would be nice that I could launch this file with the program associated under windows. Is this possible, for example via a utility program kind of launch file.doc? Yes - it's called cygstart. -- Cliff -- 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: base-files patch (atn: Eric Blake)
John Morrison wrote:
On Fri, March 25, 2005 8:26 pm, Eric Blake said:
True enough. And that points out another bug - echo $0 may fail if $0
starts with -, it should be echo -- $0. Isn't portable shell
programming fun?
Sorry that this has taken so long, but I'm just getting around to adding
all the fixes emailed wrt /etc/profile. I tried the above, and it broke
so I checked the man pages,
quote
`echo' writes each given STRING to standard output, with a space between
each and a newline after the last one. Synopsis:
echo [OPTION]... [STRING]...
The program accepts the following options. Also see *Note Common
options::. Options must precede operands, and the normally-special
argument `--' has no special meaning and is treated like any other
STRING.
/quote
so, I'm afraid that echo -- ${0} won't work.
I think echo ${0} has the desired effect (apart from a leading space).
-- Cliff
--
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: Help !!! - Problem running Cygwin in Remote Desktop session with non-admin privileges
Christopher Faylor wrote: On Tue, May 03, 2005 at 10:52:37AM +0530, Moghe, Jayant wrote: Corinna: I have been facing problems in downloading Cygwin 1.5.16. Can you please suggest a mirror site where this is available? 1.5.16 is available at every mirror site displayed by setup.exe. I am observing an odd problem while upgrading to 1.5.16. I select the Keep radio button (as I want to upgrade just package cygwin), then click on View to get the Full view. Then I find the Cygwin package, and click on the selector to cycle through the options. But I am not presented with 1.5.16 - only 1.5.15. When I switch to the Curr radio button, I do see 1.5.16 - but only the once. If I cycle through the selections it doesn't reappear - 1.5.15 transitions straight to Uninstall. However, if I click on Exp I do see both 1.5.15 and 1.5.16. Note - I've tried this on two systems, with setup v2.457.2.1 and v2.457.2.2. In both cases I had a cygwin package earlier than 1.5.15 installed. Just tried again - selecting Keep is not necessary - just go straight to the Cygwin version selector. It shows 1.5.16 initially, but if you change it you cannot get it back without selecting Exp. Aha - but if you leave it at 1.5.15.1, and then change the setting of another package (I chose cygutils, just above) then 1.5.16 does reappear. Bizarre! This could explain the OP's problem. -- Cliff -- 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: impossible to restore MBR using dd
Matthias Bertschy wrote: Hello, Cygwin version: 1.5.12 Windows XP Professional: Ver 5.1 Build 2600 Service Pack 2 I am trying to use Cygwin's dd command as a post Windows XP install command to restore our custom GRUB to the MBR after an unattended installation. For safety reasons, I would like to restore only the first 446 bytes of the MBR to keep the existing partition table. The command line to use would normally be: dd if=boot.MBR of=/dev/sda bs=446 count=1 --dd: writing '/dev/sda': No space left on device 1+0 records out 0+0 records in (I also tried with bs=512 and I get the same output) After reading: http://sourceware.org/ml/cygwin/2001-01/msg00193.html I decided to try the following: mount -s -b -f //./physicaldrive0 /dev/hd00 dd if=boot.MBR of=/dev/hd00 bs=446 count=1 -- dd: opening '/dev/hd00': Invalid argument (even if I change the device /dev/xxx name, I get the same output) I even tried directly: dd if=boot.MBR of=//./physicaldrive0 bs=446 count=1 -- dd: opening '//./physicaldrive0': Invalid argument After so many unefficient tries, I decided to read from it, just to see: dd if=//./physicaldrive0 bs=446 count=1 -- dd: reading '//./physicaldrive0': Is a directory 0+0 records out 0+0 records in So here is the: QUESTION1: Does anyone know how to write into MBR from Windows XP using Cygwin's dd ? QUESTION2: I am doing somathing wrong since dd sees //./physicaldrive0 as a directory ? Any help would be appreciated. Using /dev/sda should work. -- Cliff -- 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: impossible to restore MBR using dd
Matthias Bertschy wrote: Cliff Hones wrote: Matthias Bertschy wrote: Hello, Cygwin version: 1.5.12 Windows XP Professional: Ver 5.1 Build 2600 Service Pack 2 I am trying to use Cygwin's dd command as a post Windows XP install command to restore our custom GRUB to the MBR after an unattended installation. For safety reasons, I would like to restore only the first 446 bytes of the MBR to keep the existing partition table. The command line to use would normally be: dd if=boot.MBR of=/dev/sda bs=446 count=1 --dd: writing '/dev/sda': No space left on device 1+0 records out 0+0 records in (I also tried with bs=512 and I get the same output) After reading: http://sourceware.org/ml/cygwin/2001-01/msg00193.html I decided to try the following: mount -s -b -f //./physicaldrive0 /dev/hd00 dd if=boot.MBR of=/dev/hd00 bs=446 count=1 -- dd: opening '/dev/hd00': Invalid argument (even if I change the device /dev/xxx name, I get the same output) I even tried directly: dd if=boot.MBR of=//./physicaldrive0 bs=446 count=1 -- dd: opening '//./physicaldrive0': Invalid argument After so many unefficient tries, I decided to read from it, just to see: dd if=//./physicaldrive0 bs=446 count=1 -- dd: reading '//./physicaldrive0': Is a directory 0+0 records out 0+0 records in So here is the: QUESTION1: Does anyone know how to write into MBR from Windows XP using Cygwin's dd ? QUESTION2: I am doing somathing wrong since dd sees //./physicaldrive0 as a directory ? Any help would be appreciated. Using /dev/sda should work. -- Cliff Hello Cliff, Thanks for your help... However, if you read carefully the beginning of the mail, that's the first thing I tried: The command line to use would normally be: dd if=boot.MBR of=/dev/sda bs=446 count=1 --dd: writing '/dev/sda': No space left on device 1+0 records out 0+0 records in I don't really understand why there is No space left on device... the same command under Linux works like a charm. If anyone else has got an idea? I gave it a quick test with bs=512 and it works fine. It seems you can't write partial sectors - which is perfectly reasonable, as if allowed the driver would have to read the sector, update part and then write back. So I suggest you try the following: dd if=/dev/sda of=bootsect bs=512 count=1 dd if=boot.MBR of=bootsect bs=1 count=446 dd if=bootsect of=/dev/sda bs=512 count=1 -- Cliff -- 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: mount?
beau wrote: On 5/3/05, Vince [EMAIL PROTECTED] wrote: It will automagicly be mounted as /cygdrive/driveletter assigned to fat partition XP doesn't seem to know this partition exists. I had XP on my full 80GB, used the debian sarge isntaller to shrink it to 30GB, created 10GB FAT, gave the rest to debian, thinking I could use the FAT as a shared storage resource. Not all of which is directly on topic, apologies. Any pointers as to how to make my little scheme a reality? Am I going to have to start from scratch? :( Windows may not like the way Debian set the partition up. You may have more luck if you delete, recreate and format the FAT partition under Windows (saving anything there first, of course). Debian will almost certainly be able to access a FAT filestore made by XP. -- Cliff -- 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: Bespoke installations: simple elegance of setup.exe when setup.ini is absent
Gary R. Van Sickle wrote: ... [Yet more boring vitriolic rubbish.] ... I've been on this list for a good four years now, and never ever considered setting up a filter. I came close during the fortune flamewars and I'm getting even more close now. Please, Gary and CGF, can you take your discussion offline. -- Cliff -- 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: Rebase All command.....
DavidPostill wrote: On Tue, 26 Apr 2005 12:46:45 +0530, Ashwin N [EMAIL PROTECTED] wrote: | On 4/21/05, Dave Korn [EMAIL PROTECTED] wrote: | [...] |http://cygwin.com/acronyms#YHBT ! | | YHBT is not there on that page :) YHBT - You Have Been Trolled Or, here in the UK, You Have Been Tango'd (from a TV commercial). -- Cliff -- 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: JTAG 0.5.1 or 0.4 on cygwin on windows xp sp2 - parport wont open
Simon wrote: Hi, I am new to cygwin and my main goal is to get the JTAG stuff working over LPT1 on a PC. I wonder if anyone has installed it and got it working. I tried jtag v0.4 and it didnt work. Also I have tried the 0.5.1 version and the screen dump is shown below. I have modified the KeithKoep cable.c file to show exactly where it fails hence the SJM: KK cable.c can not do parport_open text which is my insert. ... SJM: KK cable.c can not do parport_open Error: Cable initialization failed! jtag Have I completely messed up? Do I need to install something to enable parallel port support too? Is it very complex or very simple to access the parallel port directly under cygwin as the JTAG sources try to do? lpr -d lpt1: does seem to take input from the console OK. I've not used this JTAG package, but others using the parallel port which I have used require the ioperm package. Also, you probably need to run the application under a user with administrator rights. -- Cliff -- 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: sshd on windows
Does anyone know if there is a cygwin.dll free ssh server for windows? Funnily enough, I originally read this as Is there a free ssh server for windows which uses cygwin.dll and then realised my mistake when I saw the first couple of replies. But following the last reply I'm not sure what the OP's intended meaning was. However, it's been answered both ways now - use Cygwin's openssh package, or else it's OT for this list. -- Cliff -- 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: Obscene Content Tiebreaker
Kaz Kylheku wrote: A twit hit a free software mailing list. On censoring fortune he did insist. ``Can't have limericks about pussies and dicks!'' A few clicks Googled him out a masochist! I don't think this is a limerick, though, which rather spoils the joke. A limerick has 5 lines with a metre as follows: De dah dah de dah dah de dah De dah dah de dah dah de dah De dah dah dah dah De dah dah dah dah De dah dah de dah dah de dah -- Cliff -- 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: Add requirement for SYSTEMROOT to FAQ?
David A. Rogers wrote: ... Corrina asked why it was necessary to hide SYSTEMROOT. I read that as What is the reason for hiding SYSTEMROOT? Reading skills needed! Her name is Corinna. Also, if you'd read the whole thread you'd have seen that your information was already known. Perhaps you are new to this forum, and are not aware that cgf and Corinna are the two key Cygwin developers. It's unlikely either would need to be told again what the SYSTEMROOT problem is. I understood Corinna's question to be Why should the Cygwin kernel need to hide the fact that the SYSTEMROOT environment variable is set from a Cygwin app (yet still pass it on to a Windows subprocess). You didn't answer that. In any case, I don't think an attempt to be helpful warrents a snippy response. picky The word is warrants. /picky I think the snippy (?) response was from frustration on cgf's part. Not only did you misappropriate a quote to him, you didn't answer the question asked, and gave already known information. -- Cliff -- 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: Program exited with code 0303000
Dave Korn wrote: Bobby, your advice is going from bad to worse. Nothing you have said is right, and you keep on repeating things that you have already been told don't work. You don't accurately read the things that are in front of your face before you reply. THAT'S WHY I'M GOING TO BE SHOUTING AT YOU QUITE A LOT IN THIS LETTER, BECAUSE YOU DON'T ACTUALLY LISTEN TO ANYTHING ANYONE SAYS TO YOU, YOU JUST ASSUME THEY'RE WRONG AND YOU'RE RIGHT AND I HOPE IF I SHOUT LOTS YOU'LL ACTUALLY BE ABLE TO HEAR ME. ... Dave, Bobby is not worth getting worked up about. He has been on the Cygwin list longer than you, and I expect most people have just learnt to completely ignore him. I find him quite fun, actually - I have this slight suspicion that he may be a very clever troll, but on the whole I'd guess he's just a half^H^H^H^Hquarter-wit. It's just that he does seem to have the uncanny knack of saying exactly the wrong thing every time. Bobby - I'm not trying to be rude, unpleasant or mean - you really do need to get a lot more clued up if you ever expect to be taken seriously. -- Cliff -- 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: Lot of undefined symbols at link time, even with -l option on good libraries
Frédéric ORMANCEY wrote: Thanks for this sample code = we are not far of the solution ! Same sample compile on my platform gives the following : V:gnatmake imp gnatbind -x imp.ali gnatlink imp.ali ./imp.o(.text+0x20):imp.adb: undefined reference to `_FormatMessageA' collect2: ld returned 1 exit status gnatlink: cannot call /usr/bin/gcc.exe gnatmake: *** link failed. And of course nm command as a different result also : b .bss d .data t .text U _FormatMessageA T __ada_imp Problem is in compile time, not in build time, my compiler doesn't generate apropriate symbols in objects files ! I'am using cygwin 1.5.11-1 ( latest release ) with GNAT / GCC 3.4.1 ( gcc-ada-3.4.1-20040711-1.tar.gz package ). I can't use older version of GNAT because of bugs in gnat.socket package ( Gnat form of select() function limited to 32 simultaneous sockets for example ). I was using the current Cygwin version of gnat - 3.3.3[-3] (Cygwin special). I think you are using the MinGW version, and problems with that would be better directed to the MinGW mailing lists or support forum. -- Cliff -- 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: Lot of undefined symbols at link time, even with -l option on good libraries
Larry Hall wrote: At 01:14 PM 9/22/2004, you wrote: -Original Message- From: Frédéric ORMANCEY Sent: 22 September 2004 18:07 I did it, but it don't work ! Ah, ok, that was not clear from your last message! The --enable-stdcall-fixup option suppress one warning on top of linker output trace : AVERTISSEMENT: résolution de _GetModuleHandleA par un lien vers [EMAIL PROTECTED] and unfortunatly leave ALL other errors with no effect on it. I see. Hmm. That's very strange; it should affect all the errors - that is, if they're all the same kind of error. OTOH it could be that you've gotten the calling conventions wrong with the other pragmas, so that's why --enable-stdcall-fixup doesn't work for them; there must be some different reason why the errors are caused, since they behave differently. You might care to experiment with the --enable-auto-import and, failing that, --enable-extra-pe-debug options as well. Or Frédéric could try specifying the link symbol he wants in the pragma as suggested by an earlier poster (sorry, the thread is broken in the archives and I didn't put any effort into wading through the messages to trace it all back to that message). That was me - but it seems Dave Korn's post broke the thread. But isn't it easy enough to sort messages on subject? Anyway, I tried a noddy example, as follows... [EMAIL PROTECTED] ~ $ cat imp.adb procedure imp is procedure Doit(A : integer; B : boolean; C : character); pragma Import (Stdcall, Doit, FormatMessageA); begin Doit(1, true, 'x'); end; [EMAIL PROTECTED] ~ $ gnat compile imp.adb gcc -c imp.adb [EMAIL PROTECTED] ~ $ nm imp.o b .bss d .data t .text U [EMAIL PROTECTED] T __ada_imp So Gnat is generating a stdcall-style linker symbol with @12 (the parameter block size) correctly appended. If Frédéric is not seeing this with stdcall, it is probably an indication that the specification used for Doit is wrong - ie it hasn't been defined to take any parameters. If you change the pragma line to pragma Import (Stdcall, Doit, Link_Name = FormatMessageA); the symbol is generated as U [EMAIL PROTECTED] so you can generate it without the leading underscore, but with the stdcall postfix, if you wish. [Note - the above is just an example - the *real* FormatMessageA should take 7 words (28 bytes) of parameters, and the Ada spec should match the kernel32 definition.] -- Cliff -- 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: Lot of undefined symbols at link time, even with -l option on good libraries
Larry Hall wrote: At 12:15 PM 9/21/2004, you wrote: I think you're right, it seems to be a problem with trailing underscore in function naming. For example : in /usr/lib/w32api/libkernel32.a we found : T [EMAIL PROTECTED] U __head_libkernel32_a I [EMAIL PROTECTED] which is required by win32-winbase.o, result of the build of /usr/lib/gcc/win32ada/win32-winbase.adb U _FormatMessageA U _FormatMessageW U _GlobalReAlloc U _LocalReAlloc The source code for this part is the following : pragma Import (Stdcall, Doit, FormatMessageA); I try change it with pragma Import (C, Doit, _FormatMessageA); or things like that with no success. May be it's the trailing @28 after symbol name which cause error, but I cannot control it ( it's DLL calling convention parameter size ). Compiler/linker should usually add or remove trailing @nn if necessary. To answer your general questions, I'am building a large Ada application ( 200 source files ), using W32 API, with Win2000 GNAT Compiler. Sorry, I know nothing about Ada and how it works. If the pragma statement is supposed to take the place of the traditional function prototype in C/C++, then I agree that it looks OK (again, based on my knowledge of Ada). But the result is that it's looking for symbols that use the 'C' calling convention rather than the 'stdcall' calling convention. The libraries you are linking to want the 'stdcall' calling convention (since it is the default for Windows). If you cannot get Ada to ask for the proper symbol, you could try using the '--enable-stdcall-fixup' option (for 'ld') to attempt to massage away the problem. The syntax for Pragma Import is: pragma Import( [Convention =] convention_identifier, [Entity =] local_name [, [External_Name =] string_expression] [, [Link_Name =] string_expression]); It might be worth experimenting with using Link_Name instead of External_Name - this should enable you to specify exactly what the link name generated by the Ada system is. -- Cliff -- 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: Running other scripts from Bash shell
Ashman,Tim [PYR] wrote: I am running Cygwin on a Windows 2000 machine. I also have GNU Octave 2.1.50 (very similar to Matlab) installed. Cygwin is a component of the GNU Octave 2.1.50 build, but I have installed Cygwin seperately as well. As a result of this, my octave and cygwin programs do not run together and have different root directories. Will this cause any trouble calling an Octave script from a bash script under Cygwin? My root directories are C:/cygwin and C:/Program Files/GNU Octave 2.1.50/ I would like a bash script (scheduled with cron) that is located in C:/cygwin/bin to call some Octave scripts that I have in C:/Program Files/GNU Octave 2.1.50/octave_files/ What is the best way of running scripts that are not associated with the Cygwin platform? Any advice would be greatly appreciated. Have you looked at the Octave Windows FAQ? http://octave.sourceforge.net/Octave_Windows.htm It looks as though Octave can happily coexist with your own Cygwin, provided it is installed correctly. -- Cliff -- 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: Can't Read /cygdrive/c in snapshots from 1108 on (unknown windows error 122)
D. N. Knisely wrote: I unmounted those mounts: $ mount C:\cygwin\usr\X11R6\lib\X11\fonts on /usr/X11R6/lib/X11/fonts type system (binmo de) C:\cygwin\bin on /usr/bin type system (textmode) C:\cygwin\lib on /usr/lib type system (textmode) C:\cygwin on / type system (textmode) c: on /cygdrive/c type user (textmode,noumount) No change. Am I supposed to have an actual directory entry for cygdrive? There is a directory there: ... $ ls -l cygdrive total 0 d- 29 0 Nov 24 07:09 c/ $ ls -ld cygdrive dr-xr-xr-x4 00 0 Dec 31 1969 cygdrive/ It doesn't seem to make any different if I rename it to something else; I gather that /cygdrive is actually a virtual drive like /dev. That's right. In a standard installation you would not have a real directory named cygdrive in your Cygwin root, but I wouldn't have expected there to be a problem if you did have. [Just tried it on my system and I have no problem.] However, from the above, you do seem to have a permission/ownership problem. I'd recommend removing the real /cygdrive directory, and then repeating ls -l /cygdrive - you should see your windows C drive and it should have sensible ownership/protection - the same as you see with ls -ld C:/. You don't, by any chance, have a real directory named C under your real /cygdrive? That may well confuse Cygwin. -- Cliff -- 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: Stability Problem with Cygwin Pthreads
Arash Partow wrote: for the people that are interested, this is where the threads seem to be CONTINUALLY crashing: /cygdrive/c/cygwin\binaddr2line -e cygwin1.dll 0x610de964 ../../../../../../cygwin-snapshot-20031028-1/newlib/libc/machine/i386/memcpy.S:53 .L11: shrl $2,ecx .p2align 2 rep movsl movl ebx,ecx andl $3,ecx from what i can see the memcpy is moving data from esi to edi (ecx/4)'times (word blocks), however i don't think in the rep (REPZ) of the ecx ever gets to zero, or before it does it tries to copy data from a place which it does not have access to. Seeing this, and recalling that the crashes are indeterminate, suggests to me the possibility that the problem may be caused by thread switches during the execution of the REP MOVSL instruction. REP instructions are interruptable, and can be safely restarted from where they left off, *but* indeterminate behaviour will occur if the processor string direction flag (in EFLAGS, set by CLD/STD) is not saved and restored correctly during a thread switch following an interrupt. Not knowing the internal workings of Cygwin (or Windows) threads, I don't know if this could be the problem, and unfortunately I don't have the time to research it, but I offer it as a hopefully useful suggestion. -- Cliff -- 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: Is gcc-core-3.3.1-3.tar.bz2 corrupted?
Jörg Schaible wrote: what does file report? $ file gcc-core-3.3.1-3.tar.bz2 This shows that it is actually a gzipped file. Setup knows what to do with both bzip2 and gzip formats, without relying on the extension being right. It is actually a gzipped empty tar file - the new gcc-core binary package (which is in the Misc group) seems to be a placeholder for the associated sources. -- Cliff -- 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 with a cygwin App - Broken on a pristine system until I install cygwin, cygwin1.dll doesn't seem to be enough
Benjamin Cutler wrote: ... Hrm, next time I get a chance to sit down in the CS lab and hammer away at it for a while (I currently only have a Linux box available to me without making a trip across campus) I'll try strace. As the previous poster suggested, I had already tried cygcheck, and all it spat back at me was SDL.dll, cygwin1.dll, and a bunch of standard Windows DLLs. Perhaps there's a compiler switch that I missed? Have you considered the registry? Installing Cygwin updates the registry - it's where the mount points are recorded. If your app is using a POSIX-style path anywhere (eg /tmp/...) this would not be found, and if your app is dependent on the text/binary mount switches it would behave differently. A quick check would be to temporarily rename your Cygnus Solutions registry keys (in HKLM/Software and HKCU/Software), or else use mount to experiment. -- Cliff -- 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 with a cygwin App - Broken on a pristine system until I install cygwin, cygwin1.dll doesn't seem to be enough
Christopher Faylor wrote: PLEASE don't instruct people to play around with the registry. We have a perfectly good tool for them to use -- mount. It is designed to manipulate cygwin's mount table. The fact that it is in the registry is incidental. You can do everything you need with the mount command, ignoring the registry completely. I take your point - and indeed I almost posted a suggestion to use mount alone. But the original poster sounded as though he knew what he was doing, and in this *particular* case, where the key to his problem was to find what in the environment had been changed by the Cygwin install, a quick dive into the registry looks to be the best test. It's what I would have done - and bear in mind also that it may not be mount points - doesn't Cygwin1.dll also look at the registry for application-specific CYGWIN settings? In mitigation, I did say *temporarily* rename. I guess I should also have said: Children, don't do this at home unless you know *exactly* what you are doing. CGF is absolutely right to point out that to manipulate mount points the mount command is the right way to go. and Hannu has posted an example. Also, it's not unlikely (I understand, and hope) that the mount point info will one day be moved out of the registry. But I still stand by my original suggestion, for experts only, to determine if it is a registry setting added or changed by the installation of Cygwin which was causing the problem. -- Cliff -- 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/
