Re: gnus-uu-post-insert-binary-in-article is not correct

Re: gnus-uu-post-insert-binary-in-article is not correct

[Jochen_Hayek]

>>>>> "LMI" == Lars Magne Ingebrigtsen <bugs@gnus.org> writes:

Jochen Hayek <Jochen_Hayek@ACM.org> writes:

    JH> gnus-uu-post-insert-binary-in-article does not work
    JH> for `Gnus Uu Post Encode Method': gnus-uu-post-encode-mime,
    JH> but only for gnus-uu-post-encode-uuencode and gnus-uu-post-encode-mime-uuencode,
    JH> because mmencode takes parameters different from uuencode,
    JH> as supposed in gnus-uu-post-encode-file,
    JH> used by gnus-uu-post-encode-uuencode and gnus-uu-post-encode-mime .

    LMI> Yup.  Fix in Quassia Gnus v0.24.

Well, it definitely still does not work in this conf:

    Gnus v5.6.27; nntp 5.0; nnmh 1.0; nndraft 1.0; nnfolder 1.0

May I suggest the patch, that you find in the end?
(I really did not change more, than I found necessary.)

And ... the 1st one of those `multiparts' is `as usual' not being displayed
by an MIME-enabled mail reader,
so also Gnus would not show it, if the article in is MIME (minor?!) mode.
That's btw the way, how I tested it.

================================================================================

*** gnus-uu.el	1998/07/27 13:35:40	1.1
--- gnus-uu.el	1998/07/27 14:25:20	1.3
***************
*** 196,202 ****
      ("\\.dvi$" "image/dvi")
      ("\\.mpe?g$" "video/mpeg")
      ("\\.au$" "audio/basic")
!     ("\\.\\(te?xt\\|doc\\|c\\|h\\)$" "text/plain")
      ("\\.\\(c\\|h\\)$" "text/source")
      ("read.*me" "text/plain")
      ("\\.html$" "text/html")
--- 196,203 ----
      ("\\.dvi$" "image/dvi")
      ("\\.mpe?g$" "video/mpeg")
      ("\\.au$" "audio/basic")
!     ("\\.doc$" "application/msword")
!     ("\\.\\(te?xt\\|c\\|h\\)$" "text/plain")
      ("\\.\\(c\\|h\\)$" "text/source")
      ("read.*me" "text/plain")
      ("\\.html$" "text/html")
***************
*** 1793,1799 ****
    :group 'gnus-extract-post
    :type 'boolean)
  
! (defvar gnus-uu-post-binary-separator "--binary follows this line--")
  (defvar gnus-uu-post-message-id nil)
  (defvar gnus-uu-post-inserted-file-name nil)
  (defvar gnus-uu-winconf-post-news nil)
--- 1794,1800 ----
    :group 'gnus-extract-post
    :type 'boolean)
  
! (defvar gnus-uu-post-binary-separator "---")
  (defvar gnus-uu-post-message-id nil)
  (defvar gnus-uu-post-inserted-file-name nil)
  (defvar gnus-uu-winconf-post-news nil)
***************
*** 1841,1847 ****
  ;; Encodes with base64 and adds MIME headers
  (defun gnus-uu-post-encode-mime (path file-name)
    (when (zerop (call-process shell-file-name nil t nil shell-command-switch
! 			     (format "%s %s -o %s" "mmencode" path file-name)))
      (gnus-uu-post-make-mime file-name "base64")
      t))
  
--- 1842,1848 ----
  ;; Encodes with base64 and adds MIME headers
  (defun gnus-uu-post-encode-mime (path file-name)
    (when (zerop (call-process shell-file-name nil t nil shell-command-switch
! 			     (format "%s %s" "mmencode" path)))
      (gnus-uu-post-make-mime file-name "base64")
      t))
  
***************
*** 1852,1857 ****
--- 1853,1860 ----
  		  (gnus-uu-choose-action file-name gnus-uu-ext-to-mime-list)
  		  file-name))
    (insert (format "Content-Transfer-Encoding: %s\n\n" encoding))
