AWK - What version of GAWK to use under DOS/Windows (Was: Re: problem w/cmd line quoting in

Author

What version of GAWK to use under DOS/Windows (Was: Re: problem w/cmd line quoting in

Kenny McCormack

2005-04-27, 3:56 am

In article <kdsh61h8lp7a0c3o2at43n27vuogh0cocf@4ax.com>,
Ted Davis <tdavis@gearbox.maem.umr.edu> wrote:
....
>
>Compiled with a Windows compiler, perhaps with specific modifications
>for use in the Windows console environment. The Cygwin version is
>intended for use in the Cygwin environment though it does seem to work
>in the pure Windows environment (Cygwin is installed and configured
>for DOS style files). I seem to remember that they fail differently
>when asked to do Unix specific things like bidirectional pipes and
>direct read/write to TCP/IP, though they both fail.

Points:
1) The Cygwin version works just fine with the standard Windows command
interpreters (COMMAND.COM, CMD.EXE)
2) The Unixy stuff works just fine as well. It does *not* work in any
of the "native" compiled versions.
3) Most of the "problems" that people report when using Unix tools with
standard Windows command interpreters (COMMAND.COM, CMD.EXE) are,
as I am sure you are well aware, quoting problems, which have
nothing to do with the tools and everything to do with the
brain-dead Microsoft programming efforts. The all around best
solution to these "problems", and certainly in the context of AWK, is
to put the program in a file, use the -f option, and forget about
the stupid command line.
4) (However) In fact, at least some of these "problems" go away if you
are using CMD.EXE and know how to use it properly. But a lot of us
got used to COMMAND.COM and aren't aware that MS has actually made
things a little better in CMD.EXE.
5) Your implication that a "true" version is somehow better than
the Cygwin version is a common prejudice. Duly noted.

Kenny McCormack

2005-04-27, 3:56 am

In article <nkoi61hds8i891sgdngoti3ahbt67k46vv@4ax.com>,
Ted Davis <tdavis@gearbox.maem.umr.edu> wrote:[color=darkred]
>On Fri, 22 Apr 2005 17:26:13 GMT, gazelle@yin.interaccess.com (Kenny
>McCormack) wrote:
>

<Long description of problems that I've never encountered - deleted.
(see previous post)>

It must suck to be you.

Brian Inglis

2005-04-28, 8:56 am

fOn Fri, 22 Apr 2005 16:03:22 -0500 in comp.lang.awk, Ted Davis
<tdavis@gearbox.maem.umr.edu> wrote:

>On Fri, 22 Apr 2005 17:26:13 GMT, gazelle@yin.interaccess.com (Kenny
>McCormack) wrote:
>
>When it doesn't crash the DOS emulator and/or the command processor,
>or just doesn't work at all. In the bash context,
> awk -W version
>returns the gawk version - in the CMD environment, it simply returns
>... one time it trashed the window and halted the emulator.

CMD.EXE and Cygwin are both "pure" Windows code: CMD is a Windows
console app, and Cygwin is (mainly) a Windows DLL; the VDM (Virtual
DOS Machine) is not involved.
Your symptoms sound like awk.exe may be a DOS program, which may not
work properly, at all, or cause problems, under NT-based systems.

> gawk -W version returns the same information in Cygwin, and does
>work in CMD. (I am aware that awk.exe is some kind of wrapper that
>depends on the Cygwin environment being present, but it is not unusual
>to refer to gawk as awk in commands.)
>
>
>Not true for the ones I mentioned - they depend on the underlying OS
>for the basic functionality which doesn't exist. I am talking XP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
How can anything depend on functionality which doesn't exist?

>here, so the behavior does vary from machine to machine and from time
>to time on the same machine.
Shouldn't if installed as administrator, except for policies and
permissions on files; sounds more like a DOS app.

>
>Windows command line quoting protocols are absurd, but there are some
>instances where Unix-like quoting can be used.
Will depend on the app; running Cygwin bash is the best guarantee.

>
>That would be true except that some behaviors can't be counted on to
>persist from session to session.
In what way can a deterministic machine's behaviour vary from session
to session?

>
>Not better - more appropriate for the Windows environment. Less
>likely to suprise.
There's no difference between running with the Cygwin DLL or with all
the routines from another library statically linked into the app,
other than disk and memory footprint: native Windows calls are
performed in both cases.

