will scripting work on different configs?

[serendipity]

Code: Select all

For example: 
      - Paste this script to a file scripts.xys in app path: 
        Copy the newest file from Desktop : copynew 
          ::step 
          ::set $path, <curpath> 
          ::goto Desktop| 
          ::sortby m, d 
          ::selpos 1 
          // foc list 
          ::#1016 
          // copy 
          ::#201 
          ::goto $path

Before, we start to share our scripts there are some issues which might change from user to user.
For example, i tried the above script by Don, but soon realized how my config will not let that script to work.
The above script would work only if the config > general option "set folders apart" is unchecked. I have it checked and obviously my newly created file was not copied.
Now my question is, what can be done to make sure some scripts work all the time for all of us? (especially since in near future we might start sharing our scripts )
For example in this case, there should be note somewhere that "set folders apart" should be unchecked.
Or will there be a more advanced form of scripting which would work independent of user settings?

[admin]

Code: Select all

For example: 
      - Paste this script to a file scripts.xys in app path: 
        Copy the newest file from Desktop : copynew 
          ::step 
          ::set $path, <curpath> 
          ::goto Desktop| 
          ::sortby m, d 
          ::selpos 1 
          // foc list 
          ::#1016 
          // copy 
          ::#201 
          ::goto $path

Before, we start to share our scripts there are some issues which might change from user to user.
For example, i tried the above script by Don, but soon realized how my config will not let that script to work.
The above script would work only if the config > general option "set folders apart" is unchecked. I have it checked and obviously my newly created file was not copied.
Now my question is, what can be done to make sure some scripts work all the time for all of us? (especially since in near future we might start sharing our scripts )
For example in this case, there should be note somewhere that "set folders apart" should be unchecked.
Or will there be a more advanced form of scripting which would work independent of user settings?

Good point! There might be many of these kinds of dependencies/surprises. Needs deep thinking...

[TheQwerty]

I've been thinking about this and to be honest I've been unable to come up with something Don could do that would prevent this kind of thing.

I think it's got to be up to the users to be careful when running scripts, and the script writers to take into consideration what may be different.

