Re: Building sharutils 4.13.4 with MinGW

On 04/09/13 09:21, Eli Zaretskii wrote:
> Anyway, I hate it when programs lose features as result of porting
> them.  So the changes below resurrect the full strength of 'shar' even
> when 'fork' is not available.  The trick is to use shell pipes
> instead.
>
> With these changes, all the tests in v4.13.4 pass, with a single
> exception: shar-1, and that failure is not a real one:

I've hacked tests/shar-1:

# adjust for variations in the package string and for
# variations in Windows capabilities.
#
sed -e "s/__PACKAGE_STRING__/${PACKAGE_STRING}/" \
     -e 's/-rw-rw-rw- shar-1.in/-rw-r--r-- shar-1.in/' \
     -e "s/chmod 0666 'shar-1.in'/chmod 0644 'shar-1.in'/" \
   $top_srcdir/tests/shar-1.ok > ${tmpfile}.sample

> Here are the changes:

I don't have time to digest this part of the patch,
other than to suggest:

#if HAVE_WORKING_FORK
#elif defined(__MINGW32__)
#else
#endif

I also haven't investigated, but I worry about adding the uuencode
command when HAVE_WORKING_FORK is zero.  It changes the
printf arguments and I think the uuencode gets added on
anyhow, so wouldn't it be redundant?  Dunno.  Haven't looked yet.
Anyway, forcing the pipe when fork doesn't work cancels out the
--no-piping option, so this definitely needs some massaging.

>
> --- src/shar.c~3	2013-04-09 13:37:23.287005000 +0300
> +++ src/shar.c	2013-04-09 13:45:18.562796500 +0300
> @@ -173,7 +173,20 @@ typedef struct {