[octave ] LOADPATH recurses only one level of subdirectories (on network drives)

[Larrie Carr]

So the punch line is that octave will not work with network drives due to 
the difference on how "stat" returns the number of hard links.  Octave uses 
stat to determine if the directory is recusible.  But you can replicate the 
problem with using stat on the command line.


$stat -c "%h %f" /cygdrive/c/test
2 41c0

$stat -c "%h %f" /usr/share/octave
1 41ed

$stat -c "%h %f" /cygdrive/x/cygwin/usr/share/octave
1 41ed

$ls -l /usr/share/octave
total 0
drwxr-xr-x 1 larrie mkpasswd 0 Feb   8 23.31 2.1.72
drwxr-xr-x 1 larrie mkpasswd 0 Feb   8 23.31 site

The code checks for two links (the %h) given that a subdirectory should have 
a "." and a ".." entry.  But for some reason, network drives created using 
windows within cygwin report 1.


So I'm at the edge of my understanding - should cygwin be reporting 2 or 1 
or is octave using a method that works on every other system except cygwin.


Larrie.

Larrie Carr wrote

John W. Eaton wrote

Probably the code you are looking for is the function do_subdir in
liboctave/kpse.cc.  This file contains a stripped-down version of the
kpathsearch library.  Most modifications were to remove TeX-specific
stuff and to convert it to use std::string instead of plain C strings
which historically leaked memory.  In any case, that function may use
an optimization to decide when to check for subdirectories.  The
optimization looks at the link count of the current directory.  If it
is 2, then the assumption is that the current directory does not
contain any subdirectories.  That seems to work fine for Unixy
systems.  Does that assumption not hold for Cygwin?  If so, then I
think the fix is fairly simple as there is also Windows-specific code
in that function.  Whether the optimization is performed depends on
what is #defined at compile time, so you'll probably have to do some
checking on a Cygwin system to see what is really going on.



Well, after some more experimenting, the problem appears related to using 
the recursive search feature of LOADPATH on a *network* drive.  That is,


If the path is located within a physically attached hard drive, octave 
operates as expected.  For instance, /cygdrive/c/test// works all the way 
down to /cygdrive/c/test/a/b/c/d/e/


If the path is located on a network drive created using windows "Map 
Network Drive" menu option under "My Computer", octave will only recurse 
down 1 level of subdirectory.  For instance "/usr/share/octave/site/m// 
does not work.


And if I use a cygwin windows mapping instead 
"/cygdrive/x/cygwin/usr/share/octave/site/m//, it still does not work 
correctly and recurses down only one level.


In my installation, the entire cygwin root is located on a network drive 
(and no one else uses it).  Works just fine for everything else.


John, it you got any other hints, I would appreciate it as I'm diving in.

Larrie.






--
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 with dynamic linkage?

[skaller]

On Sat, 2006-02-11 at 20:38 -0500, Igor Peshansky wrote:

> > http://felix.sf.net/flx_1.1.2_rc1.tgz
> 
> Well, you could have done *some* work on cutting the testcase down,

