XYplorer Automatic Updater

[jacky]

You may love doing RegExReplaces instead of simple if...else... but it is a royal pain, it is sloppy, and it's not at all something the majority of users can use. I also never called it "illegal" but it is a cheap and ugly hack.

Oh no I don't, I know it's ugly, and I can't wait to stop this and use standard if...else... statements, my point wasn't there's this hack so other stuff can be done, though I do factor that in it's true, but that the next step in scripting will require major work/changes, because, I think, it might not how XY scripting has been thought at first.

Not to say this shouldn't be done or delayed over & over, again I'm really waiting for this scripting 3.0, but I also know that Don has many things he wants to do, and many aren't related to scripting at all. All of that as well as time should be factored in, and given how there's been lots of scripting stuff recently already I would see Don willing to focus on "other things", and I'm just saying I don't think just because if/else/etc aren't supported, onEvent actions should be delayed.

I just don't think it requires "better" scripting support to be an interesting feature already. (Also, I'm not sure why onEvent interface would be complicated : new section on Config, a list of events and corresponding actions.)

Of course people are waiting to loop over the current selection (which can already "easily" be done... j/k ), but many have also requested actions on changing location, middle-click List, dbl-Tree, hold right+left click and the opposite, etc

I can be excited about a new feature which doesn't relate to scripting, without it meaning I want to delay and judge less important coming scripting changes. Just because people were excited about FVS didn't mean they thought conditions/loops weren't important or could be sent to scripting 5.0, or that scripting should be usable everywhere it could already be.

"My way" doesn't mean everyone needs to use this ugly regexp hack, you can wait for the new scripting syntax of course, and I'm not saying just because there's a way around it it's not important, I'm just saying I don't believe the lack of such support should be used to "delay" other features when they don't depend on it.

Because I do not see onEvent as a new scripting 3.0 and thus delaying conditions/loops/etc, it's not a scripting thing, I see that as a completely new & independent feature. One I might be more eager to get than scripting 3.0, yes, but that's all.

[admin]

Calm down folks, logic is in the house.

And before you start rewriting your scripts: I might add a sort of "goto label" command tomorrow (as PHP 6 will do, too, it appears). As the keyword "goto" is already used in XY scripting I might take PHP's intended "break label" (see http://www.php.net/~derick/meeting-note ... dding-goto).

[jacky]

oh wow, looks pretty cool!!

That new "ternary conditionals" is cool, but "broken". Thy this:

Code: Select all

 ?regexreplace $name, "some name [ETA: 12-2008]", "^(.+?) \[ETA: .+$", "$1";
 msg "working on ""$name"" right now";

Seems it's seen as "ternary conditionals" and so instead of parsing like this:

Code: Select all

