On Tue, Oct 21, 2003 at 07:26:05PM -0400, Hanson, Rob wrote:
> > 1) If I choose cygwin, the unix development tasks
> > go easier. But the Win32 stuff, in particular
> > Win32::API, etc. is not compiling
>
> It won't compile in cygwin, but there is no reason why you can't use
> ActiveState's Perl with Win32::API under cygwin. Install it outside of
> cygwin, then call it from cygwin just like any other Win32 app.
No, what I want to do is use *cygwin*'s perl with Win32::API calls. If cygwin compiled
natively, then one would have a lot more flexibility; no need for a non-free compiler,
no pathing issues, ability to download and compile the modules I want instead of going
to ppm, etc.
Try this experiment underneath cygwin's shell:
cat /tmp/script.pl
#!/cygdrive/c/perl/bin/perl
print STDERR "Hello, world!\n";
when you run this, you get:
/tmp/script.pl: no such file or directory
because activestate is interpreting /tmp/script.pl as C:\tmp\script.pl, not
C:\cygwin\tmp\script.pl.
> This runs under both cygwin and cmd with ActiveState. Cygwin understands
> "c:/".
>
> perl -e "opendir DIR, 'c:/';print readdir(DIR);closedir DIR"
yes, but what if you want to use commands that are native to the platform, not
perl analogs? And what if you want to do:
use lib "$ENV{HOME}/$path_to_work_on_both_unix_and_nt";
or:
if (-l $filename) { }
if $filename is a cygwin absolute filename (/tmp/whatever), then the activestate perl
script will try to find C:/tmp/whatever and fail.
> > Also perplexing is the lack of support for junctions
> > (reparse points) in -l and link.
>
> I'm not sure what you mean? -l has no use on cmd.
yes it does. link('file','link') works in activestate 5.8.1. link('dir', 'link') does
not. That's what reparse points are: true links for directories on windows.
> > Anyone got decent solutions? One of the things I
> > was thinking of is a 'preprocessor' to perl that
> > takes its arguments (namely script names) and does
> > magical tinkering to change /cygdrive/c into C:
> > before passing it to perl as a filename.
>
> Use "c:/" in cygwin as noted above. I'm not sure what else you would want
> the preprocessor to do.
I'd like the ability for the preprocessor to take the script file name that is fed
to it, and change it on the fly so that cygdrive/mingw paths are translated into
'native' windows paths before passed to the script. I'd also like hard links
for directories to be implemented and testable via -l, and for cygwin to be able to
compile all Win32 modules.
And maybe for 'use lib' to have the same translation done. (I think that anything more
complicated the user should have to do)
> If your concern is that for certain tasks you need to use Win32:: modules on
> windows, and other modules on *nix you can use $^O to determine which OS the
> script is being run on and use that to determine how to carry out an action.
no, my concern is the ability to use perl seamlessly on windows, so I have to do the
minimum amount of porting ability back and forth between the systems. I want:
use lib "$ENV{HOME}/lib";
to work transparently whether or not I'm using cmd.exe, sh.exe(cygwin), sh.exe(mingw),
or sh (unix)
>
> To increase portability you can use the built-in functions like opendir
> instead of `ls` or `dir`. You can also use other modules like Cwd which are
> cross platform.
>
> Hope that helps a little.
yeah, a little. But its still too complicated, things should work IMO a lot more
seamlessly than they do.
Ed
_______________________________________________
Perl-Win32-Users mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