I spent lots of time on it ;( That problem has been bugging
me for over 6 months.

> This looks to me like another instance of
>  (follow that thread
> through -- it has a reference to another thread, too).

Ah! Thank you!! That makes sense!! I had trouble with std::string
before. Now why didn't I think of that .. only recently I removed
the manual template instantiation forcing instantiation in the RTL
(because it gave link errors on OSX 10.3)

Thanks very much! Flx_dynlink_t is indeed in error!!

My policy has been to force instantiation of destructors,
constructors and all virtual or otherwise significant
functions of constructible rtl types in the rtl, 
but flx_dynlink_t has a compiler generated default constructor.

flx_libinit_t has the same problem (no default or copy ctors,
no assignment operator).

I fixed flx_dynlink_t and initialised the string 'filename' to ""
and now all the non-pthread tests work!

-- 
John Skaller 
Felix, successor to C++: http://felix.sf.net


--
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/

First Ever rebaseall

[zzapper]

Hi,
Had to do my first rebaseall
when for no apparent reason my zsh failed (dll going potty) . Trouble is when 
my shell fails I'm
kinda stuck as so much of my knowledge depends on it.

Luckiliy I googled a cygwin posting where a Cygwin maintainer was fragging some 
guy for not
realising he needed to do a rebasell

Tip
You need to rebaseall from an ash shell with everything shutdown including CRON!

How come I've cygwined 4 so long without needing rebaseall ???

-- 
zzapper
Success for Techies and Vim,Zsh tips
http://SuccessTheory.com/
-- 
zzapper
Success for Techies and Vim,Zsh tips
http://SuccessTheory.com/


--
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/

[ANNOUNCEMENT] New packages: quilt-0.43 -- Tool to work with series of patches

[Jari Aalto]

PACKAGE DESCRIPTION
===

Homepage: http://freshmeat.net/projects/quilt/
License : GPL

Tool to work with series of patches

Program manages a series of patches by keeping track of the changes each
of them makes. They are logically organized as a stack, and you can
apply, un-apply, refresh them easily by traveling into the stack
(push/pop). Quilt is good for managing additional patches applied to a
package received as a tarball or maintained in another version control
system. The stacked organization proved to be efficient for the
management of very large patch sets (more than hundred patches).

With quilt, all work occurs within a single directory tree. Since
version 0.30, commands can be invoqued from anywhere within the source
tree. Commands are of the form quilt cmd, similar to CVS commands.
They can be abbreviated as long as the specified part of the command
is unique. All commands print some help text with "quilt  -h".

CHANGES SINCE LAST RELEASE
==

None.

INSTALL OR UPGRADE NOTES


None.

CYGWIN INSTALLATION INFORMATION
===

To install this package, click on the "Install Cygwin now" link on the
 web page. This downloads setup.exe to your
system. Then, run setup and answer all of the questions. You'll find
the package listed in the "All" category. After installation, read the
documentation at directories:

/usr/share/doc//*
/usr/share/doc/Cygwin/.README

If you have questions or comments, please send them to the Cygwin
mailing list at .

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


This message has been sent to cygwin-announce list.

If you want to unsubscribe from the mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message. Send
email to the address specified there. It will be in the format:

[EMAIL PROTECTED]

More information on unsubscribing can be found:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above URL.


--
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 with dynamic linkage?

[Igor Peshansky]

On Sat, 11 Feb 2006, skaller wrote:

> On Sat, 2006-02-11 at 00:59 -0500, Igor Peshansky wrote:
> > On Sat, 11 Feb 2006, skaller wrote:
> >
> > > hi, I'm having some problem getting dynamic linkage to work.
> > > The linkage model is like this:
> > >
> > > mainline <- load time  librtl.dll
> > > ^   /
> > >  \ /
> > > dlopen/
> > >\ /
> > >   user.dll <-
> > >
> > > gdb indicates the code is crashing in dlopen. LoadLibrary
> > > doesn't appear to work either :)
>
> > In fact, a small example program, buildable with a makefile into two
> > DLLs and a main application, would be even more helpful.
>
> I have tried that .. it works :) Basically the original instructions
> on the website say to use -Wl,-auto-import ... blah blah in the advanced
> explanations suff. But the simplified example doesn't use that.
> Neither do I. I did try building an export/import lib. That does seem
> to change the time and way the system crashes.
>
> The crash occurs when an attempt is made to load the user.dll,
> even when the filename given is rubbish .. so the problem isn't
> related to that dll. The program WORKS when no filename is
> given, in which case it just prints the usual 'usage' information.
>
> In the case of a garbage filename, the rtl should be throwing
> a C++ exception. Perhaps that's causing the problem. However
> in the case of a valid filename it should work .. but I get
> the same result.
>
> Unfortunately the only easy way to reproduce the problem is to
> download and install Felix:
>
>   http://felix.sf.net/flx_1.1.2_rc1.tgz

Well, you could have done *some* work on cutting the testcase down,
especially since you know the code better than I do.  But, since I'm the
Cygwin O'Caml maintainer, I was curious, so I downloaded it (turns out the
problem has nothing to do with O'Caml).  Starting with the make log and
the generated C++ version of the code, I ended up with the attached files.
FWIW, it seems to be crashing in the flx_dynlink_t destructor (not in
dlopen) -- in fact, even before I cut it down to the attached, commenting
out any mention of dlopen still caused the crash.  Stepping through the
code in gdb quickly gets you to the place where it crashes.

> which requires Python and Ocaml. After that ./configure, make
> should work. Then make test. BTW: if any Cygwin expert would
> like to join the project that would be great!
>
> > Then wouldn't you be able to reproduce it with only one DLL and one
> > main application?  Can we see a small complete example that shows the
> > problem?
>
> As above .. small C example, as given on the Cygwin website, works
> just fine.
>
> The problem could be related to C++ RTTI, since I know
> ELF/gcc 4.0 doesn't work correctly it would be unfair to expect
> gcc 3.4 on Cygwin to do all that nasty emulation and work.
>
> (The problem here is related to duplicate typeinfo records,
> which cannot be avoided in general with dynamic linkage.
> Some care is needed in the code to ensure the RTTI is only
> instantiated once, and properly imported from that one
> location, because gcc's method of catching exceptions
> is broken)
>
> However no exception should be thrown when loading one
> of the proper dlls with dlopen(), so there could be
> two distinct faults.
>
> It's also possible -O3 -fomit-frame-pointer is the problem:
> gcc's -O3 is known to not work reliably. (however if I recall
> I got rid of both, and it made no difference).
>
> > > Info: resolving vtable for XXXby linking to __imp__XXX (auto-import)
> > >
> > > occur when linking the executable.
> >
> > Those are informational.  You can either ignore them, or give the
> > "-Wl,--enable-auto-import" flag to the linker to quiet them.
>
> I admit being confused what that does. According to my understanding
> of it, this auto-import thing should only apply to variables.
> vtables and code are read only, they should be in the code (text)
> segment shouldn't they?

I'm not sure.  Technically, vtables are data (though they contain pointers
to the code).  But I'm not a C++ internals expert, and this is not a C++
internals list... :-)  Besides, that's irrelevant to your crash.

