Gawk 4.1.4 released!

[Aharon Robbins]

Greetings all.

This note announces the next release of GNU Awk: version 4.1.4.

The following files may be retrieved from ftp://ftp.gnu.org/gnu/gawk,
or via HTTP from http://ftp.gnu.org/gnu/gawk:

-rw-rw-r-- 1 arnold arnold 4582398 Aug 25 08:41 gawk-4.1.4.tar.gz
-rw-rw-r-- 1 arnold arnold 473 Aug 25 21:10 gawk-4.1.4.tar.gz.sig
-rw-rw-r-- 1 arnold arnold 2308296 Aug 25 08:41 gawk-4.1.4.tar.lz
-rw-rw-r-- 1 arnold arnold 473 Aug 25 21:10 gawk-4.1.4.tar.lz.sig
-rw-rw-r-- 1 arnold arnold 2367832 Aug 25 08:41 gawk-4.1.4.tar.xz
-rw-rw-r-- 1 arnold arnold 473 Aug 25 21:10 gawk-4.1.4.tar.xz.sig

This is a bug fix release. The relevant part of the NEWS file is
appended below.

Differences from gawk 4.1.3 are available:

-rw-r--r-- 1 arnold arnold 676853 Aug 25 11:19 gawk-4.1.3-4.1.4.diff.gz
-rw-rw-r-- 1 arnold arnold 473 Aug 25 21:31 gawk-4.1.3-4.1.4.diff.gz.sig

The .diff file is a shell script that should be executed in the gawk-4.1.3
source directory.

The usual GNU build incantation should be used:

tar -xpvzf gawk-4.1.4.tar.gz
cd gawk-4.1.4
./configure && make && make check

The documentation on the GNU web site has will be updated in the next
few days.

Bug reports should be sent to bug-...@gnu.org.

Enjoy!

Arnold Robbins (on behalf of all the gawk developers)
arn...@skeeve.com
------------------------------------------------------------
Changes from 4.1.3 to 4.1.4
---------------------------

1. Updated to GNU autoconf 2.69, automake 1.15, gettext 0.19.7,
texinfo 6.1, texinfo.tex 2016-02-05.07, libtool 2.4.6.

2. z/OS support updated.

3. At the beginning of each statement, the debugger now checks and
reports watchpoints that have fired before checking for breakpoints.
This gives more natural behavior to the user.

4. The "exit" command has been added to the debugger as an alias
for "quit".

5. AIX 7.1 should pass the test suite now. Similar for Minix.

6. VMS support has been updated.

7. The profiler / pretty-printer now chains else-if statements instead
of causing cascading elses.

8. The return value of system() has been enhanced to convey more information.
See the doc.

9. Attempting to write to the "to" end of a two-way pipe that has been
closed is now a fatal error. Similarly, so is reading from the "from"
end that has been closed.

10. MinGW support has been updated.

11. The -d option now allows -d- to print to standard output.

12. Error messages for --help and in other instances should now get
translated correctly.

13. A new environment variable GAWK_LOCALE_DIR may be set to locate the .mo
file for gawk itself.

14. The DJGPP port is now officially deprecated.

15. A number of bugs have been fixed. See the ChangeLog.
--
Aharon (Arnold) Robbins arnold AT skeeve DOT com

[Marc de Bourget]

Le jeudi 25 août 2016 21:25:30 UTC+2, Aharon Robbins a écrit :
Thank you, Arnold! Great work as always.
I was able to compile it with MINGW on Windows 10.

There was only one warning:
gcc -c -D__USE_MINGW_ANSI_STDIO -O2 -gdwarf-2 -g3 -Wno-deprecated-declarations -DGAWK -I. -DHAVE_CONFIG_H -DDEFLIBPATH="\"c:/gawk/gawk-4.1.4/lib/gawk\"" -DSHLIBEXT="\"dll\"" debug.c
debug.c: In function 'restart':
debug.c:2905:20: warning: passing argument 2 of 'execvp' from incompatible pointer type
execvp(d_argv[0], d_argv);
^
In file included from c:\mingw\include\unistd.h:54:0,
from awk.h:156,
from debug.c:26:
c:\mingw\include\process.h:120:42: note: expected 'const char * const*' but argument is of type 'char **'
_CRTIMP intptr_t __cdecl __MINGW_NOTHROW execvp (const char*, const char* const*);

