unMENU 1.5 ... now available for download.


Recommended Posts

I changed the smarthistory file (200-unmenu-smarthistory.cgi) so that it wouldn't wake up the drives to update.  I figure there is a user script button I can click to update the history and if I just want to view it, I can use the link at the top of the page without waking up my drives.

 

That worked fine until I updated unMenu.  I guess it just checks that the file is different than expected and updates it.  I see that the old file is moved to a backup folder and I can move it back.  But, that means I have to remember to do that.  Is there some way to not have unMenu's update overwrite user modified files?

 

Thanks

Link to comment
  • Replies 1.3k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I changed the smarthistory file (200-unmenu-smarthistory.cgi) so that it wouldn't wake up the drives to update.  I figure there is a user script button I can click to update the history and if I just want to view it, I can use the link at the top of the page without waking up my drives.

 

That worked fine until I updated unMenu.  I guess it just checks that the file is different than expected and updates it.  I see that the old file is moved to a backup folder and I can move it back.  But, that means I have to remember to do that.  Is there some way to not have unMenu's update overwrite user modified files?

 

Thanks

 

I ran into this same problem the other day. I modify the myMain plugin to remove the hyperlink section and another couple files to get rid of some messages that appear in my syslog.

Link to comment

I changed the smarthistory file (200-unmenu-smarthistory.cgi) so that it wouldn't wake up the drives to update.  I figure there is a user script button I can click to update the history and if I just want to view it, I can use the link at the top of the page without waking up my drives.

 

That worked fine until I updated unMenu.  I guess it just checks that the file is different than expected and updates it.  I see that the old file is moved to a backup folder and I can move it back.  But, that means I have to remember to do that.  Is there some way to not have unMenu's update overwrite user modified files?

 

Thanks

You could name your local copy something else (199-unmenu-smarthistory.cgi as an example) and your local copy will not be touched since it is not downloaded.  That would result in two buttons, the original and yours.  Since yours is lower numbered, it would be used for either button.

 

If you change the label on your copy it will be able to be selected uniquely.  You can label the new version as

#define ADD_ON_MENU=Smart History - no spinup

I ran into this same problem the other day. I modify the myMain plugin to remove the hyperlink section and another couple files to get rid of some messages that appear in my syslog.

I don't currently have a way to exclude a locally edited version but I can think of a method I could add. 

 

I'm thinking every file being automatically downloaded will have a "#UNMENU_RELEASE ..... " line in it. 

 

Would it work for you if the script that copies new versions into place looks for the existence of that line, and if NOT found would not replace the old version with the new.  (The new would still be in the download temp directory, but not moved into place) 

 

To prevent a locally edited file from being updated automatically, you would just need to remove that line or change #UNMENU_RELEASE to anything else so it would not match when the unmenu_install script attempts to find it.

 