> > > Cygwin: latest setup provides.
> >
> > Umm, setup can provide quite a few versions ranging from ancient to
> > latest, depending on your mirror.  Why not follow the guidelines at
> >  and attach (as an uncompressed text
> > attachment) the output of "cygcheck -svr"?
>
> Done, for the XP64 machine. The other I can't get atm, since
> its dual booted with Linux which is running my mail client :)
>
> > > Any hints what is causing the problem or how to fix it?
> >
> > Not until we have enough information to allow us to reproduce the
> > problem.
>
> I need some hint of what it could be to try to reduce
> the 100KLoc to a manageable size :) It has to be something

As I said above, this has n

Re: libUSB

[Yaakov S (Cygwin Ports)]

Mary Cuper wrote:

How can I use libUSB with Windows/Cygwin like with Linux?
With Linux my code works (it finds the Atmel Microcontroller) but with
Windows/Cygwin it does not find the Microcontroller.

libUSB did not compile with Cygwin, so I installed libUSB-win32, but it does
not function.


Actually, I'm trying to get this working myself.  See:

ftp://sunsite.dk/projects/cygwinports/release/libusb/

This is a Cygwin version of libusb-win32, but it would seem from the 
website that some additional steps are necessary for it to actually find 
specific devices.


I've set the Followup-To: header to the cygwin-ports-general list, which 
is where Cygwin Ports packages should be discussed.  Please let me know 
what you find.



Yaakov

--
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: default PATH

[Stephan Mueller]

cgf wrote:
" On Sat, Feb 11, 2006 at 12:02:47PM -0800, Stephan Mueller wrote:
" >On Friday, Feb 10, Corinna wrote:
" >" On Feb  8 18:59, Dave Korn wrote:
" >" > On 08 February 2006 13:06, Eric Blake wrote:
" >" > > Yes, this is correct behavior, but it often catches people by surprise.
" >" > > POSIX requires an empty string in your PATH to be treated as the 
current
" >" > > directory, and while people are less likely to start their Windows PATH
" >" > > with ; or to have ;; in the middle, a trailing ; is pretty common from
" >" > > applications that don't know any better on Windows.
" >" > 
" >" >   No, it's not quite correct behaviour - but the incorrectness isn't in 
the interpretation of $PATH, but in the way it is translated
" >" > from %PATH%.
" >" > 
" >" > Since POSIX semantics requires an empty path component to be treated as
" >" > $CWD, but Win32 semantics require an empty path component to be ignored,
" >" ^
" >" 
" >" How do you know that?  Can you give me a pointer describing that?  I
" >" searched MSDN and KB and found not a word about how multiple semicolons
" >" are treated by Win32 functions or cmd/command.  This is tricky to test
" >" since, for instance, CreateProcess searches the current directory anyway
" >" before using %PATH% (see MSDN).
" >
" >I suspect that there is no definitive answer here, but one more datapoint:
" > path ?
" >on Win2K3 and WinXP includes the text
" > Type PATH ; to clear all search-path settings and direct cmd.exe
" > to search only in the current directory.
" >Actually invoking PATH ; results in my PATH being null.  I conclude from this
" >that a) the bit about only searching the current directory is the implicit
" >search CreateProcess does and b) empty path components (the empty strings
" >before and after the lone semicolon) are _not_ to be considered the current
" >directory, since the PATH command felt happy to throw them and their 
separating
" >semicolon away.
" 
" We know that Windows searches the current working directory no matter
" what you do so 1) there doesn't seem to be any way of knowing how
" Windows would interpret a ;; and 2) there is no way of knowing if the
" path command shell convention has anything to do with lower level
" windows internals.
" 
" So, I don't think this really answers Corinna's question.  I believe that
" she was looking for documentation which stated that ;; was ignored, not
" reasoning which implies it.

In the absence of the former, I'd hope the latter would be better than nothing.
I'd also consider that the text from PATH ? counts as documentation, and
conclusions drawn from the results of doing exactly what it says to be worth
something.

" >" > the code that translates %PATH% to $PATH is not performing
" >" > the translation correctly.  It should strip out empty components from
" >" > the win32 path if it wants to get a semantically-equivalent path
" >" > setting.  Translating an empty win32 path component into an empty
" >" > posix path component is not translating like into like.
" >" 
" >" I'm wondering how other people think of that.  In theory we could
" >" change Cygwin to ignore ";;" sequences and not to add "." to $PATH,
" >" or we can just keep it as it is.
" >
" >Given the experiment above, as well as my experience (see below) I'm inclined
" >to agree with Dave.
" >
" >" There are two different points of view possible here:
" >" 
" >" - Changing an empty Win32 path component to a POSIX "." entry is in
" >"   Cygwin for a long time.  It's possible that people rely on this
" >"   behaviour, so changing it would break existing installations.
" >"   Removing "." from $PATH could easily be accomplished in a script.
" >" 
" >" - Changing an empty Win32 path component to a POSIX "." entry is an
" >"   inherently dangerous behaviour and should not be done automatically.
" >"   Adding "." to $PATH could easily be accomplished in a script.
" >
" >More explicitly, I believe that the implicit CreateProcess search of .
" >means, in practice (not by any formal rule) that Windows users don't
" >intend to put the current directory on their paths.  I believe the vast
" >majority of multiple and trailing semicolons are the sloppy install
" >programs, and perhaps occasional sloppy users.  In the dev environment
" >I maintain for many devs at work, my  startup scripts explicitly squeeze
" >out semicolons while fixing up %PATH% to remove this ambiguity (and also
" >simplify further processing).
" >
" >So, I think it's not unreasonable to squeeze out multiple and leading and
" >trailing semicolons from the Windows path before doing the translation --
" >i.e. lose the empty components, don't turn them into dots.  This approach
" >(Corinna's second point of view above) is, I think, the truest translation
" >of %PATH% to $PATH.
" >
" >" So, what's the way to go?  Any third possibility perhaps?
" >
" >I'd also be inclined to consider explicitly p