+   (goto-char (point-max))
+   (insert "-----\n")     
    (save-restriction
      (set-buffer gnus-message-buffer)
      (goto-char (point-min))
***************
*** 1860,1866 ****
      (narrow-to-region 1 (point))
      (unless (mail-fetch-field "mime-version")
        (widen)
!       (insert "MIME-Version: 1.0\n"))
      (widen)))
  
  ;; Encodes a file PATH with COMMAND, leaving the result in the
--- 1863,1870 ----
      (narrow-to-region 1 (point))
      (unless (mail-fetch-field "mime-version")
        (widen)
!       (insert "MIME-Version: 1.0\n")
!       (insert "Content-Type: multipart/mixed; boundary=\"-\"\n"))
      (widen)))
  
  ;; Encodes a file PATH with COMMAND, leaving the result in the
.

Re: gnus-uu-post-insert-binary-in-article is not correct

[Lars Magne Ingebrigtsen]

Jochen_Hayek@ACM.org writes:

> May I suggest the patch, that you find in the end?
> (I really did not change more, than I found necessary.)

[...]

> !     ("\\.doc$" "application/msword")
> !     ("\\.\\(te?xt\\|c\\|h\\)$" "text/plain")

This one I can't accept.

> ! (defvar gnus-uu-post-binary-separator "--binary follows this line--")

[...]

> ! (defvar gnus-uu-post-binary-separator "---")

Uhm...  Why this change?

> ! 			     (format "%s %s -o %s" "mmencode" path file-name)))

[...]

> ! 			     (format "%s %s" "mmencode" path)))

I don't understand how this can work at all -- we have to give a -o
parameter to specify the output file...

Could you send a new patch?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus-uu-post-insert-binary-in-article is not correct

[Jochen_Hayek]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

Jochen_Hayek@ACM.org writes:

    >> May I suggest the patch, that you find in the end?
    >> (I really did not change more, than I found necessary.)

    LMI> [...]

    >> !     ("\\.doc$" "application/msword")
    >> !     ("\\.\\(te?xt\\|c\\|h\\)$" "text/plain")

    LMI> This one I can't accept.

Did you ever receive a lengthy MS Word `.doc' file
as attached MIME?
I assume, you did not.
People know, you don't like MIME. (Sorry, I couldn't resist ...)

But let us assume you did!

So you find something, that looks like that,
toggle to MIME mode,
and ... you have that `nice binary' in your article (text) buffer.

How would you write that region to a file?

On the other hand: have you ever received a `.doc' file,
that was not an MS Word file?
And if that would ever happen,
I assume it wouldn't even be base64 (or whatever) encoded,
so what's the damage letting `.doc' appear as `application/msword'.
Welcome to planet earth!

So why can't you accept this rather practically minded change request.

----------

    >> ! (defvar gnus-uu-post-binary-separator "--binary follows this line--")

    LMI> [...]

    >> ! (defvar gnus-uu-post-binary-separator "---")

    LMI> Uhm...  Why this change?

    >> ! 			     (format "%s %s -o %s" "mmencode" path file-name)))

    LMI> [...]

    >> ! 			     (format "%s %s" "mmencode" path)))

    LMI> I don't understand how this can work at all

Have you ever *really* tried gnus-uu-post-insert-binary-in-article,
I mean `base64', not just `uue'?
Sorry, I doubt it, because it does not work.

*All* these changes are necessary to make MIME mode
write the *decoded* regions to temporary files (using metamail).

I mean, `who sends shall also be able to receive', right?

    LMI> -- we have to give a -o parameter to specify the output file...

No, that is not a useful parameter in this context at all.
Because if you do (as Gnus does so far), you have to get the output
from that file, to which you diverted it -- using `-o'.

Whereas if you don't use `-o', the output is just going to stdout,
where you get it from and insert it to the emacs buffer.
Nice, isn't it? ^H^H^H^H^H^H^H Wouldn't it be nice?!!

    LMI> Could you send a new patch?

Would you pls reconsider this rather simple and effective patch!

It does not break anything, it cures a problem,
yes and it really works for me.

Pls!

I find this actually rather humiliating.
I never saw such a public debate about a simple patch before.

Just my $0.02 .
.

application/msword [was: Re: gnus-uu-post-insert-binary-in-article is not correct]

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]