Would that work for both of you?  Locally edited files (with that #UNMENU_RELEASE line not present) would not be auto-updated.

 

Joe L.

 

 

 

Link to comment

That would work, but i think it might hamper us from getting updates when they are actually needed.

 

I say keep the RELEASE line like it is but add a "#USER_EDITED=?" (where ? is NO by default and can be changed to YES by the user that edits it). That way, if a new release does come out we can be notified that the RELEASE lines don't match but it looks like changes were made by the user. From there the new packages could be installed and a little warning about user edited files having been over written could be presented.

Link to comment

That would work, but i think it might hamper us from getting updates when they are actually needed.

 

I say keep the RELEASE line like it is but add a "#USER_EDITED=?" (where ? is NO by default and can be changed to YES by the user that edits it). That way, if a new release does come out we can be notified that the RELEASE lines don't match but it looks like changes were made by the user. From there the new packages could be installed and a little warning about user edited files having been over written could be presented.

That could also work.    I also like the idea that you can add your own comments as to what you might have changed, just in case your memory is not perfect.

 

Let me see what I can come up with.  I'll probably need to initially ignore the new #USER_EDITED line when comparing checksums since none of the files currently have it, and if I add it to all with an initial "=NO" it would force the download of everything for everybody.  I do something like that now for the user-edited PACKAGE_VARIABLE lines in the files.

 

Granted, downloading everything would not take that long, but it would not be expected by a used looking for an update to find everything needs to be updated.

 

Joe L.

Link to comment

I am trying to understand how auto_install works so I can design an installation package for something I am writing (very very slowly),  Please remember I am a linux beginner, I may use the roight words and sound like I know what I am doing but I do not yet fully undertand some of the linux basics.

 

I look at the line in the go file:

 

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

 

I understand the first term before the and (&&)

 

The part after the and has me a little confused and some explanation would help me a lot

 

I think the first part searches in the working directory (.) for a thing ending in ".auto_install" which is of type ordinary file and

sends the file names found to sort via a pipe whose output (sorted file names ending in .auto_install with relative paths) is piped to xargs where ???? thats where I get stuck. Why is the sort even necessary?

 

I think xargs causes each line output by the sort command to be prefaced by sh which causes the line to be executed as the name of a shell script to be executed with a single argument (-n1  ???). I assume that means that each of the lines output by the sort (lines like SomeFileName.tgz.auto_install) will be executed as a shell script with argument of -c (??).  From what I can see the .tgz files contain .tar files which contain... and I am now mired in the muck!!

 

I want to build an install process for a shell script that I am developing.  That should not be too hard but I am a little lost as you can see.  Any help greatly appreciated. Better still, is there any document on how to make a conf file for unmenu which is what I assume is used to install the package and a bried description on how unmenu works?

 

I am missing something key. 

Link to comment

Forgot to mention on the .tgz / .txz.

 

Those files are compressed using 'gz' or 'xz'. The contents of which are in TAR format. It's convention to use .tgz or.txz to indicate gzip tar or xzip tar contents. Of the two, 'xz' is the new and improved format.

 

The contents of the TAR files are Slackware Packages [slackBuild]. They contain the information needed to install the contents and the actual contents to install. They are installed using the "installpkg filename.tgz" or "installpkg filename.txz"

 

For way too much information on how to generate and create Slackware Packages using the typical tool, SlackBuild, here is their wiki page: http://slackwiki.org/Writing_A_SlackBuild_Script

Link to comment

I updated the previous post to include a bit more information as I found links to the SlackBuild Wiki.

 

The -c option to sh (unix shell) according to the man page (assuming the default shell is Bash) [man bash]:

 

-c string If the -c option is present, then commands are read from string.  If there are arguments after the string, they are assigned to the positional parameters, starting with $0

 

The string passed to the shell is 1 line [-n1 option specifies at most 1 argument per command line] based on the input to 'xargs', which is the output of the 'sort' which works on the output of the 'find', which lists all *.auto_install file names.

Link to comment

I am trying to understand how auto_install works so I can design an installation package for something I am writing (very very slowly),  Please remember I am a linux beginner, I may use the roight words and sound like I know what I am doing but I do not yet fully undertand some of the linux basics.

 

I look at the line in the go file:

 

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

 

I understand the first term before the and (&&)

 

Let's see if I can break it down.

cd /boot/packages               <= changes directory to /boot/packages   If successful, exit status is 0, if not, non-zero

&&                                    <= conditionally execute the following command based on the previous exit status = 0 (0=success)

                                          (if /boot/packages did not exist, and the "cd" failed, the find command would not be invoked.)

find .                                 <= find in this (/boot/packages) directory and all sub-directories of it.

                                         (we did not limit the depth of the find, but usually there are no sub-directories)

-type f                              <= the find command is looking for files

-name "*.auto_install"          <= and the file must end its name in .auto_install

-print                                <= if the file meets all the criteria then print its path.    

                                         

The will result in a list of files that meet the correct name.  On my server right now I get this

root@Tower:/boot/packages# find . -type f -name "*.auto_install"

./unmenu.auto_install

./bash_init.auto_install

./vi_keymap.auto_install

./bwm-ng-0.6-i486-2bj.tgz.auto_install

./file-4.21-i486-1.tgz.auto_install

./htop-0.8.3-i486-1sl.tgz.auto_install

./iftop-0.17-i486-1kan.tgz.auto_install

./apcupsd-3.14.3-i486-1kjz.tgz.auto_install

./rc_files.auto_install

./unraid_addon_control.auto_install

./vm_free_kbytes.auto_install

./powerdown-1.02-noarch-unRAID.tgz.auto_install

./inotify-tools-3.13-i486-1.tgz.auto_install

./monthly_parity_check.auto_install

./pciutils-2.2.10-i486-2.tgz.auto_install

./unraid-status-email.auto_install

 

Yes, I have a lot of files being installed.

 

Next, they are sorted.  This is to allow a crude way of invoking them in a certain order.  I've not written anything to use this ability, as install order has not been an issue now that a single package can perform many installpkg steps.  Once the list has been sorted it is passed to xargs

 

xargs -n1                       <= for each line input (the -n1 indicates I do not want xargs to group the commands, but invoke them one at a time)

sh -c                             <= -c string Read and execute commands from string after processing the options, then exit.

f

 

Therefore, for each line in the set of lines fed as input, xargs will invoke sh -c "line"

 

So the result will be

sh -c  ./apcupsd-3.14.3-i486-1kjz.tgz.auto_install

sh -c  ./bash_init.auto_install

sh -c  ./bwm-ng-0.6-i486-2bj.tgz.auto_install

sh -c  ./file-4.21-i486-1.tgz.auto_install

sh -c  ./htop-0.8.3-i486-1sl.tgz.auto_install

sh -c  ./iftop-0.17-i486-1kan.tgz.auto_install

sh -c  ./inotify-tools-3.13-i486-1.tgz.auto_install

sh -c  ./monthly_parity_check.auto_install

sh -c  ./pciutils-2.2.10-i486-2.tgz.auto_install

sh -c  ./powerdown-1.02-noarch-unRAID.tgz.auto_install

sh -c  ./rc_files.auto_install

sh -c  ./unmenu.auto_install

sh -c  ./unraid-status-email.auto_install

sh -c  ./unraid_addon_control.auto_install

sh -c  ./vi_keymap.auto_install

sh -c  ./vm_free_kbytes.auto_install

 

Any file you put in /boot/packages ending with .auto_install will be executed in lexical order (because of the "sort") when you boot the server.   Most are scripts to install various packages added through the unMENU package manager.  Some in my example are hand-coded and not added with a specific package.

 

An awful lot happens with that one line.

 

Joe L.

 

Link to comment

Now to answer your question about the filename.tgz files...

 

I imagine a typical untorrent.tgz.auto_install file would contain the following:

 

/bin/installpkg untorrent.tgz

 

This will invoke the command 'installpkg' on the untorrent.tgz. The 'installpkg', 'upgradepkg', and 'removepkg' and 'slackpkg' are standard Slackware Package Management tools to install, upgrade, remove, and manage packages.

 

From Joe's earlier message, his unmenu.auto_install does the following commands:

 

cd /boot/unmenu_dist13
./uu

Link to comment

Here's what a typical Slackware Package layout consists of [ http://slackwiki.org/Packages#Slackware_Package_Layout ]

 

./
./install/doinst.sh
./install/slack-desc
[./usr/bin]
[./usr/lib]
[...]

 

The install directory as well as the files within it will be deleted after the installation of the package to the root install directory (usually '/'). The install directory is not necessarily required for the most basic packages but allows additional functionality: slack-desc  contains the package description, and doinst.sh contains post-installation instructions such as creating symbolic links.

 

Every other file within the package is simply untarred (extracted) to the root directory. Most of these files are in standard locations.

 

There are other special files within packages:

 

usr/doc/<appname><version> All documentation included with the package (such as README, INSTALL, ChangeLog, docs/, etcetera) should be placed in this directory. Some of the files in this directory should be manually copied from the source archive, since Makefiles usually don't copy these documentation files to the package build tree.

Link to comment

Now to answer your question about the filename.tgz files...

 

I imagine a typical untorrent.tgz.auto_install file would contain the following:

 

/bin/installpkg untorrent.tgz

 

This will invoke the command 'installpkg' on the untorrent.tgz. The 'installpkg', 'upgradepkg', and 'removepkg' and 'slackpkg' are standard Slackware Package Management tools to install, upgrade, remove, and manage packages.

 

From Joe's earlier message, his unmenu.auto_install does the following commands:

 

cd /boot/unmenu_dist13
./uu

That is true, as I have my "unmenu" folder, and another with unmenu_dist11, another with unmenu_dist12, and a fourth with unmenu_dist13.  A really crude method of allowing me to invoke any one of them if investigating a trouble report.

 

Joe L.

Link to comment

with regard to email notification.  It states that there must be mail configured.  How does one do that.  I am not sure what package I need to install to get mail configured. I don't want to install the older unraid_notify but that does seem to configure a mail system as part of its installation

The package you want is

mail and ssmtp - Configure unRAID to be able to send e-mail notifications via the "mail" command.  It needs to be compiled... So...

 

You'll also need to install the "C" compiler.  Don't worry, clicking on the buttons on the package manager will do everything for you, you don't have to learn "C"  Click the download button, then the "Install" button.

 

It is because I was unable to find a version of ssmtp with the encryption library compiled in.  It caused me a bit more hair loss, as I tried valiantly to connect to gmail with the compiled version I did find.

 

It was one of the incentives I had to get the package manager to where it is today.

 

So... First install the "C" compiler,  you do not need to set ti to re-install on re-boot.

 

Then install "mail and ssmtp" after configuring its editable fields. Set it to re-install on re-boot

 

Then, install the e-mail alerts. Set it to re-install on re-boot.

 

All in all, it will take you longer to edit the few configuration fields than any of the other steps.

 

Before you start, use the "Check for Updates" button on the user-scripts page, as lots of tiny fixes and improvements have been made in the past days based on feedback and suggestions.

 

Joe L.

Link to comment

The alternate package directory seems to be working well.  I now have all my packages in both /mnt/scratch/packages and /boot/packages with the unmenu_local.conf file in /boot/unmrnu with a single line in it.  Do I need to keep the packages in /boot/packages or can I remove that directory after making a backup someplace of course.

 

If I want to be able to install just a shell script and be able to refer to it as a command, I understand most of what I need to do.  I understand chmod, am not sure I need chown. Where do I put the whatsitsname.sh file? /etc/bin ?

 

Perhaps an Install Script option for unMenu or is it already there?    

Link to comment

The alternate package directory seems to be working well.  I now have all my packages in both /mnt/scratch/packages and /boot/packages with the unmenu_local.conf file in /boot/unmrnu with a single line in it.  Do I need to keep the packages in /boot/packages or can I remove that directory after making a backup someplace of course.

You can leave it in place or move it, it will not be used if you set the PACKAGE_DIRECTORY variable in unmenu_local.conf

If I want to be able to install just a sheel script and be able to refer to it as a command, I understand most of what I need to do.  I understand chmod, am not sure I need chown. Where do I put the whatsitsname.sh file? /etc/bin ?

It either needs to be invoked with an absolute path, or be in a directory that is in the search path.

 

The normal place is /usr/local/bin or /usr/local/sbin but those are re-created every time you reboot.

We've adopted a convention for local commands as

/boot/custom/bin

 

It does not exist, so you'll need to create it.

mkdir -p /boot/custom/bin

 

You can then either copy commands from it into /bin  or /usr/bin when booting up, or leave them there and add /boot/custom/bin to the search path with a line in the "go" script like this:

echo 'PATH=$PATH:/boot/custom/bin; export PATH' >/etc/profile.d/custom_path.sh

 

It creates a file in /etc/profile.d that gets invoked every time you log on.

Perhaps an Install Script option for unMenu or is it already there?    

 

No, there is none.  You can easily create one though as a .auto_install file.  That's how I have mine.

 

It is just two lines

cd /boot/unmenu

./uu

 

Link to comment

That would work, but i think it might hamper us from getting updates when they are actually needed.

 

I say keep the RELEASE line like it is but add a "#USER_EDITED=?" (where ? is NO by default and can be changed to YES by the user that edits it). That way, if a new release does come out we can be notified that the RELEASE lines don't match but it looks like changes were made by the user. From there the new packages could be installed and a little warning about user edited files having been over written could be presented.

That could also work.     I also like the idea that you can add your own comments as to what you might have changed, just in case your memory is not perfect.

 

Let me see what I can come up with.  I'll probably need to initially ignore the new #USER_EDITED line when comparing checksums since none of the files currently have it, and if I add it to all with an initial "=NO" it would force the download of everything for everybody.  I do something like that now for the user-edited PACKAGE_VARIABLE lines in the files.

 

Granted, downloading everything would not take that long, but it would not be expected by a used looking for an update to find everything needs to be updated.

 

Joe L.

I used a combination of our ideas.

 

The newest version of unmenu_install will look for a line like this in the file

#AUTO_UPDATE = NO

or

#AUTO_UPDATE = YES

 

if "#AUTO_UPDATE = NO", the update will NOT occur, but instead it will print the needed command to move it into place.  It will also print the command needed to see the difference between the old and new files.  The new file is in the /tmp/unmenu_tmp directory.

         

if "#AUTO_UPDATE = YES", the update WILL occur, and it will print the needed command to see the difference between the old and new version.  The old file will have been moved to an unmenu_old_YYYY-MM-DD_HHMI directory.

 

If no #AUTO_UPDATE line exists in the file, it will just back up the old version and copy new into place as it has done in the past.

 

The "#AUTO_UPDATE = YES/NO" must exist on a line of its own to be recognized.  To test if you have added it correctly you can type:

grep "^#AUTO_UPDATE" your_file_name

 

The output will be the #AUTO_UPDATE line you added, if you added it correctly.

 

I did not impliment a USER_EDITED line as prostaff originally suggested, since I think the AUTO_UPDATE key-word is more descriptive.  If it exists, the file was locally edited.

 

Joe L.

Link to comment

I have been in the computer field since 1960, but was never involved with Unix to any great degree.  I have always been of the nature to understand something before I use it and try to do things similar.  The explanations above fully explain, to me at least, what is going on with unMenu and the installation of packages.  I was not aware that the && would take an immediate exit if a term failed and not continue, that is it used short circuit evaluation.  I am used to all the terms of relationals being evaluated and then the relational aspect applied.  Now I see how the shell uses short circuit evaluation.  I assume if I used or (||) then the evaluations would proceed with the reult of the terms being orr'ed to determine the state of a parenthetical expression.  Very nice.  I am just not used to stringing commands together like that always having dealt with more formal languages prior to this.

 

Thank you very much for the detailed explanations and pointers. This is one amazing forum and it is all due to its members. I am trying to get my system to use unMenu in its purest form for all addons, and then be able to develop my own add ons.

 

My plan is to proceed as follows

 

1) Keep loading the array with movies. All my BR's are loaded and half my DVD's

