This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: activestate perl on cygwin

Kevin T Cella wrote:
And what does #! look like?
#! /usr/bin/perl
Is there something that the space after the "!" and before the "/" buys you?
Readability. It is simply a question of style. I prefer the space. Has it come to that?
Has it come to what? I simply asked a question. You provided an answer. Whose undies are in a bunch here?
So your specifically saying by your shebang line - execute Cygwin's perl.
As I state later, I use a symlink so I am infact executing Activestate perl.
I guess it's style too but to me it just doesn't seem to make sense to point to one place then put a symlink in there to point to another place since you're hellbent on using ActiveState. Wouldn't it be much more "stylistic" and clear to simply point directly at the Perl you insist on using? Or did you really mean you are putting /usr/bin/perl in there to appear to be portable? That sort of answer I'd understand... except you have already stated that you don't care about portability.
Seriously, are you trying to attack me or understand the problem? I am trying to be nice, I already apologized for my behavior earlier.
My opinion on this situation does not require that I'm your friend.
what does ls portion after #! in your script return?
Before the conversion using cygpath, it returns the same as in the error: /home/kcella/bin/
So then you are saying that you have no /usr/bin/perl? Is so then why do you put "#! /usr/bin/perl" in your script at all?
I think I misunderstood the question. I had taken it to mean had I executed an ls on the incoming argument to my wrapper script (ie: the script filename), what would be the output. Now I see what you were trying to get at was if the interpreter referenced by the #! line exists on my system. As I state later, I use a symlink:

$ ls -l /usr/bin/perl
lrwxrwxrwx 1 kcella None 20 Jan 13 00:19 /usr/bin/perl ->
Which is confusing. If you wish to use ActiveState then use ActiveState. If you wish to use Cygwin then use Cygwin.
So now you are saying that you have no problem?!?
Keep reading...
The example I gave is for when I have no wrapper script and just create a symlink in /usr/bin/perl that points to /c/Perl/bin/perl.exe.
Huh? There is no /c/... although I've heard of a way to do that I've also heard that it's not supported. Futher, why would you want to symlink /usr/bin/perl -> /c/Perl/bin/perl.exe?!? Or, since you insist on using ActiveState, then why not specifically specify something like #!C:/Perl/bin/perl.exe or something like that?
Again, it is just a question of style.
And it's an answer of confusion. If I were to work on your script I would see /usr/bin/perl and think "Great. He's using a standard perl and I should be able to easily use this under Linux or Cygwin's perl, etc. Wait... Err... No... He's symlinked this to ActiveState!" and would be scratching my head wondering why you attempted to appear "Unix-like" with the shebang line yet are using a proprietary perl....
I have done it both ways, I prefer using linux style pahts.
Which is why I still don't understand why you insist on ActiveState. Yes I know you said you want to use Win32 stuff but there's Win32 stuff that you could use in Cygwin too. If you really like Linux style paths, use Windows and Cygwin, seem to exert full control of the environment I would think using Cygwin's Perl, where you can more easily use Linux style paths not only for shebang but more conveniently throughout your script, would be something you'd want to do...

BTW you never answered the question of what happens in ActiveState when you call setsid. I'll answer it for you. It returns "Not implemented on this platform" or something like that. IOW ActiveState does not implement nor support calling setsid. Why would you want setsid? It's useful in writing daemons, something I do on occasion. Along with that ActiveState doesn't seem to handle signals well. Forgive me here my memory is hazy as I had worked on this problem several years ago. I was attempting to write a daemon that would be essentially a Windows service and wanted it to be a multi threaded server meaning I wanted to fork and exec copies of myself to handle incoming requests. This requires proper signal handling. I was having problems with this so I queried in ActiveState forums and the guy responsible for signals in ActiveState responded that Windows doesn't support signals very well!

Back to Cygwin's Perl I could call setsid as well as wrote a little test program that set, sent and trapped all 30 or so supported signals without a problem. So much for ActiveState!
I mount c: to /c because it is much faster to type than /cygdrive/c/ and it makes more sense from a readability standpoint.
I understand. Personally I use /dev because it's also short, is already there, seems to make sense to me that C is a device and allows me to have /dev/d, etc. However I realize it's non-standard and usually translate my usage of /dev/c -> /cygdrive/c when posting or at least explain that I do it a little differently and how I've done it when explaining my situation...
The root cause of the example is the reason for the initial post. The wrapper script was the solution I happened to choose to get around the path problem, but quickly found out that it does not work properly with: perl -e 'print join "\n", @INC, "\n";'
Oh and what is PATH set to?
/home/kcella/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/c/Perl/bin/:/c /WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem
You could probably also simply use #!perl since C:/Perl/bin is in your path...
Another question of style. Although for me it is more habitual than stylistic. Your questions are very subjective with an insulting tone. I'm sorry if I have offended you in some way.
Like I said, this discussion does not require that I like you or you like me.
Do you at least understand Why the cygwin style paths are causing an issue? And what it is I am trying to accomplish?
You've come in here and asked a question to which you have been given an answer. You insist on mixing together to separate distinct technologies that were not designed to work together where experienced people here advise that you stop fighting the two use the technologies more in the way they were intended than in ways they weren't intended. Ah but you insist on doing it the hard way. "Fine then, have fun with your problem" is not an unreasonable nor should it be an unexpected response for you.


Andrew DeFaria <>
All generalizations are false

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]