Jochen_Hayek@acm.org writes:

>     >> !     ("\\.doc$" "application/msword")
> 
>     LMI> This one I can't accept.
>
> People know, you don't like MIME. (Sorry, I couldn't resist ...)

I do not know, and am merely joking here, but maybe the two letters "ms"
above are really the combination which Lars do not like :-).

> On the other hand: have you ever received a `.doc' file, that was not
> an MS Word file?

By the way, it is a part of my life that I often, too often receive `msword'
or `wordperfect' attachments in email.  For example, people working in some
ISO groups do that, and my frequent protests are apparently not heavy enough
to significantly change their habit.  At one place where I often work, I'm
almost alone to maintain a little cluster of Unix machines, little island
of peace, lost into a wide sea of hundreds and hundreds of NT's and 95's.
Secretaries and agents routinely and frequently send messages containing
Word files, Outlook notices, Excel (sp?) data, and such other things.
Besides me, everybody there seems to be happy.  Surely, I would never
succeed into converting them all, and I think it's me who should adapt...

So, for those few reasons, I'm now ready and willing to face the sad reality!
Is there any filter or tool, which *I* could run on Unix/Linux, available
in source form (of course), allowing me to somewhat handle such documents,
when they happen to come and pollute my Gnus mailgroups?  Are such files'
intimate format (Word, Wordperfect, and others) documented somewhere?

If I was able to find enough information, I might plan some new "surfaces"
in `recode' (who knows, some of you might know this tool? :-) for handling
these formats, and devise something to ease my Gnus ways in this...  Sigh!

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: application/msword [was: Re: gnus-uu-post-insert-binary-in-article is not correct]

[Andrew J Cosgriff]

> So, for those few reasons, I'm now ready and willing to face the sad
> reality!  Is there any filter or tool, which *I* could run on
> Unix/Linux, available in source form (of course), allowing me to
> somewhat handle such documents, when they happen to come and pollute
> my Gnus mailgroups?  Are such files' intimate format (Word,
> Wordperfect, and others) documented somewhere?

you want either catdoc[1], or mswordview[2].

Enjoy,
 Andrew

Footnotes: 
[1]  http://www.ice.ru/~vitus/works/works_unix.html#catdoc

[2]  ftp://skynet.csn.ul.ie/pub/linux/utils/

-- 
Andrew J Cosgriff <ajc@bing.wattle.id.au> exterminate all rational thought !
                        hello CD truth confined brother

Re: gnus-uu-post-insert-binary-in-article is not correct

[Darren/Torin/Who Ever...]

-----BEGIN PGP SIGNED MESSAGE-----

Jochen Hayek, in an immanent manifestation of deity, wrote:
>On the other hand: have you ever received a `.doc' file,
>that was not an MS Word file?
>And if that would ever happen,
>I assume it wouldn't even be base64 (or whatever) encoded,
>so what's the damage letting `.doc' appear as `application/msword'.

Sure.  People using WordPerfect end their files in .doc.  Also, anyone
attaching any file in Pine will have their file auto-munged into
Base64 whether it's plain text or binary.  Now, if this happens to be a
plain text file that is name <something>.doc, you lose.  Believe me on
this.  I work at the University of Washington.  Waaay too many people
use Pine here.

>Welcome to planet earth!

Welcome to the real world.

>So why can't you accept this rather practically minded change request.

Remember that you have the ultimate power.  You have the source.

Darren
- -- 
<torin@daft.com> <http://www.daft.com/~torin> <torin@debian.org> <torin@io.com>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire.  C/Perl/CGI programmer and tutor. @
@		     Make a little hot-tub in your soul.		      @

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNcF95o4wrq++1Ls5AQF8LAQAg1hWwDpKsypVBGSbuefqRBopvDXJAnRJ
OXGX6UXTRf1ghurniaZWmpf/1vY8DnUjlVYOnY5F348vfgevPYewpp/jpjuRDjWs
XKKDQdCWvJwooKkdldWtPO6ol+0WRSTUGijVrpSoIDKDrYk+3boBGGVj48YaGSHf
mnpWTG8dUso=
=YK8k
-----END PGP SIGNATURE-----

