If I run this

#!/bin/bash

ARCH=$(python fetch_architecture.py)
if [ $ARCH == "aarch64" -o $ARCH == "armv71" ] ; then
    export PATH=/opt/local/llvm/bin:${PATH}
    cd /app
    RUSTFLAGS="-C linker=lld" wasm-pack build --target web --release plume-front
else
    wasm-pack build --target web --release plume-front
fi

via the terminal, it works just fine. But when I run it via the Dockerfile,

COPY . . 
RUN cargo install wasm-pack 
RUN chmod a+x ./script/plume-front.sh 
RUN sleep 1 
RUN ./script/plume-front.sh

It says python: command not found and then [: too many arguments

all 17 comments

sorted by: hot top controversial new old
[–] 14 points 2 years ago* (1 child)

Python is not found, so $ARCH gets assigned to "", and you didn't double quote your variables in the comparison, so the code parses as [ == "aarch64" which is a syntax error.

Also, maybe uname -m could work instead of that Python script.

  • source
  • hideshow 2 child comments
  • [–] 8 points 2 years ago (1 child)

    What is your base image? It has no python installed.

  • source
  • hideshow 2 child comments
  • [–] 7 points 2 years ago (1 child)

    You should use python3 anyway not python. The latter is sometimes Python 3, sometimes Python 2 and sometimes doesn't exist. python3 works reliably, assuming you have it installed.

    (And assuming you aren't using the official Windows Python installer, but that doesn't seem like the case here!)

  • source
  • hideshow 2 child comments
  • [–] 6 points 2 years ago (1 child)

    Python is not on the Path for docker. The error message "python: command not found" is then passed to the [ command (also called test) which says too many arguments.

    Add the path /use/bin/ to your python command. Or figure out why it isn't on the docker path.

  • source
  • hideshow 2 child comments
  • [–] 5 points 2 years ago* (1 child)

    This is a docker/bash question, not a python question. Also reading the error message explains the problem.

  • source
  • hideshow 2 child comments
  • [–] 5 points 2 years ago* (2 children)

    In addition to what everybody said:

    Those will help catch many problems before they happen or exactly when they happen.

    P.S I would recommend against

    set -o pipefail
    

    It can introduce some very weird behaviour when it doesn't work.

    Anti Commercial-AI license

  • source
  • hideshow 4 child comments
  • [–] 1 point 2 years ago (1 child)

    Could you elaborate on the weird behaviour introduced by pipefail?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 2 years ago* (1 child)

    This wiki explains one pitfall of nonstandard return codes in pipes. The other one that bit me is pipes that just stop existing (error 141).

    Anti Commercial-AI license

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 2 years ago (1 child)

    Thanks. Bash should just be avoided except trivial uses. It has an impressive collection of footguns. I've written a lot of bash, even used it for CGI scripts to create web tools, but honestly it is time to move on. Ansible and Python cover most of the bash use cases.

  • source
  • parent
  • hideshow 2 child comments
  • [+] 1 point 2 years ago