From aafe6254b36940e01c158974dd6091450d559d14 Mon Sep 17 00:00:00 2001 From: Claws Mail Team Date: Thu, 28 Oct 2004 15:36:15 +0000 Subject: [PATCH 1/1] This commit was manufactured by cvs2svn to create branch 'gtk2'. Cherrypick from master 2004-10-28 15:36:14 UTC reboot '2004-10-28 [christoph] 0.9.12cvs135': doc/src/rfc2231.txt tools/kdeservicemenu/README tools/kdeservicemenu/install.sh tools/kdeservicemenu/sylpheed-kdeservicemenu.pl --- doc/src/rfc2231.txt | 563 ++++++++++++++++++ tools/kdeservicemenu/README | 62 ++ tools/kdeservicemenu/install.sh | 114 ++++ .../kdeservicemenu/sylpheed-kdeservicemenu.pl | 69 +++ 4 files changed, 808 insertions(+) create mode 100644 doc/src/rfc2231.txt create mode 100644 tools/kdeservicemenu/README create mode 100644 tools/kdeservicemenu/install.sh create mode 100644 tools/kdeservicemenu/sylpheed-kdeservicemenu.pl diff --git a/doc/src/rfc2231.txt b/doc/src/rfc2231.txt new file mode 100644 index 000000000..120f98f85 --- /dev/null +++ b/doc/src/rfc2231.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 2231 Innosoft +Updates: 2045, 2047, 2183 K. Moore +Obsoletes: 2184 University of Tennessee +Category: Standards Track November 1997 + + + MIME Parameter Value and Encoded Word Extensions: + Character Sets, Languages, and Continuations + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1997). All Rights Reserved. + +1. Abstract + + This memo defines extensions to the RFC 2045 media type and RFC 2183 + disposition parameter value mechanisms to provide + + (1) a means to specify parameter values in character sets + other than US-ASCII, + + (2) to specify the language to be used should the value be + displayed, and + + (3) a continuation mechanism for long parameter values to + avoid problems with header line wrapping. + + This memo also defines an extension to the encoded words defined in + RFC 2047 to allow the specification of the language to be used for + display as well as the character set. + +2. Introduction + + The Multipurpose Internet Mail Extensions, or MIME [RFC-2045, RFC- + 2046, RFC-2047, RFC-2048, RFC-2049], define a message format that + allows for: + + + + + +Freed & Moore Standards Track [Page 1] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + (1) textual message bodies in character sets other than + US-ASCII, + + (2) non-textual message bodies, + + (3) multi-part message bodies, and + + (4) textual header information in character sets other than + US-ASCII. + + MIME is now widely deployed and is used by a variety of Internet + protocols, including, of course, Internet email. However, MIME's + success has resulted in the need for additional mechanisms that were + not provided in the original protocol specification. + + In particular, existing MIME mechanisms provide for named media type + (content-type field) parameters as well as named disposition + (content-disposition field). A MIME media type may specify any + number of parameters associated with all of its subtypes, and any + specific subtype may specify additional parameters for its own use. A + MIME disposition value may specify any number of associated + parameters, the most important of which is probably the attachment + disposition's filename parameter. + + These parameter names and values end up appearing in the content-type + and content-disposition header fields in Internet email. This + inherently imposes three crucial limitations: + + (1) Lines in Internet email header fields are folded + according to RFC 822 folding rules. This makes long + parameter values problematic. + + (2) MIME headers, like the RFC 822 headers they often + appear in, are limited to 7bit US-ASCII, and the + encoded-word mechanisms of RFC 2047 are not available + to parameter values. This makes it impossible to have + parameter values in character sets other than US-ASCII + without specifying some sort of private per-parameter + encoding. + + (3) It has recently become clear that character set + information is not sufficient to properly display some + sorts of information -- language information is also + needed [RFC-2130]. For example, support for + handicapped users may require reading text string + + + + + + +Freed & Moore Standards Track [Page 2] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + aloud. The language the text is written in is needed + for this to be done correctly. Some parameter values + may need to be displayed, hence there is a need to + allow for the inclusion of language information. + + The last problem on this list is also an issue for the encoded words + defined by RFC 2047, as encoded words are intended primarily for + display purposes. + + This document defines extensions that address all of these + limitations. All of these extensions are implemented in a fashion + that is completely compatible at a syntactic level with existing MIME + implementations. In addition, the extensions are designed to have as + little impact as possible on existing uses of MIME. + + IMPORTANT NOTE: These mechanisms end up being somewhat gibbous when + they actually are used. As such, these mechanisms should not be used + lightly; they should be reserved for situations where a real need for + them exists. + +2.1. Requirements notation + + This document occasionally uses terms that appear in capital letters. + When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" + appear capitalized, they are being used to indicate particular + requirements of this specification. A discussion of the meanings of + these terms appears in [RFC- 2119]. + +3. Parameter Value Continuations + + Long MIME media type or disposition parameter values do not interact + well with header line wrapping conventions. In particular, proper + header line wrapping depends on there being places where linear + whitespace (LWSP) is allowed, which may or may not be present in a + parameter value, and even if present may not be recognizable as such + since specific knowledge of parameter value syntax may not be + available to the agent doing the line wrapping. The result is that + long parameter values may end up getting truncated or otherwise + damaged by incorrect line wrapping implementations. + + A mechanism is therefore needed to break up parameter values into + smaller units that are amenable to line wrapping. Any such mechanism + MUST be compatible with existing MIME processors. This means that + + (1) the mechanism MUST NOT change the syntax of MIME media + type and disposition lines, and + + + + + +Freed & Moore Standards Track [Page 3] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + (2) the mechanism MUST NOT depend on parameter ordering + since MIME states that parameters are not order + sensitive. Note that while MIME does prohibit + modification of MIME headers during transport, it is + still possible that parameters will be reordered when + user agent level processing is done. + + The obvious solution, then, is to use multiple parameters to contain + a single parameter value and to use some kind of distinguished name + to indicate when this is being done. And this obvious solution is + exactly what is specified here: The asterisk character ("*") followed + by a decimal count is employed to indicate that multiple parameters + are being used to encapsulate a single parameter value. The count + starts at 0 and increments by 1 for each subsequent section of the + parameter value. Decimal values are used and neither leading zeroes + nor gaps in the sequence are allowed. + + The original parameter value is recovered by concatenating the + various sections of the parameter, in order. For example, the + content-type field + + Content-Type: message/external-body; access-type=URL; + URL*0="ftp://"; + URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar" + + is semantically identical to + + Content-Type: message/external-body; access-type=URL; + URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar" + + Note that quotes around parameter values are part of the value + syntax; they are NOT part of the value itself. Furthermore, it is + explicitly permitted to have a mixture of quoted and unquoted + continuation fields. + +4. Parameter Value Character Set and Language Information + + Some parameter values may need to be qualified with character set or + language information. It is clear that a distinguished parameter + name is needed to identify when this information is present along + with a specific syntax for the information in the value itself. In + addition, a lightweight encoding mechanism is needed to accommodate 8 + bit information in parameter values. + + + + + + + + +Freed & Moore Standards Track [Page 4] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + Asterisks ("*") are reused to provide the indicator that language and + character set information is present and encoding is being used. A + single quote ("'") is used to delimit the character set and language + information at the beginning of the parameter value. Percent signs + ("%") are used as the encoding flag, which agrees with RFC 2047. + + Specifically, an asterisk at the end of a parameter name acts as an + indicator that character set and language information may appear at + the beginning of the parameter value. A single quote is used to + separate the character set, language, and actual value information in + the parameter value string, and an percent sign is used to flag + octets encoded in hexadecimal. For example: + + Content-Type: application/x-stuff; + title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A + + Note that it is perfectly permissible to leave either the character + set or language field blank. Note also that the single quote + delimiters MUST be present even when one of the field values is + omitted. This is done when either character set, language, or both + are not relevant to the parameter value at hand. This MUST NOT be + done in order to indicate a default character set or language -- + parameter field definitions MUST NOT assign a default character set + or language. + +4.1. Combining Character Set, Language, and Parameter Continuations + + Character set and language information may be combined with the + parameter continuation mechanism. For example: + + Content-Type: application/x-stuff + title*0*=us-ascii'en'This%20is%20even%20more%20 + title*1*=%2A%2A%2Afun%2A%2A%2A%20 + title*2="isn't it!" + + Note that: + + (1) Language and character set information only appear at + the beginning of a given parameter value. + + (2) Continuations do not provide a facility for using more + than one character set or language in the same + parameter value. + + (3) A value presented using multiple continuations may + contain a mixture of encoded and unencoded segments. + + + + + +Freed & Moore Standards Track [Page 5] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + (4) The first segment of a continuation MUST be encoded if + language and character set information are given. + + (5) If the first segment of a continued parameter value is + encoded the language and character set field delimiters + MUST be present even when the fields are left blank. + +5. Language specification in Encoded Words + + RFC 2047 provides support for non-US-ASCII character sets in RFC 822 + message header comments, phrases, and any unstructured text field. + This is done by defining an encoded word construct which can appear + in any of these places. Given that these are fields intended for + display, it is sometimes necessary to associate language information + with encoded words as well as just the character set. This + specification extends the definition of an encoded word to allow the + inclusion of such information. This is simply done by suffixing the + character set specification with an asterisk followed by the language + tag. For example: + + From: =?US-ASCII*EN?Q?Keith_Moore?= + +6. IMAP4 Handling of Parameter Values + + IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations + when generating the BODY and BODYSTRUCTURE fetch attributes. + +7. Modifications to MIME ABNF + + The ABNF for MIME parameter values given in RFC 2045 is: + + parameter := attribute "=" value + + attribute := token + ; Matching of attributes + ; is ALWAYS case-insensitive. + + This specification changes this ABNF to: + + parameter := regular-parameter / extended-parameter + + regular-parameter := regular-parameter-name "=" value + + regular-parameter-name := attribute [section] + + attribute := 1*attribute-char + + + + + +Freed & Moore Standards Track [Page 6] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + attribute-char := + + section := initial-section / other-sections + + initial-section := "*0" + + other-sections := "*" ("1" / "2" / "3" / "4" / "5" / + "6" / "7" / "8" / "9") *DIGIT) + + extended-parameter := (extended-initial-name "=" + extended-value) / + (extended-other-names "=" + extended-other-values) + + extended-initial-name := attribute [initial-section] "*" + + extended-other-names := attribute other-sections "*" + + extended-initial-value := [charset] "'" [language] "'" + extended-other-values + + extended-other-values := *(ext-octet / attribute-char) + + ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") + + charset := + + language := + + The ABNF given in RFC 2047 for encoded-words is: + + encoded-word := "=?" charset "?" encoding "?" encoded-text "?=" + + This specification changes this ABNF to: + + encoded-word := "=?" charset ["*" language] "?" encoded-text "?=" + +8. Character sets which allow specification of language + + In the future it is likely that some character sets will provide + facilities for inline language labeling. Such facilities are + inherently more flexible than those defined here as they allow for + language switching in the middle of a string. + + + + + + + +Freed & Moore Standards Track [Page 7] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + If and when such facilities are developed they SHOULD be used in + preference to the language labeling facilities specified here. Note + that all the mechanisms defined here allow for the omission of + language labels so as to be able to accommodate this possible future + usage. + +9. Security Considerations + + This RFC does not discuss security issues and is not believed to + raise any security issues not already endemic in electronic mail and + present in fully conforming implementations of MIME. + +10. References + + [RFC-822] + Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822 August 1982. + + [RFC-1766] + Alvestrand, H., "Tags for the Identification of + Languages", RFC 1766, March 1995. + + [RFC-2045] + Freed, N., and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, December 1996. + + [RFC-2046] + Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + December 1996. + + [RFC-2047] + Moore, K., "Multipurpose Internet Mail Extensions (MIME) + Part Three: Representation of Non-ASCII Text in Internet + Message Headers", RFC 2047, December 1996. + + [RFC-2048] + Freed, N., Klensin, J. and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: MIME + Registration Procedures", RFC 2048, December 1996. + + [RFC-2049] + Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and + Examples", RFC 2049, December 1996. + + + + + +Freed & Moore Standards Track [Page 8] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + + [RFC-2060] + Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + + [RFC-2119] + Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [RFC-2130] + Weider, C., Preston, C., Simonsen, K., Alvestrand, H., + Atkinson, R., Crispin, M., and P. Svanberg, "Report from the + IAB Character Set Workshop", RFC 2130, April 1997. + + [RFC-2183] + Troost, R., Dorner, S. and K. Moore, "Communicating + Presentation Information in Internet Messages: The + Content-Disposition Header", RFC 2183, August 1997. + +11. Authors' Addresses + + Ned Freed + Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 + USA + + Phone: +1 626 919 3600 + Fax: +1 626 919 3614 + EMail: ned.freed@innosoft.com + + + Keith Moore + Computer Science Dept. + University of Tennessee + 107 Ayres Hall + Knoxville, TN 37996-1301 + USA + + EMail: moore@cs.utk.edu + + + + + + + + + + + + +Freed & Moore Standards Track [Page 9] + +RFC 2231 MIME Value and Encoded Word Extensions November 1997 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (1997). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Freed & Moore Standards Track [Page 10] + diff --git a/tools/kdeservicemenu/README b/tools/kdeservicemenu/README new file mode 100644 index 000000000..2a83cdb76 --- /dev/null +++ b/tools/kdeservicemenu/README @@ -0,0 +1,62 @@ +sylpheed-kdeservicemenu.pl +Version: 1.1 +Sylpheed servicemenu for Konqueror + +FILES +o README You're reading it +o install.sh installer script +o sylpheed-kdeservicemenu.pl perl program +o template_sylpheed-attach-files.desktop +o template_sylpheed-compress-attach.desktop + .desktop file templates + +DESCRIPTION +Enables attaching files from Konqueror to a new compose window +or compression of files/directories and then attaching of +the archive to a new compose window. + +Adds the following menu items to Konqueror's 'Actions' menu: +/Actions/Sylpheed/Attach file(s) +/Actions/Sylpheed/Attach as GZip File(s) +/Actions/Sylpheed/Attach as BZip File(s) +/Actions/Sylpheed/Attach as Tar Archive +/Actions/Sylpheed/Attach as Bzipped Tar Archive +/Actions/Sylpheed/Attach as Gzipped Tar Archive +/Actions/Sylpheed/Attach as Zip Archive + +All outputted files are created in /tmp +Original files are preserved when creating [FILE].gz and [FILE].bz2 + +REQUIREMENTS +Perl 5.x.x + +INSTALL +o cd sylpheed-claws/tools/kdeservicemenu +o ./install.sh --global + ./install.sh --local + (systemwide or home directory installation) + +UNINSTALL +o cd sylpheed-claws/tools/kdeservicemenu +o ./install.sh --uninstall-global + ./install.sh --uninstall-local + (systemwide or home directory uninstallation) + + +LICENSE +GNU GENERAL PUBLIC LICENSE + +THANKS +install.sh was written by Dylan Schrader +and is released under the GPL. It was originally part of his +'Attach to email' service Menu for Konqueror, version 0.6.13 + and has been +adapted for Sylpheed servicemenu for Konqueror + +LINKS +Sylpheed-Claws +Perl +KDE + +CONTACT +Paul Mangan diff --git a/tools/kdeservicemenu/install.sh b/tools/kdeservicemenu/install.sh new file mode 100644 index 000000000..ecbadd765 --- /dev/null +++ b/tools/kdeservicemenu/install.sh @@ -0,0 +1,114 @@ +#!/bin/bash + +PERL_SCRIPT="sylpheed-kdeservicemenu.pl" +DESKTOP_TEMPLATE_ONE="template_sylpheed-attach-files.desktop" +DESKTOP_ONE="sylpheed-attach-files.desktop" +DESKTOP_TEMPLATE_TWO="template_sylpheed-compress-attach.desktop" +DESKTOP_TWO="sylpheed-compress-attach.desktop" +SERVICEMENU_DIR="share/apps/konqueror/servicemenus" + +function check_environ { +#Check to see if we can coax kde-config into the PATH +echo "Checking for kde-config..." +if [ -z "$(type 'kde-config' 2> /dev/null)" ]; then #Odd way of checking if kde-config is in $PATH + echo "kde-config not found, checking for \$KDEDIR to compensate..." + if [ ! -z $KDEDIR ]; then + export PATH=$PATH:$KDEDIR/bin + else + echo "***" + echo "***$0 cannot figure out where KDE is installed." + echo "***kde-config is not in \$PATH, and \$KDEDIR is not set." + echo "***To fix this, manually change \$PATH to add the KDE executables." + echo "***E.g. export PATH=\$PATH:/opt/kde/bin" + echo "***It would also be a good idea to add this line to your shell login/profile." + echo "***" + echo + echo "Nothing was installed or removed." + exit 1 + fi +fi +echo "Okay." +} + +function install_all { +#Go ahead and install +echo "Generating $DESKTOP_ONE ..." +SED_PREFIX=${PREFIX//\//\\\/} #Replace forward slashes in $PREFIX with \/ so that sed doesn't freak out +sed "s/SCRIPT_PATH/$SED_PREFIX\\/bin\\/$PERL_SCRIPT/" $DESKTOP_TEMPLATE_ONE > $DESKTOP_ONE +echo "Installing $PREFIX/$SERVICEMENU_DIR/$DESKTOP_ONE" +mv -f $DESKTOP_ONE $PREFIX/$SERVICEMENU_DIR/$DESKTOP_ONE +echo "Generating $DESKTOP_TWO ..." +SED_PREFIX=${PREFIX//\//\\\/} #Replace forward slashes in $PREFIX with \/ so that sed doesn't freak out +sed "s/SCRIPT_PATH/$SED_PREFIX\\/bin\\/$PERL_SCRIPT/" $DESKTOP_TEMPLATE_TWO > $DESKTOP_TWO +echo "Installing $PREFIX/$SERVICEMENU_DIR/$DESKTOP_TWO" +mv -f $DESKTOP_TWO $PREFIX/$SERVICEMENU_DIR/$DESKTOP_TWO +echo "Installing $PREFIX/bin/$PERL_SCRIPT" +cp -f $PERL_SCRIPT $PREFIX/bin/ +echo "Setting permissions ..." +chmod 0644 $PREFIX/$SERVICEMENU_DIR/$DESKTOP_ONE +chmod 0644 $PREFIX/$SERVICEMENU_DIR/$DESKTOP_TWO +chmod 0755 $PREFIX/bin/$PERL_SCRIPT +} + +function uninstall_all { +echo "Removing $PREFIX/$SERVICEMENU_DIR/$DESKTOP_ONE" +rm $PREFIX/$SERVICEMENU_DIR/$DESKTOP_ONE +echo "Removing $PREFIX/$SERVICEMENU_DIR/$DESKTOP_TWO" +rm $PREFIX/$SERVICEMENU_DIR/$DESKTOP_TWO +echo "Removing $PREFIX/bin/$PERL_SCRIPT" +rm $PREFIX/bin/$PERL_SCRIPT +echo "Finished uninstall." +} + +case $1 in + "--global" ) + check_environ + PREFIX=$(kde-config --prefix) + echo "Installing in $PREFIX ..." + if [ "$(id -u)" != "0" ]; then + echo "You are not root, as would be expected." + echo "However, we will still attempt a system-wide install." + echo "But, you probably don't have permission." + fi + install_all + ;; + "--local" ) + check_environ + PREFIX=$(kde-config --localprefix) + echo "Installing in $PREFIX ..." + if [ ! -d $PREFIX/bin ]; then + mkdir $PREFIX/bin + fi + if [ ! -d $PREFIX/$SERVICEMENU_DIR ]; then + mkdir $PREFIX/$SERVICEMENU_DIR + fi + install_all + ;; + "--uninstall-global" ) + check_environ + PREFIX=$(kde-config --prefix) + echo "Uninstalling in $PREFIX ..." + if [ "$(id -u)" != "0" ]; then + echo "You are not root, if you have any global installs, you will probably not have permission to remove them." + fi + uninstall_all + ;; + "--uninstall-local" ) + check_environ + PREFIX=$(kde-config --localprefix) + echo "Uninstalling in $PREFIX ..." + uninstall_all + ;; + * ) + echo "Usage: $0 [--global|--local|--uninstall-global|--uninstall-local]" + echo + echo " --global attempts a system-wide installation." + echo " --local attempts to install in your home directory." + echo " --uninstall-global attempts a system-wide uninstallation." + echo " --uninstall-local attempts to uninstall in your home directory." + echo + exit 0 + ;; +esac + +echo "Done." diff --git a/tools/kdeservicemenu/sylpheed-kdeservicemenu.pl b/tools/kdeservicemenu/sylpheed-kdeservicemenu.pl new file mode 100644 index 000000000..6bda430a7 --- /dev/null +++ b/tools/kdeservicemenu/sylpheed-kdeservicemenu.pl @@ -0,0 +1,69 @@ +#!/usr/bin/perl + +# * Copyright 2004 Paul Mangan +# * +# * This file is free software; you can redistribute it and/or modify it +# * under the terms of the GNU General Public License as published by +# * the Free Software Foundation; either version 2 of the License, or +# * (at your option) any later version. +# * +# * This program is distributed in the hope that it will be useful, but +# * WITHOUT ANY WARRANTY; without even the implied warranty of +# * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# * General Public License for more details. +# * +# * You should have received a copy of the GNU General Public License +# * along with this program; if not, write to the Free Software +# * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +unless ($ARGV[0]) { exit; } + +my $sylpheed = "sylpheed --compose --attach"; +my $prefix = "/tmp/archive."; +my $command = find_command($ARGV[0]); +my ($sel,$att) = split_parts(); + +if ($ARGV[0] eq "gz" || $ARGV[0] eq "bz2") { + exec "$sel$sylpheed $att"; +} elsif ($ARGV[0] eq "attachfile") { + exec "$sylpheed $sel"; +} else { + exec "$command $prefix$ARGV[0] $sel;" + ."$sylpheed $prefix$ARGV[0]"; +} + +exit; + +sub find_command { + local($s) = @_; + my $com; + + if ($s eq "gz") { $com = "gzip -c"; } + elsif ($s eq "bz2") { $com = "bzip2 -c"; } + elsif ($s eq "zip") { $com = "$s -r"; } + elsif ($s eq "tar") { $com = "$s -c -f"; } + elsif ($s eq "tar.bz2") { $com = "tar -cj -f"; } + elsif ($s eq "tar.gz") { $com = "tar -cz -f"; } + + return $com; +} + +sub split_parts { + my $selectedParts = ""; + my $attachedParts = ""; + + for (my $count = $#ARGV; $count > 0; $count--) { + my @s = split("/", $ARGV[$count]); + my $p = pop(@s); + if ($ARGV[0] eq "gz" || $ARGV[0] eq "bz2") { + my $psub = $p; + $psub =~ s/\s/_/g; + my $output = "/tmp/$psub.$ARGV[0]"; + $selectedParts .= "$command \"$p\" > $output;"; + $attachedParts .= "$output "; + } else { + $selectedParts .= "\"$p\" "; + } + } + return ($selectedParts,$attachedParts); +} -- 2.25.1