Re: [patch] cygport-0.2.7 mixed-mode SRC_URIs

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Charles Wilson wrote:
> ...and allow the new PATCH_URI in cygport-0.2.7 to work when main src is
> in CVS|SVN|GIT repo.  (At present, in 0.2.7, PATCH_URI is ignored if
> inherit cvs|svn|git).

True, only because I haven't yet had such a case.

> With this patch, SRC_URI can contain multiple entries.  All SRC_URI
> entries *except the first*, and all PATCH_URIs, can only be downloaded
> from the internet via mirror|ftp|http|https protocols.  If the "extra"
> SRC_URIs or any PATCH_URIs contain a "protocol://" prefix other than
> those listed, it is an error.  If any "extra" SRC_URIs or PATCH_URIs do
> not contain a "protocol://" prefix, they are ignored (e.g. no attempt is
> made to fetch them, and no error is reported).

Could you provide a sample .cygport (and .src.patch if necessary) which
I could use for testing this feature?  (In general, for these major
patches this would be helpful.)

> NOTE:
> If SRC_URI is to contain multiple entries, and a cvs repo (or svn, or
> git) is used for the first one, then in the .cygport file SRC_URI must
> be defined AFTER 'inherit cvs' (or svn, or git) is invoked.

Of course.


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFp1ZipiWmPGlmQSMRCAv1AJ4sMN7Zaqkjs3RLOUUOmzt4jZpY+ACdFEpy
PfRY7bOPkHnz3dkGXz3Y2U0=
=MRsT
-END PGP SIGNATURE-

--
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: [patch] cygport-0.2.7 hooks for additional prep, install customization

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Charles Wilson wrote:
> [implementation details]
> [1] Possibiliyt: remove the readonly protection on the existing,
> internal, automation functions (like __prep_installdir or src_prep).
> This is a really bad idea: some of these functions (especially the __*
> ones) are NOT part of cygport's public interface, and are subject to
> change in later releases -- a .cygport file that redefines these is
> brittle with respect to future releases of the cygport framework.

Exactly why they must be marked readonly.

> Others, like src_prep(), are large, complicated, and must NOT be changed
> in any appreciable way, because other functions in cygport depend on
> stuff being "just so".  .cygport files that redefine these functions
> will ALSO be brittle -- and worse, could break things with respect to
> later cygport framework releases that are hard to identify.  Finally,
> carrying around duplicate copies (one in cygport itself, the other in
> the .cygport file) with only minor difference is a silly waste. IMNSHO.

src_prep is not a public interface function either.  I should go through
and rename this and perhaps other functions so that it's clear what's
public API.  (Of course, if cygport were better documented...)

> [2] Possibility: supply additional customization/extension points to
> allow the end user more flexibility to customize certain aspects of the
> automated "tedious steps" when necessary.  Without, mind you, obligating
> .cygport files to carry around lots of redundant copies of functions
> defined in the main cygport framework, nor overriding functions which
> are *supposed* to be internal implementation details of the cygport
> framework itself.

Could you please provide a sample .cygport showing what would be
accomplished with this?

> Obviously, I prefer [2], which is implemented below for the prep and
> install stages.

Refresh my memory, what is the need for the src_install hooks?


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFp1nepiWmPGlmQSMRCLOUAKDwQzHJQs4krbWDkTxeO0o1nXSStgCcCwud
/PHtARBeISQwuKqxH1dkPMw=
=PgnP
-END PGP SIGNATURE-

--
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: Snapshot speed on managing files

[Corinna Vinschen]

On Jan 11 13:14, Marco atzeri wrote:
> Hi All,
> I have found non specific info on the faq and
> documentation, so I am wondering if there is 
> any specific "debugging" reason to explain why
> latest snapshots 20070110 (and 04) are substantial 
> slower than 1.5.23-2 on removing multiple files.

FAQ and docs don't refer to snapshots, rather to the release.

Current CVS contains a change which is probably the cause for that.
Before deleting a file, the file is moved to the recycle bin.

The idea is to allow POSIX semantics.  A file which is in use by another
application can be deleted.  However, as long as the file is in use,
it's visible in directory listings.  There are POSIX applications which
treat the existence of the file as a failure in removing the file.  One
step further, there are applications which expect to be able to remove
the parent directory, which is also not possible as long as this file is
still in use.

To overcome this problem the file is moved to the recycle bin in
unlink(2), so that it disappears from it's original directory,
regardless whether it's still in use or not.  I tried to do this as
quick as possible but there's obviously some room for optimization.


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/

Re: cygwin 1.5.23-2 : CREAD termios option don't work

[Corinna Vinschen]

On Jan 11 16:53, Florent Morin wrote:
> Hello,
> 
> I actually develop a program in C for reading and writing data on
> serial port. It works fine on GNU/Linux. I now test it with cygwin
> (Windows XP).
> 
> I begin to set the port options, then I read/write information and
> restore port settings. I can write on serial port but can't read.
> 
> For testing, I have tried with a working program : stty. It works fine
> with all options, but not with CREAD.
> 
> $ stty cread < /dev/ttyS0
> stty: /dev/ttyS0: unable to perform all requested operations
> 
> Can someone explain this ?

Please consider to debug this yourself.  Cygwin has no volunteer which
is fluent with serial I/O right now.


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/

RE: CR/LF problems after upgrade

[Buchbinder, Barry \(NIH/NIAID\) [E]]

From: Luke Kendall
> 
> I wonder how many centuries of human endeavour has been
> absorbed because of the decision to use CR+LF as line
> endings in DOS?
> 


To be fair, \r\n seems to go back to Gary Kildall's CP/M.
http://en.wikipedia.org/wiki/Unprintable_characters


--
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: activestate perl on cygwin

[Kevin T Cella]

> [snip] but the point of this little story is that you
> are short sighted if you believe that the only platform you'll
> encounter and thus need to deal with is Windows...

I agree completely. This is for personal use.

> As has been pointed out to you already there is Win32 modules for
> Cygwin's Perl.

Sorry, I missed that.

> Although this is thorough off topic, perhaps you can explain it better
> to me as I don't use ActiveState therefore I don't see what you are
> claiming. Exactly which "full path" is expanded to "what" and passed to
> (guess) ActiveState Perl interpreter as, again, what? Is it $0 that you
> speak of that may be a Cygwin path? I'm confused however if it is $0
> then why couldn't that also be handled in the Perl script?

The error is as follows:

[~] $ myscript.pl 
Can't open perl script "/home/kcella/bin/myscript.pl": No such file or
directory

[~] $ ls -l /home/kcella/bin/myscript.pl 
-rwxr-xr-x 1 kcella None 651 Jan 12 07:33 /home/kcella/bin/myscript.pl


--
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: command line arg expansion

[jim]

Thanks Larry.   I had seen that option, but nothing to indicate that it had
changed between 1.5.12 and 1.5.23. Can anyone account for the difference
between these two versions?What I'm actually seeing is a behavior change
in a perl script that does something like:

open(LS, "ls -dF1 /c* | grep '/.*/' |");