2) Replace notify_unraid with the email message notifier in unMenu (thanks jow for the detailed how to)

3) Write my own TCP/IP notifier to inform my Home Automation system of unraid issues (using what is around as a base)

 

Link to comment

I have been in the computer field since 1960, but was never involved with Unix to any great degree.  I have always been of the nature to understand something before I use it and try to do things similar.  The explanations above fully explain, to me at least, what is going on with unMenu and the installation of packages.  I was not aware that the && would take an immediate exit if a term failed and not continue, that is it used short circuit evaluation.  I am used to all the terms of relationals being evaluated and then the relational aspect applied.  Now I see how the shell uses short circuit evaluation.  I assume if I used or (||) then the evaluations would proceed with the reult of the terms being orr'ed to determine the state of a parenthetical expression.  Very nice.  I am just not used to stringing commands together like that always having dealt with more formal languages prior to this.

 

Thank you very much for the detailed explanations and pointers. This is one amazing forum and it is all due to its members. I am trying to get my system to use unMenu in its purest form for all addons, and then be able to develop my own add ons.

 

My plan is to proceed as follows

 

1) Keep loading the array with movies. All my BR's are loaded and half my DVD's

2) Replace notify_unraid with the email message notifier in unMenu (thanks jow for the detailed how to)

3) Write my own TCP/IP notifier to inform my Home Automation system of unraid issues (using what is around as a base)

 

