in reply to perldoc on WinXP - with "less" instead of "more"

There is another package, which contains most Unix-Utilities including less for Windows. It is found under http://unxutils.sourceforge.net/ and is independent of any DLLs. I use it now about three years under NT and W2K without problems.

And it came to pass that in time the Great God Om spake unto Brutha, the Chosen One: "Psst!"
(Terry Pratchett, Small Gods)

  • Comment on Re: perldoc on WinXP - with "less" instead of "more"

Replies are listed 'Best First'.
Re^2: perldoc on WinXP - with "less" instead of "more"
by BrowserUk (Patriarch) on Jun 30, 2004 at 09:38 UTC

    Ditto++. And by avoiding the cygwin layers, they're faster to boot and easier to tweak.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
Re^2: perldoc on WinXP - with "less" instead of "more"
by Intrepid (Curate) on Jul 05, 2004 at 05:20 UTC
    Brutha wrote:
    and is independent of any DLLs

    I went back and forth in my head for a while deciding whether to say anything about this or not. I know I'm going to be d/v'ed, that's a foregone conclusion. I just suppose that its the cumulative experience I have in PMo discussions that leads me to open my mouth.

    There's a lot of misunderstanding regarding MSWindows and projects that port Perl and other *NIX tools to it, here amongst Perlmonks. I'd estimate that less than 10% of the Monks who open their yaps on such topics actually understand everything they're talking about. {Downvote me NOW, please, and get on with the next node}.

    Those *NIX tools are sure not "independent of any DLLs". They are dependent on MSVCRT.DLL. If this file isn't present, they aren't going to work. It's a "native" MSWindows DLL that Cygwin "replaces" (the role, not the actual file) with a "cygwin.dll".

    GnuWin32 != Cygwin
    unxutils != GnuWin32 != Cygwin
    mingw  !=  GnuWin32 != Cygwin
    

    • Cygwin is (largely) GNU software ported to the Cygwin psuedo-platform (linking to the C library CYGWIN.DLL)
    • GnuWin32 is (largely) GNU software ported to compile with GNU tools on the MSWin32 platform (linking to the C library MSVCRT.DLL) using the mingw toolset.
    • MinGW32 is the development platform begun for porting *NIX applications to run with linkage to only the native MSWindows C library "MSVCRT.DLL". It's now also used by people who hardly know what "GNU" means, however. It is GNU gcc, and all the binutils, and a large collection of system headers, and more. It started as an outgrowth of Cygwin. People say/write mingw and MinGW and MinGW32 interchangeably, but to me "mingw" is the entire collection of software and the community that supports it; "MinGW32" is the build platform (what to target C Preprocessor defines to, etc.). Obviously "32" refers to "32-bit" and someday there could be a MinGW64.
    • unxutils is out there in left field: who knows how they build their apps, they likely use Borland or MSVC or maybe sometimes MinGW by now. They don't document (Mailing Lists, etc.) like MinGW or Cygwin, and using their binary builds is fine if it works for you, but to me its a gamble and a short-sighted strategy. IMHO.

    Hopefully it is a little clearer now. I'd like to see some of the superstition and half-truths prevalent in the Monastery community dispelled wrt Cygwin and the rest of this. Of course for that to really happen, Monks will have to become interested in something besides Perl. I know that few Monks listen to me, because I'm not "nice" and meek and mild-mannered.

      s/cygwin.dll/cygwin1.dll/gi

      It's not just that dll, either. The cygwin gcc uses these:

      Found: C:\cygwin\bin\gcc.exe C:/cygwin/bin/gcc.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\System32\ADVAPI32.DLL C:\WINDOWS\System32\ntdll.dll C:\WINDOWS\System32\KERNEL32.dll C:\WINDOWS\System32\RPCRT4.dll C:\cygwin\bin\cygintl-2.dll C:\cygwin\bin\cygiconv-2.dll

      More and more things in cygwin will rely not just on the dll, but on the cygserver service running as time goes on.