dash bug which is affecting release goal

classic Classic list List threaded Threaded
63 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

dash bug which is affecting release goal

Thomas Bushnell, BSG-2
Dash has a serious bug which is causing grief.

The problem is that it overrides the system's "test" command (in
Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
inconsistent with the Debian versions.

Nothing in Posix permits this behavior, but it is tolerated by the
standard *provided* the shell does not change the syntax of the command.
Alas, dash does change the syntax of the command.

Now bug reports are being filed claiming that failure to conform to
dash's non-Posixism is a bug.  Programs which expect the behavior of
Debian's "test" command are not buggy.  What is buggy is a shell which
overrides the test command in an inconsistent way.

There is nothing bash-specific about expecting the "test" command to be
implemented in the normal way that Debian's "test" program is
implemented.  There is no reliance on a non-Posix *shell* feature when
one expects *other programs* to work normally.

Shells can override commands, but only if they don't play games with the
syntax.

Thomas



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Russ Allbery-2
Thomas Bushnell BSG <[hidden email]> writes:

> Dash has a serious bug which is causing grief.
>
> The problem is that it overrides the system's "test" command (in
> Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
> inconsistent with the Debian versions.

Onlookers should see http://bugs.debian.org/267142 for the long history of
the previous discussions of this.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

madcoder (Bugzilla)
In reply to this post by Thomas Bushnell, BSG-2
On Sun, Feb 10, 2008 at 06:16:44PM +0000, Thomas Bushnell BSG wrote:
> Dash has a serious bug which is causing grief.
>
> [ strip whining ]

> Alas, dash does change the syntax of the command.
>
> [ whine whine whine ]

  What is that change please ? Last time I checked dash supported the
proper POSIX required options, so I'm surprised. Instead of whining,
actually giving a bug's reference and an example of package that is
hindert by this issue would've helped.

--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Thomas Bushnell, BSG-2

On Sun, 2008-02-10 at 19:58 +0100, Pierre Habouzit wrote:

> On Sun, Feb 10, 2008 at 06:16:44PM +0000, Thomas Bushnell BSG wrote:
> > Dash has a serious bug which is causing grief.
> >
> > [ strip whining ]
>
> > Alas, dash does change the syntax of the command.
> >
> > [ whine whine whine ]
>
>   What is that change please ? Last time I checked dash supported the
> proper POSIX required options, so I'm surprised. Instead of whining,
> actually giving a bug's reference and an example of package that is
> hindert by this issue would've helped.

Dash does not implement the features of Debian /bin/test.  It is not
sufficient to implement only the features of Posix /bin/test.

The policy requires that I adapt to other Posix shells, not other Posix
implementations of test, ls, and other things.

Or are you saying that it's ok for dash to override random Debian
commands in incompatible ways?

Thomas



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Thomas Bushnell, BSG-2
In reply to this post by Russ Allbery-2

On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote:

> Thomas Bushnell BSG <[hidden email]> writes:
>
> > Dash has a serious bug which is causing grief.
> >
> > The problem is that it overrides the system's "test" command (in
> > Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
> > inconsistent with the Debian versions.
>
> Onlookers should see http://bugs.debian.org/267142 for the long history of
> the previous discussions of this.

Thank you for adding that Russ; I looked and couldn't find it right
away.

I think we need to address this before we change /bin/sh as default.
Merely papering it over is not suitable, because it means we must deal
with a changing target; every new "Posix shell" that implements slightly
different builtins will cause yet more problems.

Thomas



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Mike Bird
In reply to this post by Thomas Bushnell, BSG-2
On Sun February 10 2008 10:16:44 Thomas Bushnell BSG wrote:
> Shells can override commands, but only if they don't play games with the
> syntax.

Agreed. Within the Debian world, dash has redefined test rather
than building in test.  Therefore, within the Debian world, dash
is not Posix compliant.  Within the Debian world, this is a dash
bug.  Possible solutions include Debian-specific patches to either
make dash's test compatible or to disable dash's incompatible test.

--Mike Bird


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