Re: application/msword [was: Re: gnus-uu-post-insert-binary-in-article is not correct]

[Kai Grossjohann]

>>>>> François Pinard <pinard@iro.umontreal.ca> writes:

  > So, for those few reasons, I'm now ready and willing to face the
  > sad reality!  Is there any filter or tool, which *I* could run on
  > Unix/Linux, available in source form (of course), allowing me to
  > somewhat handle such documents, when they happen to come and
  > pollute my Gnus mailgroups?  Are such files' intimate format
  > (Word, Wordperfect, and others) documented somewhere?

Isn't there a version of Wordperfect for SCO Unix?  And isn't there an
SCO emulation for Linux?  That would be a way, wouldn't it?

Also, there is StarOffice which sort of can read Word 6 and Word 7
(Office 95) files but not Word 8 (Office 98).

Good luck,
kai
-- 
Abort this operation?   [Abort]  [Cancel]

Re: application/msword [was: Re: gnus-uu-post-insert-binary-in-article is not correct]

[Jason R Mastaler]

Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:

> Isn't there a version of Wordperfect for SCO Unix?  And isn't there an
> SCO emulation for Linux?  That would be a way, wouldn't it?

Even better, there is WordPerfect 7 for Linux
(http://www.sdcorp.com/wplinux/wplinux.html)

Re: gnus-uu-post-insert-binary-in-article is not correct

[Steinar Bang]

>>>>> "Darren/Torin/Who Ever..." <torin@daft.com>:

> Jochen Hayek, in an immanent manifestation of deity, wrote:

>> On the other hand: have you ever received a `.doc' file, that was
>> not an MS Word file?  And if that would ever happen, I assume it
>> wouldn't even be base64 (or whatever) encoded, so what's the damage
>> letting `.doc' appear as `application/msword'.

> Sure.  People using WordPerfect end their files in .doc.  Also,
> anyone attaching any file in Pine will have their file auto-munged
> into Base64 whether it's plain text or binary.  Now, if this happens
> to be a plain text file that is name <something>.doc, you lose.

Another one is FrameMaker who also likes to use .doc.

Re: gnus-uu-post-insert-binary-in-article is not correct

[Jochen_Hayek]

>>>>> "SB" == Steinar Bang <sb@metis.no> writes:

>>>>> "Darren/Torin/Who Ever..." <torin@daft.com>:

Jochen Hayek, in an immanent manifestation of deity, wrote:

    >>> On the other hand: have you ever received a `.doc' file, that was
    >>> not an MS Word file?  And if that would ever happen, I assume it
    >>> wouldn't even be base64 (or whatever) encoded, so what's the damage
    >>> letting `.doc' appear as `application/msword'.

    >> Sure.  People using WordPerfect end their files in .doc.  Also,
    >> anyone attaching any file in Pine will have their file auto-munged
    >> into Base64 whether it's plain text or binary.  Now, if this happens
    >> to be a plain text file that is name <something>.doc, you lose.

    SB> Another one is FrameMaker who also likes to use .doc.

Is this a school class, where proud pupils enumerate
the software packages, which let their files end in `.doc'?

The crucial point actually was, that a binary treated as "text/plain"
gets expanded *within* the text buffer,
whereas an "application/*" gets saved to a file.

So from my point of view (excuse my being rude)
we could also call it "application/bullshit".

I don't mind starting the external utility to load that `.doc' file
by hand.

I think this thread drifted too much into the usual anti-MS direction.
.

Re: gnus-uu-post-insert-binary-in-article is not correct

[Steinar Bang]

>>>>> Jochen_Hayek@ACM.org:

> I think this thread drifted too much into the usual anti-MS
> direction.

MSIE (at least including 3.0.  I've never tried IE4) and the various
Outlooks pre OL98, are broken in one very important way: they
disregard MIME types and rely on file extensions to determine the file 
type.

I was unable to figure out what on earth you were talking about, other 
than that you seemed to have provided a patch that would introduce
this brain damage into Gnus.

If this wasn't the case, I apologize for my assumptions.  If this was
the case, larsi was right to refuse it.

The major reason for calling this "brain damage" is that many
different applications makes claim to the same file name extensions. 


- Steinar