That you are familiar with short-circuit-evaluation is good.   I've been involved with Unix since 1979/1980 time-frame.  It was Columbus Bell-Labs Unix 1.0.  (Yup, one of the first.) had to initially learn just by reading the manuals (and had to print out my own manual at that)

 

Yes, you can write a line like

[ "joe" = "barry" ] && "echo "names match" || echo "names do NOT match"

You can also add braces and parens to make it a lot more complicated.  

 

When I wrote the one-liner to be added to the "go" script I purposely made it as simple as I could so it could be searched for easily (so I would not add it again if already there) and to allow it to be easily removed by novice users.  

 

Glad you are having fun.   I've been mostly involve with Unix, at every level down to the internals and device driver level.

 

At one point in time I had written a device driver module for a communications interface board used on a Unix server at the New-York-Stock-Exchange.   It was used to communicate with and program all the smart phones on the trading floor.   My boss just asked that we "never" make the evening news because of a failure that shut down trading. (This was pre-cell phone days, so the only communications to the brokerage houses were the phones being programmed... all direct lines, so dial-up was not even possible)

 

Somehow I doubt that system is still in place, as it has been over 20 years, but who knows.  We never did make the news.

 

My first Slackware linux was somewhere around 1974 1994.  I re-wrote the sound-card driver to be able to play Doom on it.  It was on a very old 386 based PC, and it booted from a 5 1/4 inch floppy disk when running linux from a second disk partition hidden from windows.

 