Read up on Windows and Cygwin basics before commenting.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]a
b[dot]ca)
fake address use address above to reply

Ted Davis

2005-04-28, 3:57 pm

On Thu, 28 Apr 2005 10:09:59 GMT, Brian Inglis
<Brian.Inglis@SystematicSW.Invalid> wrote:

>fOn Fri, 22 Apr 2005 16:03:22 -0500 in comp.lang.awk, Ted Davis
><tdavis@gearbox.maem.umr.edu> wrote:
>
>
>CMD.EXE and Cygwin are both "pure" Windows code: CMD is a Windows
>console app, and Cygwin is (mainly) a Windows DLL; the VDM (Virtual
>DOS Machine) is not involved.
>Your symptoms sound like awk.exe may be a DOS program, which may not
>work properly, at all, or cause problems, under NT-based systems.

!<symlink>gawk.exe

is not a pure Windows .exe program - it isn't any kind of MS .exe
program, but that's what c:\cygwin\bin\awk.exe consists of. The last
(19th) byte (not visable) is a null.

>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>How can anything depend on functionality which doesn't exist?

The above awk.exe is an example: it depends on being launched by bash
in a Cygwin environment - if the environment isn't present, it fails,
and fails because a dependency wasn't satisified. In Linux, many
attempts to install RPMs fail because some dependency is not
satisified due to the absence of some functionality, usually a library
(though curioously, netcomics and netcomics data programs depend on
each other, so the dependencies of both are not present until both
programs are present).
>
>Shouldn't if installed as administrator, except for policies and
>permissions on files; sounds more like a DOS app.

DOS was predictable - if it worked one way today, it would work the
same way tomorrow ... it either worked or it didn't. That is not true
of XP.
>
>Will depend on the app; running Cygwin bash is the best guarantee.
>
>In what way can a deterministic machine's behaviour vary from session
>to session?

XP is not deterministic in the usual sense: predicting its behavior
requires detailed knowledge of everything that has happened to the
machine since last boot. Keep in mind that MS produced at least one
OS that failed in strange ways after it had been up for some number of
days regardless of how the machine was used or not used (it took years
to detect this since the OS was highly unlikely to stay up that long).
>
>There's no difference between running with the Cygwin DLL or with all
>the routines from another library statically linked into the app,
>other than disk and memory footprint: native Windows calls are
>performed in both cases.

Except that the libraries are different - you are saying that
different libraries perform the same. One of the differences is that
the Cygwin DLL implements Unix-like functions - if the OS cannot
perform the function, the DLL has to provide a stub function to deal
with calls that would be passed on to the OS in the environment for
which the calling program's source code was originally written. If
Windows doesn't provide a functionality, the DLL must supply it, and
if the OS makes the functionality impossible, the DLL must fail calls
to it. Native Windows programs - those written exclusively for
Windows don't include calls to nonimplemented functions.
>
>Read up on Windows and Cygwin basics before commenting.

You are saying that the WIndows and Cygwin environments are identical
as far as Cygwin applications are concerned, and I have proven that
they are not. There wouldn't be any reason to have Cygwin if Windows
didn't need a lot of translation and gap filling to provide the vastly
different Unix-like environment of Cygwin - and there is more to that
environment than just the look and feel of the shell.

--
T.E.D. (tdavis@gearbox.maem.umr.edu)
SPAM filter: Messages to this address *must* contain "T.E.D."
somewhere in the body or they will be automatically rejected.

Brian Inglis

2005-04-29, 8:55 am

On Thu, 28 Apr 2005 08:26:43 -0500 in comp.lang.awk, Ted Davis
<tdavis@gearbox.maem.umr.edu> wrote:

>On Thu, 28 Apr 2005 10:09:59 GMT, Brian Inglis
><Brian.Inglis@SystematicSW.Invalid> wrote:
>
>
> !<symlink>gawk.exe
>
>is not a pure Windows .exe program - it isn't any kind of MS .exe
>program, but that's what c:\cygwin\bin\awk.exe consists of. The last
>(19th) byte (not visable) is a null.