One way to fix this is wrap it with bash, but I'd like to understand exactly
what changed.Replacing grep with the program below showed me a
difference in the wild card expansion and that lead to the assumption that
wild cards are expanded differently - maybe it's something else?

thanks for any insight,
jim 

> -Original Message-
> From: Larry Hall (Cygwin) [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, January 11, 2007 12:37 PM
> To: cygwin@cygwin.com
> Subject: Re: command line arg expansion
> 
> jim wrote:
> > I have recently upgraded from 1.5.12 to 1.5.23 and noticed 
> something that
> > has me wondering.I compiled this on 1.5.23 and have run 
> it under cmd.exe
> > on on 1.5.12 and 1.5.23:
> > 
> > #include 
> > 
> > int main(int argc, char *argv[])
> > {
> >int i, c;
> > 
> >for (i = 0; i < argc; i++)
> >   printf("arg[%d]: '%s'\n", i, argv[i]); }
> > 
> > On 1.5.12:
> > C:\>e '/.*/'
> > arg[0]: 'e'
> > arg[1]: '/.*/'
> > 
> > On 1.5.23:
> > C:\>e '/.*/'
> > arg[0]: 'e'
> > arg[1]: '/../'
> > arg[2]: '/./'
> > arg[3]: '/.other/'
> > 
> > It appears that the runtime initialization on 1.5.23 is 
> doing command line
> > expansion - is this correct?   If so, is this change 
> documented somewhere so
> > I get the full explanation?
> 
> See .  
> Look for the "(no)glob" explanation.
> 
> -- 
> Larry Hall  http://www.rfk.com
> RFK Partners, Inc.  (508) 893-9779 - RFK Office
> 216 Dalton Rd.  (508) 893-9889 - FAX
> Holliston, MA 01746
> 
> _
> 
> A: Yes.
>  > Q: Are you sure?
>  >> A: Because it reverses the logical flow of conversation.
>  >>> Q: Why is top posting annoying in email?
> 



--
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: activestate perl on cygwin

[Andrew DeFaria]

Kevin T Cella wrote:
[snip] but the point of this little story is that you are short 
sighted if you believe that the only platform you'll encounter and 
thus need to deal with is Windows...

I agree completely. This is for personal use.

What does that matter? It's still short sited.
Although this is thorough off topic, perhaps you can explain it 
better to me as I don't use ActiveState therefore I don't see what 
you are claiming. Exactly which "full path" is expanded to "what" and 
passed to (guess) ActiveState Perl interpreter as, again, what? Is it 
$0 that you speak of that may be a Cygwin path? I'm confused however 
if it is $0 then why couldn't that also be handled in the Perl script?

The error is as follows:

[~] $ myscript.pl
Can't open perl script "/home/kcella/bin/myscript.pl": No such file or
directory

[~] $ ls -l /home/kcella/bin/myscript.pl
-rwxr-xr-x 1 kcella None 651 Jan 12 07:33 /home/kcella/bin/myscript.pl
And what does #! look like? (And I'll ask for completion's sake as you 
never seems to be thorough nor accurate in your answers), what does ls 
 return? Oh and what is PATH set to? 
And while we're at it, what is the exact path of the program  you wanted 
to be executed (i.e. C:\Perl\bin\perl.exe?).

--
Andrew DeFaria 
Ever wonder what the speed of lightning would be if it didn't zigzag?


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

[Frodak]

< - Original Message 
< From: Gmane User
< To: cygwin
< Sent: Friday, January 12, 2007 1:16:32 AM
< Subject: Re: "cscope -d" can't find trailer offset if path contains space
< 
< By the way, Dave, if you're going to be poking & prodding mlscope, I was
< wondering if you might have time to look at a problem with its interface
< with vim.  Mlscope works find from the command line, but simply hangs
< when I do a symbol search from within vim.  Vim works fine with
< non-ml-cscope, however.  I believe I read in the cygwin archives that it
< had to do with the format of the records returned by the mlscope search.
< Thanks if you can spare the time to look at it.  Otherwise, thanks for
< the thought.

Refer to the following tip:

http://www.vim.org/tips/tip.php?tip_id=1362

--
Frodak





 

Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

--
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: Snapshot speed on managing files

[Lev Bishop]

On 1/12/07, Corinna Vinschen wrote:


To overcome this problem the file is moved to the recycle bin in
unlink(2), so that it disappears from it's original directory,
regardless whether it's still in use or not.  I tried to do this as
quick as possible but there's obviously some room for optimization.


Corinna, I'm sure you thought about this already, but I thought I'd
check. Does this patch make sure to move the file to the recycle bin
on the same filesystem as the original file? So that it is really a
rename (fast), rather than a move (slow). Does it do something to
limit the number of files in a single subdirectory of the recycle bin?
(Might get slow once there are too many, especially on non-NTFS. If
not, might this be the cause of the problem the OP is having?).

Lev

--
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: Snapshot speed on managing files

[Corinna Vinschen]

On Jan 12 09:24, Lev Bishop wrote:
> On 1/12/07, Corinna Vinschen wrote:
> 
> >To overcome this problem the file is moved to the recycle bin in
> >unlink(2), so that it disappears from it's original directory,
> >regardless whether it's still in use or not.  I tried to do this as
> >quick as possible but there's obviously some room for optimization.
> 
> Corinna, I'm sure you thought about this already, but I thought I'd
> check. Does this patch make sure to move the file to the recycle bin
> on the same filesystem as the original file?

Yes.  See syscalls.cc, function unlink_nt and function try_to_bin.

>  Does it do something to
> limit the number of files in a single subdirectory of the recycle bin?

No, but 99% of the files are deleted immediately anyway.  Only the files
in use by another application will hang around until they are not used
anymore.  After all, this is the unlink function.


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/

RE: activestate perl on cygwin

[moka]

Kevin wrote:
>I still
>have no way to execute the command below and a regular script on cygwin
>using Activestate.
Well, I run perl scripts on cygwin with no problem. Did not do anything special,
except
make sure NOT to install perl when installing cygwin(and making sure
 the activestate perl is in the path)


--
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: command line arg expansion

[Larry Hall (Cygwin)]

.  Reformatted.

jim wrote:

-Original Message-
From: Larry Hall (Cygwin) [mailto:reply-to-list-only-lh  cygwin  com] 
Sent: Thursday, January 11, 2007 12:37 PM

To: cygwin  cygwin  com

  ^^^
.  No one wants the spam.  Thanks.


Subject: Re: command line arg expansion

jim wrote:
I have recently upgraded from 1.5.12 to 1.5.23 and noticed 

something that
has me wondering.I compiled this on 1.5.23 and have run 

it under cmd.exe

on on 1.5.12 and 1.5.23:

#include 

int main(int argc, char *argv[])
{
   int i, c;

   for (i = 0; i < argc; i++)
  printf("arg[%d]: '%s'\n", i, argv[i]); }

On 1.5.12:
C:\>e '/.*/'
arg[0]: 'e'
arg[1]: '/.*/'

