unMENU plug-in: Go Script Manager

Notice, the "\r \n" pairs of characters... it should only have "\n"   Also, the last character in the file is the "h" it should be a"\n"

 

Actually I use gsub to remove all the \r from the .confs in the go script manager just as you do in the package manager (prior to reading the values for PACKAGE_NAME etc).  Editing or creating the file in windows should not have been a problem (i've tested it with no issues). But the file does need to end in \n or \r\n.

 

Cheers,

Matt

Guys,

 

Thats an amazingly quick response. Ive been following how good this forum is but its nice when you have a question and people show you the same courtesy.

 

I can't test until i get home but will let you know.

 

So instead of using my mac, i switched to my VM, turned on hidden files, and now see all the ._ files listed. Is this purely something the mac does? Is it safe to delete them all (there are quite a few; ie in the unmenu folder there is ._mymain_local.conf, ._unMENUstart-unmenu-goscript.conf, etc. In my packages folder there are ._rc.local-unmenu-package.conf, ._monthly_paritycheck.sh, etc).

 

Also, when using notepad2, is there some setting i have to enable to see the extra carriage returns? Frankly, I was aware of this problem and was using Textmate on my mac which i thought prevented these from occurring.

 

Lastly, any way for me to keep editing on my mac without those ._ files being created?

 

Unfortunetly I cannot help you with those questions.  I am not nor have I ever been a mac user, just never had one around... I don't use notepad2 either....

 

I think it is safe to delete all the ._ files but i'm not 100% sure on this, I'll let someone else guide you in that regard.  I do not have any of these ._ files on my flash, if that helps.

 

Cheers,

Matt

I just downloaded notepad2...

 

you can see the line endings by doing the following:

 

go to "view" menu and select "Show Line Endings"  OR press ctrl-shift-9

 

Cheers,

Matt

Thanks Matt. Very helpful.

Well it looks like your suggestions fixed my issues. The scripts load and there are no more carriage returns. However i am getting an error with the unMENU start script. I am getting the following error:

 

unMENUstart-unmenu-goscript.conf.auto_goscript: line1: syntax error near unexpected tokem '10'

unMENUstart-unmenu-goscript.conf.auto_goscript:line 1: 'sleep(10)'

 

Not sure what this is but i tried changing the sleep value to 30 in the conf file and in the auto goscript file but this resulted in the same error.

 

Result is unmenu does not load at boot.

 

Any ideas?

 

Much thanks

Well it looks like your suggestions fixed my issues. The scripts load and there are no more carriage returns. However i am getting an error with the unMENU start script. I am getting the following error:

 

unMENUstart-unmenu-goscript.conf.auto_goscript: line1: syntax error near unexpected tokem '10'

unMENUstart-unmenu-goscript.conf.auto_goscript:line 1: 'sleep(10)'

 

Not sure what this is but i tried changing the sleep value to 30 in the conf file and in the auto goscript file but this resulted in the same error.

 

Result is unmenu does not load at boot.

 

Any ideas?

 

Much thanks

sleep(10) is not valid syntax for any shell script I am aware of.

 

The correct syntax for a 10 second sleep would be:

sleep 10

 

There are no parentheses surrounding the duration.

 

Joe L.

Well it looks like your suggestions fixed my issues. The scripts load and there are no more carriage returns. However i am getting an error with the unMENU start script. I am getting the following error:

 

unMENUstart-unmenu-goscript.conf.auto_goscript: line1: syntax error near unexpected tokem '10'

unMENUstart-unmenu-goscript.conf.auto_goscript:line 1: 'sleep(10)'

 

Not sure what this is but i tried changing the sleep value to 30 in the conf file and in the auto goscript file but this resulted in the same error.

 

Result is unmenu does not load at boot.

 

Any ideas?

 

Much thanks

sleep(10) is not valid syntax for any shell script I am aware of.

 

The correct syntax for a 10 second sleep would be:

sleep 10

 

There are no parentheses surrounding the duration.

 

Joe L.

That was my fault, it was a mistake I made in interpreting the man pages for sleep... big brain fart...  I have a new version with new .confs that will (hopefully) be ready tomorrow.  It will automically delay 30 seconds before running any of the .auto_goscript files during boot (after running them through a fromdos command for extra security).  The .confs will be better prepared this time around... I have been learning a lot of linux commands the past week in order to avoid repeating the same mistake again.  Sorry 'bout that.

 

Cheers,

Matt

Thanks Matt and thanks Joe. I got it working by removing the ().

 

Looking forward to future updates. Like this add on alot.

.confs post updated... A bunch of new .confs for commonly used performance tweaks.  check out the official .confs post here: http://lime-technology.com/forum/index.php?topic=2876.msg24281#msg24281

 

I have tested and they all work fine with the new version of Go Script Manager v0.6 due out shortly.

 

Cheers,

Matt

.confs post updated... A bunch of new .confs for commonly used performance tweaks.  check out the official .confs post here: http://lime-technology.com/forum/index.php?topic=2876.msg24281#msg24281

 

I have tested and they all work fine with the new version of Go Script Manager v0.6 due out shortly.

 

Cheers,

Matt

Might I suggest that you NOT direct users to put shell scripts in the packages directory.

 

The convention we have most all adopted is a folder named

/boot/custom/bin

 

for most all the "scripts" we develop. 

It is described here in the wiki: http://lime-technology.com/wiki/index.php?title=Third_Party_Boot_Flash_Plugin_Architecture

 

The .conf files will need to be changed accordingly.

 

Mine looks like this:

root@Tower:~# ls -l /boot/custom/bin

total 320

-rwx------ 1 root root    217 Jun 18  2008 busy_shares.sh*

-rwx------ 1 root root    410 Dec  5 15:37 frequent_ls.sh*

-rwx------ 1 root root  1884 Oct 18 23:24 mail.sh*

-rwx------ 1 root root    297 Jul 24 08:53 monthly_parity_check.sh*

-rwx------ 1 root root  1370 May 26  2008 powerdown*

-rwx------ 1 root root 194152 Sep 27 22:52 smartctl*

-rwx------ 1 root root    958 Jan 16 10:46 spin.sh*

-rwx------ 1 root root  6520 Jul 17  2008 spin_drives.sh*

-rwx------ 1 root root  14731 May 21  2008 spincontrol*

Might I suggest that you NOT direct users to put shell scripts in the packages directory.

 

The convention we have most all adopted is a folder named

/boot/custom/bin

 

for most all the "scripts" we develop. 

It is described here in the wiki: http://lime-technology.com/wiki/index.php?title=Third_Party_Boot_Flash_Plugin_Architecture

 

The .conf files will need to be changed accordingly.

 

Mine looks like this:

root@Tower:~# ls -l /boot/custom/bin

total 320

-rwx------ 1 root root    217 Jun 18  2008 busy_shares.sh*

-rwx------ 1 root root    410 Dec  5 15:37 frequent_ls.sh*

-rwx------ 1 root root   1884 Oct 18 23:24 mail.sh*

-rwx------ 1 root root    297 Jul 24 08:53 monthly_parity_check.sh*

-rwx------ 1 root root   1370 May 26  2008 powerdown*

-rwx------ 1 root root 194152 Sep 27 22:52 smartctl*

-rwx------ 1 root root    958 Jan 16 10:46 spin.sh*

-rwx------ 1 root root   6520 Jul 17  2008 spin_drives.sh*

-rwx------ 1 root root  14731 May 21  2008 spincontrol*

 

I have started using this layout and I have to say that it is nice.  It makes i much easier for the knowledgeable people on this board (joe, Bubba, among many others) to help fix a problem.

 

 

Just out of curiosity Joe, what do all of those scripts do and would you mind uploading/posting the contents somewhere.  I can guess what some of them do, but i would be interested in maybe adding some of them to my configuration, as i am sure others would.

.confs post updated... A bunch of new .confs for commonly used performance tweaks.  check out the official .confs post here: http://lime-technology.com/forum/index.php?topic=2876.msg24281#msg24281

 

I have tested and they all work fine with the new version of Go Script Manager v0.6 due out shortly.

 

Cheers,

Matt

Might I suggest that you NOT direct users to put shell scripts in the packages directory.

 

The convention we have most all adopted is a folder named

/boot/custom/bin

 

for most all the "scripts" we develop. 

It is described here in the wiki: http://lime-technology.com/wiki/index.php?title=Third_Party_Boot_Flash_Plugin_Architecture

 

The .conf files will need to be changed accordingly.

 

Mine looks like this:

root@Tower:~# ls -l /boot/custom/bin

total 320

-rwx------ 1 root root    217 Jun 18  2008 busy_shares.sh*

-rwx------ 1 root root    410 Dec  5 15:37 frequent_ls.sh*

-rwx------ 1 root root   1884 Oct 18 23:24 mail.sh*

-rwx------ 1 root root    297 Jul 24 08:53 monthly_parity_check.sh*

-rwx------ 1 root root   1370 May 26  2008 powerdown*

-rwx------ 1 root root 194152 Sep 27 22:52 smartctl*

-rwx------ 1 root root    958 Jan 16 10:46 spin.sh*

-rwx------ 1 root root   6520 Jul 17  2008 spin_drives.sh*

-rwx------ 1 root root  14731 May 21  2008 spincontrol*

Fixed in official .conf thread and in attachements... I was unaware, I developed these .confs from forum posts (some old).

 

Cheers,

Matt

New version released!  V0.6 - See OP for file and further details.

 

A few new features, an update for the users of the previous version and a few more "safety" features.

 

First the update:

- For those who have run and made backups with v0.4, there is an update contained in v0.6 which will move these backups and rename them according to new conventions, you do not need to do anything.

- It will move them to the location defined by FILE_BACKUP_DIRECTORY in your unmenu_local.conf

- As the variable GO_BACKUP_DIRECTORY is no longer needed, the update will find (if it exists) the line in your unmenu_local.conf and comment it out.

Full detail are in the changelog.txt file located in the zip file.

 

Other Features:

- added the creation of a .auto_install file that will wait 30 seconds before running the .auto_goscript files through a fromdos statement before proceeding to the first .auto_goscript file for processing.

- added ability to delete old backups

- cleaned up the html code a bit

- re-wrote sections of code to conform to new backup conventions

 

IF YOU ARE USING unRAID 4.4.2, AND HAVE NOT USED THE GO SCRIPT MANAGER IN A PREVIOUS VERSION OF unRAID THEN YOU MAY HAVE PROBELMS WITH THE PROGRAM AND THE AUTOMATIC APPENDING OF THE GO FILE LINE, IF THIS IS THE CASE FOLLOW THE INSTRUCTIONS BELOW:

You need to add the following line to the end of your go file ( or /boot/custom/etc/rc.d/S10-custom_install_packages, if you use the rc.d structure) manually:

cd %PACKAGE_DIRECTORY% && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c

where %PACKAGE_DIRECTORY% is the location of your package directory.

make sure that this line is above it:

cd %PACKAGE_DIRECTORY% && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c

if not, add it above the first line.  They should appear in the go file ( or /boot/custom/etc/rc.d/S10-custom_install_packages, if you use the rc.d structure) in this order:

cd %PACKAGE_DIRECTORY% && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c
cd %PACKAGE_DIRECTORY% && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c

again where %PACKAGE_DIRECTORY% refers to the location of YOUR package directory.

My package directory is /boot/packages, and I don't use the rc.d structure as of yet

so my lines would be in the /boot/config/go file and look like this:

cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c
cd /boot/packages && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c

Just trying to be as clear as possible.

 

Alternatively, you can wait until the next version which will likely fix this issue.

 

If you are upgrading from a previous (Go Script Manager) release, It is also recommended that you use the distributed .confs where possible, they have been tested. After you run the new version, it is a good idea to diasable and re-enable all the scripts you had previously enabled.  This will update the .auto_goscript files with the appropriate changes if any exist.

 

Also I am hoping that Joe L has had some time to work on the libraries he was talking about around New Years and I will be able to add some more features in the near future. *fingers crossed*

 

Cheers,

Matt

 

Edit: provided clarification for people that your the rc.d structure and the S10-custom_install_packages

I've got these variables defined in my unmenu_local.conf:

 

#Go Script Manager Variables
AUTO_GOSCRIPT_COMMAND = cd %PACKAGE_DIRECTORY% && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c
AUTO_GOSCRIPT_TEST = grep '^[^#]*\.auto_goscript'

 

At the end of my go script I run packages located in /boot/custom/etc/rc.d

 

#Execute scripts in /boot/custom/etc/rc.d
fromdos < /boot/custom/etc/rc.d/rc.local_startup | sh

 

And, one of the scripts in /boot/custom/etc/rc.d is S10-install_custom_packages, which executes the following:

 

cd /boot/custom/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c 
cd /boot/custom/packages && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c

 

Do I still need this stuff in my go script?

 

cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c
cd /boot/packages && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c

 

Granted, where I've located my S10-install_custom_packages script isn't in the same location as everyone who runs unMenu, I thought S10-install_custom_packages was an integral part of unMenu.  Since the Go Script Manager runs under unMenu I'm not understanding why it would be necessarry to add these lines to the go script as well.  I'm just trying to understand.

I've got these variables defined in my unmenu_local.conf:

 

#Go Script Manager Variables
AUTO_GOSCRIPT_COMMAND = cd %PACKAGE_DIRECTORY% && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c
AUTO_GOSCRIPT_TEST = grep '^[^#]*\.auto_goscript'

 

At the end of my go script I run packages located in /boot/custom/etc/rc.d

 

#Execute scripts in /boot/custom/etc/rc.d
fromdos < /boot/custom/etc/rc.d/rc.local_startup | sh

 

And, one of the scripts in /boot/custom/etc/rc.d is S10-install_custom_packages, which executes the following:

 

cd /boot/custom/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c 
cd /boot/custom/packages && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c

 

Do I still need this stuff in my go script?

 

cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c
cd /boot/packages && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c

 

Granted, where I've located my S10-install_custom_packages script isn't in the same location as everyone who runs unMenu, I thought S10-install_custom_packages was an integral part of unMenu.  Since the Go Script Manager runs under unMenu I'm not understanding why it would be necessarry to add these lines to the go script as well.  I'm just trying to understand.

If you have a line in your "go" script to run /boot/custom/etc/rc.d/rc.local_startup, then you do not need to add anything more to the "go" script.

 

The S10-install_custom_packages file in /boot/custom/etc/rc.d will do the rest, as it is invoked by the rc.local_startup script.  In S10-install_custom_packages you will find the exact same two lines you could have added to the end of the "go" script if you did not have an /boot/custom/etc/rc.d/rc.local_startup file.

 

So... you do NOT need those additional two lines in your "go" script.  They would only be needed if you did not have the rc.local_startup system of files in place.

 

Joe L.

I've got these variables defined in my unmenu_local.conf:

 

#Go Script Manager Variables
AUTO_GOSCRIPT_COMMAND = cd %PACKAGE_DIRECTORY% && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c
AUTO_GOSCRIPT_TEST = grep '^[^#]*\.auto_goscript'

 

At the end of my go script I run packages located in /boot/custom/etc/rc.d

 

#Execute scripts in /boot/custom/etc/rc.d
fromdos < /boot/custom/etc/rc.d/rc.local_startup | sh

 

And, one of the scripts in /boot/custom/etc/rc.d is S10-install_custom_packages, which executes the following:

 

cd /boot/custom/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c 
cd /boot/custom/packages && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c

 

Do I still need this stuff in my go script?

 

cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c
cd /boot/packages && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c

 

Granted, where I've located my S10-install_custom_packages script isn't in the same location as everyone who runs unMenu, I thought S10-install_custom_packages was an integral part of unMenu.  Since the Go Script Manager runs under unMenu I'm not understanding why it would be necessarry to add these lines to the go script as well.  I'm just trying to understand.

 

I'm sorry, I forgot to mention the S10-install_custom_packages script.

 

It is not required that you use the rc.d structure in unMENU, I do not fully use that convention as of yet and my unMENU works fine.  I have been meaning to adopt it but for now I like being able to test a system as close to stock as possible.  Having people who use the rc.d structure report issues to me is easier to troubleshoot as these people have the tendency to be more familiar with unRAID and can usually help to diagnose at the very least what the root of the problem is and/or where it is coming from in the program.

 

You have however made me think about a small issue with the new code (indirectly).. it does not check to see if you have a rc.d structure before adding a 30 second delay to the booting process, and if i'm not mistaken, you already have a 30 second delay before S10-custom... is run.  This will mean that your unmenu (and your other tweaks) will not start until a full minute has passed.  I will fix this annoyance for the next version.  Sorry.

 

Cheers,

Matt

Matt,

 

Upgraded my Go Script Manager without problems. Nice changes. I like this plug in alot as it is easy to add and remove scripts. I have not yet adopted the _local use of unmenu but will eventually do that. Since I am new to all this, I first wanted to get everything up and running and then ill tweak everything so that future upgrading is easy.

 

 

 

Matt & Joe,

 

Thank you for the quick feedback.  I figured your responses, but I wanted a sanity check.  One last thing...

 

I have a couple of the scripts enabled in the Go Script Manager.  But, when I press the button to view the current contents of my go script this is all I see:

 

System Notification Messages
Your Go Script file contents can be viewed below. 

Contents of your Go Script file: /boot/custom/etc/rc.d/S10-install_custom_packages
cd /boot/custom/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c  
cd /boot/custom/packages && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c 

 

Even when I don't have any scripts enabled in the Go Script Manager I see the same thing.  Also when I press the button to back up my current go file, it instead creates a backup of my S10-install_custom_packages (i.e. S10-install_custom_packages-2009-01-17-1552.bak).

 

I'm wondering if it is because I am using the rc.local_startup system on my server.  Maybe I'm confusing the Go Script Manager?

 

 

Matt & Joe,

 

Thank you for the quick feedback.  I figured your responses, but I wanted a sanity check.  One last thing...

 

I have a couple of the scripts enabled in the Go Script Manager.  But, when I press the button to view the current contents of my go script this is all I see:

 

System Notification Messages
Your Go Script file contents can be viewed below. 

Contents of your Go Script file: /boot/custom/etc/rc.d/S10-install_custom_packages
cd /boot/custom/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c  
cd /boot/custom/packages && find . -name '*.auto_goscript' -type f -print | sort | xargs -n1 sh -c 

 

Even when I don't have any scripts enabled in the Go Script Manager I see the same thing.  Also when I press the button to back up my current go file, it instead creates a backup of my S10-install_custom_packages (i.e. S10-install_custom_packages-2009-01-17-1552.bak).

 

I'm wondering if it is because I am using the rc.local_startup system on my server.  Maybe I'm confusing the Go Script Manager?

 

I guess that would be a bug/mistake on my part...

 

Right now I have the Go Script manager thinking that wherever it append the line to make the auto_goscript files work is the "go file... As you have pointed out, this is wrong... I'm going to add a feature whereby IF you have an S10-custom_install file, you can back it up seperately and then the "backup go file" button will always backup the /boot/config/go file.. WIll be added to the next version.

 

Cheers,

Matt

What I don't understand is exactly what changes is this backing up. 

 

From what I can tell, every script I enable results in a new *.auto_goscript installed to my /custom/packages/ directory.  And, then, via S10-install_custom_packages these *.auto_goscript files are executed upon boot.  It doesn't appear to me that the Go Script Manager ever actually makes any changes to the go script file that would need to be backed up (or restored).

 

If I'm understanding properly, I do like that way that this is designed to work.  The only thing I can't figure out is how to control the order in which scripts enabled with the Go Script Manager are executed at boot time.

Version 0.6.1 in OP

 

The effects of this fix will only be seen by those with the /boot/custom/etc/rc.d structure.  It fixes a couple of oversights.

 

I guess that would be a bug/mistake on my part...

 

Right now I have the Go Script manager thinking that wherever it append the line to make the auto_goscript files work is the "go file... As you have pointed out, this is wrong... I'm going to add a feature whereby IF you have an S10-custom_install file, you can back it up seperately and then the "backup go file" button will always backup the /boot/config/go file.. WIll be added to the next version.

 

Cheers,

Matt

 

FIXED - please confirm that you now back-up and view /boot/config/go and not /boot/custom/etc/rc.d/S10-custom_install_packages

 

You have however made me think about a small issue with the new code (indirectly).. it does not check to see if you have a rc.d structure before adding a 30 second delay to the booting process, and if i'm not mistaken, you already have a 30 second delay before S10-custom... is run.  This will mean that your unmenu (and your other tweaks) will not start until a full minute has passed.  I will fix this annoyance for the next version.  Sorry.

 

Cheers,

Matt

 

FIXED - please check the contents of your zzz.auto_install file (it's in your package folder) AFTER running Go Script Manager v0.6.1 at least once.  if you use the rc.d structure, does it still contain the line:

sleep 30

 

TO UPDATE

1. Stop unMENU

2. remove 800-unmenu-goscriptv0.6.awk and copy over new 800-unmenu-goscriptv0.6.1.awk in your unmenu folder

3. restart unMENU and run Go Script Manager.

 

Cheers,

Matt

What I don't understand is exactly what changes is this backing up. 

 

From what I can tell, every script I enable results in a new *.auto_goscript installed to my /custom/packages/ directory.  And, then, via S10-install_custom_packages these *.auto_goscript files are executed upon boot.  It doesn't appear to me that the Go Script Manager ever actually makes any changes to the go script file that would need to be backed up (or restored).

 

If I'm understanding properly, I do like that way that this is designed to work.  The only thing I can't figure out is how to control the order in which scripts enabled with the Go Script Manager are executed at boot time.

 

You are correct, but what I was envisioning is that people may make additions/modifications to the go script manually because a package did not exist yet for them to use and did not want to make one themselves (think of a new tweak/user mod that may not have a .conf package for the package manager or the go script manager yet).  For instance, before I made the Powerdown package for the package manager, we all needed a line in our go script or in a script in the rc.d structure ot install the package on boot.  Now that we have the package manager .conf file, someone may want to modify their go file and backup the new copy incase something happens.  I also have a feature in the works whereby someone could simply modify their go script directly if that was the case (instead of needing to use another plug-in/a text editor to do it).  This would require me to have my own backup feature anyways.  It is not something that I ever envisioned would be used very much but figured if I did not include it, someone would ask for it eventually.  I already had the code in place for other features, all I needed to do was add a button to let the user invoke it (well not quite that simple, but almost).

 

In terms of Boot sequence, I am trying to work through some ideas on how to accomplish that... (it is somthing that I have as a planned feature.)  I have however been brainstorming an overhaul on the Go Script Manager and possible rebranding to a Boot Manager based on an idea I had last night.  A quick overview is that it would provide better support for the rc.d structure.  Instead of creating .auto_goscript file, if you have an rc.d structure, the appropriate S##-NAME file will be created in the /boot/custom/etc/rc.d structure.  This would fix the boot sequence problem and allow the community to decide name conventions for the tweaks/mods (and thus the boot sequence).  I could then apply this boot sequence to people running the go script/boot manager but don't have the rc.d structure through the use of .auto_goscript files.  I will probably need/ask the community for some feedback in the near future in terms of contents of their rc.d folders.

 

An easy way to control the order of the script right now is to do the following...

1. disable all script in the Go Script Manager (VERY IMPORTANT, you will get orphan .auto_goscript files left behind if you don't)

2. Open your package folder

3. rename the ****-unmenu-goscript.conf files to include leading numbers (use 2-3 digit numbers), these numbers are the order you want them to boot in.  You should add the numbers to them all..

4. re-enable the script in go-script manager

 

so the first script would be 001-****-unmenu-goscript.conf (if you renumber some but not them all, the ones with numbers will go first followed by those with letters, it uses alphanumeric sorting)

 

Cheers,

Matt

What I don't understand is exactly what changes is this backing up. 

 

From what I can tell, every script I enable results in a new *.auto_goscript installed to my /custom/packages/ directory.  And, then, via S10-install_custom_packages these *.auto_goscript files are executed upon boot.  It doesn't appear to me that the Go Script Manager ever actually makes any changes to the go script file that would need to be backed up (or restored).

 

If I'm understanding properly, I do like that way that this is designed to work.  The only thing I can't figure out is how to control the order in which scripts enabled with the Go Script Manager are executed at boot time.

he still has bug or two to squash...

You are correct, but what I was envisioning is that people may make additions/modifications to the go script manually because a package did not exist yet for them to use and did not want to make one themselves (think of a new tweak/user mod that may not have a .conf package for the package manager or the go script manager yet). 

 

Isn't this what Joe's "Config View/Edit" unMenu plugin is for?

You are correct, but what I was envisioning is that people may make additions/modifications to the go script manually because a package did not exist yet for them to use and did not want to make one themselves (think of a new tweak/user mod that may not have a .conf package for the package manager or the go script manager yet). 

 

Isn't this what Joe's "Config View/Edit" unMenu plugin is for?

Yes, but in fairness, I had the code written and working(v0.4 released Dec 26th) BEFORE that plug-in was available (Dec 28th or 29th), it made the feature obsolete, I guess.  I left it in because I still felt the option should be there for people who might have edited the go file manaully with a text editor and want to back it up.

 

As of right now, I can't easily link to the config view/edit plugin without causing formatting problems on the go script manager.  I was hoping that when Joe L. wrote the libraries that I might be able to do away with the backup button by giving them a place to go to edit the file and leave that stuff up to the config view/edit plugin libraries but can't do that easily yet.  At the very least I can't do it without taking Joe L's code and re-writting it (either like I did in the "unMENU Plugin: Config View/Edit" thread OR by adding it directly to my own).

 

Would you like me to remove the backup go file feature in future versions?

 

Cheers,

Matt