madcoder (Bugzilla)
In reply to this post by Russ Allbery-2
On Sun, Feb 10, 2008 at 06:57:51PM +0000, Russ Allbery wrote:

> Thomas Bushnell BSG <[hidden email]> writes:
>
> > Dash has a serious bug which is causing grief.
> >
> > The problem is that it overrides the system's "test" command (in
> > Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
> > inconsistent with the Debian versions.
>
> Onlookers should see http://bugs.debian.org/267142 for the long history of
> the previous discussions of this.
$ dash -c 'test a = a -a b = b ; echo $?; [ a != a -o a = b ]; echo $?'
0
1

  WTF is going on please ? -a and -o are prefectly supported (at least
in the unstable's dash)

  And FWIW in the last POSIX copy I own, in the shell and utilities
document:
  * test -a
  * test -o
  * test ( )
are XSI (X/Open System Interfaces) optional features, that unlike what
Thomas pretend are properly documented.

  I agree we would like those XSI extensions to be implemented in our
/bin/sh shells. But AFAICT dash complies, even for the () grouping:

  $ dash -c 'test \( a = a -o b = 1 \) -a c = c ; echo $?'
  0

  How come no-one even *bothered* to check. I have my plate full with
whiners.

--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Thomas Bushnell, BSG-2
In reply to this post by Russ Allbery-2

On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote:

> Thomas Bushnell BSG <[hidden email]> writes:
>
> > Dash has a serious bug which is causing grief.
> >
> > The problem is that it overrides the system's "test" command (in
> > Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
> > inconsistent with the Debian versions.
>
> Onlookers should see http://bugs.debian.org/267142 for the long history of
> the previous discussions of this.

Indeed, I had forgotten that we had actually reached consensus and then
stalled at the point of getting the list of allowed-to-deviate builtins
settled.  Colin had proposed the winning solution, IIRC.

The only builtin which we identified needed to be on that list was test
itself, and the problem here was that the deviations in posh's
implementation of test would pose serious problems.

That could be solved by saying something like "test may be builtin in
inconsistent ways, provided that X, Y, and Z features still are
supported."  That could be written (by careful choice of X, Y, and Z) to
enable bash and dash to pass muster and still avoid the problems that
supposedly are raised with posh.  

The other solution--which may be an acceptible short-term one, is to
specify explicitly that shell scripts must work with Debian bash and
Debian dash.  I have no objection to that, and continue to think it is
the simplest approach.

As always, I am happy with just about any of these solutions, but the
charge-blindly-ahead method is not good.

Thomas



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

madcoder (Bugzilla)
In reply to this post by Thomas Bushnell, BSG-2
On Sun, Feb 10, 2008 at 07:17:58PM +0000, Thomas Bushnell BSG wrote:

>
> On Sun, 2008-02-10 at 19:58 +0100, Pierre Habouzit wrote:
> > On Sun, Feb 10, 2008 at 06:16:44PM +0000, Thomas Bushnell BSG wrote:
> > > Dash has a serious bug which is causing grief.
> > >
> > > [ strip whining ]
> >
> > > Alas, dash does change the syntax of the command.
> > >
> > > [ whine whine whine ]
> >
> >   What is that change please ? Last time I checked dash supported the
> > proper POSIX required options, so I'm surprised. Instead of whining,
> > actually giving a bug's reference and an example of package that is
> > hindert by this issue would've helped.
>
> Dash does not implement the features of Debian /bin/test.  It is not
> sufficient to implement only the features of Posix /bin/test.
>
> The policy requires that I adapt to other Posix shells, not other Posix
> implementations of test, ls, and other things.
>
> Or are you saying that it's ok for dash to override random Debian
> commands in incompatible ways?
  Well, let's drop bash right away then !

$ bash -c 'type test'; zsh -c 'type test'; posh -c 'type test'; dash -c 'type test'
test is a shell builtin
test is a shell builtin
posh: type: not found
test is a shell builtin

--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Raphael Geissert
In reply to this post by madcoder (Bugzilla)
Pierre Habouzit wrote:

> On Sun, Feb 10, 2008 at 06:16:44PM +0000, Thomas Bushnell BSG wrote:
>> Dash has a serious bug which is causing grief.
>>
>> [ strip whining ]
>
>> Alas, dash does change the syntax of the command.
>>
>> [ whine whine whine ]
>
>   What is that change please ? Last time I checked dash supported the
> proper POSIX required options, so I'm surprised. Instead of whining,
> actually giving a bug's reference and an example of package that is
> hindert by this issue would've helped.
>

I just replied to Thomas on the bug report including some information that
demonstrates that his arguments on dash not implementing some (at least the
one mentioned on the report) /usr/bin/test features is not valid.
For further reference please see #464995, which is the bug report Thomas is
talking about.

Sincerely,
--
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

madcoder (Bugzilla)
In reply to this post by madcoder (Bugzilla)
On Sun, Feb 10, 2008 at 07:29:28PM +0000, Pierre Habouzit wrote:
>   How come no-one even *bothered* to check.

For the google impaired, you can find the specification here:
  http://www.opengroup.org/onlinepubs/000095399/utilities/test.html

  And yes, I think it'd be a reasonable thing to ask our shells to
support the X/OPEN specification when they divert tools, and afaict they
do. Can we move on now ?


--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Brian M. Carlson
In reply to this post by Thomas Bushnell, BSG-2
On Sun, Feb 10, 2008 at 02:34:37PM -0500, Thomas Bushnell BSG wrote:
>On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote:
>> Thomas Bushnell BSG <[hidden email]> writes:
>>
>> > Dash has a serious bug which is causing grief.
>> >
>> > The problem is that it overrides the system's "test" command (in
>> > Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
>> > inconsistent with the Debian versions.

As far as I can tell, /usr/bin/test and /usr/bin/[ are completely
useless, because none of bash, dash, posh, or zsh use them.  Maybe pdksh
does, but that's pretty much the list of shells that could be coerced
into being /bin/sh.  I propose we remove those executables from
coreutils if it turns out that they are never executed.

>The only builtin which we identified needed to be on that list was test
>itself, and the problem here was that the deviations in posh's
>implementation of test would pose serious problems.

The standard posh follows is Debian Policy.  If you change Policy, I am
pretty sure that posh will follow[0].  Policy currently specifies a set
of features that are required above and beyond minimal POSIX standards
(echo -n).

Note that people often like to use local, so if that's something that
people think should be implemented[1], then you might want to add that
to the list as well.  IMHO, all five of the shells listed above should
be able to be used successfully as /bin/sh.

>That could be solved by saying something like "test may be builtin in
>inconsistent ways, provided that X, Y, and Z features still are
>supported."  That could be written (by careful choice of X, Y, and Z) to
>enable bash and dash to pass muster and still avoid the problems that
>supposedly are raised with posh.  

If you do not like posh's behavior, then please propose an amendment to
policy to add additional features required by shells implementing
/bin/sh.  I am certain posh will implement those features.

>The other solution--which may be an acceptible short-term one, is to
>specify explicitly that shell scripts must work with Debian bash and
>Debian dash.  I have no objection to that, and continue to think it is
>the simplest approach.

I think this is ridiculous.  One of the benefits of Debian is the huge
amount of choice.  We provide at least 10 window managers, 6 desktop
environments, and some insanely large amount of music players.  People
should be free to choose the shell that best fits their needs, and
providing an API (a list of required features) is far superior to
mandating an implementation.

I don't see what your problem is with posh.  It serves a legitimate
purpose: providing the bare minimum required by Policy.  It's useful as
a test of Policy-compliance, and not much more, which is fine.

[0] I believe that Clint Adams said as much himself.
[1] I have no opinion on this, other than that I want udev to work with
posh.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Russ Allbery-2
"brian m. carlson" <[hidden email]> writes:

> The standard posh follows is Debian Policy.  If you change Policy, I am
> pretty sure that posh will follow[0].  Policy currently specifies a set
> of features that are required above and beyond minimal POSIX standards
> (echo -n).
>
> Note that people often like to use local, so if that's something that
> people think should be implemented[1], then you might want to add that
> to the list as well.  IMHO, all five of the shells listed above should
> be able to be used successfully as /bin/sh.

Policy already says that any shell interpretor installed as /bin/sh may be
assumed to support local and test -a/-o.  See Policy 10.4.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Thomas Bushnell, BSG-2
In reply to this post by madcoder (Bugzilla)

On Sun, 2008-02-10 at 20:34 +0100, Pierre Habouzit wrote:

> On Sun, Feb 10, 2008 at 07:17:58PM +0000, Thomas Bushnell BSG wrote:
> >
> > Or are you saying that it's ok for dash to override random Debian
> > commands in incompatible ways?
>
>   Well, let's drop bash right away then !
>
> $ bash -c 'type test'; zsh -c 'type test'; posh -c 'type test'; dash -c 'type test'
> test is a shell builtin
> test is a shell builtin
> posh: type: not found
> test is a shell builtin

Right.  The problem is that Debian policy on the question is incoherent.

It was wrong of me to describe it as a dash bug.

Thomas



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Thomas Bushnell, BSG-2
In reply to this post by Mike Bird

On Sun, 2008-02-10 at 11:26 -0800, Mike Bird wrote:
> On Sun February 10 2008 10:16:44 Thomas Bushnell BSG wrote:
> > Shells can override commands, but only if they don't play games with the
> > syntax.
>
> Agreed. Within the Debian world, dash has redefined test rather
> than building in test.  Therefore, within the Debian world, dash
> is not Posix compliant.  Within the Debian world, this is a dash
> bug.  Possible solutions include Debian-specific patches to either
> make dash's test compatible or to disable dash's incompatible test.

Or to follow Colin's suggestion from the policy discussion a few years
ago, and grant a special exception, carefully crafted, for particular
shell builtins.  I have no objection to that solution.

Thomas



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Thomas Bushnell, BSG-2
In reply to this post by Brian M. Carlson

On Sun, 2008-02-10 at 22:11 +0000, brian m. carlson wrote:

> On Sun, Feb 10, 2008 at 02:34:37PM -0500, Thomas Bushnell BSG wrote:
> >On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote:
> >> Thomas Bushnell BSG <[hidden email]> writes:
> >>
> >> > Dash has a serious bug which is causing grief.
> >> >
> >> > The problem is that it overrides the system's "test" command (in
> >> > Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
> >> > inconsistent with the Debian versions.
>
> As far as I can tell, /usr/bin/test and /usr/bin/[ are completely
> useless, because none of bash, dash, posh, or zsh use them.  Maybe pdksh
> does, but that's pretty much the list of shells that could be coerced
> into being /bin/sh.  I propose we remove those executables from
> coreutils if it turns out that they are never executed.

There are many cases where one may well want the test program.  We need
them regardless.

> >The only builtin which we identified needed to be on that list was test
> >itself, and the problem here was that the deviations in posh's
> >implementation of test would pose serious problems.
>
> The standard posh follows is Debian Policy.  If you change Policy, I am
> pretty sure that posh will follow[0].  Policy currently specifies a set
> of features that are required above and beyond minimal POSIX standards
> (echo -n).

I don't know what the particular issue is with posh.  It was brought up
as an example in the policy discussion a while ago.

> I don't see what your problem is with posh.  It serves a legitimate
> purpose: providing the bare minimum required by Policy.  It's useful as
> a test of Policy-compliance, and not much more, which is fine.

I don't have a problem with posh.  It was brought up in the policy discussion the last time.

Thomas



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

madcoder (Bugzilla)
In reply to this post by Thomas Bushnell, BSG-2
On Sun, Feb 10, 2008 at 11:53:35PM +0000, Thomas Bushnell BSG wrote:

>
> On Sun, 2008-02-10 at 20:34 +0100, Pierre Habouzit wrote:
> > On Sun, Feb 10, 2008 at 07:17:58PM +0000, Thomas Bushnell BSG wrote:
> > >
> > > Or are you saying that it's ok for dash to override random Debian
> > > commands in incompatible ways?
> >
> >   Well, let's drop bash right away then !
> >
> > $ bash -c 'type test'; zsh -c 'type test'; posh -c 'type test'; dash -c 'type test'
> > test is a shell builtin
> > test is a shell builtin
> > posh: type: not found
> > test is a shell builtin
>
> Right.  The problem is that Debian policy on the question is incoherent.
  Well, policy describes usage, and usage (I think) is to assume that
/bin/sh gives you a decently recent POSIX environment (I said POSIX not
GNU) and that if you rely on GNU extensions of tools (like echo -e) you
should call those commands using their full path wich can be done using
really simple tricks like:

  echo() { /bin/echo "$@" }

  Policy has absolutely no valid reasons to dictate to shells how they
are implemented, and it's a perfectly sane thing for an efficient enough
shell to implement echo, test, [, true, false and probably which as
shell builtins given their pervasive use in shell idioms.

  If the policy mandates anything else, then the policy is definitely
bogus and should be fixed, and there is nothing like "a dash bug
affecting a release goal". There are two "test" related dash bugs, one
is completely cornercase: `test \( ! -e \)` and the other is a bit more
serious though unlikely to generate an issue in the general case (the
problem with "[ '!' != ' ' ]". And after all, there is still some months
before we release to fix them instead of talking endlessly.

--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Thomas Bushnell, BSG-2

On Mon, 2008-02-11 at 01:54 +0100, Pierre Habouzit wrote:
>   Well, policy describes usage, and usage (I think) is to assume that
> /bin/sh gives you a decently recent POSIX environment (I said POSIX not
> GNU) and that if you rely on GNU extensions of tools (like echo -e) you
> should call those commands using their full path wich can be done using
> really simple tricks like:
>
>   echo() { /bin/echo "$@" }

I believe Policy prohibits the use of full paths to specify programs in
the standard PATH.

>   Policy has absolutely no valid reasons to dictate to shells how they
> are implemented, and it's a perfectly sane thing for an efficient enough
> shell to implement echo, test, [, true, false and probably which as
> shell builtins given their pervasive use in shell idioms.

Policy requires that programs which provide the same names as each other
provide equivalent functionality.  No exception (currently) is made for
test.  I am not at all opposed a carefully written exception for test;
that is the substance of Colin's proposal.

Thomas



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

Mike Bird
In reply to this post by Thomas Bushnell, BSG-2
On Sun February 10 2008 15:54:36 Thomas Bushnell BSG wrote:
> Or to follow Colin's suggestion from the policy discussion a few years
> ago, and grant a special exception, carefully crafted, for particular
> shell builtins.  I have no objection to that solution.

As a Debian user rather than a DD I hope that Debian will ensure that
this solution has absolutely no effect on non-Debian scripts which
use #!/bin/sh and (perhaps unconsciously) expect test to work as in bash.

This applies to everything from tarballs of packages which are not yet
in Debian to the dozens of tiny custom scripts that everyone has for
backups or nagios extensions or adding users or emptying cameras etc etc.

Not everyone writes scripts to the same high standards as Debian but it
would still be very unfortunate if a Debian update broke them.

--Mike Bird


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dash bug which is affecting release goal

William Pitcock-2
In reply to this post by Brian M. Carlson
On Sun, 2008-02-10 at 22:11 +0000, brian m. carlson wrote:
> As far as I can tell, /usr/bin/test and /usr/bin/[ are completely
> useless, because none of bash, dash, posh, or zsh use them.  Maybe
> pdksh
> does, but that's pretty much the list of shells that could be coerced
> into being /bin/sh.  I propose we remove those executables from
> coreutils if it turns out that they are never executed.

As far as I know, test and [ are infact required to be executables.
POSIX says so. I'm .. beyond words right now at this paragraph.

signature.asc (196 bytes) Download Attachment
1234