On 1.5.23:
C:\>e '/.*/'
arg[0]: 'e'
arg[1]: '/../'
arg[2]: '/./'
arg[3]: '/.other/'

It appears that the runtime initialization on 1.5.23 is 

doing command line
expansion - is this correct?   If so, is this change 

documented somewhere so

I get the full explanation?
See .  
Look for the "(no)glob" explanation.

Thanks Larry.   I had seen that option, but nothing to indicate that it had
changed between 1.5.12 and 1.5.23. Can anyone account for the difference
between these two versions?What I'm actually seeing is a behavior change
in a perl script that does something like:

open(LS, "ls -dF1 /c* | grep '/.*/' |");

One way to fix this is wrap it with bash, but I'd like to understand exactly
what changed.Replacing grep with the program below showed me a
difference in the wild card expansion and that lead to the assumption that
wild cards are expanded differently - maybe it's something else?


You may want to look at Perl too.  Obviously, there's a difference between
the command line and the operations in Perl but you may not be chasing the
same problem by looking at the command line issue.

Off-hand, I don't recall a conscious change here.  The glob option has been
there "forever" so if you see a difference in 1.5.12 vs now, I'd say it's
fair to assume that the 1.5.12 behavior indicates a bug that has since been
fixed.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: gcc: installation problem, cannot exec 'cc1'

[Larry Hall (Cygwin)]

Thomas Antony wrote:

Hello,
   Come to think of it, I had removed the read only stuff when it
drove me nuts with silly errors when I tried to delete or move files.
But not on C drive. Anyway, I removed those links using the script you
said and reinstalled. Now ls lists them correctly

$ ls -l /usr/lib/gcc/i686-pc-mingw32/3.4.4/
total 1234
lrwxrwxrwx  1 Tom None   34 Jan 12 09:34 cc1.exe -> 
../../i686-pc-cygwin/3.4

.4/cc1.exe
lrwxrwxrwx  1 Tom None   38 Jan 12 09:32 cc1plus.exe -> 
../../i686-pc-cygwin

/3.4.4/cc1plus.exe
lrwxrwxrwx  1 Tom None   39 Jan 12 09:34 collect2.exe -> 
../../i686-pc-cygwi

n/3.4.4/collect2.exe
-rwxr-xr-x  1 Tom None  412 May 24  2005 crtbegin.o
-rwxr-xr-x  1 Tom None  492 May 24  2005 crtend.o
drwxrwxr--+ 2 Tom Users   0 Jan 12 09:32 debug
drwxrwxr--+ 3 Tom Users   0 Jan 12 09:34 include
drwxrwxr--+ 3 Tom Users   0 Jan 12 09:34 install-tools
-rwxr-xr-x  1 Tom None52594 May 24  2005 libgcc.a
-rwxr-xr-x  1 Tom None 9772 May 24  2005 libgcov.a
-rwx--+ 1 Tom None  1063604 May 24  2005 libstdc++.a
-rwx--+ 1 Tom None  685 May 24  2005 libstdc++.la
-rwx--+ 1 Tom None   116074 May 24  2005 libsupc++.a
-rwx--+ 1 Tom None  685 May 24  2005 libsupc++.la
lrwxrwxrwx  1 Tom None   32 Jan 12 09:34 specs -> 
../../i686-pc-cygwin/3.4.4

/specs

But now, while compiling I get the error
$ gcc -mno-cygwin -o hello hello.c
/usr/bin/ld: crt2.o: No such file: No such file or directory
collect2: ld returned 1 exit status

??

Now what?




Is crt2.o in /usr/lib/mingw?  Does it look OK?


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

dos format shell script executed fine with 1.5.12, fails with 1.5.23

[jim]

I have a dos format file containing a shell script that works fine on
1.5.12.   After upgrading to 1.5.23, the script fails.   If I convert it to
Unix format, it works fine with 1.5.23, but I'm wondering what changed.
Cygwin mounts are the same; what else could be different?

thanks for any insight,
jim



--
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: dos format shell script executed fine with 1.5.12, fails with 1.5.23

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to jim on 1/12/2007 9:14 AM:
> I have a dos format file containing a shell script that works fine on
> 1.5.12.   After upgrading to 1.5.23, the script fails.   If I convert it to
> Unix format, it works fine with 1.5.23, but I'm wondering what changed.
> Cygwin mounts are the same; what else could be different?

When you upgraded cygwin, you probably also upgraded bash.  Read the
release announcements.

http://cygwin.com/ml/cygwin-announce/2006-12/msg00026.html

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFp7YL84KuGfSFAYARAn5eAJ9iJmGS26rEMisOqFItR9P1V/NlWgCgkSLg
1HakidQke/SMQ5Qmero1+KE=
=H/Ga
-END PGP SIGNATURE-

--
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: dos format shell script executed fine with 1.5.12, fails with 1.5.23

[Larry Hall (Cygwin)]

jim wrote:

I have a dos format file containing a shell script that works fine on
1.5.12.   After upgrading to 1.5.23, the script fails.   If I convert it to
Unix format, it works fine with 1.5.23, but I'm wondering what changed.
Cygwin mounts are the same; what else could be different?





--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: dos format shell script executed fine with 1.5.12, fails with 1.5.23

[Matthew Woehlke]

jim wrote:

I have a dos format file containing a shell script that works fine on
1.5.12.   After upgrading to 1.5.23, the script fails.   If I convert it to
Unix format, it works fine with 1.5.23, but I'm wondering what changed.
Cygwin mounts are the same; what else could be different?


Bash could be different. Did you update bash also? Did you read the 
Release Notes?


--
Matthew
"Stop that, it's silly!" -- Colonel
(Monty Python, "And Now For Something Completely Different")


--
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: dos format shell script executed fine with 1.5.12, fails with 1.5.23

[Brian Dessent]

jim wrote:

> I have a dos format file containing a shell script that works fine on
> 1.5.12.   After upgrading to 1.5.23, the script fails.   If I convert it to
> Unix format, it works fine with 1.5.23, but I'm wondering what changed.
> Cygwin mounts are the same; what else could be different?

The version of the Cygwin DLL here is totally irrelevant.  When you
updated the cygwin package you also updated the bash package, and the
change you are seeing is a result of changes in the bash package. 
Please consult the bash package announcement emails.  There have
probably been hundreds of emails in dozens of threads on this particular
issue over the last 6 months or so, so please take a chance to read all
those before bringing up a topic that has been beaten to death, revived,
and then beaten again.

Brian

--
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: Snapshot speed on managing files

[Brian Ford]

On Fri, 12 Jan 2007, Corinna Vinschen wrote:

> Current CVS contains a change which is probably the cause for that.
> Before deleting a file, the file is moved to the recycle bin.

Couldn't we make this conditional only if a "regular" delete fails because
the file is in use?  Would it then only penalize deletes of open files?

