> Hi John and Salvatore,
>
> actually, the security fix did not change the behaviour of run-mailcap when
> filenames contained spaces, which already triggered renaming to a temporary
> file.
I compared the behaviour with an older version.
> I think that the behaviour of the --norun option is c
Hi John and Salvatore,
actually, the security fix did not change the behaviour of run-mailcap when
filenames contained spaces, which already triggered renaming to a temporary
file.
I think that the behaviour of the --norun option is correct: it indicates
exactly what run-mailcap would be doing.
> > $ echo 1 > "FOO BAR" && run-mailcap "FOO BAR" --norun
> > less '/tmp/fileMcDJO5'
> >
> > I would expect this:
> > less '/home/stephan/FOO BAR'
> >
> > as it works without spaces.
> >
> > $ echo 1 > "FOOBAR" && run-mailcap "FOOBAR" --norun
> > less '/home/stephan/FOOBAR'
>
> This though is "
Hi,
(Not the maintainer here, but was involved for the corresponding fix):
On Wed, Dec 31, 2014 at 02:26:12PM +0100, John D. wrote:
> Package: mime-support
> Version: 3.58
> Severity: normal
> Tags: upstream
>
> Dear Maintainer,
>
> when using filenames containing a space, run-mailcap with --no
Package: mime-support
Version: 3.58
Severity: normal
Tags: upstream
Dear Maintainer,
when using filenames containing a space, run-mailcap with --norun prints out a
command containing a temporary filepath. This makes the output useless.
$ echo 1 > "FOO BAR" && run-mailcap "FOO BAR" --norun
less '
5 matches
Mail list logo
