Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Whilst making a few changes last night to my transmission helper scripts and working on an install.sh for it I found that the script would not execute.
All it would give me is 'bad function name'.
Working through the code and any changes I had made since the last version I can see no differences. I narrowed down the error to a particular function I had not amended at all.
The shell seemed to dislike the use of '-' in the function name. I changed this in the 5 or so functions where it occurs and in the function calls where the functions are invoked from. The script now runs as expected. Now these functions were originals from the script I based mine on. They had not been changed by myself at all as they do exactly as I would expect. This means either something within the DNS-323 environment has changed or I have managed to selectivly change the '_' to '-' in a few functions and their calls within a script using Vi. I do not know how I could have done this although I am open to the fact that I could have as I have been coding upto 1am in the dark and without the ability to fully touch type. This has now been resolved but has raised a concern that the environment may be having some issues.
So, running the script from the command line works as expected. I then try and improve on the startup script in the ffp/start directory only to find the call it makes using nohup seems to now be failing. Again I have not amended this at all.
I track it down to NOHUP returning an error 'applet not found'.
I have not come across this before and I have not installed anything apart from a clean ffp 0.5 environment since last changing the scripts but this was reverted back (original ffp folder was renamed. FFP 0.5 tgz was downloaded again and reboot reinstalled it, tested the ushare_watch scripts, renamed the new ffp/ install, renamed the original ffp/ install back to ffp. rebooted).
The DNS-323 has not been rebooted for a number of days now although I did a soft reboot using /sbin/reboot last night to no effect.
Any ideas ?
RB
Offline
There are significant differences between:
#!/bin/sh #!/ffp/bin/sh #!/ffp/bin/bash
/bin/sh is old busybox, /ffp/bin/sh is new busybox ash-like shell. /ffp/bin/bash is the full-blown bash.
Offline
Yes, I found the same problem when I was making my version of ushare-refresh run from the ramdisk when I added the PATH line to stop the ffp version of busybox running; if you run /bin/busybox at a command prompt you get a list of the supported commands; there's a /lot/ of useful stuff missing from it! Even some of the sed expression commands.
Offline
fonz wrote:
There are significant differences between:
Code:
#!/bin/sh #!/ffp/bin/sh #!/ffp/bin/bash/bin/sh is old busybox, /ffp/bin/sh is new busybox ash-like shell. /ffp/bin/bash is the full-blown bash.
As BASH is not standard to FFP 0.5 but an extra package I wanted to stay away from it.
I will confirm I am using the ffp sh.
Thanks
RB
Offline
For the sake of the cute little squirrel monkeys.
Tracked down to a missing '!' in the #!/ffp/bin/sh line :-(.
Oh well :-).
Working again with nohup.
CHeers
RB
Offline