Bug 658 - Commandline option does not accept newline
: Commandline option does not accept newline
Status: RESOLVED INVALID
Product: Sylpheed-Claws (GTK1)
Classification: Unclassified
Component: Other
: 1.0.0
: Other Linux
: P3 normal
Assigned To: sylpheed-claws-users
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-15 20:41 CET by Felix Eckhofer
Modified: 2005-10-22 07:23 CEST (History)
0 users

See Also:


Attachments
Perlscript workaround (893 bytes, application/x-perl)
2005-01-10 21:17 CET, Felix Eckhofer
no flags Details
Updated version - forgot to remove "--debug" parameter (882 bytes, text/plain)
2005-01-10 21:54 CET, Felix Eckhofer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Eckhofer 2004-12-15 20:41:58 CET
Just noticed that sylpheed only displayed a single line of a mail when called 
from KDE. It seems as if sc stops processing of the commandline-option when a 
newline-char is hit: 
 
sylpheed --compose "mailto:a@domain.tld?cc=b@domain.tld&body=first line 
second line" 
 
Will display in message window: 
> first line 
Everything else is discarded.
Comment 1 Alfons Hoogervorst 2004-12-16 13:11:37 CET
I checked both the source code of KDE and sylpheed, and I think that KDE should
allow you to pass the original mailto URL. Sylpheed knows how to decode it.

KDE right now decodes the URL and passes the decoded strings to the command
line. So instead of getting %0D%0A, sylpheed get the control codes for carriage
return  and linefeed.
Comment 2 Alfons Hoogervorst 2004-12-17 09:49:09 CET
Just to clear this up:
I'm using sylpheed --compose "mailto:%t?cc=%c&subject=%s&body=%B" as command line.
When using a URL like
"mailto:xxx@xxxx.xxxx.xx?subject=Testen%3F&cc=xx@xx.xx&body=Hello%2C%0A%0AThis%20is%20a%20test%21"
Sylpheed will get the body as the following command line parameters:

"Hello,"
"This"
"is"
"a"
"test!"

So, the operating system strips out all white spaces (including CR/LFs) and
passes the separate strings to sylpheed.
I'd say it's an invalid / wontfix bug report.
Comment 3 Paul 2004-12-17 10:27:54 CET
I have verified this bug under a certain condition.
If claws is launched using

sylpheed --compose "mailto:a@domain.tld?cc=b@domain.tld&body=first line 
second line" 

then all is fine.
However, if claws is already running, then it shows the behaviour described by
Felix.
Comment 4 Paul 2004-12-17 10:36:57 CET
Change 'Product', as this bug is also present in GTK1 claws.
Comment 5 Paul 2004-12-17 11:43:04 CET
I asked Hiro about this, as main also has the same behaviour. His response was:
"that's because lock_socket_input_cb() only accepts one line"
Comment 6 Alfons Hoogervorst 2004-12-17 12:17:58 CET
The problem here is mainly KDE decoding URI parts and passing them decoded and
all to the mail client. Decoding loses information (think characters that are
not valid on a command line or a locale).

(Mozilla Thunderbird users have the same problem, so it would be better if you
vote for http://bugs.kde.org/show_bug.cgi?id=81598)
Comment 7 Paul 2004-12-17 12:32:54 CET
As I understand it, this is a problem when using konsole, (gnome-terminal shows
the same behaviour too), nothing to do with kde's component chooser or kde
specifically.
Comment 8 Felix Eckhofer 2005-01-10 21:17:44 CET
Created attachment 181 [details]
Perlscript workaround

The attached perlscript can be used as a workaround. It accepts the following
parameters:
 --to, --cc, --bcc, --subject, --body, --attach
     The mail template to be passed to sylpheed via command-line.
 --sylpheed
     Path to the sylpheed executable. Leave empty for
     auto-detection ("which sylpheed")

I successfully use it from KDE like this:
sylpheed-compose.pl --to="%t" --cc="%c" --bcc="%b" --subject="%s" --body="%B"
--attach="%A"
Comment 9 Felix Eckhofer 2005-01-10 21:54:02 CET
Created attachment 182 [details]
Updated version - forgot to remove "--debug" parameter
Comment 10 Paul 2005-10-22 07:23:38 CEST
The GTK1 version of Sylpheed-Claws is no longer maintained, we now only maintain
the GTK2 version.
Therefore, I am closing this GTK1 bug report as INVALID.