Re: Desktop Entry Specification is missing [ as a reserved character in Exec
"Bollinger, John" <[email protected]> Tue, 25 Jun 2024 20:35:30 +0000
| Newsgroups | gmane.linux.xdg.devel |
|---|---|
| Message-ID | <CH2PR04MB6950D46F2B16B69276E0105EE0D52@CH2PR04MB6950.namprd04.prod.outlook.com> |
--_000_CH2PR04MB6950D46F2B16B69276E0105EE0D52CH2PR04MB6950namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tuesday, June 25, 2024 12:42 PM, meator <[email protected]> > On 6/25/24 18:13, Bollinger, John wrote: > > > I have also messaged this mailing list about this > > > (See "A few questions about escaping in desktop files" sent in 22. > > > August 2022). In this thread, I was assured that the implementation c= an > > > either choose to do word splitting and unquoting itself or it can pas= s > > > the job to a shell. > > > > I do not find that surprising, but the spec really ought to be clear > > about it. > > [...] all of this is still > speculation I believe. But I found the arguments made on that thread > reasonable. > > I have reread the thread (it has been two years since I've discussed > this). Here's a link if you're curious: > https://lists.freedesktop.org/archives/xdg/2022-August/014620.html > > The argument made is that there already exist two major implementations > handling the Exec key either way. This means that both the shell > approach and the manual approach "are correct", because if they aren't, > it would make a major implementation not compliant, which would make the > specification less reliable and it would anger other implementers too. I think where you say "less reliable", it would be more apt to say "unaccep= table to the overall community". And even if it were not the original intent tha= t both approaches should be acceptable, if that is the de facto interpretatio= n then that's the position from which any changes or interpretations must be made. Though in truth, I have trouble reading the spec as intending otherw= ise. > > --- > > > > [spec draft] > > > --- I +1 your efforts. It would be nice to see clarification in the specification. You also impose stricter rules on quoting which would make passing the arguments to the shell feasible. The way I see it, no, I don't. On one hand, none of the specifics laid out= in that draft wording are rules in their own right. They are all _consequence= s_ of the general rule that an implementation should have its choice of running the command via a shell or parsing the command line and exec()ing the result directly. On the other hand, that general rule seems to convey the prevailing interpretation of the spec, so even though some of those specifics are not spelled out in the current spec, they are nevertheless implied by it anyway. > This would remove behavior discrepancies between the shell approach and the manual approach. Yes, to the extent that there are any desktop files that actually trigger s= uch differences now. But I'm inclined to think that those tend to get ironed o= ut when a project gets bug reports about its desktop files not working with one desktop environment or another. Which is another reason to take what I describe as a more explicit expression of the de facto requirements of th= e current spec, rather than as conveying any new or fundamentally different requirements. > One disadvantage I see is that the entire shell quoting mechanism has to > be specified here. No, it doesn't. In fact, it _isn't_ (believe it or not) in the draft wordi= ng I presented (see also below). > Shell is not directly related to desktop files. > Implementations choosing to handle the Exec key manually will not even > involve a shell altogether. This imposes a pretty hard artificial > dependency on the /bin/sh quoting mechanism. Shell _is_ directly related to desktop files if it is a rule, whether expli= cit or not, that the value of the Exec key needs to be interpretable in a certain way by the shell. And although the spec doesn't say so explicitly, I do, again, think that that is a de facto rule. Specifically, as I expressed it in the draft text: "commands must be quoted and escaped such that their interpretation according to the shell's rules does not differ from their interpretation according to the more limited delimiting, quoting, and escaping rules presented in this specification." However, having expressed that rule in the spec, it would be possible to provide less precise guidance on how to satisfy that, closer in style to the current quoting rules. One needs to understand, however, that the current rules are inadequate for their apparent intended purpose. If we are interpreting that purpose correctly then that is a deeper flaw in the spec than just not covering square brackets, yet one that I don't think would be a major issue to fix, even if the change could be interpreted as backwards incompatible. > the main issue I've outlined in the > originating e-mail of this thread is globbing. Yes, I know and understand. > Implementations using the > shell for handling of Exec will treat the following line: > > > Exec=3D/usr/bin/xte[r]m > > as /usr/bin/xterm (if xterm is installed on the system in the expected > location). This is true unless these implementations employ special code > for [, which is not likely, because it is not specified. Yes. > Implementations doing word splitting and unquoting manually will see > /usr/bin/xte[r]m, Yes. > which is arguably the correct behavior. Maybe. Inasmuch as I perceive a de facto rule that Exec values must be quoted appropriately to ensure that there is no such difference in interpretation, I would argue that that Exec value is non-conforming. If it appeared in a real desktop file, I would find it eminently reasonable to file a bug report about that with the project providing that file. > If the desktop file should choose to invoke [ (as in /usr/bin/[), I > believe that no special treatment is necessary. Agreed. And the general rule I keep coming back to is consistent with that. > I would also like to point out that "real" desktop files used in > production will never contain these special edge-cases were discussing. Provisionally agreed. Certainly I don't expect ever to see anything analogous to Exec=3D/usr/bin/xte[r]m. But I'm not so quick to accept that I shouldn't expect ever to see *any* real-world example that satisfies the explicit quoting rules in the current version of the spec, but nevertheless is handled differently by different desktop environments. Such an example probably wouldn't involve square brackets, but I am in no way so sure about shell reserved words, for example. > But still, the specification should be clear. Yes. I may just submit a PR with some variation of my draft revision, and see what happens. > Because of this thread and because of other concerns, I chose to switch > the Exec handling mechanism of j4-dmenu-desktop (a desktop file runner > program I maintain) from the shell approach to the manual one. Although that puts more work on the desktop file launcher, I do think it's the preferable approach. I never like to get a shell involved unless = it's really needed. Best, John ________________________________ Email Disclaimer: www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimer --_000_CH2PR04MB6950D46F2B16B69276E0105EE0D52CH2PR04MB6950namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div id=3D"appendonsend"></div> <div class=3D"elementToProof" style=3D"font-family: Calibri, Arial, Helveti= ca, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> On Tuesday, June 25, 2024 12:42 PM, meator <[email protected]></di= v> <div class=3D"elementToProof" style=3D"font-family: Calibri, Arial, Helveti= ca, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> On 6/25/24 18= :13, Bollinger, John wrote:<br> > > > I have also messaged this mailing list about this<br> > > > (See "A few questions about escaping in desktop files&q= uot; sent in 22.<br> > > > August 2022). In this thread, I was assured that the impleme= ntation can<br> > > > either choose to do word splitting and unquoting itself or i= t can pass<br> > > > the job to a shell.<br> > ><br> > > I do not find that surprising, but the spec really ought to be cl= ear<br> > > about it.<br> ><br> > [...] all of this is still<br> > speculation I believe. But I found the arguments made on that thread<b= r> > reasonable.<br> ><br> > I have reread the thread (it has been two years since I've discussed<b= r> > this). Here's a link if you're curious:</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> <a href=3D"ht= tps://lists.freedesktop.org/archives/xdg/2022-August/014620.html" target=3D= "_blank" id=3D"OWA412d7467-0813-94e9-22f1-ffae1ebbc5e5" class=3D"OWAAutoLin= k" rel=3D"noopener noreferrer" data-auth=3D"NotApplicable"> https://lists.freedesktop.org/archives/xdg/2022-August/014620.html</a></div= > <div class=3D"elementToProof" style=3D"font-size: 11pt;">><br> > The argument made is that there already exist two major implementation= s<br> > handling the Exec key either way. This means that both the shell<br> > approach and the manual approach "are correct", because if t= hey aren't,<br> > it would make a major implementation not compliant, which would make t= he<br> > specification less reliable and it would anger other implementers too.= </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">I think where you say "less reliable", it would be more apt to= say "unacceptable</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">to the overall community". And even if it were not the origin= al intent that</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">both approaches should be acceptable, if that is the de facto interpreta= tion</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">then that's the position from which any changes or interpretations must = be</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">made. Though in truth, I have trouble reading the spec as intendin= g otherwise.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> > ---<br> > ><br> > > [spec draft] ><br> > > ---<br> <br> I +1 your efforts. It would be nice to see clarification in the<br> specification. You also impose stricter rules on quoting which would<br> make passing the arguments to the shell feasible.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">The way I see it, no, I don't. On one hand, none of the specifics = laid out in</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">that draft wording are rules in their own right. They are all= _consequences_</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">of the general rule that an implementation should have its choice of</di= v> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">running the command via a shell or parsing the command line and</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">exec()ing the result directly. On the other hand, that general rul= e seems</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">to convey the prevailing interpretation of the spec, so even though some= </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">of those specifics are not spelled out in the current spec, they are</di= v> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">nevertheless implied by it anyway.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> This would re= move<br> behavior discrepancies between the shell approach and the manual approach.<= /div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">Yes, to the extent that there are any desktop files that actually trigge= r such</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">differences now. But I'm inclined to think that those tend to get = ironed out</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">when a project gets bug reports about its desktop files not working with= </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">one desktop environment or another. Which is another reason to tak= e what</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">I describe as a more explicit expression of the de facto requirements of= the</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">current spec, rather than as conveying any new or fundamentally differen= t</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">requirements.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> One disadvant= age I see is that the entire shell quoting mechanism has to</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> be specified = here.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">No, it doesn't. In fact, it _isn't_ (believe it or not) in the dra= ft wording I</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">presented (see also below).</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">> Shell is not directly related to desktop files.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">> Implementations choosing to handle the Exec key manually will not e= ven<br> > involve a shell altogether. This imposes a pretty hard artificial<br> > dependency on the /bin/sh quoting mechanism.<br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">Shell _is_ directly related to desktop files if it is a rule, whether ex= plicit</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">or not, that the value of the Exec key needs to be interpretable in a</d= iv> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">certain way by the shell. And although the spec doesn't say so</di= v> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">explicitly, I do, again, think that that is a de facto rule. Speci= fically,</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">as I expressed it in the draft text: "commands must be quoted and</= div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">escaped such that their interpretation according to the shell's rules</d= iv> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">does not differ from their interpretation according to the more</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">limited delimiting, quoting, and escaping rules presented in this</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">specification."</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">However, having expressed that rule in the spec, it would be possible to= </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">provide less precise guidance on how to satisfy that, closer in style to= </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">the current quoting rules. One needs to understand, however, that<= /div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">the current rules are inadequate for their apparent intended purpose.</d= iv> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">If we are interpreting that purpose correctly then that is a deeper flaw= </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">in the spec than just not covering square brackets, yet one that I don't= </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">think would be a major issue to fix, even if the change could be</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">interpreted as backwards incompatible.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> the main issu= e I've outlined in the<br> > originating e-mail of this thread is globbing.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">Yes, I know and understand.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> Implementatio= ns using the<br> > shell for handling of Exec will treat the following line:<br> ><br> > > Exec=3D/usr/bin/xte[r]m<br> ><br> > as /usr/bin/xterm (if xterm is installed on the system in the expected= <br> > location). This is true unless these implementations employ special co= de<br> > for [, which is not likely, because it is not specified.<br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">Yes.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> > Implementations doing word splitting and unquoting manually will see<b= r> > /usr/bin/xte[r]m,</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= olor: rgb(0, 0, 0);"> Yes.</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> which is argu= ably the correct behavior.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">Maybe. Inasmuch as I perceive a de facto rule that Exec values mus= t be</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">quoted appropriately to ensure that there is no such difference in</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">interpretation, I would argue that that Exec value is non-conforming.</d= iv> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">If it appeared in a real desktop file, I would find it eminently reasona= ble</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">to file a bug report about that with the project providing that file.</d= iv> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><span style=3D"col= or: rgb(0, 0, 0);">> </span>If the desktop file should choose to invoke [ (as in /usr/bin/[), I<= /div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> believe that = no special treatment is necessary.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">Agreed. And = the general rule I keep coming back to is consistent with</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">that.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> I would also = like to point out that "real" desktop files used in<br> > production will never contain these special edge-cases were discussing= .</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">Provisionally agreed. Certainly I don't expect ever to see anythin= g</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">analogous to Exec=3D/usr/bin/xte[r]m. But I'm not so quick to acce= pt</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">that I shouldn't expect ever to see *any* real-world example that satisf= ies</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">the explicit quoting rules in the current version of the spec, but</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">nevertheless is handled differently by different desktop environments.</= div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">Such an example probably wouldn't involve square brackets, but I</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">am in no way so sure about shell reserved words, for example.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> But still, th= e specification should be clear.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">Yes. I may just submit a PR with some variation of my draft revisi= on,</div> <div class=3D"elementToProof" style=3D"font-size: 11pt; color: rgb(0, 0, 0)= ;">and see what happens.</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">> Because of th= is thread and because of other concerns, I chose to switch<br> > the Exec handling mechanism of j4-dmenu-desktop (a desktop file runner= <br> > program I maintain) from the shell approach to the manual one.<br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">Although that puts= more work on the desktop file launcher, I do think</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">it's the preferabl= e approach. I never like to get a shell involved unless it's</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">really needed.</di= v> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">Best,</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <div class=3D"elementToProof" style=3D"font-size: 11pt;">John</div> <div class=3D"elementToProof" style=3D"font-size: 11pt;"><br> </div> <br> <hr> <font face=3D"Arial" color=3D"Gray" size=3D"2"><br> Email Disclaimer: www.stjude.org/emaildisclaimer<br> Consultation Disclaimer: www.stjude.org/consultationdisclaimer<br> </font> </body> </html> --_000_CH2PR04MB6950D46F2B16B69276E0105EE0D52CH2PR04MB6950namp_--