(Incidentally, I've noticed this as well.)

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...



--
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: activestate perl on cygwin

[Igor Peshansky]

On Fri, 12 Jan 2007, Kevin T Cella wrote:

> > Although this is thorough off topic, perhaps you can explain it better
> > to me as I don't use ActiveState therefore I don't see what you are
> > claiming. Exactly which "full path" is expanded to "what" and passed to
> > (guess) ActiveState Perl interpreter as, again, what? Is it $0 that you
> > speak of that may be a Cygwin path? I'm confused however if it is $0
> > then why couldn't that also be handled in the Perl script?
>
> The error is as follows:
>
> [~] $ myscript.pl
> Can't open perl script "/home/kcella/bin/myscript.pl": No such file or
> directory
>
> [~] $ ls -l /home/kcella/bin/myscript.pl
> -rwxr-xr-x 1 kcella None 651 Jan 12 07:33 /home/kcella/bin/myscript.pl

That particular case is handled by the wrapper script I posted.  Note that
you *don't* need to use the wrapper script to invoke perl on the command
line -- only in the #! (shebang) line of your script file.
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!

Freedom is just another word for "nothing left to lose"...  -- Janis Joplin

--
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: Snapshot speed on managing files

[Corinna Vinschen]

On Jan 12 10:34, Brian Ford wrote:
> On Fri, 12 Jan 2007, Corinna Vinschen wrote:
> 
> > Current CVS contains a change which is probably the cause for that.
> > Before deleting a file, the file is moved to the recycle bin.
> 
> Couldn't we make this conditional only if a "regular" delete fails because
> the file is in use?  Would it then only penalize deletes of open files?

It wouldn't work.  The problem is that the delete does not fail.  Just
the file does not disappear.  And if you deleted the file and *then*
notice that it didn't disappear, Windows does not allow you to move
it anymore.  So, either you move it right before deleting, or you're
stuck.

Two points, though:

- P's to speed up the code are TC ;)
- If somebody figures out a way to learn if a file has opened handles on
  it, quick and maybe in native NT code, I'd be most grateful.


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/

Re: Snapshot speed on managing files

[Brian Ford]

Thanks for the explanation.

On Fri, 12 Jan 2007, Corinna Vinschen wrote:

> - P's to speed up the code are TC ;)

I'll look when I can, but since you mentioned "there's obviously some room
for optimization", could you state the obvious as a lead for someone who
has the time?

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...



--
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: cygwin 1.5.23-2 : CREAD termios option don't work

[Brian Ford]

On Fri, 12 Jan 2007, Corinna Vinschen wrote:
> On Jan 11 16:53, Florent Morin wrote:
> > For testing, I have tried with a working program : stty. It works fine
> > with all options, but not with CREAD.
> >
> > $ stty cread < /dev/ttyS0
> > stty: /dev/ttyS0: unable to perform all requested operations
> >
> > Can someone explain this ?
>
> Please consider to debug this yourself.  Cygwin has no volunteer which
> is fluent with serial I/O right now.

This is not a regression from 1.5.18, which I know worked fine with serial
I/O.  I will try to test 1.5.23 when I get a chance, but I have no reason
to suspect it is broken.

CREAD appears to always be enabled but not indicated by tcgetattr or
controllable via tcsetattr right now.  So, the test case above is not
indicative of the original problem.

To the OP, posting your code might be informative.

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...



--
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: Snapshot speed on managing files

[Dave Korn]

On 12 January 2007 19:31, Corinna Vinschen wrote:

> - If somebody figures out a way to learn if a file has opened handles on
>   it, quick and maybe in native NT code, I'd be most grateful.

  If you just want a boolean any/none answer, you can try opening it
exclusively.  Or do you need to know how many or other properties about them?
 

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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: Snapshot speed on managing files

[Corinna Vinschen]

On Jan 12 13:39, Brian Ford wrote:
> Thanks for the explanation.
> 
> On Fri, 12 Jan 2007, Corinna Vinschen wrote:
> 
> > - P's to speed up the code are TC ;)
> 
> I'll look when I can, but since you mentioned "there's obviously some room
> for optimization", could you state the obvious as a lead for someone who
> has the time?

I guess I haven't expressed myself quite right.  Actually I meant to
say there's some *need*" for optimization.  Looking into the code I
currently don't see how to optimize it, either.  I just hope that
somebody else, not wearing the Cygwin blinkers, may have a good idea.


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/

Re: Snapshot speed on managing files

[Corinna Vinschen]

On Jan 12 19:52, Dave Korn wrote:
> On 12 January 2007 19:31, Corinna Vinschen wrote:
> 
> > - If somebody figures out a way to learn if a file has opened handles on
> >   it, quick and maybe in native NT code, I'd be most grateful.
> 
>   If you just want a boolean any/none answer, you can try opening it
> exclusively.  Or do you need to know how many or other properties about them?

Er... no, no?  You're trying to tell me it's THAT simple?  That's it,
really?  Did I just write something about blinkers?


Time for the weekend I guess,
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/

Re: Snapshot speed on managing files

[Karl M]

So you would open it, delete it and then close it...to avoid races?

...Karl


From: Corinna Vinschen To: cygwin@cygwin.com
Subject: Re: Snapshot speed on managing files
Date: Fri, 12 Jan 2007 20:59:42 +0100

On Jan 12 19:52, Dave Korn wrote:
> On 12 January 2007 19:31, Corinna Vinschen wrote:
>
> > - If somebody figures out a way to learn if a file has opened handles 
on

> >   it, quick and maybe in native NT code, I'd be most grateful.
>
>   If you just want a boolean any/none answer, you can try opening it
> exclusively.  Or do you need to know how many or other properties about 
them?


Er... no, no?  You're trying to tell me it's THAT simple?  That's it,
really?  Did I just write something about blinkers?


Time for the weekend I guess,
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/



_
From photos to predictions, The MSN Entertainment Guide to Golden Globes has 

it all. http://tv.msn.com/tv/globes2007/?icid=nctagline1


--
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: Snapshot speed on managing files

[Dave Korn]

On 12 January 2007 20:00, Corinna Vinschen wrote:

> On Jan 12 19:52, Dave Korn wrote:
>> On 12 January 2007 19:31, Corinna Vinschen wrote:
>> 
>>> - If somebody figures out a way to learn if a file has opened handles on
>>>   it, quick and maybe in native NT code, I'd be most grateful.
>> 
>>   If you just want a boolean any/none answer, you can try opening it
>> exclusively.  Or do you need to know how many or other properties about
>> them? 
> 
> Er... no, no?  You're trying to tell me it's THAT simple? 

  No, I was asking you why that /isn't/ the answer.  

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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: Snapshot speed on managing files

[Corinna Vinschen]

On Jan 12 20:12, Dave Korn wrote:
> On 12 January 2007 20:00, Corinna Vinschen wrote:
> 
> > On Jan 12 19:52, Dave Korn wrote:
> >> On 12 January 2007 19:31, Corinna Vinschen wrote:
> >> 
> >>> - If somebody figures out a way to learn if a file has opened handles on
> >>>   it, quick and maybe in native NT code, I'd be most grateful.
> >> 
> >>   If you just want a boolean any/none answer, you can try opening it
> >> exclusively.  Or do you need to know how many or other properties about
> >> them? 
> > 
> > Er... no, no?  You're trying to tell me it's THAT simple? 
> 
>   No, I was asking you why that /isn't/ the answer.  

I don't know.  I'm busy enough being embarrassed that this idea never
occured to me while I implemented the new unlink.


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/

Re: "cscope -d" can't find trailer offset if path contains space

[Gmane User]

Frodak wrote:
> < - Original Message 
> < From: Gmane User
> < To: cygwin
> < Sent: Friday, January 12, 2007 1:16:32 AM
> < Subject: Re: "cscope -d" can't find trailer offset if path contains space
> < 
> < By the way, Dave, if you're going to be poking & prodding mlscope, I was
> < wondering if you might have time to look at a problem with its interface
> < with vim.  Mlscope works find from the command line, but simply hangs
> < when I do a symbol search from within vim.  Vim works fine with
> < non-ml-cscope, however.  I believe I read in the cygwin archives that it
> < had to do with the format of the records returned by the mlscope search.
> < Thanks if you can spare the time to look at it.  Otherwise, thanks for
> < the thought.
> 
> Refer to the following tip:
> 
> http://www.vim.org/tips/tip.php?tip_id=1362

Thanks, Frodak.  I'll keep that in my back pocket for the time being, as
I already have non-ml-cscope  running.  I recall that figuring out
patches and compiling gvim on solaris nonadmin account.  From different
patching methods, compatibility, and the various options for building
gvim, I get the impression that such a exploratory/learning step is
undertaken when one has a sizable chunk of time (though it will probably
more smoothly in the cygwin environment).  But thanks for pointing out
that option.


--
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-host-config patch

[Miguel A. Figueroa-Villanueva]

Hello Everyone,

When configuring sshd host with the ssh-host-config script I got
errors from the chown commands at the end of the script. The reason is
that my /etc/group file sets S-1-5-32-544 to 0 not 544 (my
passwd/group files are printed below). I think the following patch is
appropriate so that this case can be handled.

--- /usr/bin/ssh-host-config2006-11-08 05:09:58.00100 -0400
+++ ./ssh-host-config   2007-01-12 17:36:47.928733500 -0400
@@ -586,12 +586,18 @@ then
  else
   _user="system"
  fi
+  _group=`awk -F: '{if ( $2 == "S-1-5-32-544" ) print $1;}'
${SYSCONFDIR}/group`
+  if [ -z "${_group}" ]
+  then
+echo "${SYSCONFDIR}/group contains no group with SID
S-1-5-32-544 (Local administrators group)."
+exit 1
+  fi
  chown "${_user}" ${SYSCONFDIR}/ssh*
-  chown "${_user}".544 ${LOCALSTATEDIR}/empty
-  chown "${_user}".544 ${LOCALSTATEDIR}/log/lastlog
+  chown "${_user}"."${_group}" ${LOCALSTATEDIR}/empty
+  chown "${_user}"."${_group}" ${LOCALSTATEDIR}/log/lastlog
  if [ -f ${LOCALSTATEDIR}/log/sshd.log ]
  then
-   chown "${_user}".544 ${LOCALSTATEDIR}/log/sshd.log
+   chown "${_user}"."${_group}" ${LOCALSTATEDIR}/log/sshd.log
  fi
fi
if ! ( mount | egrep -q 'on /(|usr/(bin|lib)) type system' )

I also had problems starting the deamon because /var/log/sshd.log was
not created and 'system' did not have write permissions to /var/log. I
don't know what is the best solution to this... should /var/log be
go+w? If not then I think there should be something like this in the
sshd-host-config script:

if [ ! -e ${LOCALSTATEDIR}/log/sshd.log ]
then
 cat /dev/null > ${LOCALSTATEDIR}/log/sshd.log
 chmod 644 ${LOCALSTATEDIR}/log/sshd.log
fi

This way when it is chown at the end the deamon will be able to modify it.

Thanks,
--Miguel

/etc/passwd:
==
everyone:*:1:1:U-HOME_DESKTOP\Everyone,S-1-1-0:/home/everyone:/usr/bin/false
system:*:18:18:U-HOME_DESKTOP\SYSTEM,S-1-5-18:/home/system:/usr/bin/false
admins:*:544:0:U-HOME_DESKTOP\Administrators,S-1-5-32-544:/home/admins:/usr/bin/false
root:unused_by_nt/2000/xp:0:0:U-HOME_DESKTOP\Administrator,S-1-5-21-1935655697-412668190-682003330-500:/home/root:/usr/bin/bash
guelo:unused_by_nt/2000/xp:1004:545:U-HOME_DESKTOP\Guelo,S-1-5-21-1935655697-412668190-682003330-1004:/home/guelo:/usr/bin/bash
ileana:unused_by_nt/2000/xp:1005:545:U-HOME_DESKTOP\Ileana,S-1-5-21-1935655697-412668190-682003330-1005:/home/
ileana:/usr/bin/bash
sshd:unused_by_nt/2000/xp:1010:513:sshdprivsep,U-HOME_DESKTOP\sshd,S-1-5-21-1935655697-412668190-682003330-1010:/var/empty:/bin/false

/etc/group:

root:S-1-5-32-544:0:
system:S-1-5-18:18:
users:S-1-5-32-545:545:
powusers:S-1-5-32-547:547:
domusers:S-1-5-21-1935655697-412668190-682003330-513:513:


--
Miguel A. Figueroa Villanueva
+1 787 832-4040 x.3498
Departamento de Ingeniería Eléctrica y Computadoras
Universidad de Puerto Rico - Recinto de Mayagüez

--
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: cygwin support for shared objects (modules)

[Casey]

InspIRCd has replied back -- InspIRCd need the ability to use dlopen and 
dlclose and the method on cygwin for accessing it doesn't work properly 
at current for InspIRCd and just segfaults.


I was wondering if cygwin will have the support for this coming up?


- Casey

--
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: cygwin support for shared objects (modules)

[Christopher Faylor]

On Sat, Jan 13, 2007 at 08:38:26AM +1000, Casey wrote:
>InspIRCd has replied back -- InspIRCd need the ability to use dlopen and 
>dlclose and the method on cygwin for accessing it doesn't work properly 
>at current for InspIRCd and just segfaults.
>
>I was wondering if cygwin will have the support for this coming up?

Cygwin supports dlopen and dlclose and has for a long long time.

If something is segfaulting it needs to be debugged.  Pointing fingers
at Cygwin and saying "It's their fault", while it may well be true, is
not going to get the problem fixed.

So, unless you or someone wants to do some debugging of the problem
there is no chance that the problem will be fixed whether it is in
Cygwin or InspIRCd.

cgf

--
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: activestate perl on cygwin

[Kevin T Cella]

> That particular case is handled by the wrapper script I posted.  Note
> that
> you *don't* need to use the wrapper script to invoke perl on the
> command
> line -- only in the #! (shebang) line of your script file.

I know. Thanks. I was just trying to oblige the request from Mr. DeFaria.


--
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: activestate perl on cygwin

[Kevin T Cella]

> Well, I run perl scripts on cygwin with no problem. Did not do anything
> special,
> except
> make sure NOT to install perl when installing cygwin(and making sure
>  the activestate perl is in the path)

I tried this, but it still does not work.


--
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: activestate perl on cygwin

[Kevin T Cella]

> What does that matter? It's still short sited.

Yes, I don't disagree. Personally I do not care. I will deal with
having to port something when it happens.

> And what does #! look like?

#! /usr/bin/perl

> what does ls portion after #! in your script return?

Before the conversion using cygpath, it returns the same as
in the error: /home/kcella/bin/myscript.pl

But I think, there is some confusion here. My script will correctly execute
the
program using Activestate perl. The example I gave is for when I have no
wrapper script and just create a symlink in /usr/bin/perl that points
to /c/Perl/bin/perl.exe. The root cause of the example is the reason
for the initial post. The wrapper script was the solution I happened to
choose to get around the path problem, but quickly found out that it does
not work properly with: perl -e 'print join "\n", @INC, "\n";'

> Oh and what is PATH set to?

/home/kcella/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/c/Perl/bin/:/c
/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem


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

Local Package Directory must not be root-dir of a drive (C:\ or D:\ or ... ; drive in the sense of MS-terminology) ?

[Ulrich Diez]

Hello!

After launching Cygwin's setup.exe (the last time I tried with
2.510.2.2) for downloading and installing the Cygwin-packages,
you are asked to specify a so-called 'Local Package Directory'
which serves as cache where setup.exe stores the packages before
they get installed.

