unMENU plug-in: Config & System File Editor

Thanks to some ground-breaking work by bjp999 to get unmenu.awk to support POST requests from a browser, it was now possible for me to create a Config and System File editor plug-in for unMENU.  (this plug-in requires unmenu.awk to be version 1.1 or later    download from here  )

 

This new file-editor is restricted to a specific set of files known to be "text" files that are editable.    It does not have the ability to create a new file.

 

The list of files that may be edited include:

the "/boot/config/go" file

/boot/config/*.cfg

unmenu.conf

unmenu_local.conf  (if it exists)

as well as all the .conf files, manual and auto-install files in /boot/packages and in /boot/custom/etc/rc.d.

 

You can also define additional locally editable files for packages or software you locally installed in either the unmenu.conf or (preferably) in unmenu_local.conf. Simply add lines like this for each local file that may be edited

EDITABLE_FILE = full_path_to_your_locally_editable_file

 

The plug-in is able to determine if UNIX "newlines" are needed, or if MS-DOS carriage-return/newline pairs are needed.

 

Backup copies of edited files are kept in a "backup_files" directory.  You may view the backup copies, and see any differences.  You may revert to a backup copy at any time. 

 

To install this, simply unzip it in the same folder as your other unmenu.awk files, then stop and re-start unmenu.awk.  When it is re-started, it will add the new plug-in to its top menu.

 

As you might expect, it is possible for you to introduce syntax errors into the files being edited.  Some files, if mis-managed, might even cause unRAID to not boot properly, or at all.  If this happens, move the flash drive to your PC and copy the older version of the file in the "/boot/backup_files" folder back into place. (renaming it to get rid of the date-time-stamp.bak suffix)

 

As always, there is no way for me to duplicate all the possible content on every server.  Your files might not be edited correctly.  If so, copy the backup copy back into place and let me know what happened. (or didn't happen)

 

The main unmenu "Config View/Edit" screen looks like this:

 

Once you select a file to view, you may edit it.  When viewing a file it will alert you if any backup copies of that same file already exist.

 

The screen background color changes to let you know you are editing a file (I had pressed the "Edit File" button while viewing it).

 

If you elect to view a "backup copy" you will be shown the differences between it and the current file.  While viewing a backup copy of a file a button will be present to allow you to revert to the backup copy.  If the backup is identical to the current file, a informational message will let you know, and no "revert" button will be present.

 

Consider this to be my "beta" release of the file-editor.  Let me know of any issues, or of any files I should add to the standard list, or if it re-formats the hard-disks of all the PC's on your LAN (only kidding)

 

Joe L.

 

 

wow... i'm trying to get my head around all of that... i've got some ideas/questions... I want to run some by you...

 

first, what do you think is the better choice for me?  to try and integrate and modify this code into my own to add features to the go script manager or would it be better to try and "import" the plug-in into the go script manager through linking.  Ideally, I would like to restrict the number of files to only those relevant to the go script(the file itself and the .confs). Obviously I have a special purpose use for these features, where this plug-in is more geared towards a wide range of uses (and rightly so).

 

secondly, for creating new files.. I was thinking of creating a dummy file that would be modified by the user to input a portion of a new file name(gsub offending characters, and shorten if necessary).  This name would be passed to the dummy file and then have the program take the inputted text and create a file with that name.. you can even have it populate with the PACKAGE_NAME...etc tags on each line and then can be further modified by your new plug-in(for .confs).  like the idea?

 

Finally, should we agree on a convention for a storage location these backups?  currently(the version i'm working on now) i default to PACKAGE_DIRECTORY "/gobackup". what do you think? 

 

Also, I like the way you have named the back-up files.  I will change my code to do the same, that way both plugins will be looking for ALL available backup for the go file.(it also happens to be MUCH less code.  go figure i'd do it the hard way.  )

 

Cheers,

Matt

wow... i'm trying to get my head around all of that... i've got some ideas/questions... I want to run some by you...

 

first, what do you think is the better choice for me?  to try and integrate and modify this code into my own to add features to the go script manager or would it be better to try and "import" the plug-in into the go script manager through linking.

This version should already be able to edit the "go" package-manager packages.  I think it is FAR easier to have each plug-in do one task well, and not to try to do everything on its own.  However, it is very easy to use it either as a link, or upon pressing a button in your own goscript manager.

  Ideally, I would like to restrict the number of files to only those relevant to the go script(the file itself and the .confs).

I already do exactly that.  If the file-name being edited is not one in its list, it is not allowed to be edited.  Granted, security is *very* crude, and any really determined user will figure a way around it, but it prevents a user from doing great harm to their files.

Obviously I have a special purpose use for these features, where this plug-in is more geared towards a wide range of uses (and rightly so).

I understand, and I *must* write up how to invoke this file-editor from another plug-in.  (It might need a tiny change or two to be integrated cleanly, but I'm sure won't be too hard.) 

secondly, for creating new files.. I was thinking of creating a dummy file that would be modified by the user to input a portion of a new file name(gsub offending characters, and shorten if necessary).  This name would be passed to the dummy file and then have the program take the inputted text and create a file with that name.. you can even have it populate with the PACKAGE_NAME...etc tags on each line and then can be further modified by your new plug-in(for .confs).  like the idea?

I think a "form" that has specific fields for the "PACKAGE" is better than a blank file.  I'll work one up for my original "Package Manager" style of ".conf" files.  You can then modify it, and create the equivalent for "go script" packages.

Finally, should we agree on a convention for a storage location these backups?  currently(the version i'm working on now) i default to PACKAGE_DIRECTORY "/gobackup". what do you think? 

If you would not mind changing your backup folder name code to use the same defined variable:

FILE_BACKUP_DIRECTORY

all the backup versions of the files can be put into one place.   The name you used is too specific for most of the files that can be edited, that is why I used a more general location of "/boot/backup_files"   I did not borrow your code to create the unique file names, but I did borrow the "idea." 

Also, I like the way you have named the back-up files.  I will change my code to do the same, that way both plugins will be looking for ALL available backup for the go file.(it also happens to be MUCH less code.  go figure i'd do it the hard way.  )

I used to lead teams of developers. In doing reviews of their code I frequently had to say to myself "I would have done that differently."  Unless it is grossly inefficient, or really badly written, or hard to maintain, their code would stay as it was.  You code was fine, you were not aware of the strftime built-in to awk.    You do bring up another reason for us to both use the same folder for all the backups. (all the backup copies of "go" will be in the same folder, regardless of how or where they were edited.  From my plug-in, you can revert to any older copy.)

 

Note, I did not limit the number of backup copies of any given file, other than there can only be 1 per minute.  It is self-limiting though, as most people do not edit files that often, and those that might can use file-explorer in windows to clean out older versions.   It is still very useful to see the differences, so the older versions are very useful.  When I display them in my drop-down list, I show the newest backup copy of the file at the top of the list and the oldest at the bottom.

Cheers,

Matt

Cheers in return.    Merry Christmas (if you celebrate it)  and an early Happy-New-Year   I won't be writing the package-manager-form-editor plug-in until I finish my new project... I'll be distracted by "hardware" for the next week or so, as I assemble a second unRAID server.  The initial two 1.5TB SATA disk drives for the new server should arrive today, and I need to "mod" the old tower case I have to mount everything.   Oh yes, I need to clean out my garage and install some shelves too... but don't worry, I'll respond to questions here.

 

Joe L.

Oh yes, I need to clean out my garage and install some shelves too... but don't worry, I'll respond to questions here.

Ahhhhh...  The ol' honey-do list strikes again!

 

This version should already be able to edit the "go" package-manager packages.  I think it is FAR easier to have each plug-in do one task well, and not to try to do everything on its own.  However, it is very easy to use it either as a link, or upon pressing a button in your own goscript manager.

I already do exactly that.  If the file-name being edited is not one in its list, it is not allowed to be edited.  Granted, security is *very* crude, and any really determined user will figure a way around it, but it prevents a user from doing great harm to their files.

I've always had the the theory that you need to "hold a users hand" through a program and check their inputs.  Credit for this goes to my first ever programming teacher in high-school.  And not because he taught it, but because the man was such an idiot that he would often crash programs or destroy desired files by just not reading on-screen messages properly.  I try to write programs as if that man is my target audience.

 

I understand, and I *must* write up how to invoke this file-editor from another plug-in.  (It might need a tiny change or two to be integrated cleanly, but I'm sure won't be too hard.) 

This would be a great help, in particular how to invoke it with set states (as in, in restoring backup mode, or editing a particular file).  As well as with restricted file lists to say just -*unmenu*goscript*.confs as options in the drop down box(if possible, i might have to provide the list on my side and invoke your plug-in once selected).

 

I think a "form" that has specific fields for the "PACKAGE" is better than a blank file.  I'll work one up for my original "Package Manager" style of ".conf" files.  You can then modify it, and create the equivalent for "go script" packages.

I had kinda the same idea myself, I was just looking at solving the first incremental step (creating a file).  I was actually thinking about creating "templates" so to speak, if there are particular performance scripts that are available for adding to the go file.  I could make a page that allows users to create a .conf file based on values selected in radio buttons(if there are a known set of good values) or inputted in text fields(for values which may be theoretically unlimited in number).  or at least that was my thinking... it may be a pipe dream

 

If you would not mind changing your backup folder name code to use the same defined variable:

FILE_BACKUP_DIRECTORY

all the backup versions of the files can be put into one place.   The name you used is too specific for most of the files that can be edited, that is why I used a more general location of "/boot/backup_files"   I did not borrow your code to create the unique file names, but I did borrow the "idea." 

Will do!

 

I used to lead teams of developers. In doing reviews of their code I frequently had to say to myself "I would have done that differently."  Unless it is grossly inefficient, or really badly written, or hard to maintain, their code would stay as it was.  You code was fine, you were not aware of the strftime built-in to awk.    You do bring up another reason for us to both use the same folder for all the backups. (all the backup copies of "go" will be in the same folder, regardless of how or where they were edited.  From my plug-in, you can revert to any older copy.)

 

Note, I did not limit the number of backup copies of any given file, other than there can only be 1 per minute.  It is self-limiting though, as most people do not edit files that often, and those that might can use file-explorer in windows to clean out older versions.   It is still very useful to see the differences, so the older versions are very useful.  When I display them in my drop-down list, I show the newest backup copy of the file at the top of the list and the oldest at the bottom.

Granted there may be nothing 'wrong' with my code, I always felt it was bulky and used more of a "work around" then a proper solution.  Using diff and strftime are much, much cleaner.  I was also trying to find an alternative method of doing it.  I won't need a date_file any more and both of our backup lists will populate with a FULL list in the proper order.

 

Do you think we should check the changes between the current and previous versions and if nothing has changed to not allow a new back-up? I guess in your code, the back-up is only created when the modifications are changed, but you don't check to see if they actually made a change(i think). It would be harder for your plug-in to push recent older (different) versions down the list unnecessarily, but it could still be done.

 

Cheers in return.    Merry Christmas (if you celebrate it)  and an early Happy-New-Year   I won't be writing the package-manager-form-editor plug-in until I finish my new project... I'll be distracted by "hardware" for the next week or so, as I assemble a second unRAID server.  The initial two 1.5TB SATA disk drives for the new server should arrive today, and I need to "mod" the old tower case I have to mount everything.   Oh yes, I need to clean out my garage and install some shelves too... but don't worry, I'll respond to questions here.

 

Joe L.

 

Merry Christmas (I do celebrate it)  and a Happy New Year to you too.  And no rush on the package-manager-form-editor plug-in.  I've got some ideas I want to kick around that will keep me busy for a little while.

 

Matt

Joe L. -

 

Finally got a chance to try this out.  Works great as both an editor and viewer.  Great job!

 

Thanks!

Joe L. -

 

Finally got a chance to try this out.  Works great as both an editor and viewer.  Great job!

 

Thanks!

You are welcome...  It is all because you did the investigative work needed to make "POST" work from the browser in unmenu.awk.  Thanks in return. 

This all  looks so easy once you see how it is done.

 

Joe L.

I have an idea/feature request.

 

How about including some code such that if the FILE_BACKUP_DIRECTORY is changed from one session to the next, the program will look in the old backup folder for previous backups and moves them to the new location.  Thoughts?

 

Cheers,

 

Matt

I must have some files in the wrong place?

 

Config Editor does appear on my unMenu page.  However, when I select the "go" file to edit (for example), I get a "page cannot be displayed" browser page.

 

My unMenu files are in the root of the flash.  My "go" file is in /boot/config/ where it should be.

 

I'm sure this is something simple, but elusive to the inexperienced.

have you updated to the newest version of unmenu(v1.1)?  I'm pretty sure the plugin needs it to run with the new POST features.

 

Cheers,

Matt

I must have some files in the wrong place?

 

Config Editor does appear on my unMenu page.  However, when I select the "go" file to edit (for example), I get a "page cannot be displayed" browser page.

 

My unMenu files are in the root of the flash.  My "go" file is in /boot/config/ where it should be.

 

I'm sure this is something simple, but elusive to the inexperienced.

You must be using the newest version of unmenu for this plug-in to work.  It sounds as if you are not.

 

What version of unmenu are you using?  (click on the "about" page to see the unmenu.awk version)

It should say:

unmenu.awk: Version 1.1 Joe L.... with modifications as suggested by bjp999

 

You will need to replace the old versions of just about everything with the new 1.1 versions.  (some of the download-manager-package.conf file names changed, the older ones frequently end up with out-of-date download links.  The newer ones reflect an improved naming convention.  (Older download-manager-package ".conf" files have leading numbers, newer ones do not)

 

You start the newer verion with the "uu" command.  (in your case, since the files are on the top folder on the flash drive:

/boot/uu

 

Other than that possibility, you will need to help me to see any error messages.

telnet to your server, then type

awk -W re-interval -f unmenu.awk

It will run and send any error messages to the screen.  Type "Control-C" to stop it.  You will need to kill the first version before you start the new, otherwise it will complain it cannot open the port (since the first opened it already)

 

You can get the 1.1 version of unmenu here: http://lime-technology.com/forum/index.php?topic=2595.msg23943#msg23943

 

Joe L.

 

Joe, you are developing faster than I can implement!  Yep, I'm on version 1.0.

 

I'll make the change later today.

 

BTW, sincere thanks for sharing your remarkable work with everyone.  It adds so much to an already great system.

 

Happy New Year!

Joe, you are developing faster than I can implement!  Yep, I'm on version 1.0.

 

I'll make the change later today.

 

BTW, sincere thanks for sharing your remarkable work with everyone.  It adds so much to an already great system.

 

Happy New Year!

No problem... The older versions of the unmenu web-server could only handle "GET" requests from the browser.  A data entry form from a browser using "GET" is limited to a total url length of just over 2000 characters. (for Microsoft's IE)  This fine for simple forms with a few entry fields, but nowhere near enough to be able to edit some of the config files.  For this we needed to be able to "POST" a form to the web-server.  That method of sending data to the server does not use the "url" but sends it separately. 

 

Now, with the ability to "POST" a form to the server, we can handle much larger and more complicated data entry forms on web-pages we create.  It was bjp999 who figured out how to add POST capaibility to unmenu.awk.  It turned out to be fairly easy, but nobody had done it before... so in retrospect, it only looks easy now... but for bjp999, it took a lot of work and initiative.

 

Happy-New-Year (slightly early)

 

Joe L.

Joe L.

 

I have a request.

 

I have been having visual problems with utilizing this plugin within my own (using <iframe> tags).  The problems have been associated with the array status and menu bars being invoked automatically by your plugin... The solution I have devised to rename your current pluging to 601-unmenu-file_edit.awk and change:

#define ADD_ON_URL    config_view_edit
#define ADD_ON_MENU   Config View/Edit
#define ADD_ON_STATUS YES

to:

#define ADD_ON_URL    file_edit
#define ADD_ON_MENU
#define ADD_ON_STATUS NO
#define ADD_ON_PAGE_HEADING NO

then created a new 600-unmenu-file_edit.awk file with the following:

BEGIN {
#define ADD_ON_URL    config_view_edit
#define ADD_ON_MENU   Config View/Edit
#define ADD_ON_STATUS YES
#define ADD_ON_TYPE   awk
#define ADD_ON_VERSION   .1 Original version.  Joe L.
#define ADD_ON_VERSION   .2 Updated with ideas borrowed from go-script-manager plug-in to keep backup versions of files.
  
  
  if ( ScriptDirectory == "" ) { 
      ScriptDirectory = "."; 
  }
  if ( ConfigFile == "" ) {
      ConfigFile = "unmenu.conf";
  }

  # Local config file variables will never be overwritten by a distributd file.
  # It is here where local changes should be made without worry about them being
  # lost when a new unmenu.conf file is distributed.
  if ( LocalConfigFile == "" ) {
      LocalConfigFile = "unmenu_local.conf";
  }

  GetConfigValues(ScriptDirectory "/" ConfigFile, "");
  GetConfigValues(ScriptDirectory "/" LocalConfigFile, "");
  
  MY_HOST = CONFIG["MyHost"] ? CONFIG["MyHost"] : "Tower"
  MY_PORT = CONFIG["MyPort"] ? CONFIG["MyPort"] : "8080"
  
  CGI_setup();
  
  theHTML = "<br><iframe width=\"100%\" height=\"100%\" frameborder=0 marginwidth=0 src=\"http://"MY_HOST":"MY_PORT"/file_edit\"></iframe>"
  print theHTML

}

function GetConfigValues(cfile, preface) {
    RS="\n"
    while (( getline line < cfile ) > 0 ) {
          delete c;
          match( line , /^([^# \t=]+)([\t ]*)(=)([\t ]*)(.+)/, c)
          #print c[1,"length"] " " c[2,"length"] " " c[3,"length"] " "  c[4, "length"] " " c[5, "length"] " " line
          if ( c[1,"length"] > 0 && c[2,"length"] > 0 && 
               c[3,"length"] > 0 && c[4, "length"] > 0 && c[5, "length"] > 0 ) {
               CONFIG[ preface substr(line,c[1,"start"],c[1,"length"])] = substr(line,c[5,"start"],c[5,"length"])
               if ( DebugMode == "yes" ) { 
                   print "importing from " cfile ": " \
                     "CONFIG[" preface substr(line,c[1,"start"],c[1,"length"]) "] = " substr(line,c[5,"start"],c[5,"length"])
               }
          }
    }
    close(cfile);
}

function CGI_setup(   uri,  i) {
  delete GETARG;         delete MENU;        delete PARAM
  GETARG["Status"] = ARGV[1]; GETARG["Method"] = ARGV[2]; GETARG["URI"] = ARGV[3]; 
  i = index(ARGV[3], "?")
  if (i > 0) {             # is there a "?" indicating a CGI request?
    split(substr(ARGV[3], 1, i-1), MENU, "[/:]")
    split(substr(ARGV[3], i+1), PARAM, "&")
    for (i in PARAM) {
      j = index(PARAM[i], "=")
      GETARG[substr(PARAM[i], 1, j-1)] = substr(PARAM[i], j+1)
    }
  } else {             # there is no "?", no need for splitting PARAMs
    split(ARGV[3], MENU, "[/:]")
  }
}

 

 

Your plugin will now run as expected and we can call on it in another plugin(using the link http://*:*/file_edit) without the array status and menu headers appearing.

 