So perhaps Don should have used "::goto Desktop|*.*" instead of "::goto Desktop|". (Which still isn't perfect because it could be a file without an extension.)

Also, that script won't always return the user to the view they previously had (as it will remove any VF or Search).

So a slightly better version might be:

Code: Select all

Copy the newest file from Desktop : copyNew
	//Step through this script.
	::step
	//Get the current path.
	::set $path, <curpath>
	//Open a new tab.
	::#340
	//Go to the desktop and only show files with extensions.
	::GoTo Desktop|*.*
	//Sort by Descending Time Modified.
	::sortby m, d
	//Select the first item.
	::selpos 1
	//Focus List
	::#1016
	//Copy this item to what was the current path.
	::CopyTo $path
	//Close tab.
	::#351

However it's still not perfect.
It won't always return the user to the tab they were at when it was executed (depends on Tab opening/closing settings).
Depending on settings the original tab may or may not update automatically to show the new file. (It should remain otherwise unchanged.)
And it will screw up if the maximum number of tabs are already opened. (Unless one is the Default and can't be closed, in which case it will just be changed.)


As I said I think this is something us users are going to have to watch for, and if/when we start sharing scripts everyone should be warned to always turn on stepping the first time they use a script.

[admin]

As I said I think this is something us users are going to have to watch for, and if/when we start sharing scripts everyone should be warned to always turn on stepping the first time they use a script.

Yep, but then you change a setting (say, Sort Folders Apart), and the script that worked well for weeks suddenly stops working.

[TheQwerty]

As I said I think this is something us users are going to have to watch for, and if/when we start sharing scripts everyone should be warned to always turn on stepping the first time they use a script.

Yep, but then you change a setting (say, Sort Folders Apart), and the script that worked well for weeks suddenly stops working.

Unfortunately, but again I'm not sure how you can really ensure such things don't happen.

Maybe we need some state variables and logic blocks?

EDIT: I'm not sure this could be done but it's a thought.

Could you tie a script command to the options/states that it relies upon?
For instance ::SelPos relies on if folders are shown, are they shown first, etc.
So for every command there's a list of options that affect it.

Then there could be a function that scans a script and determines what options the entire script relies on.
And from there the function could generate a state hash that contains the states of those options.
Then there could be a corresponding function that would check the state of XY against this state hash.

And then from there we could have script commands to use this state hash, or only continue if the state hash is equal to a value contained in the script.

It's getting awfully difficult, I hope you have a better idea.

[admin]

As I said I think this is something us users are going to have to watch for, and if/when we start sharing scripts everyone should be warned to always turn on stepping the first time they use a script.

Yep, but then you change a setting (say, Sort Folders Apart), and the script that worked well for weeks suddenly stops working.

Unfortunately, but again I'm not sure how you can really ensure such things don't happen.

Maybe we need some state variables and logic blocks?

EDIT: I'm not sure this could be done but it's a thought.

Could you tie a script command to the options/states that it relies upon?
For instance ::SelPos relies on if folders are shown, are they shown first, etc.
So for every command there's a list of options that affect it.

Then there could be a function that scans a script and determines what options the entire script relies on.
And from there the function could generate a state hash that contains the states of those options.
Then there could be a corresponding function that would check the state of XY against this state hash.

And then from there we could have script commands to use this state hash, or only continue if the state hash is equal to a value contained in the script.

It's getting awfully difficult, I hope you have a better idea.

Yes, too difficult. Looks like work with no end.

I think one has to get more experience with scripting (I myself hardly have any because I spend all my time with coding... ). Time will show. And in the meantime: (1) Use shared scripts with care. (2) Be aware that certain settings (it might be possible to compile a list) might disturb certain scripts (again there will be a closed list of commands that are sensitive to user config).

[avsfan]

As I said I think this is something us users are going to have to watch for, and if/when we start sharing scripts everyone should be warned to always turn on stepping the first time they use a script.

Yep, but then you change a setting (say, Sort Folders Apart), and the script that worked well for weeks suddenly stops working.

Would it be possible/desirable to have an extra (optional) parameter in some cases? Such as in this example, "::selpos 1, File" to select the first file...

Just thinking in public...

[admin]

As I said I think this is something us users are going to have to watch for, and if/when we start sharing scripts everyone should be warned to always turn on stepping the first time they use a script.

Yep, but then you change a setting (say, Sort Folders Apart), and the script that worked well for weeks suddenly stops working.

Would it be possible/desirable to have an extra (optional) parameter in some cases? Such as in this example, "::selpos 1, File" to select the first file...

Just thinking in public...

Yes, would be a possibility. Or add something to "::sortby m, d, ---, ---" to overwrite the sort config. But I still have to find out whether this will be an endless chase (in which case I'd rather give up and say: "You care, I don't force you to use scripts" )

[jacky]

I've been thinking about this and to be honest I've been unable to come up with something Don could do that would prevent this kind of thing.

One thing that could be done is to allow scripts to both get & set settings. So your script could start by storing the current value of the setting, setting its own and then doing its stuff, and finally restoring the old value.
Even better, and to avoid bad scripts and case of break out before the end, would be that a script could change a setting (eg. force to sort folders apart) but once the script execution would be over, XY would restore any setting that was changed to its previous value.

I'm not sure if it could be interesting for a script to change settings otherwise, but if so there could be an optional parameter to tell XY not to restore the previous value when the script execution is over.

[j_c_hallgren]

I think it may have to be looked at differently based on which command it is, as with some of them, I'd suspect most users have a common or typical setting so it'd not be as needed, where other commands are so unpredictable as to users settings that having additional params might well be worth it.

Upd/Addendum: Just saw jacky's post and I'd agree with the concept of having script change settings temporarily, with an override to force them to stay if desired.

[PeterH]

I see a problem with scripts that change and later reset options: if a script (ab)ends with a problem between these commands, it will leave the changed state.
So I think it should be the possibility for "local" changes, beeing automatically reset by XY, when the script ends. But it's hard to distinguish between local changes, and changes planned to be made "for outside"...

Best could be Don's idea of supplying modifiers just for one command, as in the "::sortby m, d, ---, ---"-example. But they could mean quite a lot of work for him, as there could be a lot of modifiers for a lot of commands...

[admin]

I see a problem with scripts that change and later reset options: if a script (ab)ends with a problem between these commands, it will leave the changed state.
So I think it should be the possibility for "local" changes, beeing automatically reset by XY, when the script ends. But it's hard to distinguish between local changes, and changes planned to be made "for outside"...

Best could be Don's idea of supplying modifiers just for one command, as in the "::sortby m, d, ---, ---"-example. But they could mean quite a lot of work for him, as there could be a lot of modifiers for a lot of commands...

I think the point is: XY scripting controls the file manager, not the file system! It's not a non-GUI way to do things with files, but it's a way to do things with a GUI. And that GUI is a highly configurable beast. It can change. It has countless states.

I have some important future scripting commands in mind (backup, report) that will bypass the GUI and its inpredictable nature. But I cannot make scripting generally bypass XY. That would be like writing a new software (file management totally scripted... may somebody else do it... or isn't that what DOS was??? )

[eurytos]

I haven't done any scripting in XYPlorer yet, but would it be an option to specify a seperate config in the script file?

for example, let's say I write a script on my machine and when I am satisfied I make a copy of my config and rename it script1_config.cfg and then place a 'use' script1_config.cfg in the script file. Now if I want to send my script to someone else I would also send the script1_config.cfg file.

If that is possible it wouldn't matter what the other user's config file looks like.

[admin]

I haven't done any scripting in XYPlorer yet, but would it be an option to specify a seperate config in the script file?

for example, let's say I write a script on my machine and when I am satisfied I make a copy of my config and rename it script1_config.cfg and then place a 'use' script1_config.cfg in the script file. Now if I want to send my script to someone else I would also send the script1_config.cfg file.

If that is possible it wouldn't matter what the other user's config file looks like.

One problem here is: loading a new config requires a shutdown and restart of the app -- overkill for just a script.

[serendipity]

This seems to be a hard problem to tackle. but like eurytos said maybe there can be a temporary config file for some scripts.

The moment that script is started, the respective config loads itself (with auto restart of xy) and scripts runs and does its job and finally reloads the original config.

I know its too much for just a script, but if the script can load a new config and reload original config after running itself, then it wont be such a pain (since its all automatic).
In worst case, you can always have your own config back.

Another point is, all script writers should have default XY config (the ONLY common config we all have) as a reference which would make things easier.

I think (a) "loading default XY config", (b) "running script" and (c) "reloading user's config" is the least messy way i can think of. Others might mess up my config or might end up doing something i did not expect.