Where to start with automatic scripting for AsusWRT-Merlin

[Undareth]

Hi there,

To expand on the subject header; I'm a beginner to home networking and looking to start learning about automated scripting. I've installed amtm through an external USB and I am fairly familiar with navigating around preset scripts and packages (Diversion, Entware).

Was wondering what are some good areas to look into to start learning about automated scripting for my router. To give an example use case, I'd like to create an automated script that alternates the Router's DHCP address so that the network's IP is randomized automatically every month etc.

How does Amtm interpret or read scripts. What packages would i need to invoke if i want to run shell scripts. Anything that can point me to the first steps/

 

[ColinTaylor]

Start here:

User scripts

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

 

[Undareth]

Awesome Thanks ColinTaylor!

 

[sfx2000]

How does Amtm interpret or read scripts. What packages would i need to invoke if i want to run shell scripts. Anything that can point me to the first steps/

First step is post in the correct sub-forum - this one is for general wireless items.

 

[L&LD]

What router do you have?

If the USB stick you're using isn't an SSD used via USB, consider doing so to save yourself the pain of having a 'stick' slowly die and trying to figure out what is going wrong.

Also, study the scripts that are available already. Even if they don't particularly match your needs. The knowledge gleaned will be immeasurable and like nothing else available on the web. (Specifically, the scripts are proven to work with RMerlin-powered Asus routers and current firmware, SDK, kernel, and other specifics).

The link below is also a good starting point to get that basic knowledge of how everything is tied together too, IMO.

Home | Asuswrt-Merlin

asuswrt-merlin.net

 

[glens]

The major hurdle encountered when studying scripts is when they define everything as a function even if the function is called only once. What a freaking nightmare!

 

[thelonelycoder]

The major hurdle encountered when studying scripts is when they define everything as a function even if the function is called only once. What a freaking nightmare!

I may do that too, just to segment code and make it better manageable.
I don’t normally judge how your brain works. Mine works the way it does and I’m happy with it.

 

[Martinski]

The major hurdle encountered when studying scripts is when they define everything as a function even if the function is called only once. What a freaking nightmare!

In S/W engineering, modularity is a basic design principle & a coding technique whose primary goal is to avoid writing large monolithic applications. This is accomplished by splitting the source code into smaller, loosely coupled but cohesive & more manageable functional units that allow you to organize the code into logical modules, each of which can perform a specific task with relative independence from any other module.

While code reusability is one of the main benefits & advantages of modular programming, it's not a requirement that every function or module be called more than once because there are other well-established benefits that outweigh any possible disadvantages:

- Code is easier to read (assuming a reasonably logical & consistent naming convention and coding standards have been followed).

- Code is easier to test & debug because you can perform unit testing on each smaller function that performs one specific task. This also translates into greater coverage during the testing cycles.

- Code is easier to refactor & maintain, leveraging on the fact that it's easier to read, test & debug.

Many white papers & books have been written about this topic in the last 4 decades (at least), so I won't go into further details.

Can modular programming techniques be overused & "abused"?

I suppose they can be if an overzealous, rookie programmer, who doesn't yet understand the boundaries, is not properly trained or not given advice during formal code reviews, but that's an extremely rare occurrence, in my personal experience. In fact, the opposite happens more often where a rookie developer will write a new function that is 3 to 4 pages long without concerns for readability or reusability.

In any case, the point is that thinking that each function should be called more than once is simply a misguided concept given the currently established S/W engineering & programming paradigms.

 

[glens]

Yeah, well, as agreeable as that argument is for larger projects, we're talking mere shell scripts here. A horse of a different color, hell, breed, in my book.

All-in, this topic (an expressed desire to learn scripting by inspecting scripts, as I recall) reminds me of the time I happened upon a multi-CD set which included early Redhat, Deb-Ian, and Slackware releases (newly 2.0 kernel era). Wanting to get my feet wet, I tried them all. Slackware was the only one which didn't wrap things inside unnecessary enigmas (not to mention it booted /way/ faster to an equivalent setup, no doubt due to the simplicity). It was extremely easier to "learn Linux" when not having to also (first) learn the convoluted crap Redhat and Debian imposed (still do) upon it. (not a Slackware fan-boy - haven't used it in years; just sayin')

Easier to maintain a shell script with single-call functions? Perhaps for some, but not for most, I'm sure. Easier for someone wanting to discover the basics? Absolutely not since they'd have to be familiar with programing paradigms unnecessarily imposed from elsewhere, or its even /more/ mumbo-jumbo to wade through. And such scripts certainly don't run any better for the effort.