It's an (obsolete) old style Cygwin symlink, which can be converted to
a Cygwin shortcut in newer releases. That directory should not be in
the Windows path unless you convert the symlinks to shortcuts.

>
>The above awk.exe is an example: it depends on being launched by bash
>in a Cygwin environment - if the environment isn't present, it fails,
>and fails because a dependency wasn't satisified. In Linux, many
>attempts to install RPMs fail because some dependency is not
>satisified due to the absence of some functionality, usually a library
>(though curioously, netcomics and netcomics data programs depend on
>each other, so the dependencies of both are not present until both
>programs are present).
>
>DOS was predictable - if it worked one way today, it would work the
>same way tomorrow ... it either worked or it didn't. That is not true
>of XP.
?

>
>XP is not deterministic in the usual sense: predicting its behavior
>requires detailed knowledge of everything that has happened to the
>machine since last boot. Keep in mind that MS produced at least one
>OS that failed in strange ways after it had been up for some number of
>days regardless of how the machine was used or not used (it took years
>to detect this since the OS was highly unlikely to stay up that long).
IIRC that bug existed in the MFC library, so it was in the OS and also
every application.

>
>Except that the libraries are different - you are saying that
>different libraries perform the same. One of the differences is that
>the Cygwin DLL implements Unix-like functions - if the OS cannot
>perform the function, the DLL has to provide a stub function to deal
>with calls that would be passed on to the OS in the environment for
>which the calling program's source code was originally written. If
>Windows doesn't provide a functionality, the DLL must supply it, and
>if the OS makes the functionality impossible, the DLL must fail calls
>to it. Native Windows programs - those written exclusively for
>Windows don't include calls to nonimplemented functions.
>
>You are saying that the WIndows and Cygwin environments are identical
>as far as Cygwin applications are concerned, and I have proven that
>they are not.

I'm saying that Cygwin is just another Windows DLL and looks the same
to Windows as any other DLL, so they're identical as far as Windows is
concerned.

>There wouldn't be any reason to have Cygwin if Windows
>didn't need a lot of translation and gap filling to provide the vastly
>different Unix-like environment of Cygwin - and there is more to that
>environment than just the look and feel of the shell.

No different from any other Windows applications which have
dependencies on other DLLs.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]a
b[dot]ca)
fake address use address above to reply

Kenny McCormack

2005-04-29, 8:55 am

In article <qbo371tutpun02662r7iumi600s3abfgd6@4ax.com>,
Brian Inglis <Brian.Inglis@SystematicSW.ab.ca> wrote:
>On Thu, 28 Apr 2005 08:26:43 -0500 in comp.lang.awk, Ted Davis
><tdavis@gearbox.maem.umr.edu> wrote:
....
[color=darkred]
>?

</Totally-OT-in-comp.lang.awk/>

I will post a fuller response to Ted's latest post at some point when
I have more time, but for now I will just comment on your terse, but
heartfelt, '?' comment.

I'm guessing that you've never used XP, and are coming from the general
Unix (and, for that matter, earlier versions of MS-ware) perspective - and
the general idea that computers *are* deterministic. And that OSs (yes,
even from MS - at least up until now) are written in good faith.

I am here to say that with XP, 'taint so. The reasons are probably deeper
than I care to go into at the moment, but if you've ever used it, you will
see that it is a freakin' pinball machine of an OS. It does all kinds of
stuff behind your back, constantly pops up little balloons telling you to
do this or to do that, and seems more like a video game than an OS (at
least in the sense that, and to the sensibilities of how, a non - [home-user
or Mac user] expects an OS to behave). Total aside: I can't believe that
MS expects their usual, business-or-at-least-somewhat-serious, user base to
be comfortable with XP - they must have something else in mind, besides its
being just a "Mac killer".

It is also true that a lot of XP's nuttiness can be calmed down by using
something other than EXPLORER.EXE as your shell - and, to be quite blunt,
I can't imagine anyone with a mental age over 12 using the default shell
(and keeping their sanity).

P.S. That said, I actually kind of like XP as an underlying OS - how it
combines NT stability with DOS/'98 semantics. But, as noted, the default
UI (shell) is nuts.

Brian Inglis

2005-05-01, 3:56 pm

Kenny McCormack

2005-05-01, 3:56 pm

Sponsored Links