Posted: Wed Sep 23, 2020 14:52 Post subject: startup script editor adding question mark to filename
I'm experiencing an odd issue with the GUI editor of the startup script. I have a short script that creates some directories, copies files from a USB drive into "/tmp", etc.
I recently upgraded my N66U; after the upgrade, I was modifying the script via the GUI editor to update some filenames. I noticed that things weren't working and boiled it down to an apparent issue with the way the GUI interprets the text pasted in, specifically line endings. I repro the issue by simply having this in the "commands" box then running the command from there with the "run commands" button:
If I SSH into the box and look in "/tmp" I see "testing?", the second command if executed independently and assuming the directory is there will result with a filename of "key.pem?" What I believe is happening is that there are <CR><LF> line endings there and they're screwing things up.
This seems to be the case if I hand type these commands into the box, or paste them from an editor that does <LF> line endings.
Although when I look at the output of "nvram get rc_startup" if the script is saved, I don't see carriage returns:
Code:
nvram get rc_startup | grep -c '\r'
0
Firmware: DD-WRT v3.0-r44251 big (08/28/20)
I'm running the web interface GUI on Firefox on OSX.
I do have a workaround: I add "|ls" to every line. This presumably prevents the line ending <CR> in <CR><LF> from ending up in the filename. If that's the issue.
I haven't really played with setting rc_startup directly in the console, since the GUI is a lot more convenient, but maybe that would bypass the problem.
You cannot run commands directly from the GUI, you have to use the CLI (command Line interface like telnet or putty)
Well you can run simple commands but not more complex ones
Well you can run more complex ones if you escape all special characters and take care of line endings
Bottom line do not use the GUI to directly run commands
So you're saying this has been always this way?
It's been a while since I updated any script but I could have sworn that I would paste the entire thing in there and hit "run commands" to make sure it works properly and only then save it. Admittedly, it's been a while, so I don't recall what my process was.
I haven't yet, but I should be able to save it, reboot and see if it did what I need to. I'm not sure if I did do that, I got myself running in circles last night on this issue.
Joined: 18 Mar 2014 Posts: 7236 Location: Netherlands
Posted: Wed Sep 23, 2020 15:29 Post subject:
troger wrote:
egc wrote:
You cannot run commands directly from the GUI, you have to use the CLI (command Line interface like telnet or putty)
Well you can run simple commands but not more complex ones
Well you can run more complex ones if you escape all special characters and take care of line endings
Bottom line do not use the GUI to directly run commands
So you're saying this has been always this way?
It's been a while since I updated any script but I could have sworn that I would paste the entire thing in there and hit "run commands" to make sure it works properly and only then save it. Admittedly, it's been a while, so I don't recall what my process was.
I haven't yet, but I should be able to save it, reboot and see if it did what I need to. I'm not sure if I did do that, I got myself running in circles last night on this issue.
Yes that has always been the case, really do not use the GUI to directly run commands unless really simple ones (you can save the script and run the script from the GUI that is a simple command).
You cannot run commands directly from the GUI, you have to use the CLI (command Line interface like telnet or putty)
Well you can run simple commands but not more complex ones
Well you can run more complex ones if you escape all special characters and take care of line endings
Bottom line do not use the GUI to directly run commands
So you're saying this has been always this way?
It's been a while since I updated any script but I could have sworn that I would paste the entire thing in there and hit "run commands" to make sure it works properly and only then save it. Admittedly, it's been a while, so I don't recall what my process was.
I haven't yet, but I should be able to save it, reboot and see if it did what I need to. I'm not sure if I did do that, I got myself running in circles last night on this issue.
Yes that has always been the case, really do not use the GUI to directly run commands unless really simple ones (you can save the script and run the script from the GUI that is a simple command).
Just use something like putty like most of us do
Ok, I just re-tested my scripts by pasting them, saving and rebooting....and it works just fine.
I guess I should avoid messing around with this late at night.
Like I said above, I could have sworn that I would use "run commands" to dry run the script before deploying it. I guess I'm misremembering.
What could have happened is that with the upgrade I just ran, it appears that the startup script (rc_startup) now runs much earlier than before. I need a USB drive mounted for this particular one to work. This might have led me down this path where I was "dry running" the script and went down this rabbit hole.
Anyway that's way too much info already.
----
I moved the script to "rc_usb" since it's dependent on the USB. It appears to be a new feature. (It's been a while since I upgraded.) Perhaps I should just use a delay in the startup script....presumably rc_usb is called each time any USB is mounted, which could be an issue. (I restart httpd in this script.)
Also, silver lining: although kludgy af, putting that pipe to ls at the end of each line in the window gets rid of at least this limitation if you're hell bent on working from the GUI.
Joined: 18 Mar 2014 Posts: 7236 Location: Netherlands
Posted: Wed Sep 23, 2020 15:57 Post subject:
The problem is not the startup script running earlier but the USB mounting is slow, I use a script to wait for the usb to come up and then executing the startup script, but now you have the new usb startup, I have not tested that yet.
I begin my startup script with:
Code:
#instead of sleep check if USB is mounted by sleeping until file: usb-is-mounted is found
(i=0
until [[ -f /jffs/usb-is-mounted ]]; do
sleep 1
i=$((i+1))
if [[ $i -gt 35 ]]; then
logger "No USB mounted"
touch "/jffs/usb-is-mounted"
exit
fi
done
logger "USB $i seconds before mounted")
This checks the existence of a file on /jffs (and it will make that file if not present)
The problem is not the startup script running earlier but the USB mounting is slow, I use a script to wait for the usb to come up and then executing the startup script, but now you have the new usb startup, I have not tested that yet.
I begin my startup script with:
Code:
#instead of sleep check if USB is mounted by sleeping until file: usb-is-mounted is found
(i=0
until [[ -f /jffs/usb-is-mounted ]]; do
sleep 1
i=$((i+1))
if [[ $i -gt 35 ]]; then
logger "No USB mounted"
touch "/jffs/usb-is-mounted"
exit
fi
done
logger "USB $i seconds before mounted")
This checks the existence of a file on /jffs (and it will make that file if not present)
but starting with sleep 30 also works.
On my R6400 it takes about 8 seconds before the USB stick is mounted (it writes the mount time to syslog)
Yeah, something has changed since the last version I ran, but the startup script worked 100% reliably without checking for the mount or any delay. It was already mounted by the time it ran.
I'm not sure I'm curious enough to go through 2 years of changelists to find out. haha
There's always something that gets me when I upgrade. It's the nature of this beast.
