[To all script writers] Suggestion for better environment management

[spalife]

Thanks. This appears to require a reference file/code for it to work.
AB is very flexible in what it writes to jffs. For example, the post-mount may already have existing entware code in it that it respects and uses. But the code added can look entirely different when AB installs entware and adds to the file.

This respectful approach is used on every jffs file. I have no way to know how exactly a jffs file looks like on a router, not even when AB installs all of it.

I just tried your code inline with other scripts.
The function does not work for your situation,
will update if i can find a way

 

[spalife]

I feel like entries here should be nothing more then an execution point, and function descriptions and whatnot should be left for the file its pointing to. Try keep things simple as possible.

sh /path/to/file args # Added By BestScriptEver

And lets say ab-solution for example did want to scan for a potential whitelist, I don't think this is the best place to grab them from or define it. It also gives us less points of failure when removing (and gives users less incentive to make manual edits here)

The point was about adding a meaningful comment
to whatever is posted.
Atleast finally now we all agree that
a comment follows above, below, next or
somewhere to the scriptcall

 

[thelonelycoder]

The point was about adding a meaningful comment
to whatever is posted.
Atleast finally now we all agree that
a comment follows above, below, next or
somewhere to the scriptcall

As I use sed excessively, a one liner would be the best and simplest to find and remove.

 

[spalife]

As I use sed excessively, a one liner would be the best and simplest to find and remove.

Typically i stay away from sed when it comes to multiple changes
more so in situations when another process can
access the same file and safer to create a temp file.
The mutex can be unpredictable when it comes to sed.
Each their own style of coding

 

[spalife]

I just tried your code inline with other scripts.
The function does not work for your situation,
will update if i can find a way

I tried initially on my mac with grep version 2.5
it failed to extract the difference.

I tried again with entware grep 2.26 version.
BINGO works like a charm.

I posted the code you mentioned here,
into multiple location in a sample script
i.e., into 3 different locations in some another script.

It removed from all of them.
You can try too with just

# file1 is the code you posted here which says
# DO NOT EDIT that entire block
# file2 is some random file which has code in it
# i posted your file1 contents into 3 different locations
# at the top, in the middle, at the end

grep -Fvxf file1 wan-start

# the above removed from all locations

 

[thelonelycoder]

I tried initially on my mac with grep version 2.5
it failed to extract the difference.

I tried again with entware grep 2.26 version.
BINGO works like a charm.

I posted the code you mentioned here,
into multiple location in a sample script
i.e., into 3 different locations in some another script.

It removed from all of them.
You can try too with just

# file1 is the code you posted here which says
# DO NOT EDIT that entire block
# file2 is some random file which has code in it
# i posted your file1 contents into 3 different locations
# at the top, in the middle, at the end

grep -Fvxf file1 wan-start

# the above removed from all locations

I did not try the code but was suspicious if it runs on system binaries.
None of the code I write requires more than BusyBox and the system binaries.

 

[RMerlin]

I have entries such as these:

That's the kind of thing I would recommend moving out to an external file instead, keeping the start script itself as simple as possible. (I know, this shows that Entware doesn't follow that - something I might look at at some point in the future).

If there weren't so many different start script, I might have gone with a SysV-like setup, running everything within, say, init.d/ services.d/ firewall.d/, etc... But with 20+ of them, I don't want to create a mess of *.d folders to host startup scripts (and have to guide people toward using numbers in the filenames to create start priority). So, I started this thread to get developers to discuss among themselves about it.

 

[thelonelycoder]

That's the kind of thing I would recommend moving out to an external file instead, keeping the start script itself as simple as possible. (I know, this shows that Entware doesn't follow that - something I might look at at some point in the future).

Who did that original entware-setup.sh install script?
I would happily volunteer to make it compatible with our conclusions.

That's the kind of thing I would recommend moving out to an external file instead, keeping the start script itself as simple as possible.

I plan to do this with the next update.
The change for existing installations will not be simple to automate, but I'll try my best.

 

[thelonelycoder]

One other discussion point: Where to place the sourced file in jffs?
In AB, if you have Entware installed, it requires Entware to be mounted in /opt/ to work.
If I now outsource the entries in post-mount to a separate file, where best to place it?