I chose to download from the mirror
"http://ftp.univie.ac.at/packages/cygwin";
to the local-package-directory  "F:\Cygwin" on a Win95B-machine.

Thus everything was saved unto hard-disk-partition "F:", into the
directory (and into subdirectories of)
"F:\Cygwin\http%3a%2f%2fftp.univie.ac.at%2fpackages%2fcygwin".
Later installing from the local package directory "F:\Cygwin"
to "C:\Cygwin" as 'Cygwin-root' was straight-forward.

I observed that both moving the entire content of the 'Local
Package Directory'-structure into another subdirectory and
renaming the root of the 'Local Package Directory'-structure
usually is not a problem:

- You can e.g., move the directory-structure from "F:\" to
  "F:\FOO\BAR" so that you obtain the directory-structure
"F:\FOO\BAR\Cygwin\http%3a%2f%2fftp.univie.ac.at%2fpackages%2fcygwin"
(plus subdirectories).
  For installing from local cache you only need to specify the
  'Local Package Directory' as "F:\FOO\BAR\Cygwin".

- You can e.g., rename the directory-structure "F:\CYGWIN"  to
  "F:\FOO" so that you obtain the directory-structure
"F:\FOO\http%3a%2f%2fftp.univie.ac.at%2fpackages%2fcygwin"
(plus subdirectories).
  For installing from local cache you only need to specify the
  'Local Package Directory' as "F:\FOO".