RE: default PATH

[Stephan Mueller]

Eric writes:
" " > " There are two different points of view possible here:
" > " 
" > " - Changing an empty Win32 path component to a POSIX "." entry is in
" > "   Cygwin for a long time.  It's possible that people rely on this
" > "   behaviour, so changing it would break existing installations.
" > "   Removing "." from $PATH could easily be accomplished in a script.
" > " 
" > " - Changing an empty Win32 path component to a POSIX "." entry is an
" > "   inherently dangerous behaviour and should not be done automatically.
" > "   Adding "." to $PATH could easily be accomplished in a script.
" > 
" > 
" > " So, what's the way to go?  Any third possibility perhaps?
" > 
" > I'd also be inclined to consider explicitly prepending a dot in the
" > translation.  This means we're no longer just converting %PATH% to $PATH,
" > but rather, the CreateProcess behaviour involving %PATH% -- prepending a dot
" > is turning CreateProcess's implicit behaviour into something explicit.
" > 
" > 
" > The existing situation (point of view 1) is not horrible either, and has
" > the backwards compatibility thing going for it.  But I think I'd prefer
" > either 2 or 3.  3 has that bit of propagated evil from CreateProcess, but
" > is prehaps slightly more backwards compatible (breaking fewer installations)
" > than 2.
" 
" I strongly oppose option 3 - cygwin should never add '.' implicitly to the
" front of a POSIX path - if you are crazy enough to want dot there, put
" it there yourself explicitly.  But I like option 2, of squeezing ';;' into a
" single ':' (avoiding the implicit dot of $PATH '::'), and ignoring trailing 
';'
" (again, avoiding the implicit dot of $PATH trailing ':').  If the user wants
" dot in the middle or at the end, automagically converted from
" the Windows %PATH%, then they can explicitly use ';.;' or trailing
" ';.' to make their intent clear.  And since Windows always implicitly
" prepends '.' to %PATH%, this might cut down on the traffic to this
" list of "how did . get on my $PATH?".  (Although it will probably
" increase the traffic of "why did ;; get turned into : instead of ::?")
" 
" --
" Eric Blake

I'm not surprised at the strong objection -- note I considered option 3 to be
propagating some evil myself.  Putting dot where you want it in the path _is_
the simplest, safest course of action, in Windows and in Cygwin, except that
in Windows, it does almost no good to try to manage this yourself because
of the unavoidable implicit CreateProcess search.

That said, option 3, as I proposed it, is _not_ to implicitly put a dot on front
of a POSIX path, it's to _explicitly_ add to the front of $PATH.  That is,
assuming a Windows
set PATH=c:\windows;c:\windows\system32;c:\etc
that would be translated on entry to the Cygwin environment to
PATH=.:/cygdrive/c/windows:/cygdrive/c/windows/system32:/cygdrive/c/etc
The dot is added as part of the translation from Windows-land.  After that
conversion, you can do what you want to it -- including removing it.  Since
removing it is considered desirable, why add it at all?  Because if the goal
is to translate the meaning of the Windows PATH variable, then that ought to
include translating the ugly parts.  Otherwise, it's not translation, it's
editing, which may or may not be better.

One can argue that the PATH variable doesn't include the dot in Windows and
so shouldn't in Cygwin, and that searching the current directory first in
Windows implicitly is evil, and I won't argue with any of that.  Corinna
was requesting other options, so here it is.

If a %PATH% to $PATH translation doesn't include a leading dot, it means that
if my current directory is c:\foo, and there's a bar.exe in that directory,
and c:\foo is not explicitly on the path, then from cmd.exe, typing bar will
execute bar.exe, and doing the same from bash with a translated path won't.

If we don't care about translating the path _that_ accurately, so be it.  I
can live with option 2, and option 1 has served well (except for occasional
confusion like that leading to this thread) too.

stephan();

--
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: default PATH

[Christopher Faylor]