Can we make this a new "feature"?

 

Cheers,

Matt

Joe L.

 

I have a request.

 

I have been having visual problems with utilizing this plugin within my own (using <iframe> tags).  The problems have been associated with the array status and menu bars being invoked automatically by your plugin... The solution I have devised to rename your current pluging to 601-unmenu-file_edit.awk and change:

#define ADD_ON_URL    config_view_edit
#define ADD_ON_MENU   Config View/Edit
#define ADD_ON_STATUS YES

to:

#define ADD_ON_URL    file_edit
#define ADD_ON_MENU
#define ADD_ON_STATUS NO
#define ADD_ON_PAGE_HEADING NO

then created a new 600-unmenu-file_edit.awk file with the following:

BEGIN {
#define ADD_ON_URL    config_view_edit
#define ADD_ON_MENU   Config View/Edit
#define ADD_ON_STATUS YES
#define ADD_ON_TYPE   awk
#define ADD_ON_VERSION   .1 Original version.  Joe L.
#define ADD_ON_VERSION   .2 Updated with ideas borrowed from go-script-manager plug-in to keep backup versions of files.
  
  
  if ( ScriptDirectory == "" ) { 
      ScriptDirectory = "."; 
  }
  if ( ConfigFile == "" ) {
      ConfigFile = "unmenu.conf";
  }

  # Local config file variables will never be overwritten by a distributd file.
  # It is here where local changes should be made without worry about them being
  # lost when a new unmenu.conf file is distributed.
  if ( LocalConfigFile == "" ) {
      LocalConfigFile = "unmenu_local.conf";
  }

  GetConfigValues(ScriptDirectory "/" ConfigFile, "");
  GetConfigValues(ScriptDirectory "/" LocalConfigFile, "");
  
  MY_HOST = CONFIG["MyHost"] ? CONFIG["MyHost"] : "Tower"
  MY_PORT = CONFIG["MyPort"] ? CONFIG["MyPort"] : "8080"
  
  CGI_setup();
  
  theHTML = "<br><iframe width=\"100%\" height=\"100%\" frameborder=0 marginwidth=0 src=\"http://"MY_HOST":"MY_PORT"/file_edit\"></iframe>"
  print theHTML

}

