Quote:
Originally Posted by kaminkatze
Yes, but I think the idea was to match only the newline character "\n" and not the normal "n".
Oooh, I see. I changed the IFS=$'\n' to $"\n", which isn't the same.
Edit: IFS=$'\n' isn't working on the K3.
|
It might also depend on the application that is being used as "/bin/sh" -
Not all implementations behave the same for various reasons and then even some implementations vary from one release to another.
One thing to try - see if the make/model/version/etc of the "shell" program will let you write the newline character as hex:
IFS=$'\x0A'
If your using the "shell" program provided by Busybox, then there are some more chances for "gotcha's" ....
Over the years (and versions) Busybox has provided more than one "shell" application.
So with some versions, it depends on which one was selected at build time.
More recently, the 'ash' shell application has been the prefered one in Busybox builds. That one is the most complete and correct.
But that doesn't mean it is the one lab126 choose to build.
And of course, as can be seen in the Amazon source catalog, not all builds for all Kindles used the same version of Busybox.
(Also, you can see that Amazon did not ship the .config file "as built" with their source code releases which would let us just look-up which shell application got built.)
But putting in characters by their Hex or Octal code __usually__ works.