On Sun, Jan 16, 2005 at 07:02:56PM -0800, David Christensen wrote:
> The documentation displayed by 'perldoc Pod::Usage' is malformed --
> the majority of the text between ARGUMENTS and EXAMPLES is bold, and
> if I exit less when the colon is bold, my terminal gets stuck in
> bold. 'reset' and 'cl
Cygwin:
Perl Pod::Usage pod2usage(-verbose => 0) is supposed to display the Pod SYNOPSIS
information (ref. 'perdoc Pod::Usage'). See attached script 'test0'. On Debian
3.0r2, it works:
[EMAIL PROTECTED]:~/cygwin-issues/Pod-Usage$ perl test0
Usage:
This is the synopsis...
On Cyg
Cygwin:
The documentation displayed by 'perldoc Pod::Usage' is malformed -- the majority
of the text between ARGUMENTS and EXAMPLES is bold, and if I exit less when the
colon is bold, my terminal gets stuck in bold. 'reset' and 'clear' don't fix
it.
I am unable to find this issue on the mailing
On Sun, 16 Jan 2005, Yitzchak Scott-Thoennes wrote:
> On Sun, Jan 16, 2005 at 08:13:43PM -0500, Christopher Faylor wrote:
> > On Mon, Jan 17, 2005 at 12:38:51AM +0100, Gerrit P. Haase wrote:
> > >>More to the point, what would "break" in the cygwin environment,
> > >
> > >Try to chmod 644 any dll
On Fri, Dec 10, 2004 at 04:36:28PM +0100, Reini Urban wrote:
> Yitzchak Scott-Thoennes schrieb:
> >On Thu, Dec 09, 2004 at 11:38:38PM +0100, Reini Urban wrote:
> >
> >>Jason Pearce schrieb:
> >>
> >>>Reini Urban wrote:
> >>>
> Maybe I'll come to the pending Win32::API problem with the callbacks
On Sun, Jan 16, 2005 at 08:13:43PM -0500, Christopher Faylor wrote:
> On Mon, Jan 17, 2005 at 12:38:51AM +0100, Gerrit P. Haase wrote:
> >>More to the point, what would "break" in the cygwin environment,
> >
> >Try to chmod 644 any dll and call a program that uses this dll. This
> >fails for me (o
On Sun, Jan 16, 2005 at 02:56:57PM -0800, linda w wrote:
> I was told I might fix the problem of typing in a partial command name
> like "cyg", and the command completion character and getting a long list
> of DLL's with a few EXE's thrown in.
>
> I had been told it could be fixed through adjustme
On Mon, Jan 17, 2005 at 12:38:51AM +0100, Gerrit P. Haase wrote:
>>More to the point, what would "break" in the cygwin environment,
>
>Try to chmod 644 any dll and call a program that uses this dll. This
>fails for me (on NT4 with NTFS), if it succeeds for you, fine. Change
>the permissions as yo
linda w wrote:
More to the point, what would "break" in the cygwin environment,
Try to chmod 644 any dll and call a program that uses this dll.
This fails for me (on NT4 with NTFS), if it succeeds for you, fine.
Change the permissions as you like it;)
Gerrit
--
=^..^=
--
Unsubscribe info: htt
Max Bowsher wrote:
linda w wrote:
Is there some reason cygwin needs to return DLL's as executables, as the
underlying OS doesn't require it (having no 'executable bit').
Wrong, actually the underlying OS *does* require it. It may not have
mode bits, but it does have ACLs.
Before calling me wrong,
On Jan 16 09:56, Yitzchak Scott-Thoennes wrote:
> On Sun, Jan 16, 2005 at 12:42:11PM -0500, Christopher Faylor wrote:
> > On Sun, Jan 16, 2005 at 09:35:09AM -0800, Yitzchak Scott-Thoennes wrote:
> > >With the 20050114 snapshot, chmod is updating a file's ctime. This
> > >didn't happen with the 200
On Jan 16 08:08, Bill Priest wrote:
> All,
> In trying to compile splint from cvs, I ran into
> the problem of __mode_t not being defined. Linux
Huh? I never heard about an application which needs __mode_t defined.
If you ask me, that's a bug in splint.
Corinna
--
Corinna Vinschen
On Sun, Jan 16, 2005 at 12:42:11PM -0500, Christopher Faylor wrote:
> On Sun, Jan 16, 2005 at 09:35:09AM -0800, Yitzchak Scott-Thoennes wrote:
> >With the 20050114 snapshot, chmod is updating a file's ctime. This
> >didn't happen with the 20050111 snapshot.
>
> Yes, AFAIK, this is correct behavio
On Sun, Jan 16, 2005 at 09:35:09AM -0800, Yitzchak Scott-Thoennes wrote:
>With the 20050114 snapshot, chmod is updating a file's ctime. This
>didn't happen with the 20050111 snapshot.
Yes, AFAIK, this is correct behavior, fixed, as mentioned here:
http://sources.redhat.com/ml/cygwin/2005-01/msg0
With the 20050114 snapshot, chmod is updating a file's ctime. This
didn't happen with the 20050111 snapshot.
$ cat ctime.sh
touch foo.$$
sleep 70
ls -l foo.$$
ls -lc foo.$$
chmod 0644 foo.$$
ls -l foo.$$
ls -lc foo.$$
$ uname -a
CYGWIN_NT-5.1 DHX98431 1.5.13s(0.117/4/2) 20050114 01:55:54 i686 un
All,
In trying to compile splint from cvs, I ran into
the problem of __mode_t not being defined. Linux
defines it in types.h so that is where I put it.
Splint built w/o problems after this change;
unfortunately the bug I was hoping would be fixed in
CVS wasn't :(
Unified diff follows:
diff -u
On Sun, Jan 16, 2005 at 09:11:42AM +, Adrian Cox wrote:
>I'm interested in failures that would still occur if the two cygwin
>DLLs used different shared memory regions and registry keys.
You can satisfy your curiousity. Remember this?
http://sources.redhat.com/ml/cygwin/2005-01/msg00730.html
On Sat, 2005-01-15 at 19:42 -0500, Arturus Magi wrote:
> Adrian Cox wrote:
>
> > So what are the other problems?
>
> Programs picking up the wrong version of the DLL and failing with little
> or no explanation available to the user (whom will, likely as not, fail
> to provide a useful report
On Jan 15 08:17, [EMAIL PROTECTED] wrote:
> Seems to me we ought to see if we can't update the symlink() impl such that
> this is addressed. I'm betting there's some new attributes or whatever (as
> Igor notes) that've been added to symlinks in XP and if we can figure out
> what
> that is, and
linda w wrote:
Is there some reason cygwin needs to return DLL's as executables, as the
underlying OS doesn't require it (having no 'executable bit').
Wrong, actually the underlying OS *does* require it. It may not have mode
bits, but it does have ACLs.
Max.
--
Unsubscribe info: http://cygwi
20 matches
Mail list logo