I think I've mentioned this warning already earlier, but I assume it is not important.

[Aharon Robbins]

In article <3527392f-8e3d-476f...@googlegroups.com>,

Marc de Bourget <marcde...@gmail.com> wrote:
>Le jeudi 25 août 2016 21:25:30 UTC+2, Aharon Robbins a écrit :
>Thank you, Arnold! Great work as always.
>I was able to compile it with MINGW on Windows 10.
>
>There was only one warning:

>....

>
>I think I've mentioned this warning already earlier, but I assume it is
>not important.

No, it's not. It's not possible to get gawk to compile warning-free
on every platform with every compiler. The main thing is that it
compiles and passes 'make check'.

Enjoy.

[Kaz Kylheku]

But that is just non-POSIX-conforming Microsoft junk.

See here:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html

The correct prototype is:

int execvp(const char *file, char *const argv[]);

Any program which correctly calls execvp according to the POSIX spec
will run into this warning.

MinGW is largely obsolete now anyway. See here:

http://www.kylheku.com/cygnal/

You can build Gawk under Cygwin, then package it with the Cygnal
version of the Cygwin DLL to get a "native" program.

[Marc de Bourget]

Le vendredi 26 août 2016 06:22:18 UTC+2, Kaz Kylheku a écrit :

Hi Kaz,

what's wrong with MINGW? It seems to me the C compiler standard for Windows.
I don't want to use Cygwin, so "Cygnal" isn't an option for me either.
However, I'm interested: can you create a GAWK.exe with Cygnal for download?

[Kenny McCormack]

In article <114c8a79-520b-4f7a...@googlegroups.com>,

Marc de Bourget <marcde...@gmail.com> wrote:

...

>what's wrong with MINGW? It seems to me the C compiler standard for Windows.
>I don't want to use Cygwin, so "Cygnal" isn't an option for me either.
>However, I'm interested: can you create a GAWK.exe with Cygnal for download?

We've had this conversation before. Please refer back to an earlier sub-thread
entitled "People who don't like Cygwin for some reason". Truly, it's all
been said.

In particular, Kaz answers quite nicely the question of what is wrong with
MinGW.

--
b w r w g y b r y b

[Marc de Bourget]

Le vendredi 26 août 2016 11:21:17 UTC+2, Kenny McCormack a écrit :
> ...
> >what's wrong with MINGW? It seems to me the C compiler standard for Windows.
> >I don't want to use Cygwin, so "Cygnal" isn't an option for me either.
> >However, I'm interested: can you create a GAWK.exe with Cygnal for download?
>
> We've had this conversation before. Please refer back to an earlier sub-thread
> entitled "People who don't like Cygwin for some reason". Truly, it's all
> been said.
>
> In particular, Kaz answers quite nicely the question of what is wrong with
> MinGW.
>
> --
> b w r w g y b r y b

There is a slight difference. The old discussion was about the use of GAWK,
the new one is about compiling GAWK.
But no problem, I don't want to impose a new discussion.
However, I'm still interested in testing a GAWK.exe created by "Cygnal"
if Kaz wants to provide it for downloading.

[Kaz Kylheku]

On 2016-08-26, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <114c8a79-520b-4f7a...@googlegroups.com>,
> Marc de Bourget <marcde...@gmail.com> wrote:
> ...
>>what's wrong with MINGW? It seems to me the C compiler standard for Windows.
>>I don't want to use Cygwin, so "Cygnal" isn't an option for me either.
>>However, I'm interested: can you create a GAWK.exe with Cygnal for download?
>
> We've had this conversation before. Please refer back to an earlier sub-thread
> entitled "People who don't like Cygwin for some reason". Truly, it's all
> been said.

All the issues of using Cygwin for deploying a native app in that thread
are addressed: the path handling, working directories and such.

