ThePrez / ServiceCommander-IBMi

Service Commander for IBM i
Apache License 2.0
40 stars 12 forks source link

[BUG] /QOpenSys/pkgs/bin/bash^M: bad interpreter: No such file or directory after make install #192

Closed ajshedivy closed 1 year ago

ajshedivy commented 1 year ago

Describe the bug While working on other issues, I noticed that after running make install that the sc command does not work.

To Reproduce

from the sc root directory, call make install then invoke the sc command.

bash-5.1$ make install
bash-5.1$ sc
bash: /QOpenSys/pkgs/bin/sc: /QOpenSys/pkgs/bin/bash^M: bad interpreter: No such file or directory

Expected behavior the sc usage message should be displayed (indicating that it is working)

Additional context I am using SSHFS-Win (windows) for remote development on sc. During my testing and editing It seeming some of the internal sc source files are being converted to windows line endings. If I use dos2unix on the sc script, things work as expected:

bash-5.1$ dos2unix /QOpenSys/pkgs/bin/sc
dos2unix: converting file /QOpenSys/pkgs/bin/sc to Unix format...
bash-5.1$ sc
Usage: sc  [options] <operation> <service>

    Valid options include:
        -v: verbose mode
        -q: quiet mode (suppress warnings). Ignored when '-v' is specified
        --disable-colors: disable colored output
        --splf: send output to *SPLF when submitting jobs to batch (instead of log)
        --sampletime=x.x: sampling time(s) when gathering performance info (default is 1)
        --ignore-globals: ignore globally-configured services
        --ignore-groups=x,y,z: ignore services in the specified groups (default is 'system')
        --all/-a: don't ignore any services. Overrides --ignore-globals and --ignore-groups

    Valid operations include:
        start: start the service (and any dependencies)
        stop: stop the service (and dependent services)
        kill: stop the service (and dependent services) forcefully
        restart: restart the service
        check: check status of the service
        info: print configuration info about the service
        jobinfo: print basic performance info about the service
        perfinfo: print basic performance info about the service
        loginfo: get log file info for the service (if running)
        list: print service short name and friendly name
        groups: print an overview of all groups
    Valid formats of the <service(s)> specifier include:
        - the short name of a configured service
        - A special value of "all" to represent all configured services (same as "group:all")
        - A group identifier (e.g. "group:groupname")
        - the path to a YAML file with a service configuration
        - An ad hoc service specification by port (for instance, "port:8080")
        - An ad hoc service specification by job name (for instance, "job:ZOOKEEPER")
        - An ad hoc service specification by subsystem and job name (for instance, "job:QHTTPSVR/ADMIN2")

Is this something that needs to be investigated further?

chrjorgensen commented 1 year ago

@ajshedivy I did a quick test cloning the main branch from GitHub into a directory on an IBM i sandbox - and no problems making and running sc...

I think you should check your git config - especially if you run git on windows sending files to IBM i using SSHFS: git on Windows will by default extract files using CRLF as line endings. Git on Mac/Linux/IBM i uses LF as line endings.

chrjorgensen commented 1 year ago

@ajshedivy Just a clarification - I used a SSH terminal into the IBMi sandbox and did the git clone in the terminal. So git was running on IBM i, not on Windows.

When doing cross-platform development or using SSHFS, be careful not to send Windows files into the Mac/Linux/IBM i box - as you discovered, they use different line ending codes than Windows. You can develop on Windows without problems - just keep the git repository on Windows and push to the remote and pull on the machine where the code is meant to be compiled / run.

You can control the line endings used by git - see the autocrlf config value.

ThePrez commented 1 year ago

We can close this issue for now since I think we understand the root cause. If this is a persistent problem, I'm not opposed to putting some dos2unix calls in the Makefile or something