On Sat, Feb 11, 2006 at 12:02:47PM -0800, Stephan Mueller wrote:
>On Friday, Feb 10, Corinna wrote:
>" On Feb  8 18:59, Dave Korn wrote:
>" > On 08 February 2006 13:06, Eric Blake wrote:
>" > > Yes, this is correct behavior, but it often catches people by surprise.
>" > > POSIX requires an empty string in your PATH to be treated as the current
>" > > directory, and while people are less likely to start their Windows PATH
>" > > with ; or to have ;; in the middle, a trailing ; is pretty common from
>" > > applications that don't know any better on Windows.
>" > 
>" >   No, it's not quite correct behaviour - but the incorrectness isn't in 
>the interpretation of $PATH, but in the way it is translated
>" > from %PATH%.
>" > 
>" > Since POSIX semantics requires an empty path component to be treated as
>" > $CWD, but Win32 semantics require an empty path component to be ignored,
>" ^
>" 
>" How do you know that?  Can you give me a pointer describing that?  I
>" searched MSDN and KB and found not a word about how multiple semicolons
>" are treated by Win32 functions or cmd/command.  This is tricky to test
>" since, for instance, CreateProcess searches the current directory anyway
>" before using %PATH% (see MSDN).
>
>I suspect that there is no definitive answer here, but one more datapoint:
>   path ?
>on Win2K3 and WinXP includes the text
>   Type PATH ; to clear all search-path settings and direct cmd.exe
>   to search only in the current directory.
>Actually invoking PATH ; results in my PATH being null.  I conclude from this
>that a) the bit about only searching the current directory is the implicit
>search CreateProcess does and b) empty path components (the empty strings
>before and after the lone semicolon) are _not_ to be considered the current
>directory, since the PATH command felt happy to throw them and their separating
>semicolon away.

We know that Windows searches the current working directory no matter
what you do so 1) there doesn't seem to be any way of knowing how
Windows would interpret a ;; and 2) there is no way of knowing if the
path command shell convention has anything to do with lower level
windows internals.

So, I don't think this really answers Corinna's question.  I believe that
she was looking for documentation which stated that ;; was ignored, not
reasoning which implies it.

