Inconsistent results from "du -sk ."
When I repeatedly issue "du -sk ." within seconds of each other, the results are different, and there is no process running that could be changing the contents of the directory. Here is an illustrative session: [EMAIL PROTECTED] /c/Documents and Settings/All Users/Start Menu ### Here are the files in the directory $ ls Cygwin Bash.lnk* Fast VNC.lnk* SomeProgram@ Programs/ Tight VNC.lnk* [EMAIL PROTECTED] /c/Documents and Settings/All Users/Start Menu ### First try: $ du -sk . 394 . [EMAIL PROTECTED] /c/Documents and Settings/All Users/Start Menu ### Note: bash's extglob is set, so ###!(Programs) means everything but Programs $ du -sk !(Programs) 2 Cygwin Bash.lnk 1 Fast VNC.lnk 0 SomeProgram 1 Tight VNC.lnk [EMAIL PROTECTED] /c/Documents and Settings/All Users/Start Menu $ du -sk Programs 442 Programs [EMAIL PROTECTED] /c/Documents and Settings/All Users/Start Menu ### Second try: $ du -sk . 450 . I simply captured the output above and added comments, but the problem is not repeatable. I am using an installation that is not quite up-to-date, but haven't been in a good position to upgrade due to very intermittent access to high speed (i.e. not in my home). I will upgrade at my next opportunity. I'm running Windows 2000 on NTFS. Relevant details from "cygcheck -cvs" are: Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Cygwin DLL version info: DLL version: 1.5.10 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 116 Shared data: 4 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Tue May 25 22:07:00 EDT 2004 CVS tag: cr-0x5e6 Shared id: cygwin1S4 "du --version" yields: du (fileutils) 4.1 A Setup Package Search reveals that has been superceded by coreutils/coreutils-5.93-2. Since upgrading is nontrivial for me at present, I was trying to find a history of release notes to see if this problem has been solved in the cygwin versions since my current one. A search of the archives revealed a confusion with blocking factors in the late 90's, but not the same problem. Thanks for any other information about this. In particular, if there is an on-line history of release notes that captures this, that would be even better. Even if it does not capture this, such a set of notes would be very useful. Fred -- 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: Inconsistent results from "du -sk ."
Eric Blake wrote: > According to Fred Ma on 12/30/2005 1:20 PM: >>When I repeatedly issue "du -sk ." within seconds of each other, the >>results are different, and there is no process running that could be >>changing the contents of the directory. Here is an illustrative >>session: > > du can only report what the OS tells it. If it shows increasing numbers, > then it was very likely that some process was consuming disk space in that > directory (in spite of your claims to the contrary). > >>I am using an installation that is not quite up-to-date, but haven't > > "Not quite" is an understatement - cygwin is at 1.5.18; your version is > missing a year and a half of bug fixes. > >>Since upgrading is nontrivial for me at present, I was trying to find >>a history of release notes to see if this problem has been solved in >>the cygwin versions since my current one. A search of the archives >>revealed a confusion with blocking factors in the late 90's, but not >>the same problem. Thanks for any other information about this. In >>particular, if there is an on-line history of release notes that >>captures this, that would be even better. Even if it does not >>capture this, such a set of notes would be very useful. > > Browse the archives of the cygwin-announce list to see relevant changes > announced for each software upgrade (for this email, that would include > searching for mail with cygwin or coreutils in the subject): > http://cygwin.com/ml/cygwin-announce/ > > For particular programs, you can often find an online repository of > changes. For example, cygwin changes are tracked here: > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog?cvsroot=src > > And many programs maintain a condensed version of user-visible changes. > For example, coreutils changes that have happened since sh-utils, > fileutils, and textutils here: > http://cvs.savannah.gnu.org/viewcvs/coreutils/NEWS?rev=1.354&root=coreutils&view=markup > > Google can be your friend, after all. Google is a good tool, I used it extensively before posting. After doing more of that, and perusing the links you provided, I'm not able to find a fix that might explain the time-varying nature of du's reported numbers. It is somewhat repeatable in the sense that if I don't issue "du -sk ." for some time, and then repeatedly issue it, the first try is always low, and subsequent tries always settle on 450. It could very well be the interaction of du with the OS e.g hypothetically, if the OS returns numbers right away before it finishes tallying, perhaps the first attempts yields a premature total. For me to understand the possible causes, I'd have to become much more familiar with Cygwin, du, and windows 2000. Rather than speculating further, I'll take the steady-state result and upgrade at my first opportunity. Thank you for the links. Fred -- 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/
whole-word matches searches of mailing list archive & packages
Hello, I was searching for whether the current cygwin has the "stat" command. This is for future reference, since I am unable to update my old cygwin installation at the moment. I eventually found that "stat" resides in coreutils, but I was wondering if there is a way to specify whole-word matches when searching either the mailing list archive or while performing a Setup Package Search. The reason is that some words are very common as partial words, so searches tend to come up with many unrelated hits. Thanks. Fred -- 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: vim mlcscope interface issues
If this shows up more than once, I apologize. Gmail is telling me it didn't get sent (twice), and it doesn't show up on the mailing list archive, though that may be due to transit delay. I'm ran into hanging problems with the the following combination, updated today: cygwin 1.5.23-2 vim 7.0.122-1 mlcscope 14.1.8-2 The problem had to do with shelling out to build the cscope database via "mlcscope -b -u *". I specified the files "*" because I had Matlab files; Matlab is ont a recognized language, so the files would not be acted on by default. I think the problem arose because "*" also included the output file being built (cscope.out), so it cscope.out kept get bigger as it analyzed itself. Narrowing the files down to "*.m" restricted the files to Matlab files only, and bypassed that hanging problem. However, I get the following error trying to add the connection to cscope.out: cs_read_prompt EOF: No error E609: Cscope error: mlcscope: cannot read trailer offset from file cscope.out The only reference I've found to it is http://groups.google.ca/group/comp.editors/browse_frm/thread/2a614f2f0e87250e I don't have cscope on my system, so that's not the explanation. I also have cscopeprg=/usr/bin/mlcscope. I'll be downloading cscope as my next step. Since I've gotten vim/cscope to work on solaris before, I'm hopeful that it will be straightforward. I'm curious as to whether there has been any succcess or failures with the current cygwin/vim/mlcscope combination, which will hint at whether it is my setup or not. Thanks. Fred Date: Sun, 15 Oct 2006 17:03:42 -0500 From: Dave & Diane Subject: Re: vim mlcscope interface issues Delivered-To: mailing list cygwin at cygwin dot com Interesting find. Looks like I'll have to work with the vim folks to see if they will add support for mlcscope. It is a completely different version than cscope, but the interface is generically the same so I don't think it would be too difficult to add support in vim and fix if_cscope.c to support both. In the meantime, if you don't have sourceforge cscope installed, you might try creating a symbol link called cscope and see if that works too. Frodak wrote: > Over the last several days I've been trying to use vim > with mlcscope and have come to the conclusion that the > two won't place nice. Whenever performing a ":cs find > ..." vim would hang until I killed the mlcscope > process. I couldn't find anything on-line about > compatibly issues between the two. I downloaded > sourceforge cscope and had no issues with it working > with vim. > > I've decided to look at the vim source file > if_cscope.c line 633 and changed it to key off of the > string "mlcscope" instead of "cscope" it started to > work. > > Anyways, I thought I'd mention it because I had such a > tough time with it. > > :-) > Frodak -- 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: vim mlcscope interface issues
Just a update on the result of compiling cscope (which requires flex and libncurses-devel). The same error is gotten as that with mlcscope: cs_read_prompt EOF: No error E609: Cscope error: cscope: cannot read trailer offset from file cscope.out I also tried cscope from the command line. Without options, cscope tends to update cscope.out even though there are no newer files. This means that if you don't specify non-C-filenames, it will find nothing, and generate a rather empty cscope.out. So cscope must be invoked together with the source filenames e.g. for matlab files, "cscope *.m". In this case it properly regenerates cscope.out, even though it isn't necessary, and even without the -u option. In this, cscope finds any searched-for symbols as expected. One revealing result occurs when "cscope -d" is issued. This should force cscope to not regenerate the perfectly good cscope.out, which may already exist from a preceding "cscope -b -u *.m" or "cscope *.m". Instead of working as expected, cscope gives the same error as above: cscope: cannot read trailer offset from file cscope.out I have to call it quits for today. I may pick it up again, or simply revert to vimgrep. Thanks for any feedback. Fred On 1/2/07, Fred Ma <[EMAIL PROTECTED]> wrote: If this shows up more than once, I apologize. Gmail is telling me it didn't get sent (twice), and it doesn't show up on the mailing list archive, though that may be due to transit delay. I'm ran into hanging problems with the the following combination, updated today: cygwin 1.5.23-2 vim 7.0.122-1 mlcscope 14.1.8-2 The problem had to do with shelling out to build the cscope database via "mlcscope -b -u *". I specified the files "*" because I had Matlab files; Matlab is ont a recognized language, so the files would not be acted on by default. I think the problem arose because "*" also included the output file being built (cscope.out), so it cscope.out kept get bigger as it analyzed itself. Narrowing the files down to "*.m" restricted the files to Matlab files only, and bypassed that hanging problem. However, I get the following error trying to add the connection to cscope.out: cs_read_prompt EOF: No error E609: Cscope error: mlcscope: cannot read trailer offset from file cscope.out The only reference I've found to it is http://groups.google.ca/group/comp.editors/browse_frm/thread/2a614f2f0e87250e I don't have cscope on my system, so that's not the explanation. I also have cscopeprg=/usr/bin/mlcscope. I'll be downloading cscope as my next step. Since I've gotten vim/cscope to work on solaris before, I'm hopeful that it will be straightforward. I'm curious as to whether there has been any succcess or failures with the current cygwin/vim/mlcscope combination, which will hint at whether it is my setup or not. Date: Sun, 15 Oct 2006 17:03:42 -0500 From: Dave & Diane Subject: Re: vim mlcscope interface issues Delivered-To: mailing list cygwin at cygwin dot com Interesting find. Looks like I'll have to work with the vim folks to see if they will add support for mlcscope. It is a completely different version than cscope, but the interface is generically the same so I don't think it would be too difficult to add support in vim and fix if_cscope.c to support both. In the meantime, if you don't have sourceforge cscope installed, you might try creating a symbol link called cscope and see if that works too. Frodak wrote: Over the last several days I've been trying to use vim with mlcscope and have come to the conclusion that the two won't place nice. Whenever performing a ":cs find ..." vim would hang until I killed the mlcscope process. I couldn't find anything on-line about compatibly issues between the two. I downloaded sourceforge cscope and had no issues with it working with vim. I've decided to look at the vim source file if_cscope.c line 633 and changed it to key off of the string "mlcscope" instead of "cscope" it started to work. Anyways, I thought I'd mention it because I had such a tough time with it. -- 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: "cscope -d" can't find trailer offset if path contains space (was: vim mlcscope interface issues)
Bug fix request submitted for cscope via sourceforge: This problem arose when using vim, but also appears when using "cscope -d". I get the error "cannot read trailer offset from file cscope.out". I browsed build.c to find that it is caused when reading in a single number with fscanf. To see what could be confusing fscanf, I found the context of the "trailer offset" from http://www1.bell-labs.com/project/wwexptools/cscope/cscope.html, which shows that the number to be read occupies a single line along with other space-delimited data, including the specification of the current directory. The space delimiting will get messed up if the current directory contains spaces, which is often the case in Windows and Cygwin (though it can also be the case in *nix). P.S.: It also happens with mlcscope. -- 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/
Exclude cygwin folder from malware scans?
After some surfing, I haven't found any evidence of malware targetting cygwin. I'm considering excluding the massive file tree from scans (AV, SpyBot, AdAware). I'd be interested in more experienced opinions about this. Thanks. -- 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: Exclude cygwin folder from malware scans?
Fred Ma wrote: After some surfing, I haven't found any evidence of malware targetting cygwin. I'm considering excluding the massive file tree from scans (AV, SpyBot, AdAware). I'd be interested in more experienced opinions about this. Thanks. Larry Hall: Any such reports on this list in the past have later been shown to be problems with the software that claims to have found a fault in Cygwin. Such is the reasoning behind the following FAQ: <http://cygwin.com/faq/faq-nochunks.html#faq.setup.virus> There has actually been more evidence to support that virus scanners, firewalls, and spyware detection programs *cause* Cygwin problems by interfering with its proper operation. You can see such reports and the subsequent resolutions (un-install faulty security software) in the email archives. I haven't had any problems in that regard (malware scanners interfering with cygwin or having false positives), though I don't doubt that it has happened before. I was more wondering about the wisdom of taking the plunge and excluding the cygwin directory tree from future scans based on the past track record of not being targeted. -- 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: "cscope -d" can't find trailer offset if path contains space
Thanks. Here's some further info: http://groups.google.ca/group/comp.editors/msg/7ffc56871c614f4b Fred Dave & Diane wrote: > > Sorry for the delay - let me take a look at this in more detail. Given > the sleuthing you've done I'll probably have to go back to the cscope > owner at Bell-Labs. > > Will keep you posted. > > Dave > [mlcscope maintainer for cygwin] > > > Fred Ma wrote: > >> Bug fix request submitted for cscope via sourceforge: >> >> This problem arose when using vim, but also appears when using "cscope >> -d". I get the error "cannot read trailer offset from file >> cscope.out". I browsed build.c to find that it is caused when reading >> in a single number with fscanf. To see what could be confusing >> fscanf, I found the context of the "trailer offset" from >> http://www1.bell-labs.com/project/wwexptools/cscope/cscope.html, which >> shows that the number to be read occupies a single line along with >> other space-delimited data, including the specification of the current >> directory. The space delimiting will get messed up if the current >> directory contains spaces, which is often the case in Windows and >> Cygwin (though it can also be the case in *nix). P.S.: It also >> happens with mlcscope. -- 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/
gdb discrepancy in c++ iterators
Hello,
I'm having the following problem only on cygwin,
not on solaris 8. I have a sanity-check program:
#include
#include
using namespace std;
int main(void)
{
vector vi(3);
vector::iterator it_vi = vi.begin();
cout << "Hello world.";
}
I compile it with gcc 3.2 use
gdb2003-03-03-cvs(cygwin-special) to view
vi.begin() and it_vi. They are different:
(gdb) p vi.begin()
$1 = {> =
{}, _M_current = 0xc7e44589}
(gdb) p it_vi
$2 = {> =
{}, _M_current = 0xa041de0}
Why are they different? If I actually dereference the iterators,
they contain the same thing. But I want to deal with the iterators
themselves. In particular, I want a conditional breakpoint to trigger
when it_vi==vi.begin()+4. gdb won't let you add 4 to a random
access iterator, so I have to use the _M_current member data.
Since they are not the same above, I can't do that. Thanks for
any light on why they differ.
Fred
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: gdb discrepancy in c++ iterators
Igor Pechtchanski wrote:
> On Sat, 29 Mar 2003, Fred Ma wrote:
>
> > Hello,
> >
> > I'm having the following problem only on cygwin,
> > not on solaris 8. I have a sanity-check program:
> >
> > #include
> > #include
> > using namespace std;
> > int main(void)
> > {
> > vector vi(3);
> > vector::iterator it_vi = vi.begin();
> > cout << "Hello world.";
> > }
> >
> > I compile it with gcc 3.2 use
> > gdb2003-03-03-cvs(cygwin-special) to view
> > vi.begin() and it_vi. They are different:
> >
> > (gdb) p vi.begin()
> > $1 = {> =
> > {}, _M_current = 0xc7e44589}
> > (gdb) p it_vi
> > $2 = {> =
> > {}, _M_current = 0xa041de0}
> >
> > Why are they different? If I actually dereference the iterators,
> > they contain the same thing. But I want to deal with the iterators
> > themselves. In particular, I want a conditional breakpoint to trigger
> > when it_vi==vi.begin()+4. gdb won't let you add 4 to a random
> > access iterator, so I have to use the _M_current member data.
> > Since they are not the same above, I can't do that. Thanks for
> > any light on why they differ.
> >
> > Fred
>
> Umm, you do know that calling vi.begin() will create a *new* iterator,
> right? As for it working on other systems, they may have different
> implementations of STL iterators.
> Igor
Yes, I know that. I'm comparing it on a different system but
with the same version of gcc, so I expect the STL implementation
to be the same. I have to qualify that; the cygwin version is
gcc3.2 20020927 (prerelease). The solaris version is 3.2.1,
and since there is no 3.2.0 on www.gun.org, cygwin's gcc is
probably a tenative version of the solaris version. But I don't
expect great changes, at least not as big as the definition of
_M_current. If iterators are suped up pointers, then _M_current
is the primitive pointer that is suped up. From the properly
functioning gcc/gdb on solaris, it_vi and vi.begin() contain the
same value for _M_current. If I dereference _M_current in
either iterator, I get the right object value. If I try this on cygwin,
*it_vi._M_current returns the right value, but
*(vi.begin()._M_current) is an error because the memory
location can't be accessed. In the actual program that
I'm trying to debug, none of the changes made to a aggregate
vector elements via it_vi seem to have any effect, probably
because of the differing _M_current values (in that case,
vi.begin()._M_current is pointing to valid memory space).
About the fact that the iterators are different, gdb's print
command prints the object itself, including data members,
*not* the address of the object. So the fact that the iterators
are different should not make the objects' value different.
Another strange "clue", if it is that: if I print *it_vi._M_current
in the full blown program, vi.begin()_M_current actually changes
values (by itself) so as to be the same as it_vi._M_current.
Very bizzare.
Fred
P.S. The gdb version on cygwin (at top) is relatively
recent. In contrast, on solaris8 (where things seem to
behave right), it's gdb 4.17, copyright 1998.
--
Fred Ma, [EMAIL PROTECTED]
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: gdb discrepancy in c++ iterators
Igor Pechtchanski wrote: > Depending on the optimization level you used to compile the program (and > on the flags in the gcc specs file, and the gcc compilation options, which > are surely different on the two systems), it's quite possible gdb got > confused about where in the program you were with respect to the (probably > inlined) execution of vi.begin() (or, for that matter, the copy > constructor). > > As possible workarounds: Did you consider trying to compile without > optimization? Also, in the original program, does the bug you're looking > for manifest itself if you introduce an extra counter into the loop? If > so, you could use that counter's value as the condition for the > breakpoint. There are also counted breakpoints in gdb that you could make > use of... > Igor Yes, I've read that optimization can make things unpredicatable and confusing for debugging. I didn't turn on optimization. But this is not just a debugger confusion. The program misbehaves. I've embedded code to print out the vector elements after some action on it. No changes take effect (on cygwin), probably due to the differing iterator values (aggregate values, that is). On solaris, the program runs as expected i.e. the changes take effect. Exactly the same code, almost the same compiler. I'll try some of the gdb features you pointed out, but since the problem manifests itself in the program behaviour (and not just when using gdb), it would be a surprise to see it as a gdb problem (or my use of it). Thanks for the pointers. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Big Brother is Real
> OH. MY. GOD. > > I installed SP3 on my Win2K. Ignorance is NOT bliss. > > I guess it really is time to move to Linux. > > > > Randall Schulz > Any comments on whether a firewall helps? I don't use office, just Win2K (and even then, mostly on cygwin). I recall a time Kerio and ZoneAlarm kept asking for server rights for some Win2K service programs. Internet access didn't work without granting these rights. So I granted them. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Should C/C++ compilers be smart enough to catch this???
Hello,
I just spent a great number of hours chasing down a
bug that showed itself on g++ on cygwin, but not on
g++ on solaris2.5.8. What did it turn out to be?
I had a class member function that returned an
object, according to the prototype. Also according
to the function definition. But, the function body
didn't actually contain a return statement. Like
SomeFunc() below:
SomeClass{
// ...
ReturnType SomeFunc( SomeArgs);
Void AnotherFunc(void);
// ...
}
ReturnType SomeClass::SomeFunc(SomeArgs){
//Do stuff,
//No return statement
}
void SomeClass::AnotherFunc(void){
//Do stuff...
//Call SomeFunc():
SomeFunc(SomeArgs);
}
This caused corruption that resulted in memory
access violations, even though SomeFunc's
returned object isn't used at the point where it
is invoked. The memory violations didn't happen
at the point where SomeFunc() was invoked,
either, but in a later step in the code.
The frustrating thing is that the compiler didn't
complain at all about the discrepancy between
the lack of a return statement, even though the
function needed one. I personally find this kind
of thing quite common when I reorganize my
code e.g. moving functionality in and out of class
member functions; that is, the finger details like
return types and argument lists change so that
it's easy to miss.
Shouldn't compilers be smart enough to
not create code that corrupts when it is pretty
straighforward to realize that (1) there is an
obvious discrepancy, for which a warning can
easily be issued, or (2) realize that the return
type really isnt' being used and compile it in a
way that doesn't create memory corruption?
Fred
P.S. Since this happens only on cygwin, it
might specific to any customizations to g++
for cygwin. All in all, cygwin's gcc is a much
better indication of whether my code is buggy,
because the solaris executables generally
seem to run fine even when there are cringe-
inducing bugs, which I only find because they
crash on cygwin.
--
Fred Ma, [EMAIL PROTECTED]
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Should C/C++ compilers be smart enough to catch this???
Måns Rullgård wrote: > Fred Ma <[EMAIL PROTECTED]> writes: > > > I had a class member function that returned an object, according to > > the prototype. Also according to the function definition. But, the > > function body didn't actually contain a return statement. Like > > SomeFunc() below: > > [snip] > > > The frustrating thing is that the compiler didn't complain at all > > about the discrepancy between the lack of a return statement, even > > though the function needed one. I personally find this kind of > > thing quite common when I reorganize my code e.g. moving > > functionality in and out of class member functions; that is, the > > finger details like return types and argument lists change so that > > it's easy to miss. > > Always compile your stuff with -Wall. That should enable the warning. > > > P.S. Since this happens only on cygwin, it might specific to any > > customizations to g++ for cygwin. All in all, cygwin's gcc is a > > much better indication of whether my code is buggy, because the > > solaris executables generally seem to run fine even when there are > > cringe- inducing bugs, which I only find because they crash on > > cygwin. > > One could argue that it is the cygwin environment that is buggy, since > it causes programs to crash, even though they run correctly on > solaris. > > -- > Måns Rullgård > [EMAIL PROTECTED] Thanks for the tip about -Wall. I never realized I had so much problem with my code until I turned it on. I thought I was being high and mighty righteous-like with -pedantic, but it looks like there is a higher righteousness. Lots of good reading, too, of the man page. Despite the comment about buggy cygwin, I am all too thankful that I can compare the execution on the two platforms (solaris and cygwin). Whenever they disagree, I may curse the heavens for spending days to find out why, but it invariably uncovers a big performance/correctness bug which really, really needs to be fixed. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
top is gone
Hello, Today, I came in and found a Kerio firewall warning that someone from Australia (other side of world) tried to connect the the sshd process (part of cygwin). No problem, just deny access. Then I tried to run "top" and the command was not recognized. That's weird. xterms don't give me the expected popup menus when I control-click. I checked the task manager, and no weird processes except maybe crypserv and regsvc, both of which can be disabled according Black Viper (I'll do that as soon as I figure out how). But the missing "top" was strange enough that I wiped out the entire c:\cygwin tree and reinstalled it from scratch. Just to be safe. For some reason, top is still unrecognized, even after "hash -r". There is no top in /usr/bin, and nothing in /usr/local/bin. There is no top to select in the cygwin setup table. There is no top command in the bash man page. And there is no other posting about the missing top command in the mailing list archive. A file search for top starting from c:\cygwin turns up nothing relevant. What path is top suppose to be in? Are there any known reasons why it would just disappear like that? I just spent the whole night trying to get my environment back (not finished yet), and I wonder if it might have been something simple I'm overlooking. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- 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: top is gone (PLUS sshd logs)
[EMAIL PROTECTED] wrote: > > Fred, > > I think top is part of the procps package. Try installing that. > > Regards, > > Jurgen Thanks, Jurgen. It turns out to be in /usr/bin, which I checked. It's amazing. I wonder how it disappeared the first time (before I wiped away c:\Cygwin). Right now, xterms are behaving properly again, and I will see if they remain doing so when I've recustomized the window manager the way it was before. I wish I knew what caused that, if only to avoid recustomizing my environment again. Thanks a bunch. Fred P.S. I looked at the man pages for where sshd records its log of accesses, but couldn't find info about this. Nothing in the default config file either. Is this a cygwin specific location? I would have liked to check for external accesses today (or yesterday, by now). -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- 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: top is gone (PLUS sshd logs)
Original Message Subject: Re: top is gone (PLUS sshd logs) Date: Fri, 20 Jun 2003 05:47:06 -0400 From: Fred Ma <[EMAIL PROTECTED]> To: Vince Hoffman <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Vince Hoffman wrote: > > Hi, > sshd stores its logs in the windows event log. > Vince Hi, Vince, I just took a look at them. They are certainly quite raw. I also found a log file in /c/var/log/sshd.log. The message being that it can't load the host keys, even though the files it specifies are indeed present and readable by user "Administ", group "mkpasswd". Hmm, maybe that's the reason. I've taken the administrator out of /etc/passwd, leaving only users and "system". Still trying to get my environment back to normal. Thanks, Vince. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- 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/
top is gone (PLUS sshd logs)
Forgot to change the subject line Original Message Subject: Re: cygwin Digest 20 Jun 2003 09:53:42 - Issue 2902 Date: Fri, 20 Jun 2003 06:54:15 -0400 From: Fred Ma <[EMAIL PROTECTED]> To: Carlo Florendo <[EMAIL PROTECTED]> > Date: Fri, 20 Jun 2003 15:28:26 +0800 > From: "Carlo Florendo" <[EMAIL PROTECTED]> > > Hi Fred, > > Try running "cygcheck -svr | grep procps" and if it gives you nothing, that means > that top is not installed. By the way, you may > want click the "Packages" link under http://cygwin.com and try to look for the > utility you're missing. For example, you may type > "top.exe" (without the double-quotes, of course) at the search box.I got these > results: > > Found 4 matches for top.exe. > > procps/procps-010801-1 Utilities for monitoring your system and processes on your > system. > procps/procps-010801-2 Utilities for monitoring your system and processes on your > system. > proftpd/proftpd-1.2.9rc1-2 A flexible, stable and highly-configurable FTP Server > proftpd/proftpd-20030513-2 A flexible, stable and highly-configurable FTP Server > > It appears to me that top is not gone. It seems that it was not installed in the > first place. And FYI, you wouldn't find any hints > by reading the bash man page since the top is a different package from bash. > > > What path is top suppose to be in? > It's supposed to be in /bin (if you installed it). > > Best Regards, > > Carlo > - > Carlo Florendo > Astra Philippines., Inc. > URL: www.astra.ph www.astra.co.jp Carlo, Thanks for the pointer to the package search. The cygcheck comes up with procps, but that's only because I installed it. You may be right, perhaps the package wasn't there before. It was a combination of coincidences (misbehaving xterm, firewall warning of someone wanting to connect to sshd) that made me suspect something was wrong. I'm going to catch a few snores and take another look at those event logs. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- 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/
VNC/ssh connection freezes, so does PC
Hello, I'm using TightVNC1.2.2 on WinME to connect to a TightVNC server on a remote sunbox via cygwin's OpenSSH_3.5p1 (on both sun and WinME). It works for anywhere from 10 minutes to about 2 hours, then everything freezes. The computer is totally unresponsive. I can bring up the task manager, but can't tab through the fields and buttons. Often, not even the 3-finger salute works. The cygwin version is DLL version 1.3.15, Dll epoch 19. I am going through Sympatico's highspeed ADSL. I also have ZoneAlarm 3.1.395, Norton AV 2001, and Trojan Hunter Guard. Nothing else is running at the time of the crash. It also happens when the laptop is directly connected to the school LAN (no ADSL). I suspect it's ssh because it only started some time in the last week or so. Our ssh service (on the sun boxes) was itself undergoing some overhaul until about a week ago. Because the timing of the crash is unpredictable, this is hard to verify. Has anyone else experienced this problem? I realize that WinME is the worst possible OS, and I will soon spend the time to install something else, but I used this method of connection for almost a year without this problem. Thanks for any feedback. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Question re. export environment variable
Hello, I'm using cygwin bash 2.05b-8 (it's actually gnu). I thought that $HOSTNAME was an environment variable. When I run gnu make (I'm pretty sure this is not a make problem), $(HOSTNAME) is empty. It gets fixed if I do "export HOSTNAME" before running make. Is there a way to check if the export command has been applied to $HOSTNAME? Does the actual transcription of $HOSTNAME's value to the environment happen only once, when "export" is applied, or is there a continual monitoring an mirroring of changes to $HOSTNAME forever after applying "export"? Fred -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
"tee" is coredumping
Hello, I've got the latest cygwin 1.3.20-1, cygutils 1.1.3-1. The "tee" command is core dumping on me, but only with a particular set of circumstances. I use it as follows: make -f client.mak 2>&1 | tee client.out I realize this is not telling you a whole lot because it depends on what all happens in client.mak. I don't get a core dump if I just do "ls 2>&1 | tee client.out". Here is the short contents of client.mak: CC = gfilt $(warning Hostname is $(HOSTNAME)) ifeq ($(HOSTNAME),fmalap) $(warning Disabling Matlab engine code.) NOML = -DNOML LIBS = else NOML = LIBS = -L /opt/matlab13/extern/lib/sol2 -leng -lmx endif client: client.cpp client.hpp client.mak $(CC) $(NOML) -O -o client \ -I/opt/matlab13/extern/include \ client.cpp \ $(LIBS) The key in this file that seems to cause the crash is using CC=gfilt instead of g++. "gfilt" is a perl script (or rather, a shell script that invokes perl) to decrypt the very confusing messages from the C++ standard library. I realize it's not realistic to ask "What's wrong", but perhaps a few strategies to isolate the problem? I am no perl guy (I've used twice, like an overpowered sed script). The perl version is 5.6.1-2, with gnu license. But perl is probably not the problem, since it's tee that's dumping. Thanks in advance. Fred -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
sshd only allows connection to local accounts
Hello, I followed the procedure of setting up sshd: http://pigtail.net/LRP/printsrv/cygwin-sshd.html I launch the sshd with an account that is part of the administrator group (WinXP). One peculiarity about this account is that it is not a local account i.e. when I log into Windows, I specify a domain name other than the name of the local PC. In order for sshd to respond to connection requests, I did "mkpasswd -l > /etc/passwd". This did not allow me to connect to sshd from outside, since "mkpasswd -l" only generates entries for local users. Therefore, I used "mkpasswd -d", grepped my User ID from the output, then appended it to /etc/passwd. This didn't fix the problem. To check that sshd allowed connections to local user accounts, I created a local user account "Test" and successfully connected to it via sshd from outside. What more is required to allow ssh connections to nonlocal user accounts? I only have control over the local PC. Even here, I don't have absolute control; for example, I can't login as "administrator", but I can login to an account that is part of the administrators group. Thanks. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- 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 only allows connection to local accounts
> Subject: Re: sshd only allows connection to local accounts > Date: Wed, 15 Oct 2003 11:08:42 -0400 > From: Larry Hall <[EMAIL PROTECTED]> > > At 06:22 AM 10/15/2003, Corinna Vinschen you wrote: > >On Wed, Oct 15, 2003 at 05:08:47AM -0400, Fred Ma wrote: > >> Hello, > >> > >> I followed the procedure of setting up sshd: > >> http://pigtail.net/LRP/printsrv/cygwin-sshd.html > >> > >> [SNIP] > >> > >> What more is required to allow ssh connections to > >> nonlocal user accounts? I only have control over > > > >You're assuming too much. We don't know about your > >settings at all. What cygwin version? What ssh > >version? Password authentication or pubkey > >authentication? What do you mean by "I launch the > >sshd with an account that is part of the > >administrator group"? Does that mean you start sshd > >on the command line using that account? Or does > >that mean you start an sshd service from the command > >line using that account? Or do you mean the service > >runs under that account? Etc. Please see > >http://cygwin.com/problems.html. > > > >Corinna > > Also, instructions at <http://pigtail.net/> are > unsupported by cygwin.com. You're best bet is to > uninstall, reinstall, and then follow the > instructions in > /usr/share/doc/Cygwin/openssh-*.README. If that > doesn't help, then following Corinna's pointer above > prior to contacting this list again is a wise step. > Alternatively, you could consult with the author of > the instructions you followed. They'd be a better > resource for debugging their prescribed installation > than anyone on this list would be. > -- > Larry Hall http://www.rfk.com Larry and Corinna, The documentation describes OpenSSH's privilege separation, which smells very relevant to the symptoms I encountered. For now, I must drop the problem, but I know where to start digging for a potential solution. Also other oddities that may be related include the lack of an sshd user account; sshd exists as a user on another machine with cygwin, and it's a matter of more reading to clear up when it should be there. Thank you for the reference. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- 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/
Warning to use mkpasswd
Using an administrator account, I installed cygwin & sshd for all users on Windows XP. The administrator account is local to the machine, while my nonadministrator account is a domain power user account. When I launch a cygwin bash shell as administrator, things are fine. When I launch it as nonadministrator, I get the message Your group is currently "mkpasswd". This indicates that the /etc/passwd (and possibly /etc/group) files should be rebuilt. See the man pages for mkpasswd and mkgroup then, for example, run mkpasswd -l [-d] > /etc/passwd mkgroup -l [-d] > /etc/group Note that the -d switch is necessary for domain users. Here is what I did to create /etc/passwd and /etc/group. As administrator, I did mkpasswd -l >| /etc/passwd mkgroup -l >| /etc/group As nonadministrator, I then did mkpasswd -d | ssh [EMAIL PROTECTED] "cat >> /etc/passwd" mkgroup -d | ssh [EMAIL PROTECTED] "cat >> /etc/group" As an indication of proper functionality, I noted that I can successfully log in using ssh [EMAIL PROTECTED] ssh [EMAIL PROTECTED] Is there anything further I can do to avoid the warning message at the start of this posting? As a possible clue, I noticed that when I log onto Windows as nonAdministrator and start cygwin bash, my home diretory ~ is /c/Documents and Settings/NonAdminAccount Here, c:\ is mounted as /c. When I ssh into [EMAIL PROTECTED], however, ~ becomes /home/NonAdminAccount, which is c:\cygwin\home\NonAdminAccount. Fred -- cygcheck -cvs output, as queried from NonAdminAccount -- Cygwin Package Information Last downloaded files to: C:\Documents and Settings\AdminAccount\Desktop\Goodies\Cygwin Last downloaded files from: http://mirror.cpsc.ucalgary.ca/mirror/cygwin.com Package VersionStatus _update-info-dir 00399-1OK a2ps 4.13-1 OK alternatives 1.3.20a-2 OK ash 20040127-3 OK aspell 0.50.3-1 OK aspell-en0.51.0-1 OK atk 1.9.1-1OK atk-runtime 1.9.1-1OK base-files 3.7-1 OK base-passwd 2.2-1 OK bash 3.1-6 OK binutils 20050610-1 OK bzip21.0.3-1OK cabextract 1.1-1 OK Empty package clear clear1.0-2 OK coreutils5.94-1 OK cron 3.0.1-19 OK crypt1.1-1 OK ctags5.5-4 OK cvs 1.11.17-1 OK cygrunsrv1.16-1 OK cygutils 1.3.0-1OK cygwin 1.5.19-4 OK cygwin-doc 1.4-3 OK ddd 3.3.9-1OK diffutils2.8.7-1OK ed 0.2-1 OK editrights 1.01-1 OK enscript 1.6.4-1OK epstool 3.08-1 OK expat1.95.8-1 OK fftw33.0.1-2OK file 4.16-1 OK findutils4.2.27-1 OK fontconfig 2.2.2-1OK freeglut 2.2.0-1OK freetype22.1.9-1OK gawk 3.1.5-4OK Empty package gcc gcc 3.4.4-1OK gcc-core 3.4.4-1OK gcc-g++ 3.4.4-1OK gcc-mingw-core 20050522-1 OK gcc-mingw-g++20050522-1 OK gdb 20041228-3 OK gdbm 1.8.3-7OK gettext 0.14.5-1 OK ghostscript 8.50-1 OK ghostscript-base 8.50-1 OK ghostscript-x11 8.50-1 OK glib22.6.6-2OK glib2-runtime2.6.6-2OK gnuplot 4.0.0-1OK GraphicsMagick 1.0.6-1OK grep 2.5.1a-2 OK groff1.18.1-2 OK gtk2-x11 2.6.10-1 OK gtk2-x11-runtime 2.6.10-1 OK gv 3.6.1-1OK gvim 6.4-1 OK gzip 1.3.5-2OK ImageMagick 6.0.4-1OK jasper 1.701.0-1 OK jbigkit 1.5-3 OK lapack 3.0-5 OK lcms 1.14-1 OK less 381-1 OK lesstif 0.93.94-2 OK libaspell15 0.50.3-1 OK libbz2_1 1.0.3-1OK libcharset1 1.9.2-2OK libdb4.2
Re: Warning to use mkpasswd
Larry Hall wrote: Mister Fred Ma wrote: Using an administrator account, I installed cygwin & sshd for all users on Windows XP. The administrator account is local to the machine, while my nonadministrator account is a domain power user account. When I launch a cygwin bash shell as administrator, things are fine. When I launch it as nonadministrator, I get the message Your group is currently "mkpasswd". This indicates that the /etc/passwd (and possibly /etc/group) files should be rebuilt. See the man pages for mkpasswd and mkgroup then, for example, run mkpasswd -l [-d] > /etc/passwd mkgroup -l [-d] > /etc/group Note that the -d switch is necessary for domain users. Here is what I did to create /etc/passwd and /etc/group. As administrator, I did mkpasswd -l >| /etc/passwd mkgroup -l >| /etc/group As nonadministrator, I then did mkpasswd -d | ssh [EMAIL PROTECTED] "cat >> /etc/passwd" mkgroup -d | ssh [EMAIL PROTECTED] "cat >> /etc/group" As an indication of proper functionality, I noted that I can successfully log in using ssh [EMAIL PROTECTED] ssh [EMAIL PROTECTED] Is there anything further I can do to avoid the warning message at the start of this posting? As a possible clue, I noticed that when I log onto Windows as nonAdministrator and start cygwin bash, my home diretory ~ is /c/Documents and Settings/NonAdminAccount Here, c:\ is mounted as /c. When I ssh into [EMAIL PROTECTED], however, ~ becomes /home/NonAdminAccount, which is c:\cygwin\home\NonAdminAccount. 'ssh' uses the information in your '/etc/passwd' file to determine your home directory. You can use the '-h' flag to mkpasswd to set this as you desire, if the default is not what you want. -- cygcheck -cvs output, as queried from NonAdminAccount -- Please don't append this information, Apologies -- I did this because it was requested in the past. Common practice and expectations might have changed since. Thanks for the tip on setting the ssh login directory. Fred -- 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/
~^Z hangs ssh
Hello, I'm finding that ~^Z hangs the cygwin session rather than suspending my connection. I'm using cygwin to ssh into a solaris box. I've confirmed that suspension works properly when using ssh from sun box to sun box. Can't find any mention of this problem in the mailing list or Google. Does anyone else have this problem, or a fix? Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- 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: ~^Z hangs ssh
Larry Hall wrote: > > Shing-Fat Fred Ma wrote: > > > Hello, > > > > I'm finding that ~^Z hangs the cygwin session > > rather than suspending my connection. I'm using > > cygwin to ssh into a solaris box. I've confirmed > > that suspension works properly when using ssh from > > sun box to sun box. Can't find any mention of this > > problem in the mailing list or Google. Does anyone > > else have this problem, or a fix? > > > Sorry, I don't have a Sun box to ssh into but it works fine > going from Cygwin (W2K) to Cygwin (W2K) (different boxes though). > Perhaps you want to try "round-tripping" to Cygwin on the same box > or different ones and see how that works for you. Hmm, it works fine for me too. At my current location, I only have a single PC running cygwin and sshd, so I ssh'd myself. ~^Z works fine. It also works fine if I ssh to cygwin from a sunbox. The solaris version is OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f The Cygwin version is OpenSSH_3.6.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090702f Anyway, thanks for checking into it. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- 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/
No such file, but it's right there
Hi, I'm using cygwin 1.3.15 in WinME: Cygwin DLL version info: DLL version: 1.3.15 DLL epoch: 19 When I try to "ls" a file I know to be there, I'm told it isn't: $ which ftp telnet /usr/bin/ftp /usr/bin/telnet $ cd /usr/bin $ ls -l ftp telnet -rwxr-xr-x 1 unknown unknown 57344 Jan 6 2002 ftp* -rwxr-xr-x 1 unknown unknown 79360 Jan 6 2002 telnet* $ less ftp telnet ftp: No such file or directory telnet: No such file or directory I don't really want to less a binary file, just see whether the file's presence is recognized. I wouldn't think it's a mount problem, but here's the mount information: $ mount C:\cygwin\usr\X11R6\lib\X11\fonts on /usr/X11R6/lib/X11/fonts type system (binmode) C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode) c: on /c type user (textmode) d: on /d type user (textmode) Thanks if you have any suggestions. Fred -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
No such file, but it's right there
>Well the files are, of course, ftp.exe and telnet.exe.
>Cygwin's automagical .exe workarounds seems to not be working when going
>through a mount where there is no underlying directory.
>
>Max.
>
> Cygwin follows the Windows convention of using file file name suffix
> ".exe" for its binary executable files. While Cygwin will locate and
> execute files files given only the base name (sans suffix), other uses
> ("cat," "less," or more apropos "nm," "size" or "file") demand the
> full file name, including the ".exe" suffix.
>
> Randall Schulz
> Mountain View, CA USA
Thanks.
Fred
--
Fred Ma, [EMAIL PROTECTED]
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
dos2unix/d2u does nothing
Cygwin DLL version info: DLL version: 1.3.15 DLL epoch: 19 Hello, I'm finding that dos2unix and d2u doesn't change a file in-place, even with -U (the timestamp doesn't even change). It works find for stdin-to-stdout, though. Just thought I'd share my feelings on that (that is, I feel it doesn't work in-place, but thank goodness it works). Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: dos2unix/d2u does nothing
> > Subject: > RE: dos2unix/d2u does nothing > From: > David Kilroy <[EMAIL PROTECTED]> > Date: > Mon, 25 Nov 2002 13:33:42 - > To: > [EMAIL PROTECTED] > > >I have seen similar behaviour to what Fred sees, but I can't remember if >that was u2d or d2u. In that case the files had mixed use of \n and \r\n >line endings. I presumed d2u/u2d detected a single \n (or \r\n) in the first >X bytes, and assumed the file was already in the appropriate format. > >I 'fixed' this by running u2d then d2u (or vice versa). > >Dave. > > > >>-Original Message- >>From: Randall R Schulz [mailto:[EMAIL PROTECTED]] >>Sent: 23 November 2002 05:12 >>To: [EMAIL PROTECTED] >>Subject: Re: dos2unix/d2u does nothing >> >> >>Fred, >> >>It works OK for me. You may be experiencing an interaction >>with a text mode >>mount (though from the looks of it, "conv.c" was ported for >>cygwin to open >>files in binary mode, so this shouldn't happen). >> >>As to the mod time, perhaps you wrote the file and then >>converted it within >>the same minute, so "ls -l" doesn't show a change in the >>modification time >>(even though the difference is there at the finer time >>resolution that the >>OS and / or file system uses to record file modification times). >> >>By the way, dos2unix and d2u are identical (byte-for-byte). >> >>The other thing I can think of is that you're not running the >>dos2unix from >>the "cygutils" package, that the version you're running was >>not ported to >>Cygwin to be immune to the mount type and (conceivably) that >>it resets the >>file's modification time after reformatting it. >> >>Randall Schulz >>Mountain View, CA USA >> Hi, All, It's in the cygwin file tree, /usr/bin/dos2unix version 0.1.2. The file was a few minutes old when I tried in-place conversion. Anything is possible, regarding preserving the file timestamp even after the conversion (afterall, I think some gzip's do that). My "fix" is to use it as a filter. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gnu tar opens tgz's with file times in the future
Hello, I'm gnu-tarring files with tar version 1.13.25 on solaris, then untarring with the same version on cygwin. The files are dated 2002-12-31 18:09:xx in the tgz on solaris. When I sftp them to cygwin, the tar programs shows the files to be dated 2003-01-01 03:09.xx. But typing "date" at the cygwin prompt shows the computer clock to be right i.e. Tue Dec. 31 2002. Cygcheck gives: cygutils1.1.3-1 cygwin 1.3.17-1 I'm using Win2K with SP3. Thanks for any pointers. -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
SOLVED: gnu tar opens tgz's with file times in the future
Shing-Fat Fred Ma wrote: Hello, I'm gnu-tarring files with tar version 1.13.25 on solaris, then untarring with the same version on cygwin. The files are dated 2002-12-31 18:09:xx in the tgz on solaris. When I sftp them to cygwin, the tar programs shows the files to be dated 2003-01-01 03:09.xx. But typing "date" at the cygwin prompt shows the computer clock to be right i.e. Tue Dec. 31 2002. It was the time zone not set right on the PC. Didn't know gnu tar was made to compensate for time zones...... Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: less 378 still not anchoring to \
Max Bowsher wrote: > f wrote: > > I just reinstalled "less" from the cygwin site. > > It still doesn't seem to anchor to word boundaries > > using regex(3) rules i.e. \ doesn't > > match anything, as does . I read > > a posting suggesing a solution by using perl > > syntax (apparently): > > > > /\bSomeWord\b > > > > That works, but is there a known reason why > > the regex notation doesn't work? > > Because less is linked with pcre(3), not regex(3). > > Max. Thanks, Max. The posting I saw did indeed mention linking Perl, but I thought that meant added features rather than different syntax. It looks like I better accelerate my picking up of Perl. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question re. export environment variable
Igor Pechtchanski wrote: > On Thu, 20 Feb 2003, Fred Ma wrote: > > > Hello, > > > > I'm using cygwin bash 2.05b-8 (it's actually gnu). > > I thought that $HOSTNAME was an environment > > variable. When I run gnu make (I'm pretty > > sure this is not a make problem), $(HOSTNAME) > > is empty. It gets fixed if I do "export HOSTNAME" > > before running make. > > > > Is there a way to check if the export command > > has been applied to $HOSTNAME? Does the > > actual transcription of $HOSTNAME's value to > > the environment happen only once, when > > "export" is applied, or is there a continual > > monitoring an mirroring of changes to $HOSTNAME > > forever after applying "export"? > > > > Fred > > Fred, > > I'm afraid you might be confused about what "exporting" a variable means. > Bash maintains an "environment", which contains the values of all the > variables it's using. When bash spawns a child, that child inherits those > variables from the parent's environment that are "exported". Thus, if you > export HOSTNAME, the child will get the current value of HOSTNAME. If you > then change HOSTNAME in the parent, the child *will not* see the change. > However, if you spawn another child, that new child *will* see the new > value. > > BTW, "export" with no variable name will print out the list of all > variables that are exported from the current shell. And, if you want to > make sure it's exported, "export HOSTNAME" can do no harm. But both this > and the above are off-topic for the Cygwin list, and could have been found > by a simple perusal of "man bash". > Igor > -- >http://cs.nyu.edu/~pechtcha/ > |\ _,,,---,,_[EMAIL PROTECTED] > ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] > |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski > '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! > > Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! > -- /usr/games/fortune Igor, Thanks for the information. The "man bash" confirms what you said, and what I thought I knew before encountering the problem. What made me uncertain was that things don't always behave the same in the cygwin environment as they do in, say, solaris, and I'm never sure what behaviour might be due to customizations. Another thing that made me unsure was that it seems strange for $HOSTNAME not to be marked export by default, I didn't think that would happen intentionally. Though it appears now that it is that way. I did miss the bit in the man pages about showing all the export variables. My apologies, I should have spent more time reading it more carefully. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question re. export environment variable
Thanks, Bob. That's the way I expected it to work. I was just unsure of whether there was something cygwin-specific, as it seems strange that something like HOSTNAME is not marked for export at the time that it is set. I'll stick it into ~/.bashrc. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 Bob McGowan wrote: > Fred, perhaps this will help: > > echo $TEST # Test has no value, hence the blank line. > > $ TEST=noexport # Set but not exported > $ echo $TEST > noexport > $ env|grep TEST # Nothing found, no output. > $ export TEST # Export it. > $ env|grep TEST # And now it's found in the environment. > TEST=noexport > $ TEST=second # Change its value. > $ env|grep TEST # Same search as above, but the value is changed. > TEST=second > > Perhaps the easiest way to look at it is to think of exporting as making a type > of global variable. Everyone (within certain limits; for the shell, only its > children...) will see the exported variable. If the value changes, it changes > "everywhere". I've quoted everywhere because this only applies to children > invoked after the change. So if TEST=second and you run an xterm, the new shell > sees TEST=second. Change TEST=third in the first shell, you still have > TEST=second in the second shell, since it already got its value for TEST. Start > a third shell from the first, it will see TEST=third. And so on. > > Fred Ma wrote: > > Hello, > > > > I'm using cygwin bash 2.05b-8 (it's actually gnu). > > I thought that $HOSTNAME was an environment > > variable. When I run gnu make (I'm pretty > > sure this is not a make problem), $(HOSTNAME) > > is empty. It gets fixed if I do "export HOSTNAME" > > before running make. > > > > Is there a way to check if the export command > > has been applied to $HOSTNAME? Does the > > actual transcription of $HOSTNAME's value to > > the environment happen only once, when > > "export" is applied, or is there a continual > > monitoring an mirroring of changes to $HOSTNAME > > forever after applying "export"? > > -- > Bob McGowan > Staff Development Engineer > VERITAS Software > [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: "tee" is coredumping
Igor Pechtchanski wrote: > On Thu, 20 Feb 2003, Fred Ma wrote: > > > Hello, > > > > I've got the latest cygwin 1.3.20-1, cygutils 1.1.3-1. > > The "tee" command is core dumping on me, but > > only with a particular set of circumstances. I use > > it as follows: > > > > make -f client.mak 2>&1 | tee client.out > > > > I realize this is not telling you a whole lot because > > it depends on what all happens in client.mak. I don't > > get a core dump if I just do "ls 2>&1 | tee client.out". > > Here is the short contents of client.mak: > > > > CC = gfilt > > > > $(warning Hostname is $(HOSTNAME)) > > ifeq ($(HOSTNAME),fmalap) > > $(warning Disabling Matlab engine code.) > > NOML = -DNOML > > LIBS = > > else > > NOML = > > LIBS = -L /opt/matlab13/extern/lib/sol2 -leng -lmx > > endif > > > > client: client.cpp client.hpp client.mak > > $(CC) $(NOML) -O -o client \ > > -I/opt/matlab13/extern/include \ > > client.cpp \ > > $(LIBS) > > > > The key in this file that seems to cause the crash is > > using CC=gfilt instead of g++. "gfilt" is a perl script > > (or rather, a shell script that invokes perl) to decrypt > > the very confusing messages from the C++ standard > > library. > > > > I realize it's not realistic to ask "What's wrong", but > > perhaps a few strategies to isolate the problem? I > > am no perl guy (I've used twice, like an overpowered > > sed script). The perl version is 5.6.1-2, with gnu license. > > But perl is probably not the problem, since it's tee that's > > dumping. > > > > Thanks in advance. > > > > Fred > > "man addr2line". "cd /bin && cygcheck tee.exe". This should get you > started. > Igor > -- > http://cs.nyu.edu/~pechtcha/ > |\ _,,,---,,_[EMAIL PROTECTED] > ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] Thanks again, Igor. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Two ssh connections slow
Hello, I'm using TightVNC1.2.2 to connect to Solaris8 from WinMe. I'm using OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f to open the connection. This ssh came with cygwin-1.3.12-4, which I just upgraded to. Prior to this, I was running OpenSSH_2.3.0p1, protocol versions 1.5/2.0. I don't remember what the cygwin version was prior to the upgrade. I'm finding that when I have two VNC sessions open via two ssh channels to two different sun boxes, each session slows to an unusable speed. Most of the time, the response freezes before too long and the connection is dropped (both ssh and VNC). Strangely, it is always the same machine that drops the line, but thereafter, the remaining line speeds up to a usable speed. I don't recall two connections being a problem before the upgrade, though I can't positively say it is "correlated" with upgrading. At first, I thought it was the free ZoneAlarm firewall, but the same behaviour is observed without the firewall. Just wondering if anyone else has experienced similar kind of situation-specific slowdowns with ssh on the new cygwin installation. Fred --- Fred Ma Department of Electronics Carleton University, Mackenzie Building 1125 Colonel By Drive Ottawa, Ontario Canada K1S 5B6 [EMAIL PROTECTED] === -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gvimdiff fails on network drive
Hello,
I'm using cygwin-1.3.12-4 on WinME. I'm
using gvim 6.0 to diff a pair of files residing
on a mounted network drive i.e. /SomeUser
is a mount pointing to \\RemoteSunBox\SomeUser.
Read/write access to /SomeUser is no problem.
Using "gvim -d" on localfiles is no problem.
But using "gvim -d" on files residing on /SomeUser
generates the error E97 (can't create diff files).
I thought it might be a path name problem,
though both invocations would use unix
style path names. But just to see, I tried
putting this in _vimrc (courtesy Machitani-san):
> if has("unix")
> set shell=/bin/bash
> elseif has("win32")
> " set shell=c:/cygwin/bin/bash
> set shell=c:\\cygwin\\bin\\bash.exe
> set shellcmdflag=-c
> set shellpipe=2>&1\|\ tee
> set shellslash
> endif
But the problem persisted. Just as a note,
my gvim is invoked by the bash function
{
( unset SHELL;
/c/Program\ Files/vim/vim60/gvim $* ) &
}
because gvim's diff *never* worked prior
to the "unset SHELL".
Thanks for any suggestions.
Fred
---
Fred Ma
Department of Electronics
Carleton University, Mackenzie Building
1125 Colonel By Drive
Ottawa, Ontario
Canada K1S 5B6
[EMAIL PROTECTED]
===
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: gvimdiff fails on network drive
Vince Hoffman wrote:
> Gvim isnt linked to cygwin1.dll so it wont see cygwin mount points.
Vince,
I understand your explanation, and it sounds
like it is the cause. But why am I able to open
the two files, but not diff them? When I use
"gvim -dR", the two files open but just don't
diff. (I first cd to the remote directory via
the mount point).
Fred
-------
Fred Ma
Department of Electronics
Carleton University, Mackenzie Building
1125 Colonel By Drive
Ottawa, Ontario
Canada K1S 5B6
[EMAIL PROTECTED]
===
> > -Original Message-----
> > From: Shing-Fat Fred Ma [mailto:fma@;doe.carleton.ca]
> > Sent: 25 October 2002 19:25
> > To: [EMAIL PROTECTED]
> > Subject: gvimdiff fails on network drive
> >
> >
> > Hello,
> >
> > I'm using cygwin-1.3.12-4 on WinME. I'm
> > using gvim 6.0 to diff a pair of files residing
> > on a mounted network drive i.e. /SomeUser
> > is a mount pointing to \\RemoteSunBox\SomeUser.
> > Read/write access to /SomeUser is no problem.
> > Using "gvim -d" on localfiles is no problem.
> > But using "gvim -d" on files residing on /SomeUser
> > generates the error E97 (can't create diff files).
> >
> > I thought it might be a path name problem,
> > though both invocations would use unix
> > style path names. But just to see, I tried
> > putting this in _vimrc (courtesy Machitani-san):
> >
> > > if has("unix")
> > > set shell=/bin/bash
> > > elseif has("win32")
> > > " set shell=c:/cygwin/bin/bash
> > > set shell=c:\\cygwin\\bin\\bash.exe
> > > set shellcmdflag=-c
> > > set shellpipe=2>&1\|\ tee
> > > set shellslash
> > > endif
> >
> > But the problem persisted. Just as a note,
> > my gvim is invoked by the bash function
> >
> > {
> > ( unset SHELL;
> > /c/Program\ Files/vim/vim60/gvim $* ) &
> > }
> >
> > because gvim's diff *never* worked prior
> > to the "unset SHELL".
> >
> > Thanks for any suggestions.
> >
> > Fred
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
ftp put; less search; directory timestamp
Hello, I recently upgraded to cygwin-1.3.12-4 on WinME. Recently I noticed that ftp (Gnu inetutils) 1.3.2 hangs when "put"-ing a file (the entire file seems to be transferred though). Don't recall having this problem before. I'm connecting to my university via sympatico dialup. Also, when I use "less", I can't seem to indicate that I want to search for an entire word e.g. regexp is \ But this ends up finding nothing. I don't seem to recall this before either. I even tried less on solaris 8, and it recognizes whole words. Another thing I notice is that the timestamp (used by "ls -t" to sort) isn't necessarily updated for a directory if new files are ftp'd into the directory. This doesn't match the behaviour of solaris 8 (not that it should, but isn't the solaris 8 behaviour pretty sane?) Thanks for any suggestions, or even acknowledgements of the problem so that I know it's not just my installation. Fred --- Fred Ma Department of Electronics Carleton University, Mackenzie Building 1125 Colonel By Drive Ottawa, Ontario Canada K1S 5B6 [EMAIL PROTECTED] [EMAIL PROTECTED] === -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
