FAQ

On Fri, Jul 1, 2011 at 9:23 AM, David Cantrell wrote:
I went through a period of trying to make sure my code worked on
Windows, but I've given up.  Not because it's hard to do - it generally
isn't - but the complete lack of a reasonable set of tools* on Windows,
which just makes me angry whenever I have to touch the blasted thing,
made me stop.

* starting with a useable shell and editor, documentation, and remote
text-based access.  No doubt it doesn't help that I have no need for
Windows, either personally or professionally, so have no motivation
to put the effort into learning it.
Definitely the lack of remote text based access makes it harder. But
for anyone willing to run Windows in a virtual machine, it's not
terribly hard anymore. Personally, I use VirtualBox on Ubuntu with a
Windows 7 guest. I suggest WinXP if you have old licenses kicking
around, as it's a little less annoying about validation and such.

Gabor has made it really easy to get Padre and Strawberry Perl
together: http://padre.perlide.org/download.html

I also note that gvim runs wonderfully on Windows:
http://www.vim.org/download.php#pc -- if you prefer that over Padre,
then you only need to install Strawberry Perl:
http://strawberryperl.com/

When I was working on Windows regularly, the regular cmd.exe shell
worked well enough once I added a bunch of ported gnu programs to my
path: http://unxutils.sourceforge.net/ -- that let me keep typing
"ls", "cp", "mv" etc.

IMPORTANT -- be sure to rename/delete all of the tar/zip programs
because they are buggy and you don't want your CPAN config finding
them. You also need to rename any that conflict with windows
programs (I seem to recall "find" I renamed to "myfind" or something
like that.)

If you use git for source control and want to use it to get your code
onto the windows box, I recommend using TortoiseGit:
http://code.google.com/p/tortoisegit/

Best of luck!

-- David