>" > the code that translates %PATH% to $PATH is not performing
>" > the translation correctly.  It should strip out empty components from
>" > the win32 path if it wants to get a semantically-equivalent path
>" > setting.  Translating an empty win32 path component into an empty
>" > posix path component is not translating like into like.
>" 
>" I'm wondering how other people think of that.  In theory we could
>" change Cygwin to ignore ";;" sequences and not to add "." to $PATH,
>" or we can just keep it as it is.
>
>Given the experiment above, as well as my experience (see below) I'm inclined
>to agree with Dave.
>
>" There are two different points of view possible here:
>" 
>" - Changing an empty Win32 path component to a POSIX "." entry is in
>"   Cygwin for a long time.  It's possible that people rely on this
>"   behaviour, so changing it would break existing installations.
>"   Removing "." from $PATH could easily be accomplished in a script.
>" 
>" - Changing an empty Win32 path component to a POSIX "." entry is an
>"   inherently dangerous behaviour and should not be done automatically.
>"   Adding "." to $PATH could easily be accomplished in a script.
>
>More explicitly, I believe that the implicit CreateProcess search of .
>means, in practice (not by any formal rule) that Windows users don't
>intend to put the current directory on their paths.  I believe the vast
>majority of multiple and trailing semicolons are the sloppy install
>programs, and perhaps occasional sloppy users.  In the dev environment
>I maintain for many devs at work, my  startup scripts explicitly squeeze
>out semicolons while fixing up %PATH% to remove this ambiguity (and also
>simplify further processing).
>
>So, I think it's not unreasonable to squeeze out multiple and leading and
>trailing semicolons from the Windows path before doing the translation --
>i.e. lose the empty components, don't turn them into dots.  This approach
>(Corinna's second point of view above) is, I think, the truest translation
>of %PATH% to $PATH.
>
>" So, what's the way to go?  Any third possibility perhaps?
>
>I'd also be inclined to consider explicitly prepending a dot in the
>translation.  This means we're no longer just converting %PATH% to $PATH,
>but rather, the CreateProcess behaviour involving %PATH% -- prepending a dot
>is turning CreateProcess's implicit behaviour into something explicit.

This is absolutely *not* something that we would do.  We're not trying to mimic
Windows behavior.  We're trying to determine if there are people out there who
are expectin

RE: gnu make causes reboot

[cc979.uk]

i've found it to be outpost firewall 3.5.638.6208 (457)

probably one of its filters

after installing outpost, make crashes if i un-install outpost all is ok

and cygwin was ok with outpost 3.0
--
View this message in context: 
http://www.nabble.com/gnu-make-causes-reboot-t1102615.html#a2889296
Sent from the Cygwin Users forum at Nabble.com.


--
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 Help

[Igor Peshansky]

On Sat, 11 Feb 2006, Nitin Mathur wrote:

> Hi,,
>
> I am sorry for sending the previous post without any message. It was
> sent by mistake.
>
> I am facing a small problem. I have gcc 2.95 installed on my machine. I
> cannot download the latest version or any other version of cygwin and
> gcc because these are my company requirements. I have to work on this
> version of gcc
>
> When I try to compile any cpp file, the linker throws an error "cannot
> find -lstdc++".
>
> I tried to search the complete cygwin directory for the library. I could
> find "libstdc++.a.2.10.0". I tried to rename this as stdc++.a but failed
   
> in my attempt to get the file linked.

The name you chose is wrong; -lstdc++ will look for a file named
"libstdc++.a", not "stdc++.a".  But this is unlikely to work in any case,
since the above library does not come from the gcc2 Cygwin package.
Looks like your version of gcc2 is screwed up.

> Can anybody help me in this regard ? I shall be really grateful.
>
> I have attached the error message below the mail.
>
> Best regards,
> Nitin Mathur,
>
> C:\TEMP>g++ c3.cpp -Wall
> /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/../../../../i686-pc-cygwin/bin/ld: 
> cannot find -lstdc++
> collect2: ld returned 1 exit status

Start here:

> Problem reports:   http://cygwin.com/problems.html

Please pay particular attention to the part that talks about message
subjects and the part that asks you to attach (as an uncompressed text
attachment) the output of "cygcheck -svr" on your machine.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: default PATH

[Eric Blake]

> 
> " There are two different points of view possible here:
> " 
> " - Changing an empty Win32 path component to a POSIX "." entry is in
> "   Cygwin for a long time.  It's possible that people rely on this
> "   behaviour, so changing it would break existing installations.
> "   Removing "." from $PATH could easily be accomplished in a script.
> " 
> " - Changing an empty Win32 path component to a POSIX "." entry is an
> "   inherently dangerous behaviour and should not be done automatically.
> "   Adding "." to $PATH could easily be accomplished in a script.
> 
> 
> " So, what's the way to go?  Any third possibility perhaps?
> 
> I'd also be inclined to consider explicitly prepending a dot in the
> translation.  This means we're no longer just converting %PATH% to $PATH,
> but rather, the CreateProcess behaviour involving %PATH% -- prepending a dot
> is turning CreateProcess's implicit behaviour into something explicit.
> 
> 
> The existing situation (point of view 1) is not horrible either, and has
> the backwards compatibility thing going for it.  But I think I'd prefer
> either 2 or 3.  3 has that bit of propagated evil from CreateProcess, but
> is prehaps slightly more backwards compatible (breaking fewer installations)
> than 2.

I strongly oppose option 3 - cygwin should never add '.' implicitly to the
front of a POSIX path - if you are crazy enough to want dot there, put
it there yourself explicitly.  But I like option 2, of squeezing ';;' into a
single ':' (avoiding the implicit dot of $PATH '::'), and ignoring trailing ';'
(again, avoiding the implicit dot of $PATH trailing ':').  If the user wants
dot in the middle or at the end, automagically converted from
the Windows %PATH%, then they can explicitly use ';.;' or trailing
';.' to make their intent clear.  And since Windows always implicitly
prepends '.' to %PATH%, this might cut down on the traffic to this
list of "how did . get on my $PATH?".  (Although it will probably
increase the traffic of "why did ;; get turned into : instead of ::?")

--
Eric Blake

--
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: default PATH

[Stephan Mueller]

On Friday, Feb 10, Corinna wrote:
" On Feb  8 18:59, Dave Korn wrote:
" > On 08 February 2006 13:06, Eric Blake wrote:
" > > Yes, this is correct behavior, but it often catches people by surprise.
" > > POSIX requires an empty string in your PATH to be treated as the current
" > > directory, and while people are less likely to start their Windows PATH
" > > with ; or to have ;; in the middle, a trailing ; is pretty common from
" > > applications that don't know any better on Windows.
" > 
" >   No, it's not quite correct behaviour - but the incorrectness isn't in the 
interpretation of $PATH, but in the way it is translated
" > from %PATH%.
" > 
" > Since POSIX semantics requires an empty path component to be treated as
" > $CWD, but Win32 semantics require an empty path component to be ignored,
" ^
" 
" How do you know that?  Can you give me a pointer describing that?  I
" searched MSDN and KB and found not a word about how multiple semicolons
" are treated by Win32 functions or cmd/command.  This is tricky to test
" since, for instance, CreateProcess searches the current directory anyway
" before using %PATH% (see MSDN).

I suspect that there is no definitive answer here, but one more datapoint:
path ?
on Win2K3 and WinXP includes the text
Type PATH ; to clear all search-path settings and direct cmd.exe
to search only in the current directory.
Actually invoking PATH ; results in my PATH being null.  I conclude from this
that a) the bit about only searching the current directory is the implicit
search CreateProcess does and b) empty path components (the empty strings
before and after the lone semicolon) are _not_ to be considered the current
directory, since the PATH command felt happy to throw them and their separating
semicolon away.

" > the code that translates %PATH% to $PATH is not performing
" > the translation correctly.  It should strip out empty components from
" > the win32 path if it wants to get a semantically-equivalent path
" > setting.  Translating an empty win32 path component into an empty
" > posix path component is not translating like into like.
" 
" I'm wondering how other people think of that.  In theory we could
" change Cygwin to ignore ";;" sequences and not to add "." to $PATH,
" or we can just keep it as it is.

Given the experiment above, as well as my experience (see below) I'm inclined
to agree with Dave.

" There are two different points of view possible here:
" 
" - Changing an empty Win32 path component to a POSIX "." entry is in
"   Cygwin for a long time.  It's possible that people rely on this
"   behaviour, so changing it would break existing installations.
"   Removing "." from $PATH could easily be accomplished in a script.
" 
" - Changing an empty Win32 path component to a POSIX "." entry is an
"   inherently dangerous behaviour and should not be done automatically.
"   Adding "." to $PATH could easily be accomplished in a script.

