0

I wanted to run bish-bosh as a simple shell-based MQTT Client, so I downloaded the content of release_2015.0119.1445-1 and inited the submodules (11.3 MB of files).

After chmod a+x bish-bosh I wanted to run it but...

# ./bish-bosh
': No such file or directory

That's full output :( What am I doing wrong?

I'm using BusyBox v1.25.0.git (Linux version 2.4.25) with ash, which is listed as compatible.

Trying to run the bish-bosh executable version I get this output:

# ./bish-bosh_2015.0629.0920-2_all
./bish-bosh_2015.0629.0920-2_all: line 2890: syntax error: bad substitution
hardillb
  • 54,545
  • 11
  • 67
  • 105
Stefan
  • 197
  • 1
  • 11
  • 1
    Make sure your "executable" isn't a script that was saved with DOS newlines. If you downloaded it with, say, a revision control client configured to translate to your local system's newline format and you did the download on Windows, that can happen. – Charles Duffy Aug 17 '18 at 15:05
  • 1
    To be clear, `': No such file or directory` is a very clear marker for DOS newlines, because such newlines consist of a CRLF pair. When parsed by UNIX, which expects newlines to be LF-only, the CR becomes part of the command -- and when printed to the console, it sends the cursor to the front of the line, causing prior parts of the error message to be overwritten. – Charles Duffy Aug 17 '18 at 15:06
  • 1
    ...so, let's say your script runs `ls`. Because of the newlines it becomes `ls$'\r'`, and when the `$'\r'` is printed it sends the cursor back to the front of the line. Thus, the shell *tries* to write ```'ls$'\r'': No such file or directory```, but it comes out as just `': No such file or directory` because everything before the `$'\r'` is overwritten after the cursor moves backwards. – Charles Duffy Aug 17 '18 at 15:09
  • Oh yeah, thanks! Didn't think it was so easy! Converted the line endings, and now I get this one: `./bish-bosh: line 14: syntax error: bad substitution` Line 14 is this one: `if [ ${BASH_VERSINFO[0]} -eq 3 ]; then` but there's a `if core_variable_isSet BASH_VERSINFO; then` infront, so it shouldn't get there if variable isn't set. – Stefan Aug 17 '18 at 15:27
  • Hmm. The lack of quoting is bad practice there, but it shouldn't cause an actual error unless `BASH_VERSIONFO` is unset (as could happen if, say, the shell used to execute the script weren't actually bash). – Charles Duffy Aug 17 '18 at 15:33
  • Personally, I would write a version check more like the following: `case $BASH_VERSION in '') echo "ERROR: Not running bash" >&2; exit 1;; [123].*) echo "ERROR: Running bash ${BASH_VERSION}, need 4.0 or newer" >&2; exit 1;; esac` -- that way it'll exit with the actually *intended* error even when run on a non-bash shell, and won't be a syntax error on any shell that's POSIX-compliant. – Charles Duffy Aug 17 '18 at 15:34
  • BTW, running `bash -x yourscript` is a good place to start in terms of tracking what's going on at runtime. – Charles Duffy Aug 17 '18 at 15:35
  • I commented out that wrong check (I'm using ash, so script shouldn't be there) and checked out all files using cygwin git (because I couldn't tell git to use LF ending in submodules) and now it looks better, thanks! – Stefan Aug 17 '18 at 16:02
  • 5
    Possible duplicate of [Are shell scripts sensitive to encoding and line endings?](https://stackoverflow.com/questions/39527571/are-shell-scripts-sensitive-to-encoding-and-line-endings), or [bash script always prints `command not found`](https://stackoverflow.com/questions/7362504/bash-script-always-prints-command-not-found) – Charles Duffy Aug 17 '18 at 16:04

1 Answers1

0

As Charles Duffy pointed out: Lineendings were CRLF style, as I checked it out on Windows. Use LF lineendings, and script mostly runs.

Stefan
  • 197
  • 1
  • 11