PDA

View Full Version : Wouldn't it be nice to have a 'Save Script As..." function?


Manu Chao
01-23-2013, 10:53 AM
Right now it seems that to create a new backup script that is based on one of supplied scripts, I have to create a new script and then include one of the general ones and add my modifications. While this works, it would be conceptually cleaner if there was a 'Save Script As...' command.

dnanian
01-23-2013, 11:08 AM
No. The whole idea of including a base script (as opposed to modifying an existing one) is that changes we make in future versions are automatically reflected in the included versions.

Manu Chao
01-23-2013, 02:17 PM
No. The whole idea of including a base script (as opposed to modifying an existing one) is that changes we make in future versions are automatically reflected in the included versions.

Maybe then just make the UI clearer. Right now it looks as if one could modify one of the base script (Edit Script), but since one cannot save it under a different name one would loose access to the original base script. In other words, if the base scripts are not supposed to be edited (so you can update them), they should not be presented in a way that makes them seem editable.

In other applications, when you select to create a new script, one is given a list of options to choose from (either via a dialogue box with several 'buttons' or via a dropdown menu, the equivalent of your base scripts). In SD, the hierarchy between 'scripts' and 'script commands' is rather unclear to me. It seems everything is a script and that hierarchy does not matter. But what happens if script A says exclude folder X and script B (set to include script A) says include folder X?

Furthermore, it seems settings and scripts are saved independently from each other (with scheduled copies at least being based on scripts). And do settings actually save the options? Or what else do they save? So, what happens if you have a scheduled copy that runs fine on its own is using a smart copy and then for a different operation you change from smart copy to erase & copy? Will this affect the scheduled copy? Or does the scheduled copy include the settings that were active when it was created?

dnanian
01-23-2013, 02:25 PM
Yes, they're purposefully separate. Settings reference volumes and scripts, and contain the various options. They can also reference shell scripts.

Scheduled copies are copied to their own location and those settings are separate.

When we had an installer, the "standard scripts" folder was read-only so you couldn't change them. But, you can include your own scripts, too - ours are on the "same level" as yours in the "rights" sense. The idea, though, is to use the tool properly - and I do document that in the User's Guide.

Yes, many improvements could be made in the scripting area...and many others. The question is taking the engineering time available and applying it to areas that benefit the most users, which doesn't necessarily mean the parts of the design that are objectively the "worst" (but not necessarily used much).

Manu Chao
01-23-2013, 03:16 PM
Yes, they're purposefully separate. Settings reference volumes and scripts, and contain the various options. They can also reference shell scripts.

Scheduled copies are copied to their own location and those settings are separate.
So, settings and scheduled copies store the same things (source, destination, script, options) with scheduled copies additionally storing the scheduling information? But the stuff stored in scheduled copies cannot be accessed manually (eg, if you want another scheduled copy of the same source, script and options but another destination), to get quick access to these, you have store them also as settings?


When we had an installer, the "standard scripts" folder was read-only so you couldn't change them. But, you can include your own scripts, too - ours are on the "same level" as yours in the "rights" sense. The idea, though, is to use the tool properly - and I do document that in the User's Guide.

Yes, many improvements could be made in the scripting area...and many others. The question is taking the engineering time available and applying it to areas that benefit the most users, which doesn't necessarily mean the parts of the design that are objectively the "worst" (but not necessarily used much).
Yes, dealing with the recovery partition seems a more urgent task (eg, when putting a new HDD into a computer, you cannot easily use SD to clone things from the old HDD as it worked fine in the pre-recovery partition.

dnanian
01-23-2013, 03:21 PM
Yes, if you want to save a general setup, you'd save the settings.

Also, recreating a recovery partition, as we've likely discussed in the past, is pretty easy...