bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building sharutils 4.13.4 with MinGW


From: Eli Zaretskii
Subject: Re: Building sharutils 4.13.4 with MinGW
Date: Mon, 08 Apr 2013 18:52:43 +0300

I think I found another bug: the -T option doesn't seem to work.  (It
is easy for me to see that because any non-text file causes my 'shar'
to bail out because 'fork' always fails.)

This seems to happen because configure_shar forces MIXED_UUENCODE
option unless the -C (COMPACTER) option was given:

  if (! HAVE_OPT(COMPACTOR))
    SET_OPT_MIXED_UUENCODE;

That in effect overrides any of the mixed-uuencode options given on
the command line, including -T.

To fix that, I modified the condition to also include an explicit
MIXED_UUENCODE option:

  if (! HAVE_OPT(COMPACTOR) && ! HAVE_OPT(MIXED_UUENCODE))
    SET_OPT_MIXED_UUENCODE;

As an aside, I found the documentation of the "-C none" option
confusing.  The docs seem to imply that "-C none" will _also_ have the
effect of preventing uuencode of non-text files (note the second
sentence):

  Specifying  the compactor "none" will then disable file compres-
  sion, even for non-text files.  Any other compactor  will  force
  uuencoding  of  files,  and  the recipient must have uudecode to
  unpack the archive.  (Compressed files are  never  processed  as
  plain text.)

However, as a matter of fact, non-text files are still being run
through uuencode, even under "-C none", because this option only
controls the compression, not whether stuff will be uuencoded -- the
latter is just a _side_effect_ of compression.  I realized this only
by reading the code which implements "-C none".

I hope it will be possible to make this part of the docs less
confusing.

P.S.  I must confess that the code generated by libopts is very hard
to penetrate, when one tries to find a bug.  Those multiple layers of
complicated macros, similarly named options, and tricky control flow
makes it very hard to find which code does what.  Some options are
acted upon explicitly in the program sources, others get set in the
bowels of libopts.  E.g., to find the root cause of the -T snafu, I
needed to put a watchpoint on the corresponding element of the options
structure -- a clear sign that I had no idea where that option gets
acted upon.  Just a rant...

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]