More explicitly, I believe that the implicit CreateProcess search of .
means, in practice (not by any formal rule) that Windows users don't
intend to put the current directory on their paths.  I believe the vast
majority of multiple and trailing semicolons are the sloppy install
programs, and perhaps occasional sloppy users.  In the dev environment
I maintain for many devs at work, my  startup scripts explicitly squeeze
out semicolons while fixing up %PATH% to remove this ambiguity (and also
simplify further processing).

So, I think it's not unreasonable to squeeze out multiple and leading and
trailing semicolons from the Windows path before doing the translation --
i.e. lose the empty components, don't turn them into dots.  This approach
(Corinna's second point of view above) is, I think, the truest translation
of %PATH% to $PATH.

" So, what's the way to go?  Any third possibility perhaps?

I'd also be inclined to consider explicitly prepending a dot in the
translation.  This means we're no longer just converting %PATH% to $PATH,
but rather, the CreateProcess behaviour involving %PATH% -- prepending a dot
is turning CreateProcess's implicit behaviour into something explicit.

I like this because it's truer to preserving the user's Windows overall path
semantics and is more deterministic than the typical current accidental case
-- a Windows user automatically gets . first because of CreateProcess, and
happens to get . somewhere in their $PATH under Cygwin if they're sloppy
with the semicolons, so doesn't notice the subtle difference in order.
Other users don't get . at all because they have a tidy %PATH%, and may or
may not notice under Cygwin.

On the other hand, I don't like this because it means that the evil that
is the implicit CreateProcess . search is now pushed into Cygwin.  Of
course, a user who cares can munge $PATH after the automatic conversion to
remove a leading . if they don't like it.  I munge $PATH a whole bunch
in .bashrc a

1.5.19: timeval struct not correct defined

[Johnny Willemsen]

Hi,

In sys/time.h the timeval struct is defined as:

struct timeval {
  long tv_sec;
  long tv_usec;
};

It should be 

struct timeval {
  time_t tv_sec;
  suseconds_t tv_usec;
};

See the following link for the opengroup standard
http://www.opengroup.org/onlinepubs/007908799/xsh/systime.h.html

The type suseconds_t and useconds_t are also not there with Cygwin

Regards,

Johnny Willemsen
Remedy IT
Postbus 101
2650 AC  Berkel en Rodenrijs
The Netherlands
www.theaceorb.nl / www.remedy.nl  


--
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: ssh login and SMB drive

[Corinna Vinschen]

On Feb 11 14:04, Torsten Bronger wrote:
> Hallöchen!
> 
> Igor Peshansky <[EMAIL PROTECTED]> writes:
> 
> > On Fri, 10 Feb 2006, Torsten Bronger wrote:
> >
> >> I've running an sshd on a Cygwin system.  If I start Bash, I can
> >> see a remove drive of a Windows Server mounted at /cygdrive/t/.
> >> So far, so good.
> >>
> >> Unfortunately I can't see this drive when logging in from a Linux
> >> machine via ssh.  I suspect the reason is that the drive is
> >> password protected, and the password is not my login password.
> >> Every time I log in (via the orinary Windows login screen) I have
> >> to enter that password.
> >>
> >> Can I put this password somewhere so that Cygwin can mount it,
> >> even when I'm accessing it from outside?  Thank you!
> >
> > Can't you just run "net use t: '\\MACHINE\SHARE' '*'" from the bash prompt
> > once you're logged in via ssh?
> > Igor
> 
> I translate the german error messages into English:
> 
> -bash-3.00$ net use t: '\\sonne\erde' '*'
> Enter password for \\sonne\erde : sytem error 85 occured.
> 
> The local device name is already in use.

You can't do that, the error says it all.  Just access the drive
using the network path //sonne/erde/...


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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/

ssh login and SMB drive

[Torsten Bronger]

Hallöchen!

I've running an sshd on a Cygwin system.  If I start Bash, I can see
a remove drive on a Windows Server mounted at /cygdrive/t/.  So far,
so good.

Unfortunately I can't see this drive when logging in from a Linux
machine via ssh.  I suspect the reason is that the drive is password
protected, and the password is not my login password.  Every time I
log in (via the orinary Windows login screen) I have to enter that
password.

Can I put this password somewhere so that Cygwin can mount it, even
when I'm accessing it from outside?  Thank you!

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646


--
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: gnu make causes reboot

[Gary R. Van Sickle]

Dude: The problem is a driver.  You can reinstall Windows as many times on
as many different partitions as you want, or you can update all your
drivers, yes, each and evry one of them, and solve your problem.  The second
option takes far less time, plus you solve your problem.  It's win-win.

Bonus hint: Norton Antivirus counts as both a driver and the cause of almost
every problem anybody has ever had with a computer, except for those caused
by all other anti-anything software.

-- 
Gary R. Van Sickle
 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of cc979.uk
> Sent: Saturday, February 11, 2006 5:47 AM
> To: cygwin@cygwin.com
> Subject: Re: gnu make causes reboot
> 
> 
> sorry about not attaching cygwin results
> 
> i've just installed windows on a new-partion
> 
> no outpost firewall or nod32 antivirus and cygwin works 
> perfectly, so i'm going install them one at a time and try 
> again do see what causes the bsod
> 
> 
> --
> View this message in context: 
> http://www.nabble.com/gnu-make-causes-reboot-t1102615.html#a2884464
> Sent from the Cygwin Users forum at Nabble.com.
> 
> 
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
> 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Need Help

[Nitin Mathur]

Hi,,

I am sorry for sending the previous post without any message. It was sent by
mistake.

I am facing a small problem. I have gcc 2.95 installed on my machine. I
cannot download the latest version or any other version of cygwin and gcc
because these are my company requirements. I have to work on this version of
gcc

When I try to compile any cpp file, the linker throws an error "cannot find
-lstdc++".

I tried to search the complete cygwin directory for the library. I could
find "libstdc++.a.2.10.0". I tried to rename this as stdc++.a but failed in
my attempt to get the file linked.

Can anybody help me in this regard ? I shall be really grateful.

I have attached the error message below the mail. 

Best regards,
Nitin Mathur,

C:\TEMP>g++ c3.cpp -Wall 
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/../../../../i686-pc-cygwin/bin/ld:
cannot find -lstdc++
collect2: ld returned 1 exit status

--
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/

Need Help

[Nitin Mathur]

Best regards
Nitin Mathur,

--
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: ssh login and SMB drive

[Torsten Bronger]

Hallöchen!

Igor Peshansky <[EMAIL PROTECTED]> writes:

> On Fri, 10 Feb 2006, Torsten Bronger wrote:
>
>> I've running an sshd on a Cygwin system.  If I start Bash, I can
>> see a remove drive of a Windows Server mounted at /cygdrive/t/.
>> So far, so good.
>>
>> Unfortunately I can't see this drive when logging in from a Linux
>> machine via ssh.  I suspect the reason is that the drive is
>> password protected, and the password is not my login password.
>> Every time I log in (via the orinary Windows login screen) I have
>> to enter that password.
>>
>> Can I put this password somewhere so that Cygwin can mount it,
>> even when I'm accessing it from outside?  Thank you!
>
> Can't you just run "net use t: '\\MACHINE\SHARE' '*'" from the bash prompt
> once you're logged in via ssh?
>   Igor

I translate the german error messages into English:

-bash-3.00$ net use t: '\\sonne\erde' '*'
Enter password for \\sonne\erde : sytem error 85 occured.

The local device name is already in use.

-bash-3.00$ ls -l /cygdrive/
total 0
drwxrwxrwx+ 13 Administratoren root 0 Jan 11 03:00 c
drwxrwxrwx+  4 Administratoren root 0 Jan 11 03:01 d
drwxrwxrwx+  6 Administratoren root 0 Jan 11 03:00 e
drwxr-xr-x   1 bronger Kein 0 Feb 10 13:04 h

Besides, I want to copy files from my Linux machine to this Windows
machine using rsync, tunneled trough ssh.  This fails due to the
missing drive.  However, the drive must already be there when rsync
logs in.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646


--
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: Another .bashrc Question

[Dave]

O. Olson wrote:

If I log in (either locally and remotely) I get the
bash prompt, but the .bashrc is not sourced. If I then
type “bash” on the command line then this file gets
sourced. 


`man bash`

Check the Invocation chapter. A (bash) login shell is not expected to 
source .bashrc, although it is commonly added to either /etc/profile or 
~/.bash_profile. IIRC the /etc/profile supplied by the basefiles package 
used to source .bashrc


Other invocations do source .bashrc directly. I won't attempt to 
summarise the detail here.


Dave.

--
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: gnu make causes reboot

[cc979.uk]

sorry about not attaching cygwin results

i've just installed windows on a new-partion

no outpost firewall or nod32 antivirus and cygwin works perfectly,
so i'm going install them one at a time and try again do see what causes the
bsod


--
View this message in context: 
http://www.nabble.com/gnu-make-causes-reboot-t1102615.html#a2884464
Sent from the Cygwin Users forum at Nabble.com.


--
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: make: rm: command not found

[Tim Prince]

At 08:40 AM 2/10/2006, JefV wrote:

--
View this message in context: 
http://www.nabble.com/make%3A-rm%3A-command-not-found-t1100243.html#a2873151

Sent from the Cygwin Users forum at Nabble.com.


--
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/



SPAM: -- Spamnix Spam Report --
SPAM: Spamnix identified this message as spam.
SPAM: Score: 52
SPAM: Action: Quarantine
SPAM: --- End of Spamnix Spam Report --


How many of us do you expect to be viewing your message with spam 
filtering off?



Tim Prince 



--
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/

Had to do my first rebaseall

[zzapper]

Hi,
Had to do my first rebaseall
when for no apparent reason my zsh failed (dll going potty) . Trouble is when 
my shell fails I'm
kinda stuck as so much of my knowledge depends on it.

Luckiliy I googled a cygwin posting where a Cygwin maintainer was fragging some 
guy for not
realising he needed to do a rebasell

Tip
You need to rebaseall from an ash shell with everything shutdown including CRON!

How come I've cygwined 4 so long without needing rebaseall
-- 
zzapper
Success for Techies and Vim,Zsh tips
http://SuccessTheory.com/


--
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/