If Entware does not load for some reason (USB device faulty, file corruption) and if I were to place the outsourced files within the /opt/ structure noting will work.
If I place it in jffs, then we need a standardized way where to place our outsourced scripts.
Would /jffs/appname/your-scripts-here be OK?
I'd rather not place them in /jffs/scripts/ as it could get messy with everyone placing it in there.
With /jffs/appname/ you could have subfolders in it, say for backup and keep all your jffs files in there.

 

[RMerlin]

Who did that original entware-setup.sh install script?

@ryzhov_al, based on general ideas I tossed at him at the time. I think I did only very few minor tweaks to it after that.

he change for existing installations will not be simple to automate, but I'll try my best.

No worries. My intention wasn't to force everyone to do something this way, just to provide some recommendations to the community. In the end, the more that follows it, the better it will be for everyone involved (both users and developers), especially as a number of conflict have been appearing lately between the multiple scripts available here.

Eventually, it might be good to have a "final" version of these recommendations posted to the Wiki as well.

 

[RMerlin]

If I place it in jffs, then we need a standardized way where to place our outsourced scripts.
Would /jffs/appname/your-scripts-here be OK?
I'd rather not place them in /jffs/scripts/ as it could get messy with everyone placing it in there.
With /jffs/appname/ you could have subfolders in it, say for backup and keep all your jffs files in there.

Having a projectname folder might be best, however for simple scripts it might make things cluttered a bit. But definitely not within the existing scripts/ folder - limit that one to system scripts. That way I won't have to deal with possible filename clashes if I add new scripts in the future.

 

[FreshJR]

I'll update mine to comply with these new guildlines in the coming days.

 

[thelonelycoder]

For AB-Solution 4.0 I'm moving the Entware post-mount script to /jffs/ab-solution/ab-post-mount.
Then call it with this in /jffs/scripts/post-mount:

/jffs/ab-solution/ab-post-mount # post-mount script by AB-Solution

I'd like to combine post-mount, services-start and wan-start in one, for the convenience and it makes sense to me.

I have this now working flawless so far and since everything in that file depends on /tmp/opt being present, I try something new:

#!/bin/sh

# starting entware services
entdev="find /mnt/*/entware/bin/opkg"

if [ $($entdev 2> /dev/null) ];then
    # make symlink
    ln -nsf $($entdev | sed 's/\/bin\/opkg//g') /tmp/opt
    
    # bring up virtual interfaces
    ifconfig br0:pixelserv 172.20.0.2 up
    ifconfig br0:nginx 172.20.0.3 up
    
    # run rc.unslung
    /opt/etc/init.d/rc.unslung start $0
fi

First, I try to find the opkg binary with '/mnt/*/entware/bin/opkg', it's the first and most reliable file to determine that this is a working Entware directory.
'entware' being the folder Entware was installed on. This can be 'entware-ng' or 'entware-ng.arm' and is changed accordingly.
AB-Solution and /usr/sbin/entware-setup.sh install it in the 'entware' folder.

The reason I use "find /mnt/*/entware/bin/opkg" is to not rely on the device label or name to make the symlink.
If the device name changes or has no label, it can be sda1 or sdb1. With my 'find' I eliminate the possibility that Entware is not started in such cases.

Then I bring up the needed virtual interfaces before the start scripts are run for pixelserv and nginx (for my purposes), formerly in wan-start.

Then rc.unslung is run, formerly in services-start.

Does anyone see a problem with that?
I know that @joegreat has a similar post-mount script.
Opinions are welcome.

 

[Adamm]

entdev="find /mnt/*/entware/bin/opkg"

Wouldn't it be more efficient to have the command executed once here, rather then multiple times later on?

#!/bin/sh
# starting entware services
entdev="$(find /mnt/*/entware/bin/opkg)"
if [ "$entdev" ] 2> /dev/null; then
    # make symlink
    ln -nsf "$($entdev | sed 's/\/bin\/opkg//g')" /tmp/opt
  
    # bring up virtual interfaces
    ifconfig br0:pixelserv 172.20.0.2 up
    ifconfig br0:nginx 172.20.0.3 up
  
    # run rc.unslung
    /opt/etc/init.d/rc.unslung start "$0"
fi

You would also want to quote usage of $() and $0 to prevent word splitting (not exactly necessary here but good practice)

 

[thelonelycoder]

Wouldn't it be more efficient to have the command executed once here, rather then multiple times later on?