In all my very many shell scripts, I find it much more straightforward and easier to maintain them when only creating functions for multiple possible calls within, and in such cases the function name is /obviously/ that of an internal function. I don't expect many or even any other folks will ever peruse my scripts, but in such an event they will never have difficulty following what's going on. Very logical and straightforward flow. They won't have to scroll up, then, down, then up again (seemingly endlessly at times) just to follow what's going on - as one must do, for example, to get up to speed in any reply-before-quote message exchange. It's just backwards for no good reason. That's all I'm saying. More-advanced concepts can make sense when appropriate, but not merely as a means to increase the line-count in a shell script in an effort to make it look "advanced". Now I'm rambling and that was not my intent. Apologies for that.

 

[Martinski]

Yeah, well, as agreeable as that argument is for larger projects, we're talking mere shell scripts here. A horse of a different color, hell, breed, in my book.
...

Despite your personal experience and anecdotal evidence, there's a very large body of work & analysis that can be found in peer-reviewed case studies & literature regarding S/W development & coding best practices that completely refute your general statement that functions should be called more than once. I have never seen such a policy, requirement, or coding standard even be proposed in my 30+ years of doing S/W dev.

Now, I could agree that for very small shell scripts (1 or 2 pages worth - less than 100 lines of code), there may not be even a need to have functions in the first place, especially if the script is performing only one specific task, but such determination must be done on a case-by-case basis, and generalizations cannot be made for all situations.

Also, you seem to be greatly underestimating the power & versatility of shell scripting. In the past, I have seen significantly large projects with both Bash & C shell scripts (several thousands of lines, including a few shared libraries) that defy your comment about being "mere shell scripts."

If you can point to specific examples that you believe are an "abuse" of modular programming, then by all means show them & then we can discuss these "bad" examples (although, this would probably not be the proper forum for that kind of topic, IMO).

Anyway, your general statement & arguments do not hold water if based only on a few "bad" examples & anecdotes when compared against the numerous case studies & actual projects that clearly show the benefits & advantages of modular programming when the methodologies & techniques are correctly applied at different levels of complexity. No matter how much someone disagrees, it doesn't change the fact that these concepts have been effectively proven & well-established for decades.

 

[Maverickcdn]

To answer @Undareth the OPs original question... I myself perused other script writers projects on github for ideas and implemented many of their lines of code in my own work. I've been on/off fooling around for over 5 years now and its mind blowing going back to my original work and comparing it to what I write today. Makes me want to re-write everything I ever created back then... with more functions haha

On the debate about script formatting/functions. I for one am all for functions, to say single_use=bad is silly.

Im currently re-writing wicens (a mere shell script) and after reading this thread Ill admit I have moved some functions into where they were only called once... but some stats for @glens to cringe at... as of today the script is 3880 lines of which 50 lines are defined vars, 237 lines of inline code, 66 lines of comments and the rest is code within 100 functions and still more to go...

I suppose if you maintain/write all your code within the linux terminal and editors, yes functions can be a pain... mainting my code with Notepad++ on windows makes working wih functions a breeze

Chatgpt would tend to agree with both arguments...

Spoiler: 1000 line shell scripts

You
when writing a shell script that is roughly 1000 lines of code should the creator emphasize the use of functions or write as all inline code

ChatGPT
When writing a shell script, especially one that's around 1000 lines of code, it's generally advisable to use functions. Here's why:

1. **Modularity**: Functions help in breaking down your code into smaller, manageable chunks. Each function can represent a specific task or a logical unit, making your script more organized and easier to understand.

2. **Reusability**: By encapsulating specific functionalities within functions, you can reuse them multiple times within your script or even in other scripts if needed. This promotes code reusability and reduces redundancy.

3. **Readability**: Functions enhance the readability of your script by providing clear, descriptive names for different parts of your code. This makes it easier for you and other developers to understand the purpose of each section of your script.

4. **Debugging and Testing**: With functions, you can isolate and test individual parts of your script more easily. This can be particularly helpful when debugging or troubleshooting issues.

5. **Scalability**: As your script grows in size and complexity, using functions makes it more scalable and maintainable. It allows you to make changes or additions to specific functionalities without affecting the entire script.

However, it's essential to strike a balance. While functions offer several advantages, overusing them can also make your script overly complex. For smaller scripts or simple tasks, inline code may be more appropriate. As a rule of thumb, if you find yourself repeating the same code or if a particular section of your script performs a distinct task, consider refactoring it into a function.

 

[thelonelycoder]

amtm and Diversion are multi file scripts. I cannot imagine managing these as a single file and without functions. It would not work, even if I wanted to.
The total line count for amtm 4.3 is about 6700 while Diversion 5.1.1 is now down to 12500. Diversion 4.3 had 22325 lines of shell script code.
We are not kids playing in the sand. And we are not paid for what we do.

And, Diversion has a file that only contains functions. Aptly named functions.div, it's 4000 lines of functions alone.