regexreplace
$name
some name [ETA: 12-2008]
^(.+?) \[ETA: .+$
$1

It does like that:

Code: Select all

regexreplace
$name
some name [ETA: 12-2008]
) \[ETA
$1

Which ain't so good.

PS: I'd love the ctxt menu to work on right-click on both lists, not just the buttons. I also wouldn't mind a larger window if possible...

[graham]

admin wrote:

Calm down folks, logic is in the house.

And before you start rewriting your scripts: I might add a sort of "goto label" command tomorrow (as PHP 6 will do, too, it appears). As the keyword "goto" is already used in XY scripting I might take PHP's intended "break label" (see http://www.php.net/~derick/meeting-note ... dding-goto).

Great - scripting is already useful but not as useful as it could be. These new additions will make scripting, imo, a major tool (assuming users like me have no regex to fall back on). XY notable? XY is about to become the front runner assuming it gets the publicity. Just think where it will be down the road when scripting 3,4 is implemented!

[admin]

oh wow, looks pretty cool!!

That new "ternary conditionals" is cool, but "broken". Thy this:

Code: Select all

 ?regexreplace $name, "some name [ETA: 12-2008]", "^(.+?) \[ETA: .+$", "$1";
 msg "working on ""$name"" right now";

Seems it's seen as "ternary conditionals" and so instead of parsing like this:

Code: Select all

regexreplace
$name
some name [ETA: 12-2008]
^(.+?) \[ETA: .+$
$1

It does like that:

Code: Select all

regexreplace
$name
some name [ETA: 12-2008]
) \[ETA
$1

Which ain't so good.

PS: I'd love the ctxt menu to work on right-click on both lists, not just the buttons. I also wouldn't mind a larger window if possible...

Yep, all agreed and fixing/adding it...

[Muroph]

grouping without backreference also stopped working.
if you put "(?:something)" in a regex, the script will open the regex rename dialog instead of renaming the items.

[lukescammell]

Simply Amazing Jacky

I ran it the first time with 7-Zip args (to overwrite without asking)

Code: Select all

x "%zip%" -aoa -o"<xypath>\"

and this worked perfectly (since I was on 7.60.0000 and it was updating to 7.60.0007). Then, I ran it again right away to see what happened and I got this...


I decided not to cancel to see what happened and basically it did everything you would expect it to had it found a higher version number only it saved the current file as 7.60.0005 even though it was the .0007 file (I did a binary check).

[admin]

grouping without backreference also stopped working.
if you put "(?:something)" in a regex, the script will open the regex rename dialog instead of renaming the items.

Should be fixed in next version.

[jacky]

Simply Amazing Jacky

Thanks, glad you like it!

Then, I ran it again right away to see what happened and I got this...


I decided not to cancel to see what happened and basically it did everything you would expect it to had it found a higher version number only it saved the current file as 7.60.0005 even though it was the .0007 file (I did a binary check).

Yes, I've seen that as well. This is due to the recent changes in 0007, and the bug it introduced. As a result what's returned from readurl isn't the full page, the first part of it is missing, and that part includes the latest changelog entry (0007), that's why the script thinks the latest version available is 0005

So it assumed it was a new version (since different from your current one, and you're not supposed to be ahead of latest beta ), even though it was not, but the file downloaded is always the latest beta available (xyplorer_X.XX_beta_noinstall.zip), so it downloaded the 0007 version, thinking it was (and renaming as) 0005...

Just like when the next beta is out, it might not "see it" depending on what readurl returns : if it makes the script "skip" the latest changelog entry again, it will tell you have have the latest version while a new one will be out. Little confusing maybe, but once you'll running the next beta with the fix, it should all be back to normal...

[jacky]

The original script has been modified since that first post, here's the latest :

No more copy/paste, you can now simply download the XYS file from here.

It uses latest syntax changes that aren't supported in previous versions, now requires XY 7.60.0009 in order to work.

I've added a couple of things since last time, starting with function to Revert to a previous version. This will simply do the same thing as always, only without downloading anything but using one of the previously downloaded ZIP file. That way, if for some reason you ever want to revert back to an old version, it will be done in a couple of clicks just as easily as when updating to the latest version (Been doing that these past couple of days, pretty cool)

Also, since ZIP files are added and added all the time, added a little thing to quickly remove a bunch of them easily as well

Because I intend to give this script to a few people (XY users) I know, and they don't all use latest beta, I added an option to check for the latest official version as well. So now it supports updating both to latest beta, or latest official version (no changelog there).

In the same idea, cause I didn't want to explain how to update the script file every time they'd need to update it, I've also added a "check for update" function for the script itself. If everything works nicely, next time I update it, using this feature you'll be able to update to the latest version of the script in two clicks as well

[jacky]

In the same idea, cause I didn't want to explain how to update the script file every time they'd need to update it, I've also added a "check for update" function for the script itself. If everything works nicely, next time I update it, using this feature you'll be able to update to the latest version of the script in two clicks as well

On that note, the first new version somehow missed the internetflags so cookies were sent. Just fixed that, so if you downloaded this new script earlier today you might wanna update already (sorry!)

[lukescammell]

Excellent new version, I love it I have a couple of suggestions/questions to make this absolutely bulletproof:

1. Can we use a relative path for the "UnRAR" program? Perhaps if the program is on the same drive as XY it could default to using a relative path? This would make the most sense from the "portable" aspect of XY.
2. Wouldn't it be worth having a suggested default "args" for WinRAR, 7Zip and perhaps even WinZIP (even though I hate it, it is popular), perhaps selectable with a radio box and then an "other" option to input your own custom args?
3. As per 2. Would it be possible to have the "Beta" question a tickbox? "AutoUpdate to Beta Versions?" If that's not possible in Scripting, consider that a request Don
4. This is a picky one, but shouldn't the 5 occurrences of "UnRAR" in the .xys file and the one in the .ini be changed to something a little more semantically correct such as "Extractor" or "Archiver"? I told you it was picky, so feel free to completely and utterly ignore this request

I would try 1. manually but I'm at the latest version, so it doesn't get as far as trying to use the relative path.

Perhaps when this is fully battle tested it could become an included script for XY? I suppose you'd need an included archiver at that point wouldn't you? Don, would you consider including a free archiver, such as 7z.exe, if that's allowed under their licensing? You could then even include the 7z script when it's a little more robust I'll stop now as I'm rambling...

P.S. this is the first stuff that's got me excited about scripting, it was a bit of a non-feature for me before this...

[jacky]

Excellent new version, I love it

Thanks, glad you like it!

Can we use a relative path for the "UnRAR" program? Perhaps if the program is on the same drive as XY it could default to using a relative path? This would make the most sense from the "portable" aspect of XY.

Yeah, and actually after looking into it, the restriction to use a full path to an EXE file is from an old version, you can already use relative path (..\syntax) as it is now.
I can easily add support for the ?:\syntax obviously, so we'll have the full thing on. Will do that, good one

Wouldn't it be worth having a suggested default "args" for WinRAR, 7Zip and perhaps even WinZIP (even though I hate it, it is popular), perhaps selectable with a radio box and then an "other" option to input your own custom args?

Well.. no selectable list or nothing like that is possible, nope. What I'll do though, is add a text-screen with defaults arguments for WinRAR & 7z. From then, it's easy to select/copy the arguments one wants to use, and paste it right after.

As per 2. Would it be possible to have the "Beta" question a tickbox? "AutoUpdate to Beta Versions?" If that's not possible in Scripting, consider that a request Don

That is not possible in scripting, we only have the input command. I'm not sure about adding support for it would be in the idea of scripting, but I do feel that the possibility for input to use not a simple textbox but a combobox, and have an extra parameter to give a |-separated list of default values could be pretty useful.

For example, would be a nice way to present different default values for arguments. Here, we could have a list with 0 and 1, or if we had yet another option to disable the editing feature, thus turning input into a choice selection from a list, a Yes/No choice (or Official/BETA actually)

I don't know how easily doable it's be doing, or if Don would even like that idea, but I would like that very much, as I already have a couple script where I ask to enter 0 or 1, or make some kind of choice.

(@Don: On somewhat related note, if msg could be used to ask something, like it does now, but not cancel script execution on "Cancel/No" but return e.g. 0 or 1 in an extra param, especially now that we have some conditions, it'd be pretty nice)

This is a picky one, but shouldn't the 5 occurrences of "UnRAR" in the .xys file and the one in the .ini be changed to something a little more semantically correct such as "Extractor" or "Archiver"? I told you it was picky, so feel free to completely and utterly ignore this request

Yeah, I think I'll ignore that one

Don, would you consider including a free archiver, such as 7z.exe, if that's allowed under their licensing?

Bad idea IMO.

P.S. this is the first stuff that's got me excited about scripting, it was a bit of a non-feature for me before this...

Well, all you needed was a little monster

[lukescammell]

Glad some of that was good

Out of interest, why do you think it would be a bad idea to include an archiver (assuming it actually could be done blah blah blah)?

Also, I have a little monster, he's currently asleep (who knows for how long) and has his first cold. The snot just has to be seen to be believed...

[jacky]

Out of interest, why do you think it would be a bad idea to include an archiver (assuming it actually could be done blah blah blah)?

Well, because I don't see any reason why Don should promote any other app just like that, because XY is a file manager and there's no reason to change that. Why "force" people who just wants a file manager to have some other soft they don't want ? I'd be the first to get annoyed if I had some extra-app embedded with XY or any other app for that matter, especially because I got my own archive manager and I don't need what others "want me to use"...

Yes, here some app to unzip is required, and to edit text files some kind of text editor is required, and so on, doesn't mean XY should come with anything more than itself; up to the user to decide what other app they need/want to use around it and which they'll use, and how.

To have default arguments for the main archiver can be useful, and is required here, so yes, that's a good idea I think, but it shouldn't go any further than that, IMO.

Anyways, new version of the script has been uploaded