Re: Installing in root (was Re: Linux Journal Cygwin article)

[Brian Dessent]

linda w wrote:

> Perhaps he has read that many developers and users on this list
> use "C:\" as the root diretory and have no problems.  I had the
> impression that the advice to install into a subdirectory was more
> of a Covering One's Behind (COB?) when presenting cygwin as a commercial
> solution to vendors.  I find it more useful to have it in the root
> directory, as I use my cygwin tools and shell to manage my XP machine
> instead of the Windows tools.  I have yet to run into a problem
> with conflicting software ...

Sorry but that's a horrible idea.  I would never want to do that
personally.  If you install Cygwin as a subdirectory for itself it's
much easier to delete, backup, modify, etc.  For example if you need
multiple installations around for testing you just "umount -A", rename
the dir to something else, and reinstall a new one.

If you want /home on Cygwin and windows to match then just mount it that
way.  You can mount things however you want them, but that doesn't mean
you have to have the files physically in the root dir.  Mount c:\windows
on /windows, c:\documents and settings\ on /home, whatever.  That's no
justification for installing Cygwin in the root directory.

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/

Can't cd into directory

[acidblue]

I'm using the following syntax:
cd '/cygdrive/c/Documents and Settings'
I get a " No such file or directory" message.
cygwin on WinXP installed to C:/
I get this message no matter which directory I try to cd into.
Driving me nuts Please help.
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Can't cd into directory

[Jörg Schaible]

Please post output of
mount -p

acidblue wrote on Tuesday, February 08, 2005 9:18 AM:

> I'm using the following syntax:
> cd '/cygdrive/c/Documents and Settings'
> I get a " No such file or directory" message.
> cygwin on WinXP installed to C:/
> 
> I get this message no matter which directory I try to cd
> into. Driving me nuts Please help.

--
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: RFE: enhance setup.exe to used cached mirrors file

[Corinna Vinschen]

On Feb  8 17:22, Erik de Castro Lopo wrote:
> On Mon, 7 Feb 2005 22:28:32 -0500 (EST)
> Igor Pechtchanski <[EMAIL PROTECTED]> wrote:
> 
> > The best way to second such requests is with a patch.  Remember,
> > . :-)
> 
> Where would I find the code to setup.exe?
> 
> I had a look in the main CVS tree but couldn't find it.

See http://sourceware.org/cygwin-apps/setup.html

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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: hyperthreading fix, try #1

[Jörg Schaible]

Brian Gallew wrote on Monday, February 07, 2005 2:18 PM:

> Christopher Faylor wrote:
>> Fixing that seems to have fixed my hyperthreading problems.  I have
>> run three invocations of the scripts for four days without a hiccup.
>> Previously, I had problems within minutes.
> 
> Go, you!  Someone should give you a gold star for this.

IMHO Chris needs more something like a life-time award :)

- Jörg

--
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: bash: tab completion failure from (but not at) /

[Corinna Vinschen]

On Feb  8 07:19, [EMAIL PROTECTED] wrote:
> Recent remarks ("I have an idea about how to fix the race but it would
> introduce a destabilizing change that I'd rather not chance before 1.5.13 is
> released") suggest that an updated cygwin1.dll might be imminent.
> Please could I mention a minor but annoying glitch described along with
> Corinna's immediate and effective fix at
> http://www.cygwin.com/ml/cygwin/2004-05/msg00449.html but which has
> re-emerged in recent snapshots, at least since
> http://www.cygwin.com/ml/cygwin/2004-12/msg00838.html, in which Corinna
> records her perplexity ("weird") at this re-emergence.
> Things worked properly in snapshot 20041222 but fail from 20041223.

Nevertheless, that's a bash problem.  Is our bash maintainer still around?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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: hyperthreading fix, try #1

[Corinna Vinschen]

On Feb  8 09:31, J?rg Schaible wrote:
> Brian Gallew wrote on Monday, February 07, 2005 2:18 PM:
> > Christopher Faylor wrote:
> >> Fixing that seems to have fixed my hyperthreading problems.  I have
> >> run three invocations of the scripts for four days without a hiccup.
> >> Previously, I had problems within minutes.
> > 
> > Go, you!  Someone should give you a gold star for this.
> 
> IMHO Chris needs more something like a life-time award :)

We could ask the Queen to bestow the OM upon Chris.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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: svn on apache on Cygwin?

[Max Bowsher]

Steve Kelem wrote:
Does anyone have a pointer on how to build apache on Cygwin so that it
supports svn?
I'm working on it, but it's still at the "trailblazing" stage, rather than 
the "guidebooks available" stage.

Use svnserve instead.
Max.
--
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: RFE: enhance setup.exe to used cached mirrors file

[Erik de Castro Lopo]

On Tue, 8 Feb 2005 09:30:45 +0100
Corinna Vinschen <[EMAIL PROTECTED]> wrote:

> See http://sourceware.org/cygwin-apps/setup.html

Got it. Thanks.

