jbev2328:

That sounds like a path issue. If you're wanting cygwin to use your Strawberry perl and not the other perl, then in your .bashrc or .bash_profile you can remove the other vendor's bin directories from your PATH. For example, at $work, I needed to edit the PATH, so I put this in my .bashrc:

#20110309 - Remove irrelevent entries from $PATH
PATH=`bin/path_filter.pl`
PATH=$PATH:~/bin
export PATH
[download]

And then in my local bin directory, I put in a little script to patch up PATH as I wanted. (I didn't use anything fancy, so it doesn't matter which perl you run it under.

#!/usr/bin/perl
#
#  path_filter.pl - parse the PATH variable, and return a new path str
+ing with all
#  the duplicates removed, and any entries in the IGNORE hash removed.
#
#  Win/DOS doesn't care much about case sensitivity, so we'll map ever
+ything to lower
#  case on storage so we can remove dups in different cases (specifica
+lly for the
#  case of C:\Windows\System32 vs C:\Windows\system32)
#
# 20110309 roboticus
use strict;
use warnings;

my $DBG=0;

my %IGNORE = map { lc($_)=>0 } (
        "/DOS/c/Program Files/TortoiseSVN/bin",
        "/DOS/c/Program Files/QuickTime/QTSystem",
        "/DOS/c/WINDOWS/system32/WindowsPowerShell/v1.0",
        . . . snip! . . .
        # WBEM=Web-Based Enterprise Management (WMI), not likely neede
+d in Cygwin
        "/DOS/c/WINDOWS/System32/Wbem",
);
my %DUP = ();

my @Path = split /:/, $ENV{PATH};
my @NewPath = ();

for my $dir (@Path) {
        if (! -d $dir) {
                print STDERR "MISSING: $dir\n"  if $DBG;
        }
        elsif (exists $IGNORE{lc $dir}) {
                ++$IGNORE{$dir};
                print STDERR "IGNORED: $dir\n"  if $DBG;
        }
        elsif (exists $DUP{lc $dir}) {
                print STDERR "DUP:     $dir\n"  if $DBG;
                ++$DUP{lc $dir};
        }
        else {
                print STDERR "ADDED:   $dir\n"  if $DBG;
                $DUP{lc $dir}=0;
                push @NewPath, $dir;
        }
}

# Output the new PATH variable
print join(":", @NewPath);
[download]

Once you fix that, though, you may find another annoyance. (I'd be more specific, but it's been a while since I tried using Strawberry perl in a cygwin environment. I think it was some directory name translation issues, but I don't remember for certain.)

...roboticus

When your only tool is a hammer, all problems look like your thumb.

"How do I install Strawberry and Cygwin so they work together?"

Intuitively i think you can't. Don't do it. And reconsider the problem. If you try it nevertheless, i'm sure that this will have some strong impact to your mental health ;-)

As roboticus wrote: "...you may find another annoyance"

Best regards, Karl

Well perhaps this is one of those newbie things but I was under the impression that for file handling I need IO modules that Cygwin provides and a C compiler that Strawberry provides.

For example in one of my scripts I want to open a Windows text file, read it and write it to another file. The vendor provided IO::pty in their distribution but no other file handling modules. they provided modules like expect.pm, SSH::expect, APP::TFTP, etc. I believe I need to include IO::FILE but it doesn't work in Windows unless you have Cygwin.

I tried using just Strawberry but it wouldn't download IO::FILE (not supported in Windows). Strawberry seems just fine except for this IO issue.

Mmh, i hope very much that i don't miss something essential.

I used IO::File for a long time on various Windows systems and i can't imagine that it should be not supported by Strawberry. If that is what you meant. But why don't you simply use open for your file IO?

Regards, Karl

«The Crux of the Biscuit is the Apostrophe»

I am also curious why you want to do this. I went down this road a little bit just to try to get the benefits of the command line with my Strawberry Perl but ultimately decided, after a few headaches, to just use Windows command line.

tinypig:

I don't know about the original poster, but I wanted to try using Strawberry with cygwin just so I could use a more recent perl version than the one you can get with cygwin. It was either: (a) use cygwin's latest perl, (b) make Strawberry more convenient to work with cygin, or (c) build perl from scratch. After trying (b) for a little while, I switched back to cygwin's perl. Then later I started using perlbrew to have multiple distributions.

The windows command line (old style) is just too primitive to use, and the power shell (new style) is too different to bother with. Most of my machines are linux based with bash, so using bash and cygwin is the best fit for me.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

In my environment I have an isolation script, git-like. I will call it 'blah' for the sake of example. There are identically functioning version of blah for cmd, sh, and other environments as needed.

• $BLAH_ROOT/blah shell sets up my operating environment and opens a shell window, via the shell command in my operating environment.
• $BLAH_ROOT/blah frobnitz sets up my operating environment and calls frobnitz in my operating environment.

Basically, I configure the environment to an expected state prior to kicking off the actual worker scripts. The only thing that changes between production, test, my development, your development, and Joe Blogg's development environments are the settings configured in the isolation scripts (blah.cmd, for example). Given this setup, you should be able to isolate your environment from the operating system to be able to interact however you wish it to - including totally ignoring your vendor's minimal installation of perl.

From the OS side of things, if you need to launch something from, for example, a shortcut, you would preface the invocation with the isolation script appropriate for the environment you are launching your real script under. blah plackup myapp.psgi, as an example, would launch your myapp.psgi plack application in the environment configured by blah. You need to change the environment (or launch it in dev, or change the location of a resource, or....), you use a modified isolation script.

You can even take it so far, if you wish, as to pass in the location of all of your resources (databases, data locations, ports, hostnames, and so on) via the environment through your isolation script. As an example, I have a CSV set of data that I use for my user database in development, and in production I use a corporately-maintained LDAP store. The only change is a modification to an environment variable pointing to a different data source (see URI::db and DBD::LDAP). No change in the code, only a change in the data source.

See also twelve factor app.