I have no idea how many programming languages I've used over the years...

 

Joe L.

 

Edit: fixed typo on date.

Link to comment

Some day we will have to meet.

 

Some issues I think I have noted with using an alternate package directory as experienced when I tried to set up email with your excellent how to.

 

I did an update first as you suggested and what surprised me was that the /boot/packages directory had all new time stamps for the files that were in it and the /mnt/scratch/packages directory did not.  I thought I could eliminate the /boot/packages directory but this indicates that I may not be ready to do that.

 

I believe (but may be wrong) that when you build the line to load all of the auto_install files you are not taking into account that there may be an alternate directory specified.

 

It appeared that ssmtp did not load properly with the alternate directory specification, but I think you mentioned something about that.

 

I went back to NO alternate directory and was able to get all working fine including mail notify.  I might suggest that on the section under packages in the ssmtp package setup if possible include a test button to see if mail is working so you don't have to bounce to the user scripts p[age and back again until one (me) gets it right.

 

On a separate topic, is there any way to modify where syslogs go so that all syslogs go to the alternate location.  Purko had posted some code which seems to work but only allows for a current and last log to be at the alternate location. I assume for it to be truly effective it would have to be done in the unraid boot portion of the system and not at go file time.

 

I have two thinks left I want to do besides finishing loading the array:

 