Erik
-- 
+---+
  Erik de Castro Lopo  [EMAIL PROTECTED] (Yes it's valid)
+---+
"We can build a better product than Linux" -- Microsoft
Corp.'s Windows operating-system chief, Jim Allchin.
One has to wonder why, with their huge resources, they haven't.

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

Re: Can't cd into directory

[acidblue]

Sure thing:
[EMAIL PROTECTED] ~
$ mount -p
Prefix  Type Flags
/cygdrive   system   binmode
[EMAIL PROTECTED] ~
$
- Original Message - 
From: "Jörg Schaible" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, February 08, 2005 12:26 AM
Subject: RE: Can't cd into directory


Please post output of
mount -p
acidblue wrote on Tuesday, February 08, 2005 9:18 AM:
I'm using the following syntax:
cd '/cygdrive/c/Documents and Settings'
I get a " No such file or directory" message.
cygwin on WinXP installed to C:/
I get this message no matter which directory I try to cd
into. Driving me nuts Please help.
--
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/

Possible bug

[Vijay Kiran Kamuju]

try this :
$ AUTOHEADER="autoheader`echo "$AUTOCONF" | sed 's/.*autoconf//'`"
$ test -x $AUTOHEADER
$ echo $?

the result in cygwin is 1
but the result in fedora is 0

this is not enabling me to cross compile tvtime

--
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: Possible bug

[Vijay Kiran Kamuju]

oops in fedora its 1

code in tvtime boot strap thats failing
-
test -x "$AUTOHEADER" ||
  AUTOHEADER="autoheader`echo "$AUTOCONF" | sed 's/.*autoconf//'`" &&
AUTOHEADER=`type -p "$AUTOHEADER"` ||
  {
echo `basename $0`: GNU Autoconf installed improperly 1>&2 &&
  exit 2;
  }

in tvtime bootstrap under cygwin im geting the message 

GNU Autoconf installed improperly 

but not in fedora

bye,
Vijay 

On Tue, 8 Feb 2005 15:41:20 +0530, Vijay Kiran Kamuju
<[EMAIL PROTECTED]> wrote:
> try this :
> $ AUTOHEADER="autoheader`echo "$AUTOCONF" | sed 's/.*autoconf//'`"
> $ test -x $AUTOHEADER
> $ echo $?
> 
> the result in cygwin is 1
> but the result in fedora is 0
> 
> this is not enabling me to cross compile tvtime
>

--
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: Possible bug

[Brian Dessent]

Vijay Kiran Kamuju wrote:

> code in tvtime boot strap thats failing
> -
> test -x "$AUTOHEADER" ||
>   AUTOHEADER="autoheader`echo "$AUTOCONF" | sed 's/.*autoconf//'`" &&
> AUTOHEADER=`type -p "$AUTOHEADER"` ||
>   {
> echo `basename $0`: GNU Autoconf installed improperly 1>&2 &&
>   exit 2;
>   }
> 
> in tvtime bootstrap under cygwin im geting the message
> 
> GNU Autoconf installed improperly
> 
> but not in fedora

That's a fault of the tvtime configure script then it seems.  Under
linux, sh is bash, but not under Cygwin (and many other nixes) where sh
is the standard bourne shell.  "type -p" is a bashism, you can't use it
in a sh script.  "sh" does not support any flags for the "type" builtin.

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: hyperthreading fix, try #1

[Nick Coghlan]

Christopher Faylor wrote:
On Mon, Feb 07, 2005 at 08:17:52AM +0100, Volker Bandke wrote:
Which system configuration did you use to recreate the problem?

I got enough donations to purchase the following:
Motherboard:	ASUS P4P800SE 
Memory:		1G
CPU:		CPU P4/3.0EGHz 800M 478P/1MB HT RT
HD:		Samsung 120GB
Case:		ASPIRE XINFINITY BL 350W RTL
Those specs are pretty close to mine, so I have a reasonable hope that your fix 
will work for me too. Hopefully I'll get a chance to try it this weekend.

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.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/

Re: perl winpid?

[Gerrit P. Haase]

Yitzchak Scott-Thoennes wrote:
On Mon, Feb 07, 2005 at 02:17:32PM +0100, Reini Urban wrote:
Igor Pechtchanski schrieb:
On Sun, 6 Feb 2005, Reini Urban wrote:
I feel quite stupid now, but found nothing simple.
How to get the winpid from the current process in cygwin's perl?

We will check out there where this cygwin specific functionality
will go to.
Win32::Process::CygwinToWin32ProcessID() is my suggestion.

I'd rather see them in the Proc:: namespace, and I think it would make
sense to put them in perl's cygwin.c itself, if Gerrit is willing to
release yet another perl-5.8.6.  If this sounds OK, I'll come up with
a patch.
I have no problem with another release.  And I agree that such important
functions should go inside perl.
Gerrit
--
=^..^=
--
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: perl & Win32 lib support

[Reini Urban]

Yitzchak Scott-Thoennes schrieb:
On Mon, Feb 07, 2005 at 06:42:21PM -0800, linda w wrote:
I thought there had been a fix in the works for this problem -- I
wanted to write a program using cygwin perl to access/modify the Registry.
When I load the Win32 package from cpan and try building it, I get
a familiar error message "IsWinNT" is undefined, so building and
installing cpan registry access routines isn't possible. 

Is there something else that would break if "IsWinNT" is set to
"true" if the underlying OS is NT based (or IsWin95 for Win9x/Me)?
I might be able to use ActiveState's Perl, but it doesn't play
so well with CPAN and doesn't seem to handle Cygwin paths very well
either.
Was there a work-around for this?

Upgrade to perl5.8.6, which addresses the IsWinNT-missing problem.
Also, I believe Reini will be releasing a new version of perl-libwin32
real soon now.
The interim version is at
  http://xarch.tu-graz.ac.at/publ/cygwin/release/perl-libwin32
(use http://xarch.tu-graz.ac.at/publ/cygwin/ as setup "User URL:")
But I want to wait a bit for Rafael's answer about maintainership 
change, and for confirmation on the new libwin32 list about my proposed 
new Win32::Process functions and version bump.

perl-win32-gui and perl-win32-api will be the next.
New clamav and postgresql versions are also pending. Still some problems 
there (upstream and here).

--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
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: tee piping to head gives error message

[John Chatelle]

Don't break head.

  We won't want "Argument list too long" when piping a stream to head. 

-- Original Message ---
From: "Buchbinder, Barry (To: cygwin-cygwin.com
Sent: Mon, 7 Feb 2005 13:49:49 -0500
Subject: RE: tee piping to head gives error message

> At Monday, February 07, 2005 1:13 PM, Dave Korn wrote:
> >> -Original Message-
> >> From: cygwin-owner On Behalf Of Buchbinder, Barry (NIH/NIAID)
> >> Sent: 07 February 2005 17:28
> > 
> >> As described in the Subject.  Though it seems that everything works
> >> OK; tee just gives and error message under some circumstances.
> >> 
> >> /tmp> cat stafflist.htm | tee ttt | head > /dev/null
> >> tee: standard output: Broken pipe
> > 
> >> So the file that tee write looks good and the write error is
> >> only to the pipe.
> > 
> >   That'll be because head closed the pipe, and tee was still trying
> > to write into it.
> 
> Further experimentation supported that.  Inserting cat between tee 
> and head did not eliminate the error message, while inserting sort did.
> 
> >> So head seems to be passing on the number of lines that ones
> >> asks it to pass on.
> > 
> >   Given that the purpose of head is to print the first few lines of a
> > file, it kind of makes sense to me that it would close the file after
> > it's read them rather than keeping the input file open and manually
> > reading-and-discarding the entire rest of it for no good reason.
> 
> Agreed.
> 
> >   So I reckon this is as-expected and by-design behaviour.
> 
> with the upstream maintainers, or to patch himself.  (I won't 
> complain if he doesn't patch it.  Taking on coreutils was quite a 
> commitment -- well deserving of the two gold stars -- and I know 
> that fixing this may be a low priority.)  Unfortunately, though PTC, 
> I'm not capable of providing a patch. In any case, tee seems to save 
> its input as desired, so while the error message is annoying and 
> misleading, I suppose that one can live with it.
> 
--- Cut ---


--
This message and any attachments may contain information that is protected
by law as privileged and confidential, and is transmitted for the sole use
of the intended recipient(s). If you are not the intended recipient, you
are hereby notified that any use, dissemination, copying or retention of
this e-mail or the information contained herein is strictly prohibited. If
you have received this e-mail in error, please immediately notify the
sender by e-mail, and permanently delete this e-mail.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner and F-Prot.



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

cygwin1.dll crash

[Lannoye Xavier]

Hi

I've just run an setup to add some fonctionalities (cron) to my cygwin
install, but it crashed at the end of the configuration process with
the following message

"the procedure entry point _impure_ptr could not be located in the
dynamic link library cygwin1.dll"

Now, wathever I try to rin I've got this error message

any idea is welcome:-/

thks

--
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: cygwin1.dll crash

[Brian Dessent]

Lannoye Xavier wrote:

> I've just run an setup to add some fonctionalities (cron) to my cygwin
> install, but it crashed at the end of the configuration process with
> the following message
> 
> "the procedure entry point _impure_ptr could not be located in the
> dynamic link library cygwin1.dll"
> 
> Now, wathever I try to rin I've got this error message

You have some older version of cygwin1.dll on your system that is
incompatible.  Follow the instructions at
, specifically the part about cygcheck,
if you want help.

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: cygwin1.dll crash

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Lannoye Xavier
> Sent: 08 February 2005 13:20

> Hi
> 
> I've just run an setup to add some fonctionalities (cron) to my cygwin
> install, but it crashed at the end of the configuration process with
> the following message
> 
> "the procedure entry point _impure_ptr could not be located in the
> dynamic link library cygwin1.dll"
> 
> Now, wathever I try to rin I've got this error message
> 
> any idea is welcome:-/

  Try this:

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

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: Possible bug

[Vijay Kiran Kamuju]

but the below code in tvtime bootstrap works fine
--

test -x "$AUTOCONF" ||
  AUTOCONF=`type -p autoconf2.50` ||
AUTOCONF=`type -p autoconf` ||
  {
echo `basename $0`: cannot find GNU Autoconf 1>&2 &&
  exit 1;
  }


On Tue, 8 Feb 2005 16:01:54 +0530, Vijay Kiran Kamuju
<[EMAIL PROTECTED]> wrote:
> oops in fedora its 1
> 
> code in tvtime boot strap thats failing
> -
> test -x "$AUTOHEADER" ||
>   AUTOHEADER="autoheader`echo "$AUTOCONF" | sed 's/.*autoconf//'`" &&
> AUTOHEADER=`type -p "$AUTOHEADER"` ||
>   {
> echo `basename $0`: GNU Autoconf installed improperly 1>&2 &&
>   exit 2;
>   }
> 
> in tvtime bootstrap under cygwin im geting the message
> 
> GNU Autoconf installed improperly
> 
> but not in fedora
> 
> bye,
> Vijay
> 
> On Tue, 8 Feb 2005 15:41:20 +0530, Vijay Kiran Kamuju
> <[EMAIL PROTECTED]> wrote:
> > try this :
> > $ AUTOHEADER="autoheader`echo "$AUTOCONF" | sed 's/.*autoconf//'`"
> > $ test -x $AUTOHEADER
> > $ echo $?
> >
> > the result in cygwin is 1
> > but the result in fedora is 0
> >
> > this is not enabling me to cross compile tvtime
> >
>

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

RE: Can't cd into directory

[Igor Pechtchanski]

On Tue, 8 Feb 2005, Jörg Schaible wrote:

> acidblue wrote on Tuesday, February 08, 2005 9:18 AM:
>
> > I'm using the following syntax:
> > cd '/cygdrive/c/Documents and Settings'
> > I get a " No such file or directory" message.
> > cygwin on WinXP installed to C:/
> >
> > I get this message no matter which directory I try to cd
> > into. Driving me nuts Please help.
>
> Please post output of
> mount -p

Instead of providing information bit by bit, please see the Cygwin posting
guidelines at  for the necessary system
information.

Oh, and please don't top-post.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
--
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: tee piping to head gives error message (also with snapshot 20050206)

[Christian Weinberger]

Here's
> a test on a file with 4207 lines in it.
> 
> dk  mace /artimi/firmware> cat diffs.txt  | tee tmp2.txt  | head -4100 >
/dev/nu
> ll
> tee: write error
> dk  mace /artimi/firmware> cat diffs.txt  | tee tmp2.txt  | head -4100 >
/dev/nu
> ll
> dk  mace /artimi/firmware> cat diffs.txt  | tee tmp2.txt  | head -4100 >
/dev/nu
> ll
> dk  mace /artimi/firmware> cat diffs.txt  | tee tmp2.txt  | head -4100 >
/dev/nu
> ll

I reproduced this bahaviour with the most recent snapshot 20050206.

$ cat /usr/share/doc/mutt-1.4.1/manual.txt | tee tmp2.txt | head -4100
 > /dev/null
tee: standard output: Broken pipe
tee: write error

Unfortunately, the recent fix of cgf in the piping code seems not to fix this
isssue.

Regards,
Christian


--
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: cygwin1.dll crash

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Lannoye Xavier
> Sent: 08 February 2005 13:40

> Hi
> 
> here you have a syscheck log


  Let's take a look

Path:   C:\oracle\ora90\bin
C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86

  Ah.  A version of Perl.  And not ActiveState perl.  Very likely compiled and
running under cygwin.  An old version of the dll, most likely.  If my theory is
right, you're going to have trouble as long as both the Oracle directories and
the cygwin directories are in your PATH setting at the same time.  Would you
mind posting back the output you get from running "dir /w
C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86 C:\oracle\ora90\bin" in a
DOS shell?  I'd like to see.

  To fix the cygwin installation, you could shut down all oracle-related
software, including Apache if that's running, then move C:\cygwin\bin to the
front of your PATH, and re-run setup.exe; that should update your installation
OK.  But then you might later have trouble running oracle stuff.  So the best
solution would probably be to remove cygwin from your PATH altogether, and add
the command "PATH C:\cygwin\bin;%PATH%" to your C:\cygwin\Cygwin.bat startup
file.


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: hyperthreading fix, try #1

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Corinna Vinschen
> Sent: 08 February 2005 08:48

> On Feb  8 09:31, J?rg Schaible wrote:
> > Brian Gallew wrote on Monday, February 07, 2005 2:18 PM:
> > > Christopher Faylor wrote:
> > >> Fixing that seems to have fixed my hyperthreading 
> problems.  I have
> > >> run three invocations of the scripts for four days 
> without a hiccup.
> > >> Previously, I had problems within minutes.
> > > 
> > > Go, you!  Someone should give you a gold star for this.
> > 
> > IMHO Chris needs more something like a life-time award :)
> 
> We could ask the Queen to bestow the OM upon Chris.
> 

We could ask the Buddha to bestow the AUM upon him too!

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: Installing in root (was Re: Linux Journal Cygwin article)

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Brian Dessent
> Sent: 08 February 2005 08:12

> linda w wrote:
> 
> > Perhaps he has read that many developers and users on this list
> > use "C:\" as the root diretory and have no problems.  I had the
> > impression that the advice to install into a subdirectory was more
> > of a Covering One's Behind (COB?) when presenting cygwin as 
> a commercial
> > solution to vendors.  I find it more useful to have it in the root
> > directory, as I use my cygwin tools and shell to manage my 
> XP machine
> > instead of the Windows tools.  I have yet to run into a problem
> > with conflicting software ...
> 
> Sorry but that's a horrible idea.  I would never want to do that
> personally.  If you install Cygwin as a subdirectory for itself it's
> much easier to delete, backup, modify, etc.  For example if you need
> multiple installations around for testing you just "umount -A", rename
> the dir to something else, and reinstall a new one.
> 
> If you want /home on Cygwin and windows to match then just 
> mount it that
> way.  You can mount things however you want them, but that 
> doesn't mean
> you have to have the files physically in the root dir.  Mount 
> c:\windows
> on /windows, c:\documents and settings\ on /home, whatever.  That's no
> justification for installing Cygwin in the root directory.


  Yow!  Confusing the root directory of a single drive with the root of
an entire filesystem tree gives me cognitive dissonance!  



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: perl winpid?

[Reini Urban]

Gerrit P. Haase schrieb:
Yitzchak Scott-Thoennes wrote:
On Mon, Feb 07, 2005 at 02:17:32PM +0100, Reini Urban wrote:
Igor Pechtchanski schrieb:
On Sun, 6 Feb 2005, Reini Urban wrote:
I feel quite stupid now, but found nothing simple.
How to get the winpid from the current process in cygwin's perl?

We will check out there where this cygwin specific functionality
will go to.
Win32::Process::CygwinToWin32ProcessID() is my suggestion.

I'd rather see them in the Proc:: namespace, and I think it would make
sense to put them in perl's cygwin.c itself, if Gerrit is willing to
release yet another perl-5.8.6.  If this sounds OK, I'll come up with
a patch.
I have no problem with another release.  And I agree that such important
functions should go inside perl.
Ok.
Then we won't have to pollute the Win32::Process namespace with this 
cygwin-only functionality. And we don't have to wait for the still 
unmaintained libwin32 upstream.

README.cygwin, cygwin/cygwin.c:
=item cygwin32_winpid_to_pid($pid)
Returns the windows process ID for the given cygwin pid. cygwin-only.
=item cygwin32_pid_to_winpid($pid)
Returns the cygwin process ID for the given windows pid. cygwin-only.
Or as seperate Proc::Cygwin package, which could be maintained at CPAN 
and go to vendor_perl within gerrit's perl package?

  Proc::Cygwin::Win32ProcessID($pid)
  Proc::Cygwin::CygwinProcessID($winpid)
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
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: cygwin1.dll crash

[Lannoye Xavier]

here you have the output for dir /w
its quite huge

I've put the cygwin path in top of my PATH var. but still the same problem

regards


On Tue, 8 Feb 2005 14:37:23 -, Dave Korn <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: cygwin-owner On Behalf Of Lannoye Xavier
> > Sent: 08 February 2005 13:40
> 
> > Hi
> >
> > here you have a syscheck log
> 
>   Let's take a look
> 
> Path:   C:\oracle\ora90\bin
> C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86
> 
>   Ah.  A version of Perl.  And not ActiveState perl.  Very likely compiled and
> running under cygwin.  An old version of the dll, most likely.  If my theory 
> is
> right, you're going to have trouble as long as both the Oracle directories and
> the cygwin directories are in your PATH setting at the same time.  Would you
> mind posting back the output you get from running "dir /w
> C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86 C:\oracle\ora90\bin" in a
> DOS shell?  I'd like to see.
> 
>   To fix the cygwin installation, you could shut down all oracle-related
> software, including Apache if that's running, then move C:\cygwin\bin to the
> front of your PATH, and re-run setup.exe; that should update your installation
> OK.  But then you might later have trouble running oracle stuff.  So the best
> solution would probably be to remove cygwin from your PATH altogether, and add
> the command "PATH C:\cygwin\bin;%PATH%" to your C:\cygwin\Cygwin.bat startup
> file.
> 
> 
> 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/
> 
>


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

Re: Can't cd into directory

[Jonathan Arnold]

acidblue wrote:
acidblue wrote on Tuesday, February 08, 2005 9:18 AM:
I'm using the following syntax:
cd '/cygdrive/c/Documents and Settings'
I get a " No such file or directory" message.
cygwin on WinXP installed to C:/
I get this message no matter which directory I try to cd
into. Driving me nuts Please help.
<[EMAIL PROTECTED]>
To: 
Sent: Tuesday, February 08, 2005 12:26 AM
Subject: RE: Can't cd into directory
Please post output of
mount -p
Sure thing:
[EMAIL PROTECTED] ~
$ mount -p
Prefix  Type Flags
/cygdrive   system   binmode
[EMAIL PROTECTED] ~
$
You should probably double check the pages found here:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
in the Using Cygwin document. Probably you have a problem with
the mount table.
--
Jonathan Arnold (mailto:[EMAIL PROTECTED])
Amazing Developments   http://www.buddydog.org
I feel like a fugitive from the law of averages. -
 William H. Mauldin
--
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: cygwin1.dll crash

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Lannoye Xavier
> Sent: 08 February 2005 14:50

> here you have the output for dir /w
> its quite huge

 Directory of C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86

[.]   [..]  a2p.exe   perl.dll
perl.exe  perl5.00503.exe   perl95.exeperlglob.exe
   6 File(s)987.136 bytes


  This is ActiveState perl, so I was wrong in my first guess.  I'm still
suspicious that it's the root cause of the trouble though; if any of the
setup.exe post-install scripts rely on perl, they are liable to invoke active
state perl instead of cygwin perl, and break when it fails to understand
cygwin-style POSIX paths.

> I've put the cygwin path in top of my PATH var. but still the 
> same problem

  Hmm, peculiar.  May need some more thinking time over this.  Precisely how did
you set it?  If you do it using the PATH command in a DOS prompt, that wouldn't
affect a copy of setup.exe that you launched from explorer, you do need to set
it in Start Menu / Settings / Control Panel / System / Advanced / Environment
Variables.  Try setting your PATH to nothing but these entries:

C:\cygwin\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem

and see if that helps any.

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/

Read the reports before you trade

[Richard]

Test message

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

Couldn't create signal pipe - User permission problem? (IIS6/Win2003)

[[EMAIL PROTECTED]]

Dear List,
I am seeking advice regarding the permissions it necessary for a windows
system user to have in order to successfully execute a binary that uses 
cygwin1.dll.

The binary in question is mkisofs.exe as supplied with the
cdrtools-2.01-win32-bin package. The package is supplied with
cygwin1.dll version 1.5.12, which I believe to be up to date.
My operating system is Windows 2003 server.
When I try to execute the binary it exists with the error message shown 
below:

3 [main] ? 1148 cygheap_user::init: OpenProcessToken(), Win32 error 5
D:\cgi-bin\cdrtools-2.01-win32-bin\mkisofs.exe (1148): *** couldn't
create signal pipe, Win32 error 0
I have identified Win32 error 5 as an "access denied" error.
I have verified that NTFS permissions are not at fault using a utility 
called FileMon from SysInternals to check file system accesses and their 
status. Im quite certain that the NTFS permissions are not the problem.

I am not executing mkisofs.exe from a command prompt or shell, but
rather as a CGI application from a PHP script running under the
IIS6 web server.
This worked fine under Windows 2000 on IIS5, and so I suspect that the 
problem relates to tighter security settings on IIS6 / Windows 2003.

I found this thread:
http://cygwin.com/ml/cygwin/2003-10/msg00447.html
I granted the user the application pool is running under "create global 
objects" permission as suggested. Additionally I have granted the user 
"adjust memory quotas for a process" and "replace a process at token 
level" as Microsoft suggests is necessary for CGI applications. But 
still the process exits with the same error message.

And so my question is, does anyone have any idea which permission might 
be missing and be causing this error to occur?

And does anyone have any experience with calling binaries that use 
cygwin1.dll as a CGI application under Windows 2003 and IIS6?

Thank you for your time,
Andrew
NB: I am still able to execute other binaries (that dont use 
cygwin1.dll) as this user under IIS6. For instance to call rar.exe.

--
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: cygwin1.dll crash

[Lannoye Xavier]

I've tried what you said, cleaned my PATH var (using control panel,  ...)
but it doesn't work. 
still the same problem

I ran a new IExporer window, to make sure it takes the new path values.

I could do a full uninstall of cygwin, and install  a clean one, but
that looks so terrible;-(

thks


On Tue, 8 Feb 2005 15:48:41 -, Dave Korn <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: cygwin-owner On Behalf Of Lannoye Xavier
> > Sent: 08 February 2005 14:50
> 
> > here you have the output for dir /w
> > its quite huge
> 
>  Directory of C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86
> 
> [.]   [..]  a2p.exe   perl.dll
> perl.exe  perl5.00503.exe   perl95.exeperlglob.exe
>6 File(s)987.136 bytes
> 
>   This is ActiveState perl, so I was wrong in my first guess.  I'm still
> suspicious that it's the root cause of the trouble though; if any of the
> setup.exe post-install scripts rely on perl, they are liable to invoke active
> state perl instead of cygwin perl, and break when it fails to understand
> cygwin-style POSIX paths.
> 
> > I've put the cygwin path in top of my PATH var. but still the
> > same problem
> 
>   Hmm, peculiar.  May need some more thinking time over this.  Precisely how 
> did
> you set it?  If you do it using the PATH command in a DOS prompt, that 
> wouldn't
> affect a copy of setup.exe that you launched from explorer, you do need to set
> it in Start Menu / Settings / Control Panel / System / Advanced / Environment
> Variables.  Try setting your PATH to nothing but these entries:
> 
> C:\cygwin\bin
> C:\WINDOWS\system32
> C:\WINDOWS
> C:\WINDOWS\System32\Wbem
> 
> and see if that helps any.
> 
> 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/
> 
>

--
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: perl winpid?

[Reini Urban]

Reini Urban schrieb:
Gerrit P. Haase schrieb:
Yitzchak Scott-Thoennes wrote:
On Mon, Feb 07, 2005 at 02:17:32PM +0100, Reini Urban wrote:
Igor Pechtchanski schrieb:
On Sun, 6 Feb 2005, Reini Urban wrote:
I feel quite stupid now, but found nothing simple.
How to get the winpid from the current process in cygwin's perl?

We will check out there where this cygwin specific functionality
will go to.
Win32::Process::CygwinToWin32ProcessID() is my suggestion.

I'd rather see them in the Proc:: namespace, and I think it would make
sense to put them in perl's cygwin.c itself, if Gerrit is willing to
release yet another perl-5.8.6.  If this sounds OK, I'll come up with
a patch.

I have no problem with another release.  And I agree that such important
functions should go inside perl.
I've found the need functionality buried in Proc::ProcessTable.
Both pid's are populated for all windows processes.
$ perl -MProc::ProcessTable -e '$t = new Proc::ProcessTable;
map { print $_->fname, "\t", $_->pid, "\t", $_->winpid,"\n"; }
@{$t->table}'
/usr/bin/cygrunsrv  572 572
/usr/bin/cygrunsrv  840 840
C:\WINNT\Explorer.EXE   12201220
f:\cygnus\bin\perl.exe  22842284
f:\cygnus\bin\sh.exe27082708
f:\cygnus\bin\less.exe  29202920
f:\cygnus\bin\perl.exe  26082608
But the cygwin pid's seem to be wrong.
Some cygwin processes are not detected as such, so the pids are listed 
as winpid's.
And fname is printed as windows path for those processes, though it 
should be printed as cygwin path.
I'll complain upstream.

Then we won't have to pollute the Win32::Process namespace with this 
cygwin-only functionality. And we don't have to wait for the still 
unmaintained libwin32 upstream.

README.cygwin, cygwin/cygwin.c:
=item cygwin32_winpid_to_pid($pid)
Returns the windows process ID for the given cygwin pid. cygwin-only.
=item cygwin32_pid_to_winpid($pid)
Returns the cygwin process ID for the given windows pid. cygwin-only.
Or as seperate Proc::Cygwin package, which could be maintained at CPAN 
and go to vendor_perl within gerrit's perl package?

  Proc::Cygwin::Win32ProcessID($pid)
  Proc::Cygwin::CygwinProcessID($winpid)
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
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: Using PWD

[Arthur I Schwarz]

Well, you got me all enthused, sigh :-(.

Which requires a path. The objective (here) is not to put the scripts on a
path because they are transient and using PATH would be overkill. So:

./   Which does indeed provide a path ('.'). But so
does dirname $0.
source scripts/ Which can't find . `dirname $0`
returns 'bash', and as an added mystery if the code looks like:

 echo $0
 echo `dirname $0`
 which -a 

the system also crashes my bash shell.

Oh well.

art

On Sun, 6 Feb 2005 09:20:53 -0800,  wrote:

>I'm trying to find the directory of an executing bash script and am having
>very limited success. For example(s):
>
>1. /script.sh
>2. source /script.sh
>3. bash /script.sh
>
>I can find the correct  only for the first example (dirname $0). PWD
>(of course) only works when  == ./. The other two cases I can't seem
>to get to work. Any idea how to get the  in examples 2 and 3?
>
>art
>
Art,
unless I'm missing something you want

which -a your_script


zzapper (vim, cygwin, wiki & zsh)
--

vim -c ":%s%s*%CyrnfrTfcbafbeROenzSZbbyranne%|:%s)[R-T]) )Ig|:norm G1VGg?"

http://www.vim.org/tips/tip.php?tip_id=305  Best of Vim Tips


--
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: RXVT copy/paste behavior

[Phil Betts]

On Tuesday, February 08, 2005 6:14 AM Rizwan Kassim wrote (sort of):

> I haven't been able to find out how to do the following:
> I'd like to accelerate my car using the left pedal and find some
> other way of stopping it (maybe the pedal on the right).
>
> Anyone know how to do this?
> 
> Cheers,
> Rizwan

It may be possible, but if you do it, don't be surprised when you
crash and burn the first time you try to drive a different car.

The selection model used by rxvt is standard throughout the X11 world.
Learn it and enjoy the elegant simplicity of the scheme instead of the
insane mouse, keyboard, mouse, keyboard routine that characterises the
Windows way.

Phil


**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.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: several more bugs found by coreutils

[Corinna Vinschen]

On Feb  2 11:07, Corinna Vinschen wrote:
> On Feb  1 20:58, Erik Blake wrote:
> > Further coreutils-5.3.0 debugging turned up more POSIX bugs in cygwin:
> > 
> >  defines struct passwd with the pw_uid and pw_gid members as ints, 
> > although POSIX requires uid_t and gid_t.
> > http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
> 
> include/pwd.h is a newlib file.  However, I was pretty happy that pw_uid
> and pw_gid were defined as int, when we changed uids and gids from 16 to
> 32 bits.  It was the one file which wasn't necessary to change.
> 
> We could just redefine struct passwd to use uid_t and gid_t, but this
> would break (very very very very unlikely) builds of Cygwin using
> sources of versions before 1.5.0.  In other words, old Cygwin sources
> using 16 bit uids/gids would go down hell.
> 
> Personally, I think I can live with that, but I would like to hear if
> there's any good reason to build historic versions (say, b20) with a
> recent newlib.
> 
> >  defines utimes with non-const second parameter, although POSIX 
> > requires it to be const; likewise for utime in  (deferred to 
> > ).  Additionally, both utimes() and utime() are required to 
> > touch file ctime on success.
> > http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html
> > [snip]
> 
> That should be easy to change in sys/time.h.
> As far as the implementation of utime/utimes is affected, I already
> changed it to set st_ctime.

I have attached a patch to newlib this time.  Thinking about that
for a while, I'm pretty sure that it doesn't make sense to build
old 32 bit versions of Cygwin with recent newlib versions.  So I'm
opting for having a clean pwd.h.

The below patch changes the definitions of struct passwd and utimes(2)
according to SUSv3.


Corinna

* libc/include/pwd.h (struct passwd): Change pw_uid and pw_gid
members to uid_t and gid_t according to SUSv3.
* libc/include/sys/time.h (utimes):  Change second parameter
to const according to SUSv3.

Index: libc/include/pwd.h
===
RCS file: /cvs/src/src/newlib/libc/include/pwd.h,v
retrieving revision 1.2
diff -p -u -r1.2 pwd.h
--- libc/include/pwd.h  9 Mar 2003 21:08:51 -   1.2
+++ libc/include/pwd.h  8 Feb 2005 17:37:22 -
@@ -50,8 +50,8 @@ extern "C" {
 struct passwd {
char*pw_name;   /* user name */
char*pw_passwd; /* encrypted password */
-   int pw_uid; /* user uid */
-   int pw_gid; /* user gid */
+   uid_t   pw_uid; /* user uid */
+   gid_t   pw_gid; /* user gid */
char*pw_comment;/* comment */
char*pw_gecos;  /* Honeywell login info */
char*pw_dir;/* home directory */
Index: libc/include/sys/time.h
===
RCS file: /cvs/src/src/newlib/libc/include/sys/time.h,v
retrieving revision 1.4
diff -p -u -r1.4 time.h
--- libc/include/sys/time.h 21 Apr 2001 03:22:47 -  1.4
+++ libc/include/sys/time.h 8 Feb 2005 17:37:22 -
@@ -72,7 +72,7 @@ struct  itimerval {
 
 int _EXFUN(gettimeofday, (struct timeval *__p, struct timezone *__z));
 int _EXFUN(settimeofday, (const struct timeval *, const struct timezone *));
-int _EXFUN(utimes, (const char *__path, struct timeval *__tvp));
+int _EXFUN(utimes, (const char *__path, const struct timeval *__tvp));
 int _EXFUN(getitimer, (int __which, struct itimerval *__value));
 int _EXFUN(setitimer, (int __which, const struct itimerval *__value,
struct itimerval *__ovalue));

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.

--
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: several more bugs found by coreutils

[Christopher Faylor]

On Tue, Feb 08, 2005 at 06:42:11PM +0100, Corinna Vinschen wrote:
>I have attached a patch to newlib this time.  Thinking about that
>for a while, I'm pretty sure that it doesn't make sense to build
>old 32 bit versions of Cygwin with recent newlib versions.  So I'm
>opting for having a clean pwd.h.
>
>The below patch changes the definitions of struct passwd and utimes(2)
>according to SUSv3.

Cool.  I was wondering about that.

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: several more bugs found by coreutils

[Corinna Vinschen]

On Feb  8 12:47, Christopher Faylor wrote:
> On Tue, Feb 08, 2005 at 06:42:11PM +0100, Corinna Vinschen wrote:
> >I have attached a patch to newlib this time.  Thinking about that
> >for a while, I'm pretty sure that it doesn't make sense to build
> >old 32 bit versions of Cygwin with recent newlib versions.  So I'm
> >opting for having a clean pwd.h.
> >
> >The below patch changes the definitions of struct passwd and utimes(2)
> >according to SUSv3.
> 
> Cool.  I was wondering about that.

It requires also a patch to Cygwin, but I'm waiting for Jeff's approval
first.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

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

Re: Can't cd into directory

[Jonathan Arnold]

(Please reply to the mailing list, not me directly).
acidblue wrote:
- Original Message - From: "Jonathan Arnold" 
<[EMAIL PROTECTED]>
To: "acidblue" <[EMAIL PROTECTED]>
Cc: 
Sent: Tuesday, February 08, 2005 7:26 AM
Subject: Re: Can't cd into directory


acidblue wrote:
acidblue wrote on Tuesday, February 08, 2005 9:18 AM:
I'm using the following syntax:
cd '/cygdrive/c/Documents and Settings'
I get a " No such file or directory" message.
cygwin on WinXP installed to C:/
I get this message no matter which directory I try to cd
into. Driving me nuts Please help.
<[EMAIL PROTECTED]>
To: 
Sent: Tuesday, February 08, 2005 12:26 AM
Subject: RE: Can't cd into directory
Please post output of
mount -p
Sure thing:
[EMAIL PROTECTED] ~
$ mount -p
Prefix  Type Flags
/cygdrive   system   binmode
[EMAIL PROTECTED] ~
$

You should probably double check the pages found here:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
in the Using Cygwin document. Probably you have a problem with
the mount table.
--
Jonathan Arnold (mailto:[EMAIL PROTECTED])
Amazing Developments   http://www.buddydog.org
I feel like a fugitive from the law of averages. -
 William H. Mauldin
Ok I read the documents suggetsed and I am confused on how to mount my c 
drive.
could some one give me the right syntax,
'cause 'mount -s /c and mount -s c:\  won't work
Yes, those are not the correct commands. You need to tell it both
the win32 path and the posix path:
mount -s c:\\ /c
Assuming you're using the bash shell, you need to escape the first
'\' in the path.
But normally, if you cygdrive is /, you should have this already. Again,
check out the Problems report page, and try posting a new question, with
all the necessary info.
http://cygwin.com/problems.html
--
Jonathan Arnold (mailto:[EMAIL PROTECTED])
Amazing Developments   http://www.buddydog.org
I feel like a fugitive from the law of averages. -
 William H. Mauldin
--
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: several more bugs found by coreutils

[Jeff Johnston]

Corinna Vinschen wrote:
On Feb  2 11:07, Corinna Vinschen wrote:
On Feb  1 20:58, Erik Blake wrote:
Further coreutils-5.3.0 debugging turned up more POSIX bugs in cygwin:
 defines struct passwd with the pw_uid and pw_gid members as ints, 
although POSIX requires uid_t and gid_t.
http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
include/pwd.h is a newlib file.  However, I was pretty happy that pw_uid
and pw_gid were defined as int, when we changed uids and gids from 16 to
32 bits.  It was the one file which wasn't necessary to change.
We could just redefine struct passwd to use uid_t and gid_t, but this
would break (very very very very unlikely) builds of Cygwin using
sources of versions before 1.5.0.  In other words, old Cygwin sources
using 16 bit uids/gids would go down hell.
Personally, I think I can live with that, but I would like to hear if
there's any good reason to build historic versions (say, b20) with a
recent newlib.

 defines utimes with non-const second parameter, although POSIX requires it to 
be const; likewise for utime in  (deferred to ).  Additionally, 
both utimes() and utime() are required to touch file ctime on success.
http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html
[snip]
That should be easy to change in sys/time.h.
As far as the implementation of utime/utimes is affected, I already
changed it to set st_ctime.

I have attached a patch to newlib this time.  Thinking about that
for a while, I'm pretty sure that it doesn't make sense to build
old 32 bit versions of Cygwin with recent newlib versions.  So I'm
opting for having a clean pwd.h.
The below patch changes the definitions of struct passwd and utimes(2)
according to SUSv3.
Looks fine.  Please go ahead.
-- Jeff J.
Corinna
* libc/include/pwd.h (struct passwd): Change pw_uid and pw_gid
members to uid_t and gid_t according to SUSv3.
* libc/include/sys/time.h (utimes):  Change second parameter
to const according to SUSv3.
Index: libc/include/pwd.h
===
RCS file: /cvs/src/src/newlib/libc/include/pwd.h,v
retrieving revision 1.2
diff -p -u -r1.2 pwd.h
--- libc/include/pwd.h	9 Mar 2003 21:08:51 -	1.2
+++ libc/include/pwd.h	8 Feb 2005 17:37:22 -
@@ -50,8 +50,8 @@ extern "C" {
 struct passwd {
 	char	*pw_name;		/* user name */
 	char	*pw_passwd;		/* encrypted password */
-	int	pw_uid;			/* user uid */
-	int	pw_gid;			/* user gid */
+	uid_t	pw_uid;			/* user uid */
+	gid_t	pw_gid;			/* user gid */
 	char	*pw_comment;		/* comment */
 	char	*pw_gecos;		/* Honeywell login info */
 	char	*pw_dir;		/* home directory */
Index: libc/include/sys/time.h
===
RCS file: /cvs/src/src/newlib/libc/include/sys/time.h,v
retrieving revision 1.4
diff -p -u -r1.4 time.h
--- libc/include/sys/time.h	21 Apr 2001 03:22:47 -	1.4
+++ libc/include/sys/time.h	8 Feb 2005 17:37:22 -
@@ -72,7 +72,7 @@ struct  itimerval {
 
 int _EXFUN(gettimeofday, (struct timeval *__p, struct timezone *__z));
 int _EXFUN(settimeofday, (const struct timeval *, const struct timezone *));
-int _EXFUN(utimes, (const char *__path, struct timeval *__tvp));
+int _EXFUN(utimes, (const char *__path, const struct timeval *__tvp));
 int _EXFUN(getitimer, (int __which, struct itimerval *__value));
 int _EXFUN(setitimer, (int __which, const struct itimerval *__value,
 	struct itimerval *__ovalue));


--
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: several more bugs found by coreutils

[Jeff Johnston]

Corinna Vinschen wrote:
On Feb  8 12:47, Christopher Faylor wrote:
On Tue, Feb 08, 2005 at 06:42:11PM +0100, Corinna Vinschen wrote:
I have attached a patch to newlib this time.  Thinking about that
for a while, I'm pretty sure that it doesn't make sense to build
old 32 bit versions of Cygwin with recent newlib versions.  So I'm
opting for having a clean pwd.h.
The below patch changes the definitions of struct passwd and utimes(2)
according to SUSv3.
Cool.  I was wondering about that.

It requires also a patch to Cygwin, but I'm waiting for Jeff's approval
first.
Done.
Corinna

--
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: RXVT copy/paste behavior

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Phil Betts
> Sent: 08 February 2005 17:09

> The selection model used by rxvt is standard throughout the X11 world.

  It's insane.

  Unless you have the precision muscular control skills of a world-class
gymnast, a mouse always moves at least a little bit when you press down on the
button.

  This makes it very tricky to select a new window without unintentionally
erasing the contents of the clipboard that you were hoping to paste there
because the mouse moved just enough as you clicked it to select a single
character and the auto-copy destroyed your clipboard contents without asking.

  Destroying user data without any kind of confirmation, are-you-sure, or
requiring a difficult-to-type-accidentally key-combination (such as ctrl-c) is
an appallingly incompetent piece of UI design.  It's like having a pistol
without a safety catch, or an ICBM without a dual-key control.

  FWIW, it's not just X programs that do this.  TeraTerm (a 'doze terminal
emulator) has this same behaviour, and it has wasted lots of my time and energy
in having to repeatedly go back to the original window and re-copy the original
text.

  And don't tell me that I'm only ever allowed to select windows by clicking on
the menu bar and that I get what I deserve if I click in the main part of the
window.  If you have lots of windows open, the menu bars of many of them are
often obscured.  Why should 99% of the window's surface area be verboten for
selecting that window?

  The entire model is screwy.  It wastes lots of my time and interrupts my
workflow.  The 'doze way works smoothly and is much closer to fail-safe: it's
very hard to accidentally press Ctrl+C and lose data in the same way.

> Learn it and enjoy the elegant simplicity of the scheme instead of the
> insane mouse, keyboard, mouse, keyboard routine that characterises the
> Windows way.

  Real experts operate a computer with one hand on the mouse and one on the
keyboard *at the same time* anyway.  This makes it very easy to do selecting,
cutting and pasting.  And under 'doze, you can also use a right-click over the
selected area to bring up a menu with cut, copy and paste options.  You don't
*have* to use the keyboard if you don't find it more efficient.


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: RXVT copy/paste behavior

[Andrew DeFaria]

Dave Korn wrote:
The selection model used by rxvt is standard throughout the X11 world.
It's insane.
And it's not necessarily standard either. For example, Konsole on SuSE 
does not auto select.

Unless you have the precision muscular control skills of a world-class 
gymnast, a mouse always moves at least a little bit when you press 
down on the button.

This makes it very tricky to select a new window without 
unintentionally erasing the contents of the clipboard that you were 
hoping to paste there because the mouse moved just enough as you 
clicked it to select a single character and the auto-copy destroyed 
your clipboard contents without asking.
It's not quite as bad as that really. Slight movements do not alway 
register a selection. It is hit and miss sometimes...

Destroying user data without any kind of confirmation, are-you-sure, 
or requiring a difficult-to-type-accidentally key-combination (such as 
ctrl-c) is an appallingly incompetent piece of UI design. It's like 
having a pistol without a safety catch, or an ICBM without a dual-key 
control.

FWIW, it's not just X programs that do this. TeraTerm (a 'doze 
terminal emulator) has this same behaviour, and it has wasted lots of 
my time and energy in having to repeatedly go back to the original 
window and re-copy the original text.

And don't tell me that I'm only ever allowed to select windows by 
clicking on the menu bar and that I get what I deserve if I click in 
the main part of the window. If you have lots of windows open, the 
menu bars of many of them are often obscured. Why should 99% of the 
window's surface area be verboten for selecting that window?

The entire model is screwy. It wastes lots of my time and interrupts 
my workflow. The 'doze way works smoothly and is much closer to 
fail-safe: it's very hard to accidentally press Ctrl+C and lose data 
in the same way.

Learn it and enjoy the elegant simplicity of the scheme instead of 
the insane mouse, keyboard, mouse, keyboard routine that 
characterises the Windows way.
Real experts operate a computer with one hand on the mouse and one on 
the keyboard *at the same time* anyway. This makes it very easy to do 
selecting, cutting and pasting. And under 'doze, you can also use a 
right-click over the selected area to bring up a menu with cut, copy 
and paste options. You don't *have* to use the keyboard if you don't 
find it more efficient.
Good points.
--
A closed mouth gathers no feet.
--
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: perl & Win32 lib support

[linda w]

There must be something else involved or I've messed something else up:
> perl -v
This is perl, v5.8.6 built for cygwin-thread-multi-64int
...

   I seem to have 5.8.6 installed.  Is there anything else I should
look at.  I probably have something else messed up somewhere.  :-/
Sigh.
-linda
Yitzchak Scott-Thoennes wrote:
Upgrade to perl5.8.6, which addresses the IsWinNT-missing problem.
Also, I believe Reini will be releasing a new version of perl-libwin32
real soon now.
 

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

Problem with alarm() not functioning twice in one program.

[Max Bowsher]

The following program produces the output:
Begin
Done
Begin
...and then hangs.
Can anyone help me understand why?
Thankyou,
Max.

#include 
#include 
#include 
#include 
jmp_buf timer;
void alarm_handler(int dummy)
{
 longjmp(timer, 1);
}
void speedtest(void)
{
 fprintf(stderr, "Begin\n");
 signal(SIGALRM, alarm_handler);
 if (setjmp(timer) == 0) {
   alarm(1);
   while(1) {};
 }
 signal(SIGALRM, SIG_DFL);
 fprintf(stderr, "Done\n");
 return;
}
int main(int argc, char* argv[])
{
 speedtest();
 speedtest();
 return 0;
}
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem with alarm() not functioning twice in one program.

[Brian Ford]

On Tue, 8 Feb 2005, Max Bowsher wrote:

> The following program produces the output:
>
> Begin
> Done
> Begin
> ...and then hangs.
>
> Can anyone help me understand why?
>
http://www.cygwin.com/ml/cygwin/2004-10/msg00598.html

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

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

Re: Problem with alarm() not functioning twice in one program.

[Max Bowsher]

Brian Ford wrote:
On Tue, 8 Feb 2005, Max Bowsher wrote:
The following program produces the output:
Begin
Done
Begin
...and then hangs.
Can anyone help me understand why?
http://www.cygwin.com/ml/cygwin/2004-10/msg00598.html
Ah, OK.
So are you saying "SIGALRM has been entered, but has not returned, so the 
signal handling code won't try to enter it again" ?

That makes sense, I'll see if I can get the problem piece of code fixed.
Max.
--
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/

Changing root path from /ecos-c/ to /

[Bruce Hampton]

Hi,

I'm using Cygwin. I wish to change the default path for C: from /ecos-c/ to /.

When I type "mount" in cygwin, I get the following:

C:\PFARM\cygwin on / type system (binmode)
c: on /ecos-c type user (textmode)
c: on / type user (textmode)
e: on /cygdrive/e type user (textmode,noumount)
f: on /cygdrive/f type user (textmode,noumount)
h: on /cygdrive/h type user (textmode,noumount)
i: on /cygdrive/i type user (textmode,noumount)

C:\PFARM\examples\EVBA7Board\GNU\Simple\RAMCode>

The utility I'm using fails unless C: on the Windows box is mounted as '/'.

Any suggestions?

Shane.

p.s.

"Whenever Cygwin generates a POSIX path from a Win32 one, it uses the longest 
matching prefix in the mount table. Thus, if C: is mounted as /c and also 
as /, then Cygwin would translate C:/foo/bar to /c/foo/bar."

(http://www.cygwin.com/cygwin-ug-net/using.html#mount-table)




--
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: several more bugs found by coreutils

[Corinna Vinschen]

On Feb  8 14:17, Jeff Johnston wrote:
> Corinna Vinschen wrote:
> >I have attached a patch to newlib this time.  Thinking about that
> >for a while, I'm pretty sure that it doesn't make sense to build
> >old 32 bit versions of Cygwin with recent newlib versions.  So I'm
> >opting for having a clean pwd.h.
> >
> >The below patch changes the definitions of struct passwd and utimes(2)
> >according to SUSv3.
> >
> 
> Looks fine.  Please go ahead.
> 
> -- Jeff J.
> 
> >
> >Corinna
> >
> > * libc/include/pwd.h (struct passwd): Change pw_uid and pw_gid
> > members to uid_t and gid_t according to SUSv3.
> > * libc/include/sys/time.h (utimes):  Change second parameter
> > to const according to SUSv3.

Thanks, applied.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

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

Re: Problem with alarm() not functioning twice in one program.

[Brian Ford]

On Tue, 8 Feb 2005, Max Bowsher wrote:
> Brian Ford wrote:
> > On Tue, 8 Feb 2005, Max Bowsher wrote:
> >> The following program produces the output:
> >>
> >> Begin
> >> Done
> >> Begin
> >> ...and then hangs.
> >>
> >> Can anyone help me understand why?
> >>
> > http://www.cygwin.com/ml/cygwin/2004-10/msg00598.html
>
> Ah, OK.
>
> So are you saying "SIGALRM has been entered, but has not returned, so the
> signal handling code won't try to enter it again" ?

SIGALRM has been blocked upon entry to the signal handling routine.
Since you long jumped out of it, it's still blocked.

Did you follow that thread through to the end?  Maybe I should have quoted
this instead:

http://www.cygwin.com/ml/cygwin/2004-10/msg00606.html

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

--
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: RXVT copy/paste behavior

[Reid Thompson]

Dave Korn wrote:
>> -Original Message-
>> From: cygwin-owner On Behalf Of Phil Betts
>> Sent: 08 February 2005 17:09
> 
>   It's insane.

not really -- works exceptionally well for me, much better than keyboard
shortcuts for my use.

>   Unless you have the precision muscular control skills of a
> world-class gymnast, a mouse always moves at least a little
> bit when you press down on the button.

I never considered my muscular control as such - but evidently I should
try out for the next olympics

>   This makes it very tricky to select a new window without
> unintentionally erasing the contents of the clipboard that
> you were hoping to paste there because the mouse moved just
> enough as you clicked it to select a single character and the
> auto-copy destroyed your clipboard contents without asking.

I cannot remember the last time this happened to me... i.e. extremely
rare for this to occur.

>   The entire model is screwy.  It wastes lots of my time and
> interrupts my workflow.  The 'doze way works smoothly and is
> much closer to fail-safe: it's very hard to accidentally
> press Ctrl+C and lose data in the same way.
not true, considering that the c and v keys sit side by side on the
keyboard.

if the sequence copy with left mouse button, select new window with left
mouse button, paste into new window with middle mouse button/scroll
wheel causes you problems...

try

copy with left mouse button, select_and_paste at same time into new
window via middle mouse button/scroll wheel.

reid

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

Re: Problem with alarm() not functioning twice in one program.

[Max Bowsher]

Brian Ford wrote:
On Tue, 8 Feb 2005, Max Bowsher wrote:
Brian Ford wrote:
On Tue, 8 Feb 2005, Max Bowsher wrote:
The following program produces the output:
Begin
Done
Begin
...and then hangs.
Can anyone help me understand why?
http://www.cygwin.com/ml/cygwin/2004-10/msg00598.html
Ah, OK.
So are you saying "SIGALRM has been entered, but has not returned, so the
signal handling code won't try to enter it again" ?
SIGALRM has been blocked upon entry to the signal handling routine.
Since you long jumped out of it, it's still blocked.
Did you follow that thread through to the end?
No, I assumed you were pointing to a specific message.
Maybe I should have quoted
this instead:
http://www.cygwin.com/ml/cygwin/2004-10/msg00606.html
Very helpful, thanks.
Max.
--
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: RXVT copy/paste behavior

[Reid Thompson]

Dave Korn wrote:
>> -Original Message-
>> From: cygwin-owner On Behalf Of Phil Betts
>> Sent: 08 February 2005 17:09
> 
>> The selection model used by rxvt is standard throughout the X11
>> world. 
> 
http://seth.positivism.org/man.cgi/rxvt

there are hyperlinks in the above page that reference how the selection
style is configured...

selectstyle: mode
  Set mouse selection style to old which is 2.20, oldword
which is
  xterm style with 2.20 old word selection, or anything else
which
  gives xterm style selection.



reid

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

bug in setup.exe?

[Swenson, Eric]

I've run into the following situation on several machines now, at multiple
times -- each with different versions of cygwin (so I'm not following the
bug reporting procedure as I think the version information provided by
cygcheck isn't really relevant and as I'm currently in a non-cygwin-working
state as a result of this issue).
 
Frequently, when running setup.exe and specifying that all packages should
be installed (the mode I almost always use), setup.exe bombs while
uninstalling a package that it knows it needs to update with the error that
cygwin1.dll is not found.  Indeed, at the point the dialog box comes up
telling me that cygwin1.dll wasn't found, if I check, it has indeed been
deleted from my /bin directory (actually d:\cygwin\bin).  I suspect this is
because setup has determined that it needs to upgrade my cygwin1.dll, and
therefore must uninstall the old one first and then install the new one.
The problem is, that either setup itself (doubtful) or one or more of the
uninstall/install scripts needs cygwin1.dll in order to run successfully.  
 
Can anyone in the "know" tell me how this is supposed to work?  
 
I tried searching the mailing lists, but the cygwin site says that searching
was disabled due to your recent disk crash.  I tried searching on google and
only found one relevant reference
(http://sources.redhat.com/ml/cygwin/2002-12/msg01346.html) and that page
didn't lead me to any responses.  
 
If you press the ok button on the dialog telling you that cygwin1.dll was
not found, setup proceeds with the next package.  Frequently, I have to
press OK many times (depending on the packages needing to be installed, of
course) in order to get to the end of setup.  Sometimes I can get through
with a successfull uninstall/install of the necessary packages and
cygwin1.dll does get installed again.  But the packages whose
uninstall/install depended on cygwin1.dll, of course, were not actually
"correctly" uninstalled or installed.  
 
Ideas?  -- Eric
 
 

--
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: tee piping to head gives error message

[Eric Blake]

Buchbinder, Barry (NIH/NIAID  niaid.nih.gov> writes:
> > 
> >   Given that the purpose of head is to print the first few lines of a
> > file, it kind of makes sense to me that it would close the file after
> > it's read them rather than keeping the input file open and manually
> > reading-and-discarding the entire rest of it for no good reason.
> 
> Agreed.
> 
> >   So I reckon this is as-expected and by-design behaviour.
> 
> I might put it as "as-designed" rather than "by-design".  And for me, it
> certainly was unexpected.  tee and head are both part of coreutils.  I would
> expect that all coreutils would behave the same for head closing the pipe,
> but they don't.  And I would also expect that all utilities in a package
> that includes a utility that breaks pipes as a normal course of its
> operation would be silent when the two utilities are used together.  I would
> expect that tee pipes to head more often than something nasty happens and a
> pipe just breaks.

Coreutils is following POSIX, and the behavior of pipes is by design within 
POSIX.  POSIX requires that a failed write into a pipe raises SIGPIPE, and that 
the default action on SIGPIPE is to terminate the process.  Note that 
termination bypasses exit handlers registered with atexit().  POSIX also allows 
an application to ignore SIGPIPE; at which point it will detect failures in 
writing to a broken pipe but can continue in normal operation.  Furthermore, 
all of the coreutils are designed to check, using atexit() handlers, for any 
failed write to stdout.

Normally, tee and most other coreutils do nothing special with SIGPIPE, which 
means they only ignore SIGPIPE if their parent process was ignoring it.  So my 
guess is that somewhere in your shell you are setting up your environment to 
ignore SIGPIPE, so that applications spawned by your shell see write failures 
to broken pipes rather than the default of early termination.

Study this example, in bash, for more insight into child behavior when SIGPIPE 
is ignored or not:

$ trap - PIPE   # restore default handling to SIGPIPE
$ yes | tee /dev/null | head > /dev/null
$ echo ${PIPESTATUS[*]}
141 141 0   # yes and tee had SIGPIPE, head was successful
$ seq 1 | tee foo | head > /dev/null
$ echo ${PIPESTATUS[*]}
141 141 0   # yes and tee had SIGPIPE, head was successful
$ wc foo
 2474  2475 11264 foo   # foo did not get the complete output of seq
$ trap '' PIPE  # now ignore SIGPIPE
$ seq 1000 | tee /dev/null | head > /dev/null
$ echo ${PIPESTATUS[*]}
0 0 0   # all 3 programs were successful
$ seq 1 | tee foo | head > /dev/null
tee: standard output: Broken pipe
tee: write error
$ echo ${PIPESTATUS[*]}
0 1 0   # seq and head were successful, tee noticed the broken pipe
$ wc foo
1 1 48894 foo   # foo got the complete output of seq
$ yes | tee /dev/null | head > /dev/null
tee: standard output: Broken pipe

# At this point, yes and tee are in an infinite loop, hit ctrl-c
$ echo ${PIPESTATUS[*]}
130 130 0   # yes and tee had SIGINT from ctrl-c, head was successful
$ yes | tee -i /dev/null | head > /dev/null
tee: standard output: Broken pipe

# Again, an infloop, hit ctrl-c
$ echo ${PIPESTATUS[*]}
130 1 0 # yes had SIGINT, tee just regular failure from broken pipe

> 
> This seems like something the coreutils maintainer might want to address
> with the upstream maintainers, or to patch himself.  (I won't complain if he
> doesn't patch it.

Nope - as the cygwin coreutils maintainer, I won't patch coreutils, because the 
problem of an error message from writing to a broken pipe is not unique to 
cygwin (I ran the same tests on coreutils 5.3.0 on Solaris and saw similar 
behavior).  However, note that tee currently has the POSIX-mandated -i option 
to ignore SIGINT, where in prior versions of coreutils it was treating -i as 
ignoring all signals; the change in 5.3.0 for tee to terminate on SIGPIPE was 
intentional, added around April 2004 (see /usr/share/doc/coreutils-5.3.0/NEWS, 
or http://lists.gnu.org/archive/html/bug-coreutils/2004-04/msg00126.html).  You 
may have success if you propose upstream on the coreutils mailing list the 
addition of a new option to ignore SIGPIPE to allow the restoration of prior 
behavior while still complying with POSIX.  You may also want to ask for an 
interpretation from the POSIX folks as to whether write errors to stdout must 
force tee to fail, or if the current wording that tee return 0 only if "The 
standard input was successfully copied to all output files" allows success even 
if writes to stdout failed, basing your argument on the fact that stdout is not 
one of the output files on the command line.  
http://www.opengroup.org/onlinepubs/009695399/utilities/tee.html

If, as Dave Korn's followup pointed out, cygwin is hanging on some instances of 
pipe handling and process termination interaction, then that is a cygwin and 
not a coreutils bug, and I wouldn't know what to do to try to patch that.

>  Takin

[PATCH] Re: perl winpid?

[Yitzchak Scott-Thoennes]

On Tue, Feb 08, 2005 at 03:48:01PM +0100, Reini Urban wrote:
> Gerrit P. Haase schrieb:
> >Yitzchak Scott-Thoennes wrote:
> >>On Mon, Feb 07, 2005 at 02:17:32PM +0100, Reini Urban wrote:
> >>>Igor Pechtchanski schrieb:
> On Sun, 6 Feb 2005, Reini Urban wrote:
> 
> >I feel quite stupid now, but found nothing simple.
> >How to get the winpid from the current process in cygwin's perl?
> >
> >>>We will check out there where this cygwin specific functionality
> >>>will go to.
> >>>Win32::Process::CygwinToWin32ProcessID() is my suggestion.
> >
> >>I'd rather see them in the Proc:: namespace, and I think it would make
> >>sense to put them in perl's cygwin.c itself, if Gerrit is willing to
> >>release yet another perl-5.8.6.  If this sounds OK, I'll come up with
> >>a patch.
> >
> >I have no problem with another release.  And I agree that such important
> >functions should go inside perl.
> 
> Ok.
> Then we won't have to pollute the Win32::Process namespace with this 
> cygwin-only functionality. And we don't have to wait for the still 
> unmaintained libwin32 upstream.
> 
> README.cygwin, cygwin/cygwin.c:
> =item cygwin32_winpid_to_pid($pid)
> 
> Returns the windows process ID for the given cygwin pid. cygwin-only.
> 
> =item cygwin32_pid_to_winpid($pid)
> 
> Returns the cygwin process ID for the given windows pid. cygwin-only.

How does this look?

--- README.cygwin.orig  2003-08-19 07:37:00.0 -0700
+++ README.cygwin   2005-02-08 11:47:03.38288 -0800
@@ -369,6 +369,8 @@
 
 See comment on fork in L below.
 
+=head1 Specific features of the Cygwin port
+
 =head2 Script Portability on Cygwin
 
 Cygwin does an outstanding job of providing UNIX-like semantics on top of
@@ -470,6 +472,25 @@
 
 =back
 
+=head2 Prebuilt methods:
+
+=over 4
+
+=item C
+
+Returns current working directory.
+
+=item C
+
+Translates a cygwin pid to the corresponding Windows pid (which may or
+may not be the same).
+
+=item C
+
+Translates a Windows pid to the corresponding cygwin pid (if any).
+
+=back
+
 =head1 INSTALL PERL ON CYGWIN
 
 This will install Perl, including I pages.
--- perl/cygwin/cygwin.c.orig   2002-03-20 15:02:25.0 -0800
+++ perl/cygwin/cygwin.c2005-02-08 12:37:48.601689600 -0800
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 
 /*
  * pp_system() implemented via spawn()
@@ -155,6 +156,39 @@
 XSRETURN_UNDEF;
 }
 
+static
+XS(XS_Proc_Cygwin_cygwin32_pid_to_winpid)
+{
+dXSARGS;
+if (items != 1)
+Perl_croak(aTHX_ "Usage: Proc::Cygwin::cygwin32_pid_to_winpid(pid)");
+pid_t pid = (pid_t)SvIV(ST(0));
+pid_t RETVAL;
+dXSTARG;
+if ((RETVAL = cygwin_internal(CW_CYGWIN_PID_TO_WINPID, pid)) > 0) {
+   XSprePUSH; PUSHi((IV)RETVAL);
+XSRETURN(1);
+}
+XSRETURN_UNDEF;
+}
+
+static
+XS(XS_Proc_Cygwin_cygwin32_winpid_to_pid)
+{
+dXSARGS;
+if (items != 1)
+Perl_croak(aTHX_ "Usage: Proc::Cygwin::cygwin32_winpid_to_pid(pid)");
+pid_t pid = (pid_t)SvIV(ST(0));
+pid_t RETVAL;
+dXSTARG;
+if ((RETVAL = cygwin32_winpid_to_pid(pid)) > 0) {
+XSprePUSH; PUSHi((IV)RETVAL);
+XSRETURN(1);
+}
+XSRETURN_UNDEF;
+}
+
+
 void
 init_os_extras(void)
 {
@@ -162,4 +196,8 @@
 dTHX;
 
 newXS("Cwd::cwd", Cygwin_cwd, file);
+newXS("Proc::Cygwin::cygwin32_winpid_to_pid",
+  XS_Proc_Cygwin_cygwin32_winpid_to_pid, file);
+newXS("Proc::Cygwin::cygwin32_pid_to_winpid",
+  XS_Proc_Cygwin_cygwin32_pid_to_winpid, file);
 }
--- perl/MANIFEST.orig  2005-02-01 04:17:14.0 -0800
+++ perl/MANIFEST   2005-02-08 13:35:30.299366400 -0800
@@ -2493,6 +2493,7 @@
 t/lib/1_compile.t  See if the various libraries and extensions 
compile
 t/lib/commonsense.tSee if configuration meets basic needs
 t/lib/compmod.pl   Helper for 1_compile.t
+t/lib/cygwin.t Builtin cygwin function tests
 t/lib/Devel/switchd.pm Module for t/run/switchd.t
 t/lib/Dev/Null.pm  Module for testing Test::Harness
 t/lib/dprof/test1_tPerl code profiler tests
--- perlpatch/t/lib/cygwin.t1970-01-01 00:00:00.0 +
+++ perl/t/lib/cygwin.t 2005-02-08 21:33:53.319916800 +
@@ -0,0 +1,33 @@
+#!perl
+
+BEGIN {
+chdir 't' if -d 't';
+@INC = ('../lib');
+unless ($^O eq "cygwin") {
+   print "1..0 # skipped: cygwin specific test\n";
+   exit 0;
+}
+}
+
+use Test::More tests => 4;
+
+is(Proc::Cygwin::cygwin32_winpid_to_pid(
+   Proc::Cygwin::cygwin32_pid_to_winpid($$)),
+   $$, "perl pid translates to itself");
+
+my $parent = getppid;
+SKIP: {
+skip "test not run from cygwin process", 1 if $parent <= 1;
+is(Proc::Cygwin::cygwin32_winpid_to_pid(
+   Proc::Cygwin::cygwin32_pid_to_winpid($parent)),
+   $parent, "parent pid translates to itself");
+}
+
+my $catpid = open my $cat, "|cat" or die "Couldn't cat: $!";
+open my $ps, "ps|" or die "Couldn't do ps: $!";
+my ($catwinpid) = ma

RE: RXVT copy/paste behavior

[Reid Thompson]

> copy with left mouse button, select_and_paste at same time
> into new window via middle mouse button/scroll wheel.

or,

copy with left mouse button, select new window with right mouse
button(rather than left), paste with middle button/scroller

reid

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

ClamAV update

[Tony Hain]

I realize there have been disk problems lately, but how long should it
normally take for the ClamAV utility to be updated? FreshClam has been
screaming in the logs for 2 weeks now about needing an update, and there
have been 2 version updates in that time:
--
Received signal 14, wake up
ClamAV update process started at Wed Jan 26 15:26:02 2005
WARNING: Your ClamAV installation is OUTDATED - please update immediately!
WARNING: Local version: 0.80 Recommended version: 0.81
main.cvd is up to date (version: 29, sigs: 29086, f-level: 3, builder:
tomek)
daily.cvd is up to date (version: 685, sigs: 727, f-level: 3, builder:
diego)
--

$ tail /var/log/freshclam.log
--
Received signal 14, wake up
ClamAV update process started at Tue Feb  8 09:37:21 2005
WARNING: Your ClamAV installation is OUTDATED - please update immediately!
WARNING: Local version: 0.80 Recommended version: 0.82
main.cvd is up to date (version: 29, sigs: 29086, f-level: 3, builder:
tomek)
daily.cvd is up to date (version: 700, sigs: 1256, f-level: 4, builder:
ccordes)

WARNING: Your ClamAV installation is OUTDATED - please update immediately!
WARNING: Current functionality level = 3, required = 4
--

I would just go to the ClamAV site and pull it down, but when I installed
through the Cygwin setup the location and names of files changed. I don't
know if that would have happened anyway due to version changes or if there
is something different about this distribution. In any case the reason I
went with the Cygwin distribution was to simplify updates and stay current
with other fixes, but for some reason the update from ClamAV doesn't appear
to be making it over to the Cygwin distribution path in a timely manner. Is
this expected behavior or is something broken?

Tony 


--
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] Re: perl winpid?

[Yitzchak Scott-Thoennes]

On Tue, Feb 08, 2005 at 01:46:41PM -0800, Yitzchak Scott-Thoennes wrote:

> How does this look?
> 
> --- README.cygwin.orig2003-08-19 07:37:00.0 -0700
> +++ README.cygwin 2005-02-08 11:47:03.38288 -0800

Sorry for the inconsistent directory levels; those should have been
perl/README.cygwin...

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

Setting the Windows Path variable for children of a bash script....

[Matthew Bogosian]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Howdy all,
I've searched through the archives on this, but I've come up empty, so 
I figured I'd ask

I'm trying to execute a cygwin-ignorant Windows binary from a bash 
script. However, the DLLs required to load this binary are not in the 
system- or user-wide Windows Path variable (nor do I want them to be). 
I'm trying to modify the environment before execution of this binary, 
but it doesn't seem to work. Here's what I've got:

# ...
Path="$(cygpath -pw "${PATH}");$(cygpath -pw "${LD_LIBRARY_PATH}")"
export Path
exec /cygdrive/c/path/to/windows/binary.exe
LD_LIBRARY_PATH contains the paths in which the DLLs specific to 
binary.exe reside. Unfortunately, binary.exe doesn't seem to be able to 
find them there when being invoked from the script's exec command.

Before someone suggests the obvious, I am using Cygwin and bash (etc.) 
as a test harness for a binary I'm writing. I may test several 
different versions of the binary on the same machine. The DLLs cannot 
reside in c:\windows\..., nor can they reside in the same directory as 
binary.exe because binary.exe is actually c:\Python24\python.exe and 
the DLLs are from different versions of a third-party SDK that I'm 
accessing via swig/python. In short, I need to be able to override 
where the DLLs are found by the cygwin-ignorant version of Python in a 
shell script on an ad hoc basis.

Please don't tell me to use Cygwin's python either, since I have to 
test the Windows version using the same test harness.

Does anyone know how to do this? Any help is much appreciated.
-- Matt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCCUCMnLpDzL5I7l8RAu0hAJwKF4C/6vyb/lJNLc8Ml5lDj/tRawCeIxrb
xVavIVr4YXHG29NeTJZdnSQ=
=yoUB
-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: Setting the Windows Path variable for children of a bash script....

[Matthew Bogosian]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Incidentally, I have already thought of doing something like this:
# ...
Path="$(cygpath -pw "${PATH}");$(cygpath -pw "${LD_LIBRARY_PATH}")"
export Path
exec "${0}.bat" "${Path}" ${1+"[EMAIL PROTECTED]"}
Where "${0}.bat" may be something like:
set Path=%1
shift
%1 %2 %3 ...
But this does not work, since some of my arguments may contain spaces 
(which are not parsed correctly in the batch file), and batch files 
have an unusable limit on the number of useful arguments they can parse 
(%* is *not* affected by the shift batch file command, nor does it 
properly quote arguments). Using "%1" "%2" "%3" ... does not help 
either.

In short, I do not believe that batch files are a viable solution to my 
problem (though this may stem from my ignorance on how to write them 
robustly). Either way, I would like to find an alternate solution.

-- Matt
On Feb 8, 2005, at 14:43, Matthew Bogosian wrote:
...
I'm trying to execute a cygwin-ignorant Windows binary from a bash 
script. However, the DLLs required to load this binary are not in the 
system- or user-wide Windows Path variable (nor do I want them to be). 
I'm trying to modify the environment before execution of this binary, 
but it doesn't seem to work. Here's what I've got:

# ...
Path="$(cygpath -pw "${PATH}");$(cygpath -pw "${LD_LIBRARY_PATH}")"
export Path
exec /cygdrive/c/path/to/windows/binary.exe
LD_LIBRARY_PATH contains the paths in which the DLLs specific to 
binary.exe reside. Unfortunately, binary.exe doesn't seem to be able 
to find them there when being invoked from the script's exec command.

...
Does anyone know how to do this? Any help is much appreciated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCCUMunLpDzL5I7l8RAv8PAKCRGQEebvZVYrlwziw2fNB9m/qfQACeP1me
VIpvbTm0cpnlYa+m3YDy+Zo=
=fRSK
-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: bug in setup.exe?

[Igor Pechtchanski]

On Tue, 8 Feb 2005, Swenson, Eric wrote:

> I've run into the following situation on several machines now, at multiple
> times -- each with different versions of cygwin (so I'm not following the
> bug reporting procedure as I think the version information provided by
> cygcheck isn't really relevant and as I'm currently in a non-cygwin-working
> state as a result of this issue).
>
> Frequently, when running setup.exe and specifying that all packages should
> be installed (the mode I almost always use), setup.exe bombs while
> uninstalling a package that it knows it needs to update with the error that
> cygwin1.dll is not found.  Indeed, at the point the dialog box comes up
> telling me that cygwin1.dll wasn't found, if I check, it has indeed been
> deleted from my /bin directory (actually d:\cygwin\bin).  I suspect this is
> because setup has determined that it needs to upgrade my cygwin1.dll, and
> therefore must uninstall the old one first and then install the new one.
> The problem is, that either setup itself (doubtful) or one or more of the
> uninstall/install scripts needs cygwin1.dll in order to run successfully.
>
> Can anyone in the "know" tell me how this is supposed to work?

This is indeed a (known, long-standing) bug in setup.exe.  The problem is
that some packages have pre-remove scripts that prepare a package for
removal.  These scripts are run when the packages are removed, which
happens in alphabetical order of package names, so the scripts will bomb
out if their packages happen to follow the "cygwin" package
alphabetically.

It's clear that one needs to run all pre-remove scripts before removing
the actual package files.  It's also clear that the alphabetical package
name order is the wrong order to run pre-remove scripts in.  What is not
clear is what the right order is.  . :-)

> I tried searching the mailing lists, but the cygwin site says that
> searching was disabled due to your recent disk crash.  I tried searching
> on google and only found one relevant reference
> (http://sources.redhat.com/ml/cygwin/2002-12/msg01346.html) and that
> page didn't lead me to any responses.
>
> If you press the ok button on the dialog telling you that cygwin1.dll
> was not found, setup proceeds with the next package.  Frequently, I have
> to press OK many times (depending on the packages needing to be
> installed, of course) in order to get to the end of setup.  Sometimes I
> can get through with a successfull uninstall/install of the necessary
> packages and cygwin1.dll does get installed again.  But the packages
> whose uninstall/install depended on cygwin1.dll, of course, were not
> actually "correctly" uninstalled or installed.
>
> Ideas?  -- Eric

One possible idea is to find out which packages have pre-remove scripts
(run

find /etc/preremove -type f | xargs cygcheck -f | sort -u

to find those) and upgrade them before upgrading everything else.  This,
of course, carries other problems with it (i.e., the postinstall scripts
may need the new versions of cygwin1.dll, etc).  Ultimately, this needs to
be fixed in setup.exe (once we figure out the right way of doing it).
There was some discussion of this in the cygwin-apps archives (search for
"preremove", I think).
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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: Changing root path from /ecos-c/ to /

[Larry Hall]

At 12:20 AM 2/7/2005, you wrote:
>Hi,
>
>I'm using Cygwin. I wish to change the default path for C: from /ecos-c/ to /.
>
>When I type "mount" in cygwin, I get the following:
>
>C:\PFARM\cygwin on / type system (binmode)
>c: on /ecos-c type user (textmode)
>c: on / type user (textmode)
>e: on /cygdrive/e type user (textmode,noumount)
>f: on /cygdrive/f type user (textmode,noumount)
>h: on /cygdrive/h type user (textmode,noumount)
>i: on /cygdrive/i type user (textmode,noumount)
>
>C:\PFARM\examples\EVBA7Board\GNU\Simple\RAMCode>
>
>The utility I'm using fails unless C: on the Windows box is mounted as '/'.
>
>Any suggestions?
>
>Shane.
>
>p.s.
>
>"Whenever Cygwin generates a POSIX path from a Win32 one, it uses the longest 
>matching prefix in the mount table. Thus, if C: is mounted as /c and also 
>as /, then Cygwin would translate C:/foo/bar to /c/foo/bar."
>
>(http://www.cygwin.com/cygwin-ug-net/using.html#mount-table)


Seems like you're answering your own question. Try 'umount -f /ecos-c'.


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


--
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: Setting the Windows Path variable for children of a bash script....

[Igor Pechtchanski]

On Tue, 8 Feb 2005, Matthew Bogosian wrote:

> Howdy all,
>
> I've searched through the archives on this, but I've come up empty, so I
> figured I'd ask
>
> I'm trying to execute a cygwin-ignorant Windows binary from a bash script.
> However, the DLLs required to load this binary are not in the system- or
> user-wide Windows Path variable (nor do I want them to be). I'm trying to
> modify the environment before execution of this binary, but it doesn't seem to
> work. Here's what I've got:
>
> # ...
> Path="$(cygpath -pw "${PATH}");$(cygpath -pw "${LD_LIBRARY_PATH}")"
> export Path
> exec /cygdrive/c/path/to/windows/binary.exe
>
> LD_LIBRARY_PATH contains the paths in which the DLLs specific to binary.exe
> reside. Unfortunately, binary.exe doesn't seem to be able to find them there
> when being invoked from the script's exec command.
>
> Before someone suggests the obvious, I am using Cygwin and bash (etc.) as a
> test harness for a binary I'm writing. I may test several different versions
> of the binary on the same machine. The DLLs cannot reside in c:\windows\...,
> nor can they reside in the same directory as binary.exe because binary.exe is
> actually c:\Python24\python.exe and the DLLs are from different versions of a
> third-party SDK that I'm accessing via swig/python. In short, I need to be
> able to override where the DLLs are found by the cygwin-ignorant version of
> Python in a shell script on an ad hoc basis.
>
> Please don't tell me to use Cygwin's python either, since I have to test the
> Windows version using the same test harness.
>
> Does anyone know how to do this? Any help is much appreciated.

PATH="${PATH}:${LD_LIBRARY_PATH}"
export PATH
exec /cygdrive/c/path/to/windows/binary.exe

The "PATH" variable is treated specially by Cygwin and is translated from
POSIX path format to Windows path format when calling Windows programs.
In your first case it was doing the translation twice, so C:\WINDOWS
became C;C:\WINDOWS.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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: bug in setup.exe?

[Swenson, Eric]

Thanks, Igor.  Would another possible solution be to have setup special case
*only* the cygwin-dll package?  Have it run all the pre-remove scripts
first, then if the cygwin-dll package needs updating, do that, and then do
the rest?  Then, packages that have a dependency on cygwin1.dll in their
scripts can be marked as needing to be run before (or after for post-remove)
the cygwin-dll update.  Then, the actual ordering algorithm is simply: run
pre-remove scripts, remove cygwin.dll, install new cygwin.dll, and then run
post-remove scripts.  

-- Eric

> -Original Message-
> From: Igor Pechtchanski [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 08, 2005 2:59 PM
> To: Swenson, Eric
> Cc: cygwin@cygwin.com
> Subject: Re: bug in setup.exe?
> 
> 
> On Tue, 8 Feb 2005, Swenson, Eric wrote:
> 
> > I've run into the following situation on several machines 
> now, at multiple
> > times -- each with different versions of cygwin (so I'm not 
> following the
> > bug reporting procedure as I think the version information 
> provided by
> > cygcheck isn't really relevant and as I'm currently in a 
> non-cygwin-working
> > state as a result of this issue).
> >
> > Frequently, when running setup.exe and specifying that all 
> packages should
> > be installed (the mode I almost always use), setup.exe bombs while
> > uninstalling a package that it knows it needs to update 
> with the error that
> > cygwin1.dll is not found.  Indeed, at the point the dialog 
> box comes up
> > telling me that cygwin1.dll wasn't found, if I check, it 
> has indeed been
> > deleted from my /bin directory (actually d:\cygwin\bin).  I 
> suspect this is
> > because setup has determined that it needs to upgrade my 
> cygwin1.dll, and
> > therefore must uninstall the old one first and then install 
> the new one.
> > The problem is, that either setup itself (doubtful) or one 
> or more of the
> > uninstall/install scripts needs cygwin1.dll in order to run 
> successfully.
> >
> > Can anyone in the "know" tell me how this is supposed to work?
> 
> This is indeed a (known, long-standing) bug in setup.exe.  
> The problem is
> that some packages have pre-remove scripts that prepare a package for
> removal.  These scripts are run when the packages are removed, which
> happens in alphabetical order of package names, so the 
> scripts will bomb
> out if their packages happen to follow the "cygwin" package
> alphabetically.
> 
> It's clear that one needs to run all pre-remove scripts 
> before removing
> the actual package files.  It's also clear that the 
> alphabetical package
> name order is the wrong order to run pre-remove scripts in.  
> What is not
> clear is what the right order is.  
> . :-)
> 
> > I tried searching the mailing lists, but the cygwin site says that
> > searching was disabled due to your recent disk crash.  I 
> tried searching
> > on google and only found one relevant reference
> > (http://sources.redhat.com/ml/cygwin/2002-12/msg01346.html) and that
> > page didn't lead me to any responses.
> >
> > If you press the ok button on the dialog telling you that 
> cygwin1.dll
> > was not found, setup proceeds with the next package.  
> Frequently, I have
> > to press OK many times (depending on the packages needing to be
> > installed, of course) in order to get to the end of setup.  
> Sometimes I
> > can get through with a successfull uninstall/install of the 
> necessary
> > packages and cygwin1.dll does get installed again.  But the packages
> > whose uninstall/install depended on cygwin1.dll, of course, were not
> > actually "correctly" uninstalled or installed.
> >
> > Ideas?  -- Eric
> 
> One possible idea is to find out which packages have 
> pre-remove scripts
> (run
> 
> find /etc/preremove -type f | xargs cygcheck -f | sort -u
> 
> to find those) and upgrade them before upgrading everything 
> else.  This,
> of course, carries other problems with it (i.e., the 
> postinstall scripts
> may need the new versions of cygwin1.dll, etc).  Ultimately, 
> this needs to
> be fixed in setup.exe (once we figure out the right way of doing it).
> There was some discussion of this in the cygwin-apps archives 
> (search for
> "preremove", I think).
>   Igor
> -- 
>   http://cs.nyu.edu/~pechtcha/
>   |\  _,,,---,,_  [EMAIL PROTECTED]
> ZZZzz /,`.-'`'-.  ;-;;,_  [EMAIL PROTECTED]
>  |,4-  ) )-,_. ,\ (  `'-' Igor Pechtchanski, Ph.D.
> '---''(_/--'  `-'\_) fL   a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
> 
> "The Sun will pass between the Earth and the Moon tonight for a total
> Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
> 

--
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: bug in setup.exe?

[Igor Pechtchanski]

Eric,

Please make sure your mailer honors the Reply-To: field.  I set it for a
reason.  Thanks.

I've also reformatted your top-posted message.  Top-posting is rather
annoying -- if you can possibly avoid it, please do.

On Tue, 8 Feb 2005, Swenson, Eric wrote:

> > -Original Message-
> > From: Igor Pechtchanski [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 08, 2005 2:59 PM
> > To: Swenson, Eric
> > Cc: [EMAIL PROTECTED]

.  Thanks.

> > Subject: Re: bug in setup.exe?
> >
> > On Tue, 8 Feb 2005, Swenson, Eric wrote:
> >
> > > I've run into the following situation on several machines now, at
> > > multiple times -- each with different versions of cygwin (so I'm not
> > > following the bug reporting procedure as I think the version
> > > information provided by cygcheck isn't really relevant and as I'm
> > > currently in a non-cygwin-working state as a result of this issue).
> > >
> > > Frequently, when running setup.exe and specifying that all packages
> > > should be installed (the mode I almost always use), setup.exe bombs
> > > while uninstalling a package that it knows it needs to update with
> > > the error that cygwin1.dll is not found.  Indeed, at the point the
> > > dialog box comes up telling me that cygwin1.dll wasn't found, if I
> > > check, it has indeed been deleted from my /bin directory (actually
> > > d:\cygwin\bin).  I suspect this is because setup has determined that
> > > it needs to upgrade my cygwin1.dll, and therefore must uninstall the
> > > old one first and then install the new one. The problem is, that
> > > either setup itself (doubtful) or one or more of the
> > > uninstall/install scripts needs cygwin1.dll in order to run
> > > successfully.
> > >
> > > Can anyone in the "know" tell me how this is supposed to work?
> >
> > This is indeed a (known, long-standing) bug in setup.exe.  The problem
> > is that some packages have pre-remove scripts that prepare a package
> > for removal.  These scripts are run when the packages are removed,
> > which happens in alphabetical order of package names, so the scripts
> > will bomb out if their packages happen to follow the "cygwin" package
> > alphabetically.
> >
> > It's clear that one needs to run all pre-remove scripts before
> > removing the actual package files.  It's also clear that the
> > alphabetical package name order is the wrong order to run pre-remove
> > scripts in.  What is not clear is what the right order is.
> > . :-)
> >
> > > I tried searching the mailing lists, but the cygwin site says that
> > > searching was disabled due to your recent disk crash.  I tried
> > > searching on google and only found one relevant reference
> > > (http://sources.redhat.com/ml/cygwin/2002-12/msg01346.html) and that
> > > page didn't lead me to any responses.
> > >
> > > If you press the ok button on the dialog telling you that
> > > cygwin1.dll was not found, setup proceeds with the next package.
> > > Frequently, I have to press OK many times (depending on the packages
> > > needing to be installed, of course) in order to get to the end of
> > > setup.  Sometimes I can get through with a successfull
> > > uninstall/install of the necessary packages and cygwin1.dll does get
> > > installed again.  But the packages whose uninstall/install depended
> > > on cygwin1.dll, of course, were not actually "correctly" uninstalled
> > > or installed.
> > >
> > > Ideas?  -- Eric
> >
> > One possible idea is to find out which packages have
> > pre-remove scripts
> > (run
> >
> > find /etc/preremove -type f | xargs cygcheck -f | sort -u
> >
> > to find those) and upgrade them before upgrading everything else.
> > This, of course, carries other problems with it (i.e., the postinstall
> > scripts may need the new versions of cygwin1.dll, etc).  Ultimately,
> > this needs to be fixed in setup.exe (once we figure out the right way
> > of doing it). There was some discussion of this in the cygwin-apps
> > archives (search for "preremove", I think).
> > Igor
>
> Thanks, Igor.  Would another possible solution be to have setup special
> case *only* the cygwin-dll package?  Have it run all the pre-remove
> scripts first, then if the cygwin-dll package needs updating, do that,
> and then do the rest?  Then, packages that have a dependency on
> cygwin1.dll in their scripts can be marked as needing to be run before
> (or after for post-remove) the cygwin-dll update.  Then, the actual
> ordering algorithm is simply: run pre-remove scripts, remove cygwin.dll,
> install new cygwin.dll, and then run post-remove scripts.
>
> -- Eric

In fact, there's no need to special-case cygwin1.dll -- just running the
pre-remove scripts in a batch before all the package files are removed
will work for 99% of the cases.  Feel free to submit a patch on that
one...

Doing it right in general is very tricky, though.  Suppose a pre-remove
script for package B needs to run "Atool" from package 

Re: perl & Win32 lib support

[Yitzchak Scott-Thoennes]

On Tue, Feb 08, 2005 at 12:04:51PM -0800, linda w wrote:
> There must be something else involved or I've messed something else up:
> 
> > perl -v
> This is perl, v5.8.6 built for cygwin-thread-multi-64int
> ...
> 
>I seem to have 5.8.6 installed.  Is there anything else I should
> look at.  I probably have something else messed up somewhere.  :-/
> Sigh.
> 
> -linda
> 
> 
> Yitzchak Scott-Thoennes wrote:
> 
> >Upgrade to perl5.8.6, which addresses the IsWinNT-missing problem.
> >Also, I believe Reini will be releasing a new version of perl-libwin32
> >real soon now.

What exactly is giving the error, and what error are you getting?

--
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: Changing root path from /ecos-c/ to /

[Shane Tolmie]

Hi Larry,
Well, I wish it were that simple. That command doesnt work - it needs 
the Win32 file system to basic utilities like ls, etc.

When eCos is installed, it somehow makes c: mount on /ecos-c, it 
previously was /. We're trying to find a way to put it back.

Shane.
Larry Hall wrote:
At 12:20 AM 2/7/2005, you wrote:
 

Hi,
I'm using Cygwin. I wish to change the default path for C: from /ecos-c/ to /.
When I type "mount" in cygwin, I get the following:
C:\PFARM\cygwin on / type system (binmode)
c: on /ecos-c type user (textmode)
c: on / type user (textmode)
e: on /cygdrive/e type user (textmode,noumount)
f: on /cygdrive/f type user (textmode,noumount)
h: on /cygdrive/h type user (textmode,noumount)
i: on /cygdrive/i type user (textmode,noumount)
C:\PFARM\examples\EVBA7Board\GNU\Simple\RAMCode>
The utility I'm using fails unless C: on the Windows box is mounted as '/'.
Any suggestions?
Shane.
p.s.
"Whenever Cygwin generates a POSIX path from a Win32 one, it uses the longest 
matching prefix in the mount table. Thus, if C: is mounted as /c and also 
as /, then Cygwin would translate C:/foo/bar to /c/foo/bar."

(http://www.cygwin.com/cygwin-ug-net/using.html#mount-table)
   


Seems like you're answering your own question. Try 'umount -f /ecos-c'.
--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 

 

--
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: Setting the Windows Path variable for children of a bash script....

[Matthew Bogosian]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Okay, I could have *sworn* I tried that before and it didn't work, but 
I tried it again, and it seems to be exactly what I wanted/hoped for. 
Ugh...sorry for the unnecessary traffic and thanks for the quick 
response!

-- Matt
On Feb 8, 2005, at 15:07, Igor Pechtchanski wrote:
On Tue, 8 Feb 2005, Matthew Bogosian wrote:
...
I'm trying to execute a cygwin-ignorant Windows binary from a bash 
script.
However, the DLLs required to load this binary are not in the system- 
or
user-wide Windows Path variable (nor do I want them to be). I'm 
trying to
modify the environment before execution of this binary, but it 
doesn't seem to
work. Here's what I've got:

# ...
Path="$(cygpath -pw "${PATH}");$(cygpath -pw "${LD_LIBRARY_PATH}")"
export Path
exec /cygdrive/c/path/to/windows/binary.exe
LD_LIBRARY_PATH contains the paths in which the DLLs specific to 
binary.exe
reside. Unfortunately, binary.exe doesn't seem to be able to find 
them there
when being invoked from the script's exec command.

...
PATH="${PATH}:${LD_LIBRARY_PATH}"
export PATH
exec /cygdrive/c/path/to/windows/binary.exe
The "PATH" variable is treated specially by Cygwin and is translated 
from
POSIX path format to Windows path format when calling Windows programs.
In your first case it was doing the translation twice, so C:\WINDOWS
became C;C:\WINDOWS.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCCVc7nLpDzL5I7l8RAifPAJ9XGh1lXCI/4rnWZ5WV21hojnYeKwCeJbGc
UFID820EZT1+ZKk5SRGrzbo=
=N/u5
-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: bash: tab completion failure from (but not at) /

[Ronald Landheer-Cieslak]

Corinna Vinschen wrote:
On Feb  8 07:19, [EMAIL PROTECTED] wrote:
Recent remarks ("I have an idea about how to fix the race but it would
introduce a destabilizing change that I'd rather not chance before 1.5.13 is
released") suggest that an updated cygwin1.dll might be imminent.
Please could I mention a minor but annoying glitch described along with
Corinna's immediate and effective fix at
http://www.cygwin.com/ml/cygwin/2004-05/msg00449.html but which has
re-emerged in recent snapshots, at least since
http://www.cygwin.com/ml/cygwin/2004-12/msg00838.html, in which Corinna
records her perplexity ("weird") at this re-emergence.
Things worked properly in snapshot 20041222 but fail from 20041223.
Nevertheless, that's a bash problem.  Is our bash maintainer still around?
Yep, still here..
I'll have a look at what your patch in Bash is up to tomorrow (still 
don't have a Windows machine at home) but it should be compiled in - 
there's no reason why it wouldn't be: the only thing I haven't changed 
is a fix for http://cygwin.com/ml/cygwin/2004-09/msg01517.html.

I'll report back when I've checked (ping me if that doesn't happen in 24 
hours - I'm rather busy lately...)

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

Help with deleting Cygwin shortcuts

[Ivan Lenev]

Hello!
Can someone help me with deleting all the files from the 
\Cygwin directory?
I was able to delete about 99% of the files in the 
directories, but some files stated that they cannot be
deleted because "Access is Denied. Make sure the disk is 
not full or write protected." I tried everything from 'Safe 
Mode' to deleting with Cmd. All of these files are 
Shortcuts to some other files. Ex. d:\cygwin\etc\hosts 
cannot be deleted.
I even tried cutting them into the recycle bin. I am also 
sure that the shortcuts are not used by any programs or 
services.
Any help would be appreciated!!!

-Ivan Lenev




--
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 deleting Cygwin shortcuts

[Peter Rehley]

On Feb 8, 2005, at 5:23 PM, Ivan Lenev wrote:
Hello!
Can someone help me with deleting all the files from the
\Cygwin directory?
I was able to delete about 99% of the files in the
directories, but some files stated that they cannot be
deleted because "Access is Denied. Make sure the disk is
not full or write protected." I tried everything from 'Safe
Mode' to deleting with Cmd. All of these files are
Shortcuts to some other files. Ex. d:\cygwin\etc\hosts
cannot be deleted.
I even tried cutting them into the recycle bin. I am also
sure that the shortcuts are not used by any programs or
services.
Any help would be appreciated!!!
-Ivan Lenev

Have you tried change or looking at the permissions on the shortcuts?
Enjoy,
Peter
---
A Møøse once bit my sister
--
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: Re: Help with deleting Cygwin shortcuts

[Ivan Lenev]

I'm pretty sure that I have full access since I'm the only 
user, and I don't see a "Security/Permissions" Tab in the 
properties of any of my files. I'm running WinXP Home, and 
no file sharing.

-Ivan Lenev 

On Tue Feb 8 18:51 , Peter Rehley <[EMAIL PROTECTED]> sent:



On Feb 8, 2005, at 5:23 PM, Ivan Lenev wrote:

> Hello!
> Can someone help me with deleting all the files from the
> \Cygwin directory?
> I was able to delete about 99% of the files in the
> directories, but some files stated that they cannot be
> deleted because "Access is Denied. Make sure the disk is
> not full or write protected." I tried everything 
from 'Safe
> Mode' to deleting with Cmd. All of these files are
> Shortcuts to some other files. Ex. d:\cygwin\etc\hosts
> cannot be deleted.
> I even tried cutting them into the recycle bin. I am also
> sure that the shortcuts are not used by any programs or
> services.
> Any help would be appreciated!!!
>
> -Ivan Lenev
>
>
Have you tried change or looking at the permissions on the 
shortcuts?

Enjoy,
Peter
---
A Møøse once bit my sister


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


-Ivan Lenev




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

strange cp behavior with (coreutils 5.2.1)

[Jane Doe]

$ net use shiva /u:shiva\\administrator
$ cp //shiva/c\$/cvsmq/eqgame.h .
cp: cannot open `//shiva/c$/cvsmq/eqgame.h.exe' for
reading: No such file or directory
$ net use shiva /d
$ net use shiva /u:develop\\dkaa
$ cp -v //shiva/c\$/cvsmq/eqgame.h .
`//shiva/c$/cvsmq/eqgame.h' -> `./eqgame.h'

I think this used to work when cp was part of
fileutils.  The file itself has owner (develop\dkaa)
read permissions but Everyone has no explicit
permissions.  Giving Everyone read permissions makes
it work.

This file was generated with cvs.  On the server:
$ ls -l eqgame.h
-rw-rw-r--1 dkaa group31497 Jan 31 18:25
eqgame.h

Is this a real bug?  Thanks.



__ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.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: Changing root path from /ecos-c/ to /

[Larry Hall]

At 07:13 PM 2/8/2005, you wrote:
>Hi Larry,
>
>Well, I wish it were that simple. That command doesnt work - it needs the 
>Win32 file system to basic utilities like ls, etc.


Huh?  'umount' is a command that doesn't rely on any other command.  It's a
separate executable.  See 'man umount' for more details.


>When eCos is installed, it somehow makes c: mount on /ecos-c, it previously 
>was /. We're trying to find a way to put it back.


True enough.  And technically since this is an issue with eCos, you will
really need to follow-up with them if 'umount' won't work for you for 
some reason and the docs I pointed you to don't help you either.



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


--
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: strange cp behavior with (coreutils 5.2.1)

[Larry Hall]

At 10:15 PM 2/8/2005, you wrote:
>$ net use shiva /u:shiva\\administrator
>$ cp //shiva/c\$/cvsmq/eqgame.h .
>cp: cannot open `//shiva/c$/cvsmq/eqgame.h.exe' for
>reading: No such file or directory
>$ net use shiva /d
>$ net use shiva /u:develop\\dkaa
>$ cp -v //shiva/c\$/cvsmq/eqgame.h .
>`//shiva/c$/cvsmq/eqgame.h' -> `./eqgame.h'
>
>I think this used to work when cp was part of
>fileutils.  The file itself has owner (develop\dkaa)
>read permissions but Everyone has no explicit
>permissions.  Giving Everyone read permissions makes
>it work.


That doesn't sound strange to me at all.  If you don't have any access 
to the file as the user of the share, I wouldn't expect to be able to 
access the file.  


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


--
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: strange cp behavior with (coreutils 5.2.1)

[Jane Doe]

--- Larry Hall
<[EMAIL PROTECTED]> wrote:

> At 10:15 PM 2/8/2005, you wrote:
> >$ net use shiva /u:shiva\\administrator
> >$ cp //shiva/c\$/cvsmq/eqgame.h .
> >cp: cannot open `//shiva/c$/cvsmq/eqgame.h.exe' for
> >reading: No such file or directory
> >$ net use shiva /d
> >$ net use shiva /u:develop\\dkaa
> >$ cp -v //shiva/c\$/cvsmq/eqgame.h .
> >`//shiva/c$/cvsmq/eqgame.h' -> `./eqgame.h'
> >
> >I think this used to work when cp was part of
> >fileutils.  The file itself has owner
> (develop\dkaa)
> >read permissions but Everyone has no explicit
> >permissions.  Giving Everyone read permissions
> makes
> >it work.
> 
> 
> That doesn't sound strange to me at all.  If you
> don't have any access 
> to the file as the user of the share, I wouldn't
> expect to be able to 
> access the file.  

I don't really have a problem with the lack of access,
it's the fact that cp complains about the file with
.exe suffix.  Everyone has read&execute privileges for
the directory of the file so cp should know the file
is there and unreadable.

Thanks.



__ 
Do you Yahoo!? 
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.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: RXVT copy/paste behavior

[Gary R. Van Sickle]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Korn
> Sent: Tuesday, February 08, 2005 1:25 PM
> To: cygwin@cygwin.com
> Subject: RE: RXVT copy/paste behavior
> 
> > -Original Message-
> > From: cygwin-owner On Behalf Of Phil Betts
> > Sent: 08 February 2005 17:09
> 
> > The selection model used by rxvt is standard throughout the 
> X11 world.
> 
>   It's insane.
> 

I'm with you 1000% on this one Korny, and for every reason you've stated.
The short answer to it though is this: contrary to most Unix-heads' beliefs,
the world did not stop on the date that Unix was invented.  Progress (dare I
say, "innovation"?) has in fact occurred since the first line of C code was
written, the last VT-100 terminal was thrown in the trash, and the X-Windows
mess was thought up.

-- 
Gary R. Van Sickle
 


--
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: Changing root path from /ecos-c/ to /

[Shane Tolmie]

Hi Larry,
Tried it again, and it worked this time. Had to restart the shell. 
Thanks for your help.

Shane.
Larry Hall wrote:
At 07:13 PM 2/8/2005, you wrote:
Hi Larry,
Well, I wish it were that simple. That command doesnt work - it needs the Win32 file system to basic utilities like ls, etc.

Huh?  'umount' is a command that doesn't rely on any other command.  It's a
separate executable.  See 'man umount' for more details.

When eCos is installed, it somehow makes c: mount on /ecos-c, it previously was /. We're trying to find a way to put it back.

True enough.  And technically since this is an issue with eCos, you will
really need to follow-up with them if 'umount' won't work for you for 
some reason and the docs I pointed you to don't help you either.


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


--
Regards,
Shane Tolmie (BEng. Elec. Hons.)
Managing Director
DesignREM Ltd.
Cell: +64(21)2977741
Phone: +64(3)3793012
Fax: +64(3)3660118
[EMAIL PROTECTED]
www.designrem.com

This email or attachments may contain confidential or legally privileged 
information intended for the sole use of the addressee(s). Any use, 
redistribution, disclosure, or reproduction of this message, except as 
intended, is prohibited. If you received this email in error, please 
notify the sender and remove all copies of the message, including any 
attachments. Thanks.


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

sshd "ssh_exchange_identification: Connection closed by remote host" until restarted

[David Christensen]

Cygwin:

I recently rebuilt my XP Pro SP2 workstation and re-installed Cygwin.  I noticed
that when the machine is booted, sshd is unresponsive until I manually stop and
restart it:

[EMAIL PROTECTED]:~$ date
Tue Feb  8 21:02:53 PST 2005
[EMAIL PROTECTED]:~$ ssh localhost
ssh_exchange_identification: Connection closed by remote host
[EMAIL PROTECTED]:~$ cygcheck -s -v -r > cygcheck.out
[EMAIL PROTECTED]:~$ date
Tue Feb  8 21:04:01 PST 2005
[EMAIL PROTECTED]:~$ ssh localhost
ssh_exchange_identification: Connection closed by remote host
[EMAIL PROTECTED]:~$ date
Tue Feb  8 21:11:45 PST 2005
[EMAIL PROTECTED]:~$ ssh localhost
ssh_exchange_identification: Connection closed by remote host
[EMAIL PROTECTED]:~$ net stop sshd
The CYGWIN sshd service is stopping.
The CYGWIN sshd service was stopped successfully.

[EMAIL PROTECTED]:~$ net start sshd
The CYGWIN sshd service is starting.
The CYGWIN sshd service was started successfully.

[EMAIL PROTECTED]:~$ ssh localhost
Last login: Tue Feb  8 21:00:49 2005 from localhost
[EMAIL PROTECTED]:~$ exit
logout
Connection to localhost closed.
[EMAIL PROTECTED]:~$


Any suggestions?


TIA,

David


cygcheck.out
Description: Binary data
--
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 deleting Cygwin shortcuts

[Gerrit P. Haase]

Ivan Lenev wrote:
I'm pretty sure that I have full access since I'm the only 
user, and I don't see a "Security/Permissions" Tab in the 
properties of any of my files. I'm running WinXP Home, and 
no file sharing.
XP Home sucks, get a book about XP where is described how
to tweak security settings anyway.
Gerrit
--
=^..^=
--
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/

New user on Cygwin

[BIGONI STEFANO]

Good morning,
I'm Stefano Bigoni, System Admin of University of Ferrara (Italy). I 
installed yesterday CygWin on a Windows XP Professional Platform. I've been 
searching on help the procedure to set-up a sftp external new user, but I 
can't find any information about it.
Could you help me, please?
Thanks in advance
Dott. Stefano Bigoni


--
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: cygwin1.dll crash

[Lannoye Xavier]

hi again

the problem is solved

(blushing...)

I rebooted my computer, and now everything works fine again

thanks for your time;-/


On Tue, 8 Feb 2005 17:06:34 +0100, Lannoye Xavier
<[EMAIL PROTECTED]> wrote:
> I've tried what you said, cleaned my PATH var (using control panel,  ...)
> but it doesn't work.
> still the same problem
> 
> I ran a new IExporer window, to make sure it takes the new path values.
> 
> I could do a full uninstall of cygwin, and install  a clean one, but
> that looks so terrible;-(
> 
> thks
> 
> 
> On Tue, 8 Feb 2005 15:48:41 -, Dave Korn <[EMAIL PROTECTED]> wrote:
> > > -Original Message-
> > > From: cygwin-owner On Behalf Of Lannoye Xavier
> > > Sent: 08 February 2005 14:50
> >
> > > here you have the output for dir /w
> > > its quite huge
> >
> >  Directory of C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86
> >
> > [.]   [..]  a2p.exe   perl.dll
> > perl.exe  perl5.00503.exe   perl95.exeperlglob.exe
> >6 File(s)987.136 bytes
> >
> >   This is ActiveState perl, so I was wrong in my first guess.  I'm still
> > suspicious that it's the root cause of the trouble though; if any of the
> > setup.exe post-install scripts rely on perl, they are liable to invoke 
> > active
> > state perl instead of cygwin perl, and break when it fails to understand
> > cygwin-style POSIX paths.
> >
> > > I've put the cygwin path in top of my PATH var. but still the
> > > same problem
> >
> >   Hmm, peculiar.  May need some more thinking time over this.  Precisely 
> > how did
> > you set it?  If you do it using the PATH command in a DOS prompt, that 
> > wouldn't
> > affect a copy of setup.exe that you launched from explorer, you do need to 
> > set
> > it in Start Menu / Settings / Control Panel / System / Advanced / 
> > Environment
> > Variables.  Try setting your PATH to nothing but these entries:
> >
> > C:\cygwin\bin
> > C:\WINDOWS\system32
> > C:\WINDOWS
> > C:\WINDOWS\System32\Wbem
> >
> > and see if that helps any.
> >
> > 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/
> >
> >
>

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

cygwin digest format

[Gorden Jemwa]

Could the digest format be changed into a single message format 
containing all the messages instead of a single message with other 
messages embeddded as attachments? I don't know what others think but 
IMO its easier to read browse through a single message than opening 
individual attachment, unless (of course) there are strong reasons for 
the current digest format.

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