carlocorradini / inline Goto Github PK

Reference Issues

No response

Summary

what do you think of deprecating the default name for the input-file and name the output-file something like original-script-name.inlined.sh?

could be more intuitive when running the command without parameter, which currently lead to script.sh not found instead of the help/usage screen.

Basic Example

Drawbacks

No response

Description

running the script on alpine/busybox fails with the following error:

readlink: unrecognized option: m
BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary.

Usage: readlink [-fnv] FILE

Display the value of a symlink

        -f      Canonicalize by following all symlinks
        -n      Don't add newline
        -v      Verbose

Reproduction steps

on `alpine:3.17.0` run:

bash inline.sh --in-file test.sh

test.sh

#!/bin/ash

echo "hello"
source header.sh

header.sh

# fail on non-zero exit code
set -e -o pipefail -o errexit

OS

Alpine Linux Busybox

hopefully helpful links:

• basherpm/basher#49
• BernieO/calcardbackup#4

Reference Issues

No response

Summary

Add a silent log level to disable logging

Basic Example

--log-level silent

Drawbacks

No response

just to share my thoughts, having a folder structure like that:

├── bin
│   └── main.sh
            source templates/test/a.sh
└── templates
    └── test
        ├── a.sh
                echo this is a
                source templates/test/b.sh # required for regular bash script usage
                vs
                source b.sh # required with inline.sh
        └── b.sh
                echo this is b

and running main.sh from the root dir leads to an error like:

bash bin/main.sh
...
[FATAL] Unable to resolve source file path ...
[FATAL] Error inlining file ...

it works if source is used without path but then the usage breaks if i want to run it with a native bash call and vice versa.

some option like --relative-sourcing vs --source-from-cwd could be helpful