#!/bin/sh
# starting entware services
entdev="$(find /mnt/*/entware/bin/opkg)"
if [ "$entdev" ] 2> /dev/null; then
    # make symlink
    ln -nsf "$($entdev | sed 's/\/bin\/opkg//g')" /tmp/opt
 
    # bring up virtual interfaces
    ifconfig br0:pixelserv 172.20.0.2 up
    ifconfig br0:nginx 172.20.0.3 up
 
    # run rc.unslung
    /opt/etc/init.d/rc.unslung start "$0"
fi

You would also want to quote usage of $() and $0 to prevent word splitting (not exactly necessary here but good practice)

I'm not sure but your code does not work.
I'm declaring a variable and test for it, and if so use it with entdev=, that happens once if not found and twice if found, same as your code would.
This is better, without the fear of expanding $():

#!/bin/sh
# starting entware services
entdev="find /mnt/*/entware/bin/opkg"
if [ "$($entdev 2> /dev/null)" ]; then
    # make symlink
    ln -nsf "$($entdev | sed 's/\/bin\/opkg//g')" /tmp/opt   
    # bring up virtual interfaces
     ifconfig br0:pixelserv 172.20.0.2 up
     ifconfig br0:nginx 172.20.0.3 up
    # run rc.unslung
    /opt/etc/init.d/rc.unslung start $0
fi

 

[thelonelycoder]

That would run the binary @Adamm , not find it:

entdev="$(find /mnt/*/entware/bin/opkg)"

 

[Adamm]

That would run the binary @Adamm , not find it:

Yes that is intended, the result will then be stored as a var which is faster to reference then running the code again (and would eliminate the very unlikely possibility the result changes in the split second between executions).

Assuming the code fails because the file doesn't exist, the if statement would also fail so the same functionality would be present with a few less CPU cycles overall. Minor changes but "why not"

admin@RT-AC68U-EE20:/tmp/home/root# entdev="$(find /mnt/*/entware/bin/opkg)" 2>/dev/null
admin@RT-AC68U-EE20:/tmp/home/root# if [ "$entdev" ]; then echo "result is true"; fi
result is true
admin@RT-AC68U-EE20:/tmp/home/root# entdev="$(find /mnt/*/entware/bin/missingBinary)" 2>/dev/null
admin@RT-AC68U-EE20:/tmp/home/root# if [ "$entdev" ]; then echo "result is true"; fi
admin@RT-AC68U-EE20:/tmp/home/root#

(I actually made a mistake in my version, line 3 would need to have stderr silenced, not the if statement)

 

[thelonelycoder]

Yes that is intended, the result will then be stored as a var which is faster to reference then running the code again (and would eliminate the very unlikely possibility the result changes in the split second between executions).

Assuming the code fails because the file doesn't exist, the if statement would also fail so the same functionality would be present with a few less CPU cycles overall. Minor changes but "why not"

admin@RT-AC68U-EE20:/tmp/home/root# entdev="$(find /mnt/*/entware/bin/opkg)" 2>/dev/null
admin@RT-AC68U-EE20:/tmp/home/root# if [ "$entdev" ]; then echo "result is true"; fi
result is true
admin@RT-AC68U-EE20:/tmp/home/root# entdev="$(find /mnt/*/entware/bin/missingBinary)" 2>/dev/null
admin@RT-AC68U-EE20:/tmp/home/root# if [ "$entdev" ]; then echo "result is true"; fi
admin@RT-AC68U-EE20:/tmp/home/root#

(I actually made a mistake in my version, line 3 would need to have stderr silenced, not the if statement)

The problem is that it's useless here where I need the path to the 'entware' folder, not a true of false:

ln -nsf "$($entdev | sed 's/\/bin\/opkg//g')" /tmp/opt

 

[Adamm]

he problem is that it's useless here where I need the path to the 'entware' folder, not a true of false:

Sorry I overlooked that, you would just echo the var instead of calling the find binary again. Realistically there's no "noticeable" improvement, all in theory and synthetic benchmarks.

ln -nsf "$(echo "$entdev" | sed 's/\/bin\/opkg//g')" /tmp/opt

 

[thelonelycoder]

Sorry I overlooked that, you would just echo the var instead of calling the find binary again. Realistically there's no "noticeable" improvement, all in theory and synthetic benchmarks.

ln -nsf "$(echo "$entdev" | sed 's/\/bin\/opkg//g')" /tmp/opt

That'll do, thanks.