1)write a TCP based notification system

 

2) see if I can get the logitech squeezebox server running on the unraid box.  There is a thread on just that subject.  I don't want the squeezebox server on one box and the files on another causing the audio streams to traverse the network twice.

 

 

 

Link to comment

I used a combination of our ideas.

 

The newest version of unmenu_install will look for a line like this in the file

#AUTO_UPDATE = NO

or

#AUTO_UPDATE = YES

 

if "#AUTO_UPDATE = NO", the update will NOT occur, but instead it will print the needed command to move it into place.  It will also print the command needed to see the difference between the old and new files.  The new file is in the /tmp/unmenu_tmp directory.

         

if "#AUTO_UPDATE = YES", the update WILL occur, and it will print the needed command to see the difference between the old and new version.   The old file will have been moved to an unmenu_old_YYYY-MM-DD_HHMI directory.

 

If no #AUTO_UPDATE line exists in the file, it will just back up the old version and copy new into place as it has done in the past.

 

The "#AUTO_UPDATE = YES/NO" must exist on a line of its own to be recognized.  To test if you have added it correctly you can type:

grep "^#AUTO_UPDATE" your_file_name

 

The output will be the #AUTO_UPDATE line you added, if you added it correctly.

 

I did not impliment a USER_EDITED line as prostaff originally suggested, since I think the AUTO_UPDATE key-word is more descriptive.   If it exists, the file was locally edited.

 

Joe L.

 

Joe, that's awesome.

 

I have been putting my server to S3 sleep, using the script in unMenu, every night before going to bed. I will probably change to the automatic "go to sleep" script which checks for network activity and more before executing it.

 

Back to topic. With the end of the month comes the auto parity check script. Last night I left the server running, so the script would run. I could have manually checked the parity this morning,  but I would rather have it run overnight. I remembered about the batch file I have (wolcmd) to wake up the server from windows, so I decided to setup a scheduled task to run that batch file the last day of the month at 11:55pm.

 

Problem was accounting for 28,29,30 or 31 days per month. So I ended up changing the check parity script to run at 12:05am. My scheduled task wakes the server on the 1st day of every month at 12:00am.

 

With adding the #AUTO_UPDATE = YES/NO, I can keep my script with my changes intact. When checking for unMenu updates, it warns me that the script was not updated but I can check the differences between the two.

 

Joe, ideally would be to have a button, similar to the one in the "Config View/Edit" page that lets us view the backup version. On clicking it, we could see the differences and then decide to apply the update or not.

 

Comments?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.