[BusyBox] init difficulties

[Rob Landley]

On Thursday 09 October 2003 07:16, Steven P Valliere wrote:
> If anyone cares, it turned out that most of my
> init script problems were due to the fact that
> the shell apparently treats some invisible/
> non-printable control characters as valid file
> (and/or directory) name characters and consequently
> was unable to find some things because some invisible
> junk was glommed onto the end of the lines.
>
> I retyped the entire scripts (using ed directly on
> my target machine) and they work fine now.  Sigh.
>
> I have some comments/thoughts for developers:
>
> 1. I cannot think of any time that one SHOULDN'T
>    remove trailing whitespace from input lines --
>    whether from the command line itself or when
>    reading a script.

I've bumped into this before.  If you run a script that was touched by a 
windows machine, the \r on the end of "#!/bin/bash" line is taken as part of 
the interpreter name.

The FUN bit is that vi will automatically strip the \r off of each line (and 
put it back on again at save) unless you give it the -b option!  So when you 
examine the thing, it looks just fine...

> 2. Why would ANY character < 0x20 (space) be valid
>    in a file or directory name?

Because we can?

The spec says somewhere the only characters you can't use in a name are / and 
newline.  (And I think null.)  \0xFF is another fun character people use...

> 3. Error messages that actually mean something
>    would also be a HUGE help.  For example, when
>    ash tried to execute a script but there was
>    invisible garbage at the end of #!/bin/sh it
>    simply reported 'File not found' (or something
>    to that effect) implying that the SCRIPT was
>    not found.  It REALLY should show the name of
>    the file it was looking for.  And insmod was
>    reporting .o: module cannot be located (or
>    again, something similar).  Needless to say,
>    I didn't have a single entry reading 'insmod .o'
>    to the error was much less than helpful.  In
>    fact, the error stripped the filename itself AND
>    the trailing garbage -- which would've instantly
>    illustrated the problem.

Bash has this same problem.  Try it.  This isn't busybox specific.

> OK, I'll shut up now.
> Not that anyone's listening anyway.

Rob