RE: CygWin and email clients

[Jeremy T. Harrison]

Thank you for your response -- I will look into mutt.

In the meantime, I was able to tweak ssmtp to take attachments (even
inlining graphics,) flexibly work on different ports from the command
line as well as support TLS.  ...One of those days/nights of rampant
creativity.  :)

If anyone is interested in my scripting, let me know.

Jeremy

-Original Message-
From: Reid Thompson [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 30, 2007 8:10 AM
To: Jeremy T. Harrison
Subject: Re: CygWin and email clients

On Sun, 2007-04-29 at 18:07 -0600, Jeremy T. Harrison wrote:
> I have tried with varied success to use "ssmtp" and "email" as my
email
> send applications under CygWin.  For what ssmtp was designed to do, it
> works fine, but, doesn't meet my requirements; "email" seems to be a
> stepchild of sorts, and does not meet my needs (it doesn't support
TLS),
> though I do very much like its flexibility otherwise.
> 
> Are any CygWin users out there using a command line e-mail
application?
> My requirements are basically, that I can send e-mail from the command
> line (i.e. from within scripts and from crontab); include attachments;
> and, use different ports as well as TLS.
> 
> I have read variously of scripts to run ssmtp with attachments; but I
> have not come across any of those scripts.  If anyone might be able to
> direct me to such a script I would be grateful!  Notwithstanding, if
> anyone has a different email solution - that meets requirements
> comparable to mine - I would appreciate learning how you meet your
> needs.
> 
> Thank you!
> 
> Jeremy Harrison
> 
> [EMAIL PROTECTED];[EMAIL PROTECTED]
> 
> 
> 
> --
> 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/
> 

mutt -x -s "this is my subject" -a /this/is/my/attachment
[EMAIL PROTECTED] 

--
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: Puzzling local share permissions problem with ssh sessions on Win2K3

[Andrew DeFaria]

Shankar Unni wrote:

Shankar Unni wrote:

My login groups are incomplete. 


I just saw this post: http://cygwin.com/ml/cygwin/2006-07/msg00129.html

Is this situation still present in the latest (1.5.24) Cygwin?

WAG: Have you done mkgroup -d >> /etc/group?
--
ClearSCM, Inc.
Andrew DeFaria, President 
One reason most people play golf is to wear clothes they wouldn't be 
caught dead in otherwise.



--
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 Cygwin (-mno-cygwin) to JNI to a 3rd party DLL

[Larry Hall (Cygwin)]

On 05/01/2007, Pete Flugstad wrote:
> On 5/1/07, Brian Dessent  wrote:

.  Thanks,

> > You'll have to run this in a debugger to be sure, but I'd start looking
> > at calling convention clashes, i.e. stdcall vs cdecl.  This should be a
> > function of the header files and how they declare prototypes.
> 
> The thing that's odd is that without the 3rd party DLL present, everything
> works just fine.  My JNI functions are called and work (just debug printouts
> in that case).  Only when I actually call the 3rd party DLL (and obviously
> I'm linking against it), does it fail - and it fails before it even
> tries to call
> a function - during the loading phase.

I think the questions you need to ask yourself are:

 o What are you using in place of the 3rd party DLL in the cases where it
   works?
 o How was it compiled?
 o How well do those settings match what the 3rd party DLL used?

Depending what the answers are, it may well describe your successes and
failures.

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

_

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

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

Re: missing functions

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Samuel Thibault on 5/1/2007 5:02 PM:
> Eric Blake, le Tue 01 May 2007 22:55:11 +, a écrit :
>> I noticed a couple of functions that cause link errors even though they are 
>> required by POSIX (or at least will be required by the next version of 
>> POSIX), 
>> implemented by newlib, and declared in the headers:
>>
>> _Exit
>> dprintf
> 
> Mmm, I can't find dprintf in susv3...

What part of "will be required by the next version of POSIX" did you not
catch?

If you are a member of the Austin group (signup is free,
http://www.opengroup.org/austin/lists.html), then you can read the current
draft of POSIX 200x due to come out in the next 2 or 3 years.  Meanwhile,
here is a summary of what is in the current draft:
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=9977

The fact that vdprintf was omitted from v2 of the draft is a bug, and
hopefully it will be fixed before the final release
(https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=10339).

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

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

iD8DBQFGN9nn84KuGfSFAYARAh8FAJkB5NHgzcgkDnG9/3G2svoguguB5QCgvKc4
LXd7y5GdYqd98X1wnxVFr3I=
=+s68
-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: Successfull Build of gcc on Cygwin WinXp SP2

[Aaron Gray]

Aaron Gray wrote:

Thank you. I am a bit unsure of where abouts (what directory) do you 
install

the snapshot ?


Again, this has nothing to do with gcc, take it the Cygwin list.  If you
are using the full snapshots (cygwin-inst-$date.tar.bz2) they should be
unpacked in the root (/).  The other types are just the cygwin1.dll
which goes in /usr/bin of course.  And again, you do *not* need to mess
with any of this to make stdio.h usable for building gcc.  Just take
stdio.h from newlib HEAD and place it in /usr/include.


The FAQ does not seem to say that. From the instructions it would seem it
would go in the current users directory.


Read it again.  Both tar commands include -C which means "cd to this
directory before extacting."


I am a bit confused what winsup is as well.


That is just a directory in the "src" tree that contains the code for
Cygwin, MinGW, w32api, and other miscellaneous Windows things.  But note
that you can't build Cygwin from just winsup/cygwin, as Cygwin needs
other parts of the "src" tree, such as libiberty and newlib.  When you
do a "cvs co cygwin" that is actually a CVS module that gets you a
selected subset of the entire "src" tree, including the toplevel scripts
that are shared across gcc/binutils/gdb/sim/etc.  If you later do "cvs
up" from the toplevel you'll accidently get the entire "src" tree which
you don't need, so you have to do "cvs up" in each individual directory.


Thanks. I think I understand most of that and will try again fresh tommorow.

I'll try not to bother the GCC list if I can possibly avoid it.

Thanks again,

Aaron


--
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: missing functions

[Samuel Thibault]

Eric Blake, le Tue 01 May 2007 22:55:11 +, a écrit :
> I noticed a couple of functions that cause link errors even though they are 
> required by POSIX (or at least will be required by the next version of 
> POSIX), 
> implemented by newlib, and declared in the headers:
> 
> _Exit
> dprintf

Mmm, I can't find dprintf in susv3...

Samuel

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

missing functions

[Eric Blake]

I noticed a couple of functions that cause link errors even though they are 
required by POSIX (or at least will be required by the next version of POSIX), 
implemented by newlib, and declared in the headers:

_Exit
dprintf

There is also a big list of integer-only and reentrant variants of *printf that 
might be worth exporting:

asiprintf, _asiprintf, asiprintf_r, _asiprintf_r, diprintf, _diprintf, 
diprintf_r, _diprintf_r, _dprintf, dprintf_r, _dprintf_r, fiprintf_r, 
_fiprintf_r, fprintf_r, _fprintf_r, iprintf_r, _iprintf_r, printf_r, _printf_r, 
siprintf_r, _siprintf_r, sniprintf, _sniprintf, sniprintf_r, _sniprintf_r, 
snprintf_r, _snprintf_r, sprintf_r, _sprintf_r, vasiprintf, _vasiprintf, 
vasiprintf_r, _vasiprintf_r, vdiprintf, _vdiprintf, vdiprintf_r, _vdiprintf_r, 
vdprintf, _vdprintf, vdprintf_r, _vdprintf_r, vfiprintf_r, _vfiprintf_r, 
vfprintf_r, _vfprintf_r, viprintf, _viprintf, viprintf_r, _viprintf_r, 
vprintf_r, _vprintf_r, vsiprintf, _vsiprintf, vsiprintf_r, _vsiprintf_r, 
vsniprintf, _vsniprintf, vsniprintf_r, _vsniprintf_r, vsnprintf_r, 
_vsnprintf_r, vsprintf_r, _vsprintf_r

The above list does not include my pending addition of the asnprintf family of 
functions to newlib, but that would also be worth exporting.

-- 
Eric Blake



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

Re: using Cygwin (-mno-cygwin) to JNI to a 3rd party DLL

[Pete Flugstad]

On 5/1/07, Brian Dessent <[EMAIL PROTECTED]> wrote:

You'll have to run this in a debugger to be sure, but I'd start looking
at calling convention clashes, i.e. stdcall vs cdecl.  This should be a
function of the header files and how they declare prototypes.


The thing that's odd is that without the 3rd party DLL present, everything
works just fine.  My JNI functions are called and work (just debug printouts
in that case).  Only when I actually call the 3rd party DLL (and obviously
I'm linking against it), does it fail - and it fails before it even
tries to call
a function - during the loading phase.


This is not the right list.  When using -mno-cygwin you aren't using any
of Cygwin, you're essentially cross compiling to MinGW.  So their
mailing list would probably be the right place to ask.


I'll go ask there.  Thanks!!!


The gcc list is
*never* the right place to ask anything relating to debugging program
crashes, unless you can actually identify a specific compiler bug (which
it never is, 99.999% of the time.)


Good to know.

Thanks!
Pete

--
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: Puzzling local share permissions problem with ssh sessions on Win2K3

[Shankar Unni]

Shankar Unni wrote:

My login groups are incomplete. 


I just saw this post: http://cygwin.com/ml/cygwin/2006-07/msg00129.html

Is this situation still present in the latest (1.5.24) 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/

Re: newlib?: pow function can produce incorrect results.

[Cary R.]

Patch generated and applied to newlib CVS. As an added  bonus I fixed a
few other inconsistencies in acos(), asin(), log() and log10().

Cary

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.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: using Cygwin (-mno-cygwin) to JNI to a 3rd party DLL

[Brian Dessent]

Pete Flugstad wrote:

>   But when I add the 3rd party DLL calls back in (and link against the
> link lib),
> everything links OK, but when I try and run it, I get an error from the JVM:
> 
>Load Error: myJni.dll: Invalid access to memory location
>   java.lang.UnsatisfiedLinkError: myJni.dll: Invalid access to
> memory location
> at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
> at java.lang.Runtime.loadLibrary0(Runtime.java:822)
> at java.lang.System.loadLibrary(System.java:993)
> at com.test.jniTest.main(miniAce.java:33)

You'll have to run this in a debugger to be sure, but I'd start looking
at calling convention clashes, i.e. stdcall vs cdecl.  This should be a
function of the header files and how they declare prototypes.

>   I setup the same C code under MSVC and generate with that, and it works
> just fine.  In looking at the MSVC generated DLL, I see that it's symbol names
> have an underscore '_' on the front of them, while the GCC -mno-cygwin
> generated ones do not.   I don't know that that matters, as when I built 
> without
> the 3rd party DLL, it still works.

The name mangling when using stdcall is rather confusing, see
.

>   I realize this may not be the right place for this question - it may
> be more GCC
> related than Cygwin related (especially since I'm using -mno-cygwin),
> but I know the
> guys who did a lot work on LD to make this work are here.  I'm maybe hoping
> someone here has seen this before?  Alternatively, what is the right
> place for this
> question - the main GCC mailing list?  Or maybe it's a Sun/JVM question?

This is not the right list.  When using -mno-cygwin you aren't using any
of Cygwin, you're essentially cross compiling to MinGW.  So their
mailing list would probably be the right place to ask.  The gcc list is
*never* the right place to ask anything relating to debugging program
crashes, unless you can actually identify a specific compiler bug (which
it never is, 99.999% of the time.)

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/

using Cygwin (-mno-cygwin) to JNI to a 3rd party DLL

[Pete Flugstad]

Hello,

 We have a 3rd party Windows DLL that we want to interface with from Java,
obviously using JNI.  The 3rd party DLL provides a link lib to link
against.  It's
a pure C interface (no C++).  I've used the 3rd party DLL just fine for a while
now from MSVC (ver 6), but now we want to call it from Java.

 I've been trying to use Cygwin's GCC with -mno-cygwin to build the JNI
portion - that maps from the JNI call to the actual DLL call -
basically following
the Inonit tutorial ().  I've done
this before very successfully (for rebuilding rxtx serial lib) but not
with a 3rd
party DLL in the mix.

 I've tested out all the JNI stuff by commenting out all the calls to
the 3rd party
DLL, and I can get from Java to the native C code just fine.

 But when I add the 3rd party DLL calls back in (and link against the
link lib),
everything links OK, but when I try and run it, I get an error from the JVM:

  Load Error: myJni.dll: Invalid access to memory location
 java.lang.UnsatisfiedLinkError: myJni.dll: Invalid access to
memory location
   at java.lang.ClassLoader$NativeLibrary.load(Native Method)
   at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
   at java.lang.Runtime.loadLibrary0(Runtime.java:822)
   at java.lang.System.loadLibrary(System.java:993)
   at com.test.jniTest.main(miniAce.java:33)

 Now, I copied the 3rd party DLL to the same directory as my DLL, and as
I'm running this from (and '.' in in my PATH, and in java's
system.library.path).
And I still get the same problem.

 I setup the same C code under MSVC and generate with that, and it works
just fine.  In looking at the MSVC generated DLL, I see that it's symbol names
have an underscore '_' on the front of them, while the GCC -mno-cygwin
generated ones do not.   I don't know that that matters, as when I built without
the 3rd party DLL, it still works.

 It seems like maybe there is some problem with the JVM and loading dependent
libs?   But I thought that that was something that Windows did, not
the JVM?  (we're
using Sun's JVM, 1.5.0_11).

 Eventually I would like to use SWIG to automate wrapping the 3rd
party DLL's API,
but I want to get over this hurdle first.

 I realize this may not be the right place for this question - it may
be more GCC
related than Cygwin related (especially since I'm using -mno-cygwin),
but I know the
guys who did a lot work on LD to make this work are here.  I'm maybe hoping
someone here has seen this before?  Alternatively, what is the right
place for this
question - the main GCC mailing list?  Or maybe it's a Sun/JVM question?

Thanks,
Pete

--
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: [Ping Python maintainer]: enhancement request

[Thorsten Kampe]

* Thorsten Kampe (Tue, 1 May 2007 20:49:59 +0100)
> * Brian Dessent (Tue, 01 May 2007 12:25:15 -0700)
> > Thorsten Kampe wrote:
> > > What about this "winsymlinks" Cygwin environment variable? The
> > > description says "if set, Cygwin creates symlinks as Windows shortcuts
> > > with a special header and the R/O attribute set. If not set, Cygwin
> > > creates symlinks as plain files with a magic number, a path and the
> > > system attribute set. Defaults to set".
> > > 
> > > So why don't the symlinks "work" under Windows (despite being "created
> > > as Windows shortcuts with a special header")??
> > 
> > They do work, in Explorer.  Or in common dialogs, like file-open,
> > file-save-as, etc.  But CMD.EXE doesn't know anything about Explorer
> > shortcuts, so it will never do the right thing.
> 
> I can't confirm that: I've created a shortcut to setup.exe and started 
> the link called setup.lnk in cmd.exe and setup.exe was started. The 
> same with a command line program.

Okay, but the shortcut has to be called with the .lnk extension.


--
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: [Ping Python maintainer]: enhancement request

[Thorsten Kampe]

* Brian Dessent (Tue, 01 May 2007 12:25:15 -0700)
> Thorsten Kampe wrote:
> > What about this "winsymlinks" Cygwin environment variable? The
> > description says "if set, Cygwin creates symlinks as Windows shortcuts
> > with a special header and the R/O attribute set. If not set, Cygwin
> > creates symlinks as plain files with a magic number, a path and the
> > system attribute set. Defaults to set".
> > 
> > So why don't the symlinks "work" under Windows (despite being "created
> > as Windows shortcuts with a special header")??
> 
> They do work, in Explorer.  Or in common dialogs, like file-open,
> file-save-as, etc.  But CMD.EXE doesn't know anything about Explorer
> shortcuts, so it will never do the right thing.

I can't confirm that: I've created a shortcut to setup.exe and started 
the link called setup.lnk in cmd.exe and setup.exe was started. The 
same with a command line program.


--
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: [Ping Python maintainer]: enhancement request

[Brian Dessent]

Thorsten Kampe wrote:

> What about this "winsymlinks" Cygwin environment variable? The
> description says "if set, Cygwin creates symlinks as Windows shortcuts
> with a special header and the R/O attribute set. If not set, Cygwin
> creates symlinks as plain files with a magic number, a path and the
> system attribute set. Defaults to set".
> 
> So why don't the symlinks "work" under Windows (despite being "created
> as Windows shortcuts with a special header")??

They do work, in Explorer.  Or in common dialogs, like file-open,
file-save-as, etc.  But CMD.EXE doesn't know anything about Explorer
shortcuts, so it will never do the right thing.

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: [Ping Python maintainer]: enhancement request

[Thorsten Kampe]

* Jason Tishler (Tue, 01 May 2007 14:32:06 -0400)
> On Tue, May 01, 2007 at 10:21:25AM -0400, Christopher Faylor wrote:
> > OTOH, I still don't see any reason not to tell people "you have to run
> > bash first if you want to use python".
> 
> This is the solution that I prefer.

I think the best solution would be to make the Cygwin symlinks somehow 
"Windows compatible" - so Windows would be able to run those as if 
they were shortcuts.

What about this "winsymlinks" Cygwin environment variable? The 
description says "if set, Cygwin creates symlinks as Windows shortcuts 
with a special header and the R/O attribute set. If not set, Cygwin 
creates symlinks as plain files with a magic number, a path and the 
system attribute set. Defaults to set".

So why don't the symlinks "work" under Windows (despite being "created 
as Windows shortcuts with a special header")??

Thorsten


--
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: Puzzling local share permissions problem with ssh sessions on Win2K3

[Shankar Unni]

Shankar Unni wrote:

Dave Korn wrote:


cygcheck.out: CYGWIN = 'ntsec'
  Perhaps you need smbntsec as well?


Thanks! That did it..


Alas, that didn't *quite* do it.

I finally figured out that I had to uninstall and re-install 
(ssh-host-config) the sshd service, with CYGWIN=ntsec smbntsec.  The 
permissions on files look OK now, but there's still a problem:


My login groups are incomplete. When logged in via remote desktop, my 
groups are:


$ id
uid=13555(sunni) gid=11552(etdev) groups=544(Administrators),555(Remote 
Desktop Users),545(Users),16244(BusinessSignatures e),16487(Development 
Organiza),16381(DL- Global Employees),10513(Domain 
Users),16562(EntrustEmp),11552(etdev),11269(RAS-VPN 
Users),14162(RWC-Remote Users),11284(Terminal Server Users)


But when logged in via sshd, my groups are:
$ id
uid=13555(sunni) gid=11552(etdev) groups=544(Administrators),555(Remote 
Desktop Users),545(Users),11552(etdev)


Basically, all my CORP domain group memberships are missing except my 
primary login group (the user is a CORP domain user, as is the etdev 
group). Notice the missing groups with ids > 1..


(This causes all sorts of subtle permissions problems on certain files 
with more restrictive ACLs. Like all my ClearCase views :-/).


How do I get my sshd login session to contain all the Domain group 
memberships as well?



--
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: [Ping Python maintainer]: enhancement request

[Jason Tishler]

On Tue, May 01, 2007 at 10:21:25AM -0400, Christopher Faylor wrote:
> OTOH, I still don't see any reason not to tell people "you have to run
> bash first if you want to use python".

This is the solution that I prefer.

> I believe that the vast majority of people who use Cygwin always
> invoke click on the cygwin icon and, so, would never even notice this.

Exactly!

On the other hand, since I have received a few requests over the years
to fix the invoking-python-from-cmd problem, I figured I should try to
be more accommadating...

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

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

Re: Cygwin build documentation error.

[Aaron Gray]

Aaron Gray wrote:


I am getting errors on building Cygwin. It appears to be something to do
with the documentation.

Am I missing something simple such as a package like cygwin-doc and if so
where do I get it ?

Error text below...

Many thanks in advance,
[...]

`/usr/build/cygwin/i686-pc-cygwin/winsup/doc'

gcc -g /usr/src/src/winsup/doc/doctool.c -o doctool
./doctool -m -d /usr/src/src/winsup/doc -d /usr/src/src/winsup/utils -d
/usr/src/src/winsup/cygwin -s /usr/src/src/winsup/doc -o 
cygwin-ug-net.sgml

/usr/src/src/winsup/doc/cygwin-ug-net.in.sgml
xmlto html -o cygwin-ug-net/ -m /usr/src/src/winsup/doc/cygwin.dsl
cygwin-ug-net.sgml
usage: xmlto [OPTION]... FORMAT XML



This should go to the Cygwin list.  You're building in winsup, which is
not part of gcc, so this is totally off topic.

The answer is that you probably have a missing package, or maybe a
non-Cygwin/native version of xmlto in your PATH, but we don't know.
Send your cygcheck output as directed in cygwin.com/problems.html.

Brian


I have appended the cygcheck output as an attachment. And append the build 
error output ...


Many thanks in advance,

Aaron

make[3]: Entering directory `/usr/build/cygwin/i686-pc-cygwin/winsup/doc'
gcc -g /usr/src/src/winsup/doc/doctool.c -o doctool
./doctool -m -d /usr/src/src/winsup/doc -d /usr/src/src/winsup/utils -d 
/usr/src/src/winsup/cygwin -s /usr/src/src/winsup/doc -o cygwin-ug-net.sgml 
/usr/src/src/winsup/doc/cygwin-ug-net.in.sgml
xmlto html -o cygwin-ug-net/ -m /usr/src/src/winsup/doc/cygwin.dsl 
cygwin-ug-net.sgml

usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current working directory
 -p postprocopts pass option to postprocessor
 --extensionsturn on stylesheet extensions for this tool chain
 --searchpathcolon-separated list of fallback directories
 --skip-validation
 do not attempt to validate the input before processing

Available FORMATs depend on the type of the XML file (which is
determined automatically).

For documents of type "docbook":
fo
html
html-nochunks
htmlhelp
javahelp
man
txt
xhtml
xhtml-nochunks
xmlto html-nochunks -m /usr/src/src/winsup/doc/cygwin.dsl cygwin-ug-net.sgml
usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current working directory
 -p postprocopts pass option to postprocessor
 --extensionsturn on stylesheet extensions for this tool chain
 --searchpathcolon-separated list of fallback directories
 --skip-validation
 do not attempt to validate the input before processing

Available FORMATs depend on the type of the XML file (which is
determined automatically).

For documents of type "docbook":
fo
html
html-nochunks
htmlhelp
javahelp
man
txt
xhtml
xhtml-nochunks
cp cygwin-ug-net.html cygwin-ug-net/cygwin-ug-net-nochunks.html
rm -f cygwin-ug-net/cygwin-ug-net-nochunks.html.gz
gzip cygwin-ug-net/cygwin-ug-net-nochunks.html
./doctool -m -d /usr/src/src/winsup/doc -d /usr/src/src/winsup/utils -d 
/usr/src/src/winsup/cygwin -s /usr/src/src/winsup/doc -o cygwin-api.sgml 
/usr/src/src/winsup/doc/cygwin-api.in.sgml
xmlto html -o cygwin-api/ -m /usr/src/src/winsup/doc/cygwin.dsl 
cygwin-api.sgml

usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current working directory
 -p postprocopts pass option to postprocessor
 --extensionsturn on stylesheet extensions for this tool chain
 --searchpathcolon-separated list of fallback directories
 --skip-validation
 do not attempt to validate the input before processing

Available FORMATs depend on the type of the XML file (which is
determined automatically).

For documents of type "docbook":
fo
html
html-nochunks
htmlhelp
javahelp
man
txt
xhtml
xhtml-nochunks
xmlto html -o faq -m /usr/src/src/winsup/doc/cygwin.dsl 
/usr/src/src/winsup/doc/faq-sections.xml

usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
 -v  verbose output (-vv for very verbose)
 -x stylesheet   use the specified stylesheet instead of choosing one
 -m fragment use the XSL fragment to customize the stylesheet
 -o directoryput output in the specified directory instead of
 the current working directory
 -p postprocopts pass option to postprocess

Re: Cygwin build documentation error.

[Brian Dessent]

Aaron Gray wrote:

> I am getting errors on building Cygwin. It appears to be something to do
> with the documentation.
> 
> Am I missing something simple such as a package like cygwin-doc and if so
> where do I get it ?
> 
> Error text below...
> 
> Many thanks in advance,
> [...]
`/usr/build/cygwin/i686-pc-cygwin/winsup/doc'
> gcc -g /usr/src/src/winsup/doc/doctool.c -o doctool
> ./doctool -m -d /usr/src/src/winsup/doc -d /usr/src/src/winsup/utils -d
> /usr/src/src/winsup/cygwin -s /usr/src/src/winsup/doc -o cygwin-ug-net.sgml
> /usr/src/src/winsup/doc/cygwin-ug-net.in.sgml
> xmlto html -o cygwin-ug-net/ -m /usr/src/src/winsup/doc/cygwin.dsl
> cygwin-ug-net.sgml
> usage: xmlto [OPTION]... FORMAT XML


This should go to the Cygwin list.  You're building in winsup, which is
not part of gcc, so this is totally off topic.

The answer is that you probably have a missing package, or maybe a
non-Cygwin/native version of xmlto in your PATH, but we don't know. 
Send your cygcheck output as directed in cygwin.com/problems.html.

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: [Ping Python maintainer]: enhancement request

[Christopher Faylor]

On Tue, May 01, 2007 at 03:30:59PM +0100, Thorsten Kampe wrote:
>* Christopher Faylor (Tue, 1 May 2007 10:22:58 -0400)
>>On Tue, May 01, 2007 at 02:59:20PM +0100, Thorsten Kampe wrote:
>>>* Eric Blake (Tue, 01 May 2007 07:27:49 -0600)
According to Thorsten Kampe on 5/1/2007 7:11 AM:
>Both things are actually the same under Cygwin (tested on my FAT32
>flash drive and under Windows XP NTFS).

True only for FAT and FAT32, which don't support hard links at all.

>NTFS supports hard links but these are likely not the same as the Unix
>hard links

Actually, NTFS hard links are supported, and cygwin uses them
(setup.exe, however, currently does not, so making a hard link in a
package won't matter, since setup.exe turns it into a copy anyway).

>and Cygwin ln does not create the Windows ones.

Actually, cygwin ln resorts to whatever cygwin1.dll does in the link()
syscall, and in the case of an NTFS drive, this creates an NTFS hard
link.
>>>
>>>You are right.  Unfortunately you cannot "see" hard links in Cmd or 4NT
>>>"dir" output (while softlinks are displayed as junctions).
>>
>>That's incorrect.  DIR does display hard links, at least on XP.
>
>It displays the file but no information that this is "only" a hard
>link.  With ls you have "-i" to check the inode...

It doesn't matter what DIR displays.

I don't think it's fruitful to spend a lot of time worrying about how
the non-POSIX, non-LINUX, MS-DOS shell interacts with the more advanced
things that Cygwin does.  The whole point of Cygwin is
to make things better so that you don't have to use MS-DOS tools.

Anyway, I'm only still typing because I'm trying to make sure that there
are no misconceptions in this thread which will come back to haunt in
the future.  I don't think that a hard link is the way to go unless
someone wants to fix setup.exe.

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: [Ping Python maintainer]: enhancement request

[Dave Korn]

On 01 May 2007 15:33, Christopher Faylor wrote:

> On Tue, May 01, 2007 at 03:15:52PM +0100, Dave Korn wrote:
>> On 01 May 2007 14:59, Charles Wilson wrote:
>>> Because python is a command interpreter,
> 
>>> Similarly, sh.exe
>> 
>> I think these are two very strong arguments in favour.
> 
> python.exe isn't anything like the interactive shell 

  AFAIUI, that's not what "command interpreter" means.  I though shells were a
subcategory of command interpreters.  YMMV.

>> I note that we already (appear to?) do the same for perl.
> 
> Ok.  I agree that is an argument in favor since I don't recall many
> complaints about perl.  It is a simple copy though, AFAICT.  I've
> registered my objections now and I'll leave the decision to the maintainer.

  Likewise.

>> (/me remembers back to the insane gyrations I had to go through a
>> couple of years ago when I had to setup makefiles for my clients who
>> wanted to invoke them from cmd.exe using --win32 and have them work on
>> systems that could have either cygwin python or active python or both
>> and they could come in any order in the path  )
> 
> This isn't really relevant to the discussion 

  Yes, it was a humorous aside.  I certainly wasn't suggesting trying to
accomodate such exotic corner cases, but it amuses me to describe them.

>since the cygwin version of
> make wouldn't have any problem with symlinks.

  JFTR, --win32 meant that it was using cmd.exe to launch python rather than
bash (and there were redirects in the commands, implying that it had to take
the slow path), which meant no symlinks, which meant those annoying NTVDM
popups when it tries to execute ascii as opcodes.


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: [Ping Python maintainer]: enhancement request

[Charles Wilson]

Christopher Faylor wrote:

On Tue, May 01, 2007 at 03:15:52PM +0100, Dave Korn wrote:

On 01 May 2007 14:59, Charles Wilson wrote:

Because python is a command interpreter,



Similarly, sh.exe

I think these are two very strong arguments in favour.


python.exe isn't anything like the interactive shell that people use on
a day to day basis and simply stating that it is doesn't mean that it is.


Just to clarify, when I say command interpreter I wasn't necessarily 
implying interactive -- just as nobody (I hope) attempts to use /bin/sh 
in its pure, restricted posix mode, as their native interactive shell. 
[side note: IPython, an interactive shell-like python environment -- is 
really cool].  I just meant that python /interprets/ /commands/ 
(possibly -- usually -- in a script).


For ActivePython, you'll see win32 shortcuts with target:

/python.exe 

If cygwin's 'python' is a copy of version x.y, then cygwin users can do 
the same: have win32 shortcuts with target:


/python.exe 

(Now, ActivePython sometimes cheats: it associates .py with itself, and 
often win32 pythoners will just give their scripts a name with that 
extension.  And obviously, windows doesn't, itself, recognize shbang lines)


Granted, there are 57 other, different solutions that don't require 
cygwin's 'python' to be a copy, like invoke version x.y directly from 
the shortcut:


/python2.5 

or cgf's use-bash-first:

/bash.exe python 

or use-bash-first and rely on shbang:
/bash.exe 


But if cygwin does the copy thing, we'd be following the 'principle of 
least surprise' for ActivePython folks (AP is, after all, the other 
major python implementation on win32; IronPython is coming along nicely, 
tho).



'invoke from native win32' means 'from a shortcut OR cmd window' not 
just 'from a cmd window'


--
Chuck

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

[ANNOUNCEMENT] Updated: naim-0.11.8.2.1-2

[Jonathan C. Allen]

Note: Package change, no upstream changes.

PACKAGE DESCRIPTION
===

naim - A console AIM, ICQ, IRC, and Lily client

Homepage: http://naim.n.ml.org/ 
Version : 0.11.8.2.1
License : GPL

naim is a console client for AOL Instant Messenger (AIM),
AOL I Seek You (ICQ), Internet Relay Chat (IRC), and The
Lily CMC.

CYGWIN INSTALLATION INFORMATION
===

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

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

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

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


This message has been sent to cygwin-announce list.

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

[EMAIL PROTECTED]

More information on unsubscribing can be found:

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

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

jca

--
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: [Ping Python maintainer]: enhancement request

[Thorsten Kampe]

* Christopher Faylor (Tue, 1 May 2007 10:22:58 -0400)
> On Tue, May 01, 2007 at 02:59:20PM +0100, Thorsten Kampe wrote:
> >* Eric Blake (Tue, 01 May 2007 07:27:49 -0600)
> >>According to Thorsten Kampe on 5/1/2007 7:11 AM:
> >>>Both things are actually the same under Cygwin (tested on my FAT32
> >>>flash drive and under Windows XP NTFS).
> >>
> >>True only for FAT and FAT32, which don't support hard links at all.
> >>
> >>>NTFS supports hard links but these are likely not the same as the Unix
> >>>hard links
> >>
> >>Actually, NTFS hard links are supported, and cygwin uses them
> >>(setup.exe, however, currently does not, so making a hard link in a
> >>package won't matter, since setup.exe turns it into a copy anyway).
> >>
> >>>and Cygwin ln does not create the Windows ones.
> >>
> >>Actually, cygwin ln resorts to whatever cygwin1.dll does in the link()
> >>syscall, and in the case of an NTFS drive, this creates an NTFS hard
> >>link.
> >
> >You are right.  Unfortunately you cannot "see" hard links in Cmd or 4NT
> >"dir" output (while softlinks are displayed as junctions).
> 
> That's incorrect.  DIR does display hard links, at least on XP.

It displays the file but no information that this is "only" a hard 
link. With ls you have "-i" to check the inode...

Thorsten


--
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: [Ping Python maintainer]: enhancement request

[Christopher Faylor]

On Tue, May 01, 2007 at 03:15:52PM +0100, Dave Korn wrote:
>On 01 May 2007 14:59, Charles Wilson wrote:
>>Because python is a command interpreter,

>>Similarly, sh.exe
>
>I think these are two very strong arguments in favour.

python.exe isn't anything like the interactive shell that people use on
a day to day basis and simply stating that it is doesn't mean that it is.

The only reason that I can see for making a copy would be to support the
use of python in a .bat file.  Otherwise you could always just do
python from the command line.

>I note that we already (appear to?) do the same for perl.

Ok.  I agree that is an argument in favor since I don't recall many complaints
about perl.  It is a simple copy though, AFAICT.  I've registered my objections
now and I'll leave the decision to the maintainer.

>(/me remembers back to the insane gyrations I had to go through a
>couple of years ago when I had to setup makefiles for my clients who
>wanted to invoke them from cmd.exe using --win32 and have them work on
>systems that could have either cygwin python or active python or both
>and they could come in any order in the path  )

This isn't really relevant to the discussion since the cygwin version of
make wouldn't have any problem with symlinks.

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: [Ping Python maintainer]: enhancement request

[Christopher Faylor]

On Tue, May 01, 2007 at 02:59:20PM +0100, Thorsten Kampe wrote:
>* Eric Blake (Tue, 01 May 2007 07:27:49 -0600)
>>According to Thorsten Kampe on 5/1/2007 7:11 AM:
>>>Both things are actually the same under Cygwin (tested on my FAT32
>>>flash drive and under Windows XP NTFS).
>>
>>True only for FAT and FAT32, which don't support hard links at all.
>>
>>>NTFS supports hard links but these are likely not the same as the Unix
>>>hard links
>>
>>Actually, NTFS hard links are supported, and cygwin uses them
>>(setup.exe, however, currently does not, so making a hard link in a
>>package won't matter, since setup.exe turns it into a copy anyway).
>>
>>>and Cygwin ln does not create the Windows ones.
>>
>>Actually, cygwin ln resorts to whatever cygwin1.dll does in the link()
>>syscall, and in the case of an NTFS drive, this creates an NTFS hard
>>link.
>
>You are right.  Unfortunately you cannot "see" hard links in Cmd or 4NT
>"dir" output (while softlinks are displayed as junctions).

That's incorrect.  DIR does display hard links, at least on XP.

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: [Ping Python maintainer]: enhancement request

[Christopher Faylor]

On Tue, May 01, 2007 at 09:59:24AM -0400, Charles Wilson wrote:
>Christopher Faylor wrote:
>>Before you do this, I have a question.  Why is this important now when 
>>you've
>>apparently been doing this for many years?  This isn't the only package 
>>which
>>makes symlinks to executables.  And, since, AFAIK, setup.exe doesn't 
>>understand
>>hard links it means that you really do have to make a copy.  If you make a 
>>copy
>>you stand the chance of having python.exe out of sync with the thing that 
>>it is
>>supposed to be pointing to.
>>
>>If it was a general Cygwin policy to always make copies, I could see 
>>changing
>>Python.  But, again, since it isn't, I don't see why python should be 
>>unique.
>
>Because python is a command interpreter, and therefore likely to be 
>invoked directly from the windows environment -- unlike, say, egrep. 
>Similarly, sh.exe is a copy of bash.exe (and used to be a copy of 
>ash.exe) -- and not a symlink.

I really don't think it's more likely for python to be invoked from the
MS-DOS command line than it is for egrep.  I think it would be quite the
reverse in fact.  I very rarely invoke python or perl as anything other
than a #! script but I use grep every day from the command line and in
scripts.

And, of course, how often have we seen cases where sh.exe was
"inexplicably" not the right version?

>I think this copy (or hardlink) should be performed by a postinstall 
>script -- again, just like sh.exe is updated by bash packages.

We'll have to agree to disagree then.  I think a postinstall step for
this is a band-aid.  If a hard link is required (and I'm not convinced
that it is) then it's time to bite the bullet and implement it in
setup.exe.  I think it's especially bad for python since the whole
reason for the symlink is to allow a versioned python and you lose that
information with a post-install step.

OTOH, I still don't see any reason not to tell people "you have to run
bash first if you want to use python".  I believe that the vast majority
of people who use Cygwin always invoke click on the cygwin icon and, so,
would never even notice this.

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: [Ping Python maintainer]: enhancement request

[Dave Korn]

On 01 May 2007 14:59, Charles Wilson wrote:


> Because python is a command interpreter, 

> Similarly, sh.exe 

  I think these are two very strong arguments in favour.  I note that we
already (appear to?) do the same for perl.

  (/me remembers back to the insane gyrations I had to go through a couple of
years ago when I had to setup makefiles for my clients who wanted to invoke
them from cmd.exe using --win32 and have them work on systems that could have
either cygwin python or active python or both and they could come in any order
in the path )

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: [Ping Python maintainer]: enhancement request

[Thorsten Kampe]

* Eric Blake (Tue, 01 May 2007 07:27:49 -0600)
> According to Thorsten Kampe on 5/1/2007 7:11 AM:
> > Both things are actually the same under Cygwin (tested on my FAT32 
> > flash drive and under Windows XP NTFS).
> 
> True only for FAT and FAT32, which don't support hard links at all.
> 
> > NTFS supports hard links but 
> > these are likely not the same as the Unix hard links
> 
> Actually, NTFS hard links are supported, and cygwin uses them (setup.exe,
> however, currently does not, so making a hard link in a package won't
> matter, since setup.exe turns it into a copy anyway).
> 
> > and Cygwin ln 
> > does not create the Windows ones.
> 
> Actually, cygwin ln resorts to whatever cygwin1.dll does in the link()
> syscall, and in the case of an NTFS drive, this creates an NTFS hard link.

You are right. Unfortunately you cannot "see" hard links in Cmd or 4NT 
"dir" output (while softlinks are displayed as junctions).

Thorsten


--
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: [Ping Python maintainer]: enhancement request

[Charles Wilson]

Christopher Faylor wrote:

Before you do this, I have a question.  Why is this important now when you've
apparently been doing this for many years?  This isn't the only package which
makes symlinks to executables.  And, since, AFAIK, setup.exe doesn't understand
hard links it means that you really do have to make a copy.  If you make a copy
you stand the chance of having python.exe out of sync with the thing that it is
supposed to be pointing to.

If it was a general Cygwin policy to always make copies, I could see changing
Python.  But, again, since it isn't, I don't see why python should be unique.


Because python is a command interpreter, and therefore likely to be 
invoked directly from the windows environment -- unlike, say, egrep. 
Similarly, sh.exe is a copy of bash.exe (and used to be a copy of 
ash.exe) -- and not a symlink.


I think this copy (or hardlink) should be performed by a postinstall 
script -- again, just like sh.exe is updated by bash packages.


--
Chuck

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

Re: [Ping Python maintainer]: enhancement request

[Christopher Faylor]

On Tue, May 01, 2007 at 09:50:31AM -0400, Lev Bishop wrote:
>On 5/1/07, Christopher Faylor  wrote:
>>On Tue, May 01, 2007 at 08:06:23AM -0400, Jason Tishler wrote:
>>>OK.  Should I copy or make a hard link?
>>
>>Before you do this, I have a question.  Why is this important now when
>>you've apparently been doing this for many years?  This isn't the only
>>package which makes symlinks to executables.  And, since, AFAIK,
>>setup.exe doesn't understand hard links it means that you really do
>>have to make a copy.  If you make a copy you stand the chance of having
>>python.exe out of sync with the thing that it is supposed to be
>>pointing to.
>
>You could avoid that particular problem by making a hardlink in a
>postinstall script, right?

That would mean that python.exe wouldn't be owned by any package.

You could also solve the problem at hand by just using sh.exe to invoke
python from a non-Cygwin command prompt.

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: [Ping Python maintainer]: enhancement request

[Lev Bishop]

On 5/1/07, Christopher Faylor  wrote:

On Tue, May 01, 2007 at 08:06:23AM -0400, Jason Tishler wrote:
>OK.  Should I copy or make a hard link?

Before you do this, I have a question.  Why is this important now when you've
apparently been doing this for many years?  This isn't the only package which
makes symlinks to executables.  And, since, AFAIK, setup.exe doesn't understand
hard links it means that you really do have to make a copy.  If you make a copy
you stand the chance of having python.exe out of sync with the thing that it is
supposed to be pointing to.


You could avoid that particular problem by making a hardlink in a
postinstall script, right?

Lev

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

Re: display ps command line parameters

[Igor Peshansky]

On Tue, 1 May 2007, [EMAIL PROTECTED] wrote:

> All,
> Thanks for your replies.
>
> > An alternative would be to parse /proc/PID/cmdline.
>
> I think I'll use Tony's solution, as I don't have pstree available on my
> "development" or "live" Cygwin installation. This would be quicker as I can
> use it straight "out of the box".
>
> I was looking for exactly something like the cmdline file yesterday!


Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

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

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

Re: [Ping Python maintainer]: enhancement request

[Christopher Faylor]

On Tue, May 01, 2007 at 08:06:23AM -0400, Jason Tishler wrote:
>On Sun, Apr 29, 2007 at 11:58:57PM +0100, Thorsten Kampe wrote:
>> I just found out that in the standard Cygwin Python setup it is not 
>> possible to run the Python interpreter from a Win32 command shell. 
>> (You get an error about the NTVDM (NT Virtual DOS machine even when C:
>> \cygwin\bin is in the path).
>
>The following works:
>
>C:\>bash -c python
>Python 2.5 (r25:51908, Mar 13 2007, 08:13:14)
>...
>
>> The reason is that python.exe is a symbolic link to python2.5.exe. As 
>> the Python interpreter itself is only about 43 Kb in size I suggest 
>> copying the interpreter instead of symlinking (Zsh for instance does 
>> the same).
>
>OK.  Should I copy or make a hard link?

Before you do this, I have a question.  Why is this important now when you've
apparently been doing this for many years?  This isn't the only package which
makes symlinks to executables.  And, since, AFAIK, setup.exe doesn't understand
hard links it means that you really do have to make a copy.  If you make a copy
you stand the chance of having python.exe out of sync with the thing that it is
supposed to be pointing to.

If it was a general Cygwin policy to always make copies, I could see changing
Python.  But, again, since it isn't, I don't see why python should be unique.

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: display ps command line parameters

[Christopher Faylor]

On Tue, May 01, 2007 at 10:41:19AM +0100, [EMAIL PROTECTED] wrote:
>> An alternative would be to parse /proc/PID/cmdline. 
>I think I'll use Tony's solution, as I don't have pstree available on my
>"development" or "live" Cygwin installation. This would be quicker as I can
>use it straight "out of the box".
>
>I was looking for exactly something like the cmdline file yesterday!

It seems rather silly to parse /proc/PID/cmdline when you could just use
procps.

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: [Ping Python maintainer]: enhancement request

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Thorsten Kampe on 5/1/2007 7:11 AM:
> Both things are actually the same under Cygwin (tested on my FAT32 
> flash drive and under Windows XP NTFS).

True only for FAT and FAT32, which don't support hard links at all.

> NTFS supports hard links but 
> these are likely not the same as the Unix hard links

Actually, NTFS hard links are supported, and cygwin uses them (setup.exe,
however, currently does not, so making a hard link in a package won't
matter, since setup.exe turns it into a copy anyway).

> and Cygwin ln 
> does not create the Windows ones.

Actually, cygwin ln resorts to whatever cygwin1.dll does in the link()
syscall, and in the case of an NTFS drive, this creates an NTFS hard link.

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

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

iD8DBQFGN0BV84KuGfSFAYARAhBNAKCfFpTntgcNwCD/Xj+/iHP/n88GbQCgzUVn
CR9SNOA/WKzJzjaq/uGPCi4=
=i8wC
-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: [Ping Python maintainer]: enhancement request

[Thorsten Kampe]

* Jason Tishler (Tue, 01 May 2007 08:06:23 -0400)
> On Sun, Apr 29, 2007 at 11:58:57PM +0100, Thorsten Kampe wrote:
> > I just found out that in the standard Cygwin Python setup it is not 
> > possible to run the Python interpreter from a Win32 command shell. 
> > (You get an error about the NTVDM (NT Virtual DOS machine even when C:
> > \cygwin\bin is in the path).
> 
> The following works:
> 
> C:\>bash -c python
> Python 2.5 (r25:51908, Mar 13 2007, 08:13:14)
> ...

Yes, of course. It's just the Win32 Shells (Cmd, 4NT) that don't know 
the Cygwin symlinks
 
> > The reason is that python.exe is a symbolic link to python2.5.exe. As 
> > the Python interpreter itself is only about 43 Kb in size I suggest 
> > copying the interpreter instead of symlinking (Zsh for instance does 
> > the same).
> 
> OK.  Should I copy or make a hard link?

Both things are actually the same under Cygwin (tested on my FAT32 
flash drive and under Windows XP NTFS). NTFS supports hard links but 
these are likely not the same as the Unix hard links and Cygwin ln 
does not create the Windows ones.

Thorsten


--
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: [Ping Python maintainer]: enhancement request

[Jason Tishler]

On Sun, Apr 29, 2007 at 11:58:57PM +0100, Thorsten Kampe wrote:
> I just found out that in the standard Cygwin Python setup it is not 
> possible to run the Python interpreter from a Win32 command shell. 
> (You get an error about the NTVDM (NT Virtual DOS machine even when C:
> \cygwin\bin is in the path).

The following works:

C:\>bash -c python
Python 2.5 (r25:51908, Mar 13 2007, 08:13:14)
...

> The reason is that python.exe is a symbolic link to python2.5.exe. As 
> the Python interpreter itself is only about 43 Kb in size I suggest 
> copying the interpreter instead of symlinking (Zsh for instance does 
> the same).

OK.  Should I copy or make a hard link?

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
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: display ps command line parameters

[[EMAIL PROTECTED]]

All, 

Thanks for your replies.

> An alternative would be to parse /proc/PID/cmdline. 
I think I'll use Tony's solution, as I don't have pstree available on my
"development" or "live" Cygwin installation. This would be quicker as I can
use it straight "out of the box".

I was looking for exactly something like the cmdline file yesterday!

Thanks again!

Andy Burgess

-- 
  _ __   __
//_  /  /| /_  /  /...Your friendly computer professionals
 __//__ /  / |/__ /  / web : jet-net.co.uk
/ phone: 01256 819531 mobile : 07770 808843

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