function GetConfigValues(cfile, preface) {
    RS="\n"
    while (( getline line < cfile ) > 0 ) {
          delete c;
          match( line , /^([^# \t=]+)([\t ]*)(=)([\t ]*)(.+)/, c)
          #print c[1,"length"] " " c[2,"length"] " " c[3,"length"] " "  c[4, "length"] " " c[5, "length"] " " line
          if ( c[1,"length"] > 0 && c[2,"length"] > 0 && 
               c[3,"length"] > 0 && c[4, "length"] > 0 && c[5, "length"] > 0 ) {
               CONFIG[ preface substr(line,c[1,"start"],c[1,"length"])] = substr(line,c[5,"start"],c[5,"length"])
               if ( DebugMode == "yes" ) { 
                   print "importing from " cfile ": " \
                     "CONFIG[" preface substr(line,c[1,"start"],c[1,"length"]) "] = " substr(line,c[5,"start"],c[5,"length"])
               }
          }
    }
    close(cfile);
}

function CGI_setup(   uri,  i) {
  delete GETARG;         delete MENU;        delete PARAM
  GETARG["Status"] = ARGV[1]; GETARG["Method"] = ARGV[2]; GETARG["URI"] = ARGV[3]; 
  i = index(ARGV[3], "?")
  if (i > 0) {             # is there a "?" indicating a CGI request?
    split(substr(ARGV[3], 1, i-1), MENU, "[/:]")
    split(substr(ARGV[3], i+1), PARAM, "&")
    for (i in PARAM) {
      j = index(PARAM[i], "=")
      GETARG[substr(PARAM[i], 1, j-1)] = substr(PARAM[i], j+1)
    }
  } else {             # there is no "?", no need for splitting PARAMs
    split(ARGV[3], MENU, "[/:]")
  }
}

 

 

Your plugin will now run as expected and we can call on it in another plugin(using the link http://*:*/file_edit) without the array status and menu headers appearing.

 

Can we make this a new "feature"?

 

Cheers,

Matt

Matt,

 

I have no problem with you creating a slightly modified version of the plug-in with the top of screen status turned off and naming it 601-unmenu-file_edit.awk .  You beat me to it, as I was planning on doing something  similar, but I was thinking of a "library" function you could then use in your own plug-in.

 

I was going to modify the library routine to allow you to specify any desired file, not just those in my initial drop-down list.  I've not even started on it though, as I've been doing other things around here.

 

This is the beauty of the plug-in system though... you can see the "awk" code, and it is fairly easy to modify locally for a special need.

 

Your method of modifying my original plug-in to work with an embedded <iframe> holding the actual editor URL is interesting.  Let me check it out.  I'm not opposed to making the file-editor plug-in more general purpose, you just took a different approach than I was thinking about...  We'll see if it makes it into the "Official-Un-Official" distribution, but something like it will, that's for sure... It will probably be a combination of our ideas.

This is pretty neat, considering it is "just" awk.  Isn't it. 

 

Thanks for contributing.   

 

Joe L.

Matt,

 

I have no problem with you creating a slightly modified version of the plug-in with the top of screen status turned off and naming it 601-unmenu-file_edit.awk .   You beat me to it, as I was planning on doing something  similar, but I was thinking of a "library" function you could then use in your own plug-in.

 

I was going to modify the library routine to allow you to specify any desired file, not just those in my initial drop-down list.  I've not even started on it though, as I've been doing other things around here.

 

This is the beauty of the plug-in system though... you can see the "awk" code, and it is fairly easy to modify locally for a special need.

 

Your method of modifying my original plug-in to work with an embedded <iframe> holding the actual editor URL is interesting.   Let me check it out.   I'm not opposed to making the file-editor plug-in more general purpose, you just took a different approach than I was thinking about...   We'll see if it makes it into the "Official-Un-Official" distribution, but something like it will, that's for sure... It will probably be a combination of our ideas.

This is pretty neat, considering it is "just" awk.  Isn't it. 

 

Thanks for contributing.   

 

Joe L.

I have just been experimenting and seeing if I could find a way to invoke the plug-in you supplied easily with little modification to either of our plugins... I found that if I passed the arguments in the iframe line itself, then the plugin is automatically restricted.  for instance, if I call on the url file_edit with file_edit?editable_files=/boot/config/go, then your plugin would be opened in the iframe and theFile would be forced set to /boot/config/go.  I was able to also invoke(and lock) the editfile and savefile states with the same process. 

 

There is a big limitation in making the effects of using the iframe approach "seamless", in that once a particular task is complete the user may be presented undesirable(and often unuasable) options in the iframe by the file_edit plugin.  I think your library idea is probably the way to go long-term and for use in other plug-ins.  Although the iframe is quite useful, as I have discovered in my experimentation.

 

I've been having fun learning "awk" and writing my own plug-in for unMENU.  I look forward to seeing your "library" idea when you get the time to piece it together.

 

Cheers,

Matt

It looks like I can't do something like this in unmenu_local.conf.conf and edit all my scripts through unMenu. Correct?

 

EDITABLE_FILE=/boot/scripts/*.sh

 

I guess I could fumble a script together to output the files from there to the .conf file.

It looks like I can't do something like this in unmenu_local.conf.conf and edit all my scripts through unMenu. Correct?

 

EDITABLE_FILE=/boot/scripts/*.sh

 

I guess I could fumble a script together to output the files from there to the .conf file.

The unmenu editor EDITABLE_FILE lines must point to specific files.

If you want to edit all the .sh files in a folder, you must add one EDIITABLE_FILE line per file. It does not take wild-cards.

 

It does already let you edit any .sh files in /boot and in /boot/custom/bin

so another method to edit the files would be to

mkdir -p /boot/custom/bin

cp /boot/scripts/*.sh /boot/custom/bin/

 

Edit them there in /boot/custom/bin, and then copy them back to their original location.

 

Or, you can edit the plug-in file in unMENU itself to add the /boot/scripts folder

Around line 40 of  600-unmenu-file_edit.awk  you will find these lines:

# now, scan some directories for "possible" editable files.

 editable_files = GetEditableFiles(editable_files, "/boot/config", "*.cfg" )

 editable_files = GetEditableFiles(editable_files, "/boot", "*.cfg" )

 editable_files = GetEditableFiles(editable_files, ScriptDirectory, "*.conf" )

 editable_files = GetEditableFiles(editable_files, CONFIG["PACKAGE_DIRECTORY"], "*.conf" )

 editable_files = GetEditableFiles(editable_files, CONFIG["PACKAGE_DIRECTORY"], "*.manual_install" )

 editable_files = GetEditableFiles(editable_files, CONFIG["PACKAGE_DIRECTORY"], "*.auto_install" )

 editable_files = GetEditableFiles(editable_files, CONFIG["AUTO_INSTALL_DIRECTORY"], "* | grep -v '*.zip'" )

 editable_files = GetEditableFiles(editable_files, "/boot", "*.sh" )

 editable_files = GetEditableFiles(editable_files, "/boot/custom/bin", "*.sh" )

 

Add one more line like this one  (Wild cards are supported here):

 editable_files = GetEditableFiles(editable_files, "/boot/scripts", "*.sh" )

 

You can also create all the EDITABLE_FILE lines and append them to unmenu_local.conf automatically by typing:

 

for i in /boot/scripts/*.sh; do echo EDITABLE_FILE = $i; done >>/boot/unmenu/unmenu_local.conf

Thanks Joe. Both methods will work, but I will edit the .awk so any new .sh file I create show up with out having to run the loop again.

 

I like the backup feature when editing files though unMenu