But if you decide to use the root-directory of a 'drive' (e.g.,
the root-directory of an empty hard-disk-partition) as 'Local
Package Directory' --the directory-structure becomes e.g.,:
  "F:\http%3a%2f%2fftp.univie.ac.at%2fpackages%2fcygwin"
  (plus subdirectories)
--, you get plenty of error-messages when trying to download
additional files to local package directory "F:\" or when trying
to install from local package-directory "F:\" to "C:\Cygwin" as
'Cygwin-root'.

Things like:

   Cannot open F:\/setup.log for writing -
   no such file or directory

or

  Cannot write to F:\/\http%3a%2f%2fftp.univie.ac
  .at%2fpackages%2fcygwin\release\tetex\tetex-extra
  \tetex-extra-3.0.0-3.tar.bz2.tmp - no such file
  or directory"

Notice the additional slash after the first backslash in the
path-names.

I wonder if this issue is Win95B-related, if it is Cygwin-
specific or if my general understanding of the way how the
'Local Package Directory' is to be specified is wrong?

Sincerely

Ulrich



--
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: activestate perl on cygwin

[Andrew DeFaria]

Kevin T Cella wrote:

And what does #! look like?

#! /usr/bin/perl

Is there something that the space after the "!" and before the "/" buys you?

So your specifically saying by your shebang line - execute Cygwin's perl.

what does ls portion after #! in your script return?
Before the conversion using cygpath, it returns the same as in the 
error: /home/kcella/bin/myscript.pl
So then you are saying that you have no /usr/bin/perl? Is so then why do 
you put "#! /usr/bin/perl" in your script at all?
But I think, there is some confusion here. My script will correctly 
execute the program using Activestate perl. 

So now you are saying that you have no problem?!?
The example I gave is for when I have no wrapper script and just 
create a symlink in /usr/bin/perl that points to /c/Perl/bin/perl.exe.
Huh? There is no /c/... although I've heard of a way to do that I've 
also heard that it's not supported. Futher, why would you want to 
symlink /usr/bin/perl -> /c/Perl/bin/perl.exe?!? Or, since you insist on 
using ActiveState, then why not specifically specify something like 
#!C:/Perl/bin/perl.exe or something like that?
The root cause of the example is the reason for the initial post. The 
wrapper script was the solution I happened to choose to get around the 
path problem, but quickly found out that it does not work properly 
with: perl -e 'print join "\n", @INC, "\n";'

Oh and what is PATH set to?

/home/kcella/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/c/Perl/bin/:/c
/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem
You could probably also simply use #!perl since C:/Perl/bin is in your 
path...


--

Andrew DeFaria 
Anything worth fighting for is worth fighting dirty for.


--
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: command line arg expansion

[Morgan Gangwere]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

