Mail Archives: cygwin/2007/01/13/10:58:56
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/myscript.pl
>> So then you are saying that you have no /usr/bin/perl? Is so then why
>> do you put "#! /usr/bin/perl" in your script at all?
> I think I misunderstood the question. I had taken it to mean had I
> executed an ls on the incoming argument to my wrapper script (ie: the
> script filename), what would be the output. Now I see what you were
> trying to get at was if the interpreter referenced by the #! line
> exists on my system. As I state later, I use a symlink:
>
> $ ls -l /usr/bin/perl
> lrwxrwxrwx 1 kcella None 20 Jan 13 00:19 /usr/bin/perl ->
> /c/Perl/bin/perl.exe
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 <http://defaria.com>
All generalizations are false
--
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/
- Raw text -