This is spelled out in a clear database of issues on the Cygnal home
page, which have links to git commits in the Cygnal repo.

The idea that a Windows application is a single exe with no DLL's isn't
addressed; that is untrue and downright moronic.

MinGW links programs to MSVCRT.DLL in the system folder it to avoid a
GPL violation: linking a GPL-ed program to a proprietary library is
forbidden, unless it is a system library (the "system library exception
clause" in the GPL).

According to Microsoft, MSVCRT.DLL in the system folder is an internal,
undocumented library that applications aren't supposed to use.

This very fact makes MinGW risky for software deployment.
Microsoft could put out a Windows service pack that will change
that library and break your code. Their level of support for your
problem will be "told you so".

Any serious development tool for Windows has a DLL run-time library that
you ship with programs. There are those that allow static binaries. But
that is a bad idea; if a security flaw is found and fixed in a library,
users can't just update to that library; they have to additionally wait
for you to roll out a new static binary with that fix.

[Marc de Bourget]

OK. Now I think Kenny is right: We really already had this discussion :-)
At Kaz: If you like, you can send me gawk.exe with DLL to my private mail.

[Kaz Kylheku]

If you use the MinGW environment, you'are already using Cygwin.

That environment is a stripped down fork of an ancient version of
Cygwin.

Speaking of which, Cygwin has the MinGW compilers available as
a package, so there is no need to use the MinGW environment to build
programs conforming to the MinGW scheme (single .exe depending on
MSVCRT.DLL in the Windows system folder).

> However, I'm interested: can you create a GAWK.exe with Cygnal for download?

If you want that to be 4.1.4, I'm just going to wait for Cygwin
to provide the Gawk update first.

Because how this works is that we simply take the gawk.exe from Cygwin
and package it up with the half dozen or so DLLs that it needs. Except,
in the case of cygwin1.dll, we use the one provided by Cygnal, not the
stock Cygwin version.

Now with those DLL's and that gawk.exe I have a "native" Gawk. I can put
that into a .zip file or installer or whatever and ship it.

This gawk will now understand when you give it a file name argument like
C:foo.txt, and the current directory on drive C is
C:\Users\bob\Downloads, that you're referring to
C:\Users\bob\Downloads\foo.txt.

When you use command pipes in this gawk, it will use "cmd.exe /c
<command>" to run them, rather than looking for a /bin/sh.exe
interpreter, like it would under the regular cygwin1.dll.

That's all there is to it: swap DLL, get native-like behavior without
losing the degree of completion and quality of Cygwin's POSIX
and ISO C library implementation.

[Marc de Bourget]

In the meantime, the "official" MSWindows port using MinGW
by Eli Zaretskii of GAWK 4.1.4 has been released:
https://sourceforge.net/projects/ezwinports/files/
Thank you, Eli!

[Kaz Kylheku]

Cygwin also updated to Gawk 4.1.4.

Corinna Vinshen posted on Friday to the cygwin mailing list:

Subject: [ANNOUNCEMENT] Updated: gawk-4.1.4-1

https://www.cygwin.com/ml/cygwin/2016-08/msg00506.html

[Kaz Kylheku]

Okay, I updated to it now. Let's make a package with Cygnal.

By the way, I updated my 64 bit Cygwin to it, so we are
making a 64 bit native gawk for windows.

First, ldd will tell us what libs we need from Cygwin:

$ gawk --version | head -1
GNU Awk 4.1.4, API: 1.1 (GNU MPFR 3.1.4, GNU MP 6.1.1)
0:rocktron:~$ ldd /usr/bin/gawk.exe
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x77330000)
kernel32.dll => /cygdrive/c/Windows/system32/kernel32.dll (0x77210000)
KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll (0x7fefd130000)
cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
cyggmp-10.dll => /usr/bin/cyggmp-10.dll (0x3ff870000)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ff910000)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ff5b0000)
cygmpfr-4.dll => /usr/bin/cygmpfr-4.dll (0x3fef80000)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3ffa10000)
cygreadline7.dll => /usr/bin/cygreadline7.dll (0x3fea50000)
cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x3ff000000)
USER32.dll => /cygdrive/c/Windows/system32/USER32.dll (0x77110000)
GDI32.dll => /cygdrive/c/Windows/system32/GDI32.dll (0x7fefde90000)
LPK.dll => /cygdrive/c/Windows/system32/LPK.dll (0x7fefde80000)
USP10.dll => /cygdrive/c/Windows/system32/USP10.dll (0x7fefdbc0000)
msvcrt.dll => /cygdrive/c/Windows/system32/msvcrt.dll (0x7fefd720000)
IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x7fefdb90000)
MSCTF.dll => /cygdrive/c/Windows/system32/MSCTF.dll (0x7fefd920000)