jim wrote:
> Morgan,
> 
> What do you mean by:
> 
>> isnt this because if the wildcard reading in 1.5.23?
> 
> Is this something that has changed between 1.5.12 and 1.5.23?Maybe I'm
> connecting two unrelated datapoints, but I noticed the problem because of a
> perl script that looks like:
> 
> open(LS, "ls -dF1 /c* | grep '/.*/' |");
> 
> This worked fine on older versions of Cygwin, but doesn't work any more.
> In trying to figure out what was going on, I replaced grep with the program
> to print out argv and noticed the difference.
> 
> thanks,
> jim
> 
>> -Original Message-
>> From: Morgan Gangwere [mailto:[EMAIL PROTECTED] 
>> Sent: Thursday, January 11, 2007 4:32 PM
>> To: cygwin@cygwin.com
>> Subject: Re: command line arg expansion
>>
> jim wrote:
 I have recently upgraded from 1.5.12 to 1.5.23 and noticed 
> something that
 has me wondering.I compiled this on 1.5.23 and have run 
> it under cmd.exe
 on on 1.5.12 and 1.5.23:

 #include 

 int main(int argc, char *argv[])
 {
int i, c;

for (i = 0; i < argc; i++)
   printf("arg[%d]: '%s'\n", i, argv[i]); }

 On 1.5.12:
 C:\>e '/.*/'
 arg[0]: 'e'
 arg[1]: '/.*/'

 On 1.5.23:
 C:\>e '/.*/'
 arg[0]: 'e'
 arg[1]: '/../'
 arg[2]: '/./'
 arg[3]: '/.other/'

 It appears that the runtime initialization on 1.5.23 is 
> doing command line
 expansion - is this correct?   If so, is this change 
> documented somewhere so
 I get the full explanation?

 thanks for any insight,
 jim



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


> isnt this because if the wildcard reading in 1.5.23?
> 
> i have seen this several times, especially in this kind of program.
> handle the argv[] as an array of real strings and  you should 
> be fine TTBOMK 

i may have been confused. what shell are you running this from?


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFFqDmlXIyDjlIx4voRArStAJ94hgvkDJRrtUIZGrYAuGfvVlqQEwCgkvBV
Ik0DJFYJ6wLIuDifaOBTkKU=
=5e2i
-END PGP SIGNATURE-

--
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: [patch] cygport-0.2.7 mixed-mode SRC_URIs

[Charles Wilson]

Yaakov (Cygwin Ports) wrote:

Could you provide a sample .cygport (and .src.patch if necessary) which
I could use for testing this feature?  (In general, for these major
patches this would be helpful.)


http://cygutils.fruitbat.org/ITP/mixed-mode-demo.tar.bz2

contains
jpeg-6b-12.cygport
jpeg-6b-12.cygwin.patch
jpeg-6b-12.src.patch
jpegv6b-loslesscrop-after-ljpeg-debian.tar.bz2

which is a CVS cygport with SRC_URI of
"${PN}-${PV}-${PD}.tar.bz2 \
 ftp://ftp.simplesystems.org/pub/ImageMagick/delegates/ljpeg-6b.tar.gz \
 jpegv6b-loslesscrop-after-ljpeg-debian.tar.bz2"

so: main source code from CVS, download an upstream patch with binary 
test-images in a tarball via ftp, unpack a local (e.g. no download URI 
specified) tarball containing multiple upstream patches, THEN apply 
.src.patch and .cygwin.patch.


If THAT doesn't exercise the mixed-mode patch, nothin' will.


When you're ready for another test case for one of the other patches, 
let me know.


--
Chuck

--
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: activestate perl on cygwin

[Kevin T Cella]

> > >  And what does #! look like?
> > #! /usr/bin/perl
> Is there something that the space after the "!" and before the "/" buys
> you?

Readability. It is simply a question of style. I prefer the space. Has
it come to that?
 
> So your specifically saying by your shebang line - execute Cygwin's
> perl.

As I state later, I use a symlink so I am infact executing Activestate perl.
Seriously, are you trying to attack me or understand the problem? I am
trying to be nice, I already apologized for my behavior earlier.

> >> what does ls portion after #! in your script return?
> > Before the conversion using cygpath, it returns the same as in the
> > error: /home/kcella/bin/myscript.pl
> So then you are saying that you have no /usr/bin/perl? Is so then why
> do
> you put "#! /usr/bin/perl" in your script at all?

I think I misunderstood the question. I had taken it to mean had I
executed an ls on the incoming argument to my wrapper script (ie: the
script filename), what would be the output. Now I see what you were
trying to get at was if the interpreter referenced by the #! line exists
on my system. As I state later, I use a symlink:

$ ls -l /usr/bin/perl
lrwxrwxrwx 1 kcella None 20 Jan 13 00:19 /usr/bin/perl ->
/c/Perl/bin/perl.exe

> So now you are saying that you have no problem?!?

Keep reading...

> > The example I gave is for when I have no wrapper script and just
> > create a symlink in /usr/bin/perl that points to
> /c/Perl/bin/perl.exe.
> Huh? There is no /c/... although I've heard of a way to do that I've
> also heard that it's not supported. Futher, why would you want to
> symlink /usr/bin/perl -> /c/Perl/bin/perl.exe?!? Or, since you insist
> on
> using ActiveState, then why not specifically specify something like
> #!C:/Perl/bin/perl.exe or something like that?

Again, it is just a question of style. I have done it both ways, I
prefer using linux style pahts. I mount c: to /c because it is
much faster to type than /cygdrive/c/ and it makes more sense from
a readability standpoint.
 
> > The root cause of the example is the reason for the initial post. The
> > wrapper script was the solution I happened to choose to get around
> the
> > path problem, but quickly found out that it does not work properly
> > with: perl -e 'print join "\n", @INC, "\n";'
> >> Oh and what is PATH set to?
> >
> /home/kcella/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/c/Perl/bi
> n/:/c
> > /WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem
> You could probably also simply use #!perl since C:/Perl/bin is in your
> path...

Another question of style. Although for me it is more habitual
than stylistic. Your questions are very subjective with an insulting tone.
I'm sorry if I have offended you in some way. Do you at least understand
Why the cygwin style paths are causing an issue? And what it is I am trying
to accomplish?



--
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: [patch] cygport-0.2.7 mixed-mode SRC_URIs

[Charles Wilson]

Charles Wilson wrote:


If THAT doesn't exercise the mixed-mode patch, nothin' will.


Except that it also uses the src_prep_init_hook changes.  Which only 
makes sense: if you download third-party or upstream patches, somehow 
you've got to "do" something with them.  PATCH_URI helps, but in this 
case the lossless-jpeg "patch" contains binary images that must be 
copied into src/ somehow.  And that's what the jpeg.cygport does in 
src_prep_init_hook.


I could probably simplify jpeg.cygport's src_prep_init_hook() a little 
bit by putting

${origsrcdir}/ljpeg-6b.patch
${origsrcdir}/100_crop.patch
${origsrcdir}/200_crop_man.patch
${origsrcdir}/201_rdjpgcom_locale.patch
${origsrcdir}/202_jpeglib.h_c++.patch
${origsrcdir}/203_rdppm.patch
${origsrcdir}/204_exif_extra.patch
into PATCH_URI, but that still leaves the following in src_prep_init_hook():
cd ${origsrcdir}
mv testimgl* ${SRC_DIR}/
cd ${SRC_DIR}
But those images are only needed by src_test().

However, the above procedure doesn't work, because:
   (1) the two "extra" tarballs are unpacked into ${origsrcdir}

   (2) cygport strips directory specifiers from PATCH_URIs:

for _patch_uri in ${PATCH_URI}
do
_src_orig_patches="${_src_orig_patches} ${_patch_uri##*/}";
done

   and for good reason, too! Those PATCH_URIs might have http://
   or worse in them.

   (3) _src_orig_patches therefore contains "bare" filenames with no
   directory, and apply_patch is called as:

for src_patch in ${_src_orig_patches}
do
apply_patch ${top}/${src_patch};
done

I don't see either of those for-loops being changed, because they do 
what they do for very good reasons; changing their behavior would break 
lots of stuff.  Maybe:


for src_patch in ${_src_orig_patches}
do
if [ -e ${origsrcdir}/${src_patch} ]
then
apply_patch ${origsrcdir}/${src_patch}
else
apply_patch ${top}/${src_patch};
fi
done

But what if your third-party tarball contained:

one-patch
two/another-patch
three/yet-one-more-patch

So, even if jpeg.cygport uses PATCH_URI as above, it'd still need a 
src_prep_init_hook() function to move the patches from ${origsrcdir} to 
${T}.  Frankly, I'd prefer to keep them in ${origsrcdir} and call 
apply_patch -- for THOSE patches -- explicitly, if I'm gonna have a 
src_prep_init_hook() anyway.


When you're ready for another test case for one of the other patches, 
let me know.


Sorry, didn't see the next message you sent asking for an demo of the 
"hooks" stuff.  Obviously the mixed-mode-demo patch will do so for the 
src_prep_*_hooks, but I'll send a demo that needs the 
src_install_*_hooks in a separate message...


--
Chuck

--
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: [patch] cygport-0.2.7 hooks for additional prep, install customization

[Charles Wilson]

Yaakov (Cygwin Ports) wrote:

Could you please provide a sample .cygport showing what would be
accomplished with this?


Well, there's the src_prep_init|fini_hook example used in the 
jpeg.cygport (from the mixed-mode-demo tarball).  Again, the extra 
SRC_URIs are all unpacked automatically by cygport, but then the 
specific package .cygport has to DO something with those contents, if 
the extra SRC_URIs are not just .patch files.


In which case they should be in PATCH_URI, instead.


Obviously, I prefer [2], which is implemented below for the prep and
install stages.


Refresh my memory, what is the need for the src_install hooks?


rxvt-unicode-X is a good example of that:

rxvt-unicode-X has $PN = "rxvt-unicode-X" but all documentation is 
provided by the subpackage rxvt-unicode-common, and I want that 
documentation to be in

  /usr/share/doc/rxvt-unicode-${PV}/
and NOT either of
   /usr/share/doc/rxvt-unicode-X-${PV}/
   /usr/share/doc/rxvt-unicode-common-${PV}/

cygport is rather insistent that ${P}[== ${PN}-${PV}] and subdirectories 
under ${P} will used throughout for docdir (it's even hardcoded in 
/usr/lib/cygport/bin/dodoc).  And that's a good thing, for almost any 
package.  So, rather than trying to overload the current behavior with a 
lot of brittle logic, I added instead a patch that allowed me to "go 
with the flow", and then "clean up" afterwards:


src_install_fini_hook() {
cd ${D}
mv usr/share/doc/${P} usr/share/doc/${BASE_PN}-${PV}
}

Much simpler.

src_prep_init_hook is called at the first point in src_prep that makes 
any sense at all, and src_prep_fini_hook is called as the very last act 
of src_prep.


src_install_init_hook is called as the very first act of 'install)' -- 
even before __prepinstalldirs.  I'm not sure what good this will do, but 
it's there for symmetry. (and if it came after __prepinstalldirs, then 
those customizations should go at the top of src_install() anyway!)