Search Discussions

  • Eric Wilhelm at Jul 9, 2011 at 8:04 am
    # from David Golden
    # on Saturday 02 July 2011 03:51:
    On Fri, Jul 1, 2011 at 9:23 AM, David Cantrell wrote:
    ... the complete lack of a reasonable set of
    tools* on Windows, which just makes me angry whenever I have to
    touch the blasted thing, made me stop.

    * starting with a useable shell and editor, documentation, and
    remote text-based access.  ...
    Definitely the lack of remote text based access makes it harder.  But
    for anyone willing to run Windows in a virtual machine, it's not
    terribly hard anymore.  Personally, I use VirtualBox on Ubuntu with a
    Windows 7 guest.  I suggest WinXP if you have old licenses kicking
    around, as it's a little less annoying about validation and such.
    With a VM install, you still have to wade through the boggy experience
    of mousing-around in a completely foreign environment while swearing at
    the shell for being completely unreasonable about everything. But none
    of this has anything to do with whether your code works on Windows,
    only whether you can work within it. IMO, it would be much better to
    not be actually using windows (or mac for that matter) if that's not
    your preferred environment and you just need to debug some
    compatibility issue.

    Not to mention the general case of a CPAN author, where you can't assume
    that they could be bothered to *obtain* a windows/mac OS, let alone
    boot it. Some open and deployable environment / test kit would go much
    further than anything involving a VM and proprietary license. I think
    the utter lack of convenience in testing for and fixing cross-OS bugs
    is the big barrier to getting better cross-OS support. Nobody likes
    coding in the dark with a hours-long latency to see if their fix works.

    I had no luck getting things to build under wine (IIRC, the trouble came
    with XS modules), but it's been a few years and I haven't messed with
    it lately. If it did work well, I'm not sure how much it would gloss
    over issues of command-not-found and backslashed-path errors.

    It seems like you could construct a pretty thoroughly windowsish
    environment by hiding all useful commands (e.g. rename /bin,/usr/bin)
    and unsetting $PATH, then make some working/temp directories with
    spaces in the names. That would catch most of the common problems.
    Not sure if you could emulate the brokenness of the backslashes on a
    *nix though.

    --Eric
    --
    Peer's Law: The solution to the problem changes the problem.
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • Serguei Trouchelle at Jul 9, 2011 at 8:38 am

    Eric Wilhelm wrote:

    With a VM install, you still have to wade through the boggy experience
    of mousing-around in a completely foreign environment while swearing at
    the shell for being completely unreasonable about everything.
    I know that Norton Commander clones generally are not used anywhere outside the former Soviet Union, but you may take a
    look at Far Commander ( http://www.farmanager.com/download.php?l=en ) and install MSYS and MinGW (and optionally: 1.
    install ActivePerl, 2. Install StrawberryPerl).
    After that, you should have something close to your working environment, and more (thanks to Far Cmdr).
    It seems like you could construct a pretty thoroughly windowsish
    environment by hiding all useful commands (e.g. rename /bin,/usr/bin)
    and unsetting $PATH, then make some working/temp directories with
    spaces in the names. That would catch most of the common problems.
    Not sure if you could emulate the brokenness of the backslashes on a
    *nix though.
    Perl on Windows doesn't have any problems with straight slashes. Unless you do my $bla = `/bin/sh`;
    Something like "open (my $FILE, '<', '/Windows/TEMP/File.txt')" works just fine, though I would recommend using
    File::Spec->cat just to be sure.

    P.S. Programming in Perl on the Windows as primary platform for more than 10 years.

    --
    Serguei Trouchelle
  • David Golden at Jul 9, 2011 at 10:31 am

    On Sat, Jul 9, 2011 at 4:03 AM, Eric Wilhelm wrote:
    Not to mention the general case of a CPAN author, where you can't assume
    that they could be bothered to *obtain* a windows/mac OS, let alone
    I think you're missing the point of my post, which was to offer a way
    for people to try it without a lot of hassle if they were inclined to
    do so but not sure how.

    I certainly wasn't preaching that all CPAN authors must set up Windows VMs.

    -- David
  • David Cantrell at Jul 11, 2011 at 10:35 am

    On Sat, Jul 09, 2011 at 01:03:49AM -0700, Eric Wilhelm wrote:
    # from David Golden
    On Fri, Jul 1, 2011 at 9:23 AM, David Cantrell wrote:
    ... the complete lack of a reasonable set of
    tools on Windows, which just makes me angry whenever I have to
    touch the blasted thing, made me stop.
    Definitely the lack of remote text based access makes it harder.  But
    for anyone willing to run Windows in a virtual machine, it's not
    terribly hard anymore ...
    With a VM install, you still have to wade through the boggy experience
    of mousing-around in a completely foreign environment while swearing at
    the shell for being completely unreasonable about everything. But none
    of this has anything to do with whether your code works on Windows,
    only whether you can work within it. IMO, it would be much better to
    not be actually using windows (or mac for that matter) if that's not
    your preferred environment and you just need to debug some
    compatibility issue.
    How can I debug a problem that only happens on Windows without using
    Windows?
    Not to mention the general case of a CPAN author, where you can't assume
    that they could be bothered to *obtain* a windows/mac OS, let alone
    boot it. Some open and deployable environment / test kit would go much
    further than anything involving a VM and proprietary license.
    Adam Kennedy tried to help with this, by persuading Microsoft to make a
    few VMs available for perly people to use. I have no idea how
    successful it's been.
    I think
    the utter lack of convenience in testing for and fixing cross-OS bugs
    is the big barrier to getting better cross-OS support. Nobody likes
    coding in the dark with a hours-long latency to see if their fix works.
    This is why, when I can, I set up some kind of guest account on machines
    that I use for CPAN-testing, so that authors can debug and fix things
    themselves rather than rely on me to be "remote hands" which might have
    a several *week* latency.

    --
    David Cantrell | Minister for Arbitrary Justice

    When one has bathed in Christ there is no need to bathe a second time
    -- St. Jerome, on why washing is a vile pagan practice
    in a letter to Heliodorus, 373 or 374 AD

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmodule-authors @
categoriesperl
postedJul 2, '11 at 10:51a
activeJul 11, '11 at 10:35a
posts5
users4
websitecpan.org...

People

Translate

site design / logo © 2021 Grokbase