Thus, these:

cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
cyggmp-10.dll => /usr/bin/cyggmp-10.dll (0x3ff870000)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3ff910000)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ff5b0000)
cygmpfr-4.dll => /usr/bin/cygmpfr-4.dll (0x3fef80000)
cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x3ffa10000)
cygreadline7.dll => /usr/bin/cygreadline7.dll (0x3fea50000)
cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x3ff000000)

Let's use Awk to copy them.

$ mkdir winawk
$ cp $(ldd /usr/bin/gawk.exe | awk '/usr.bin/ { print $3 }') winawk
$ cp /usr/bin/gawk.exe winawk

Now clobber the cygwin1.dll with the Cygnal one. I will pull it right from
my Cygnal build directory:

$ cp ~/newlib-cygwin64/x86_64-unknown-cygwin/winsup/cygwin/new-cygwin1.dll winawk/cygwin1.dll

Now we just package it up:

$ tar czvf winawk.tar.gz winawk

And there it is for you on my website:

http://www.kylheku.com/cygnal/winawk.tar.gz

SHA256: 8dd1c30b84bee9e1606393c0946433aae47b578b98a4c2d22c011c1a5d6c83f8

[Marc de Bourget]

Thank you, Kaz!

[Kaz Kylheku]

On 2016-08-29, Marc de Bourget <marcde...@gmail.com> wrote:
> Thank you, Kaz!

No problem.

If something doesn't work right in this build of Gawk, the
issue can be attacked in two ways.

We determine whether it's a Cygnal issue (Cygnal not doing enough to
provide the "native" behavior expected on Windows for that situation) or
else it's the program itself doing something "Unixy" internally.

In the latter case, the program can be patched so that it makes a
run-time check when it starts up: "am I running on Cygwin or Cygnal?"
and sets a flag. The flag can then control the behavior.
We can still use the same executable on Cygwin, and the patch can be
Cygwin specific, and "upstreamed" into the program.

One behavior of Gawk is that it reads and writes POSIX text streams:
linefeed terminated. Gawk doesn't go through the C stdio library,
and so it doesn't "benefit" from Cygnal using CR-LF line termination
for text streams by default.

--
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List: http://www.kylheku.com/diy
ADA MP-1 Mailing List: http://www.kylheku.com/mp1

[Aharon Robbins]

In article <201608290...@kylheku.com>,

Kaz Kylheku <221-50...@kylheku.com> wrote:
>One behavior of Gawk is that it reads and writes POSIX text streams:
>linefeed terminated. Gawk doesn't go through the C stdio library,
>and so it doesn't "benefit" from Cygnal using CR-LF line termination
>for text streams by default.

Not quite. It uses read(2) for input and stdio.h fwrite for output.
The BINMODE variable exists to control how "binary" vs. "text" mode
works on non-POSIX systems.

[Kaz Kylheku]

Thanks for that pointer.

Okay, so output will be text mode if the stream is opened without the
"b" flag.

From the documentaton of BINMODE, it doesn't look like it will help
here. The I/O is already in binary mode, and the variable can only
request binary mode.

This build of Gawk is for a POSIX environment (Cygwin).

Basically, Gawk has to be built so that it uses text mode, and then
configure bi-directional binmode if it is running on regular Cygwin.

It seems like an easily solvable problem; the main thing is that
the switching is already implemented in Gawk. It's just a question
of enabling it at compile time (if that is required) and defaulting
it appropriately.