@includes after update to 0.9
esquifit
directly edited in the script.
What would happen after the update 0.8 -> 0.9 with an old script for
which the @includes are different in the script code and in
config.xml? Which @includes would survive?
Erik Vold
If I understand correctly, beginning with 0.9 headers can/must be
directly edited in the script.
What would happen after the update 0.8 -> 0.9 with an old script for
which the @includes are different in the script code and in
config.xml? Which @includes would survive?
--
Erik Vergobbi Vold
Email: erik...@gmail.com
Website: http://erikvold.com/
Twitter: http://twitter.com/erikvold
Identi.ca: http://identi.ca/erikvold
LinkedIn: http://www.linkedin.com/in/erikvold
esquifit
> On Sat, Jan 22, 2011 at 13:24, esquifit <esqu...@googlemail.com> wrote:
>>
>> What would happen after the update 0.8 -> 0.9 with an old script for
>> which the @includes are different in the script code and in
>> config.xml? Which @includes would survive?
>
> The user defined @includes and other @include/@exclude edits remain in the
> config.xml (and continue to be used) until the user edits the user script
> (opening the file and making changes that result in the lastModified
> timestamp to change on the user script) or updates it (installing a new
> version) iirc.
Thanks for the swift answer. Just to be sure that I understand:
1) Does this mean that config.xml continues to exist, only that now it
will be (automatically) synced with the script?
2) If after the upgrade to 0.9 I make a minor edit in a script and
save it, will the @includes in config.xml replace those in the script?
(this should be the case, I think)
3) Reinstalling the script would, as usual, overwrite the current @includes
Regarding 3: if GM could check any difference in the @in/exclude
headers between the script being installed and the installed one, and
issue a warning in that case, it would be great. An option 'overwrite
@in/excludes or leave current @in/excludes unchanged' would be even
better.
Erik Vold
On 2011-01-22, at 15:44, esquifit <esqu...@googlemail.com> wrote:
> On Sat, Jan 22, 2011 at 11:36 PM, Erik Vold <erik...@gmail.com> wrote:
>> On Sat, Jan 22, 2011 at 13:24, esquifit <esqu...@googlemail.com> wrote:
>>>
>>> What would happen after the update 0.8 -> 0.9 with an old script for
>>> which the @includes are different in the script code and in
>>> config.xml? Which @includes would survive?
>>
>> The user defined @includes and other @include/@exclude edits remain in the
>> config.xml (and continue to be used) until the user edits the user script
>> (opening the file and making changes that result in the lastModified
>> timestamp to change on the user script) or updates it (installing a new
>> version) iirc.
>
> Thanks for the swift answer. Just to be sure that I understand:
> 1) Does this mean that config.xml continues to exist, only that now it
> will be (automatically) synced with the script?
yes, the 'sync' only happens when a script is changed though, and only for the one script that changed.
> 2) If after the upgrade to 0.9 I make a minor edit in a script and
> save it, will the @includes in config.xml replace those in the script?
no, the @includes in the script replace the ones stored in config.xml
> 3) Reinstalling the script would, as usual, overwrite the current @includes
yes
> Regarding 3: if GM could check any difference in the @in/exclude
> headers between the script being installed and the installed one, and
> issue a warning in that case, it would be great. An option 'overwrite
> @in/excludes or leave current @in/excludes unchanged' would be even better.
Make an issue ;)
E
esquifit
>[...]>>[...]
>> 2) If after the upgrade to 0.9 I make a minor edit in a script and
>> save it, will the @includes in config.xml replace those in the script?
>
> no, the @includes in the script replace the ones stored in config.xml
Well, I suppose this means that I'll have to go through the nearly 200
scripts I have installed and check one by one whether there is a
metadata mismatch between the script and config.xml, and manually
update the affected scripts to reflect the reality before attempting
the upgrade to 0.9. Otherwise I could potentially have massive
problems. If my understanding is correct, this is certainly something
it should be informed about in the GM blog at the minimum, and also at
UMO.
PS: I change metadata of 3rd part scripts very often because they tend
to be too permissive, for example "http:*.youtube.*/*", which to the
effects of security amounts to the same as "http:*". My own scripts
also change continuously, since they are under permanent optimization.
sizzlemctwizzle
> Well, I suppose this means that I'll have to go through the nearly 200
> scripts I have installed and check one by one whether there is a
> metadata mismatch between the script and config.xml, and manually
> update the affected scripts to reflect the reality before attempting
> the upgrade to 0.9. Otherwise I could potentially have massive
> problems. If my understanding is correct, this is certainly something
> it should be informed about in the GM blog at the minimum, and also at
> UMO.
adding the @include rules to the scripts you actually plan on editing.
> PS: I change metadata of 3rd part scripts very often because they tend
> to be too permissive, for example "http:*.youtube.*/*", which to the
> effects of security amounts to the same as "http:*". My own scripts
> also change continuously, since they are under permanent optimization.
@include rules are unsafe.
esquifit
> Do you really plan on editing all 200 of your scripts? How about just
> adding the @include rules to the scripts you actually plan on editing.
This doesn't seem to be less work. After all I have to go through all
scripts to see whether something has changed, besides the fact that I
might want to remove/alter some @includes in the original script.
What I plan now is to wait 6 months until I have the time and
motivation to make a thorough cleansing and reduce my list of scripts
to no more than say 50 which I actually use.
Until then I won't be able to upgrade.
>> PS: I change metadata of 3rd part scripts very often because they tend
>> to be too permissive, for example "http:*.youtube.*/*", which to the
>> effects of security amounts to the same as "http:*". My own scripts
>> also change continuously, since they are under permanent optimization.
>
> Contact the original author of the script and tell him that his
> @include rules are unsafe.
This is actually a flaw of GM itself. How could you specify an
@include that would cover all country-specific versions of
wikipedia.org or youtube.com? There's no such thing as
"tld.youtube.com", so users are forced to write things like
http://*.youtube.com/*, which as I said, could be anything like
http://evil.domain/foo#bar.youtube.com/. When installing 3rd party
scripts I take the trouble of transforming all this permissive
@includes into non-ambiguous one. It makes no sense to contact each
author, since this would be time consuming, no success is guaranteed,
author might be not availabe anymore, and in most cases the author
could not change anything (for s/he does not want to publish a
wikipedia script that works only for the Seychelles islands)
Anthony Lieuallen
> This is actually a flaw of GM itself. How could you specify an
> @include that would cover all country-specific versions of
> wikipedia.org or youtube.com?
Whoops, no, this is a _feature_ of greasemonkey, for example:
@include http://www.google.tld/*
http://wiki.greasespot.net/Include_and_exclude_rules#Magic_TLD
> ...
> http://*.youtube.com/*, which as I said, could be anything like
> http://evil.domain/foo#bar.youtube.com/. When installing 3rd party
> scripts I take the trouble of transforming all this permissive
> @includes into non-ambiguous one.
> ...
I applaud your effort (not to mention knowledge of the potential
pitfalls), but situations like these were judged to be the severe
minority, while the changes made were instead judged to be an
improvement for everyone.
Long story short: it's impossible to please everyone all of the time.
We do our best to please as many people as we can as much of the time as
possible, but everything in the real world is a compromise.
esquifit
> I applaud your effort (not to mention knowledge of the potential pitfalls),
> but situations like these were judged to be the severe minority, while the
> changes made were instead judged to be an improvement for everyone.
>
> Long story short: it's impossible to please everyone all of the time. We do
> our best to please as many people as we can as much of the time as possible,
> but everything in the real world is a compromise.
Sure, I'm not complaining nor even requesting any feature. I was just
trying to understand what I should consider before upgrading to 0.9.
Yet I think that the fact that after the upgrade to 0.9 every
subsequent edit would overwrite config.xml with the actual headers in
the script is, IMHO, something it should be informed about.