As for src_install_fini_hook -- well, sometimes you need to take care of 
business AFTER src_postinst() does its thing:

  __prepdoc && __prepetc && __prepman && __prepstrip

Now, rxvt-unicode-X.cygport depends on the mixed-mode patch, the "hooks" 
patch, and "multiple postinstall/preremove scripts" patch.  The 
rxvt.cygport uses both

src_prep_init_hook()
and src_install_fini_hook().

I've put hooks-demo.tar.bz2 here:
   http://cygutils.fruitbat.org/ITP/hooks-demo.tar.bz2
It contains:

rxvt-unicode-X-7.7-6.cygport
rxvt-unicode-X-7.7-6.cygwin.patch
rxvt-unicode-X-7.7-6.src.patch
uwc-7.7-6.zip

Note that the src_prep_init_hook() runs a script contained in the 
uwc-7.7-6.zip zipfile.  That script is a little chatty, the following 
(encountered during 'cygport ... prep' is not an error:


Appending include to rxvt.h
Adding uwc.o to Makefile and Makefile.in
grep: Makefile: No such file or directory
sed: can't read Makefile: No such file or directory
Transforming files to use u_ versions of multi-byte functions
Removing identical copies of transformed files
command.C ../command.C differ: char 5505, line 202
init.C ../init.C differ: char 15335, line 557
main.C ../main.C differ: char 2354, line 65
misc.C ../misc.C differ: char 1423, line 32
rxvt.h ../rxvt.h differ: char 21316, line 689
rxvtfont.C ../rxvtfont.C differ: char 14456, line 427
screen.C ../screen.C differ: char 25445, line 851
Saving original versions of transformed files to sav/
Copying transformed versions to ./

Enjoy...

--
Chuck

--
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: command line arg expansion

[Christopher Faylor]

On Thu, Jan 11, 2007 at 11:38:18AM -0800, jim wrote:
>I have recently upgraded from 1.5.12 to 1.5.23 and noticed something that
>has me wondering.I compiled this on 1.5.23 and have run it under cmd.exe
>on on 1.5.12 and 1.5.23:
>
>#include 
>
>int main(int argc, char *argv[])
>{
>   int i, c;
>
>   for (i = 0; i < argc; i++)
>  printf("arg[%d]: '%s'\n", i, argv[i]);
>}
>
>On 1.5.12:
>C:\>e '/.*/'
>arg[0]: 'e'
>arg[1]: '/.*/'
>
>On 1.5.23:
>C:\>e '/.*/'
>arg[0]: 'e'
>arg[1]: '/../'
>arg[2]: '/./'
>arg[3]: '/.other/'
>
>It appears that the runtime initialization on 1.5.23 is doing command line
>expansion - is this correct?   If so, is this change documented somewhere so
>I get the full explanation?
>
>thanks for any insight,

This problem was introduced when we upgraded to a newer version of
glob().  We're using a fairly recent version of this routine from
FreeBSD bug, AFAICT, it has a bug which disallows quoting characters.

I've checked in a very simple fix for this and am generating a new
snapshot.

Thanks for the test case.  You actually can see the failing behavior by
running cygwin's echo from a windows command line.

cgf

--
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: HISTFILE in zsh

[Peter A. Castro]

On Sat, 23 Dec 2006, Eli Barzilay wrote:

Greetings, Eli,
  (Sorry for the long delay, vacation, etc etc.)


I'm having the same problem that is described at

 http://www.cygwin.com/ml/cygwin/2004-12/msg00195.html

I'm surprised that it was reported in 2004 -- I use cygwin on several
machines with no problems, it's only a new one that is having the
above symptom.

(Which is related to saving/loading the history file -- `fc -R foo'
and `fc -W foo' also hang.  Using strace, it looks like the problem is
some kind of an infinite loop that is related to a lock file for the
history file.)


I've seen this reported before, but I still can't seem to reproduce it.
Can you collect the system info as per http://www.cygwin.com/problems.html

In your debugging, what routine were you seeing the loop?  Was it zsh
code or cygwin code?  Was it a system call returning a bad value?  I'd
like to track this down finally.

Lastly, have you tried the latest cygwin snapshot?

Thanks!

--
Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
"Cats are just autistic Dogs" -- Dr. Tony Attwood

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