MacOS support

[smith]

The release files are debs. If I download the source and run otel.sh I get

exec: Failed to execute process './usr/bin/otel.sh': The file specified the interpreter '/bin/false', which is not an executable command.

So, I'm assuming the scripts are making some Linux-specific assumptions.

A version that runs on MacOS would be great, if you're not planning that, a note about OS support in the README would be great.

If making the scripts MacOS compatible seems like it's not impossible, any notes on how to get it working would be helpful.

[plengauer]

@smith it looks like you have tried to run it directly, but it needs to be sourced rather than executed. in the readme, there is a space between the . and the otel.sh. the file is not intended to run directly, therefore the /bin/false shebang.

that being said, i never tried to run it anything non-linux. the code itself doesnt have a lot (if any) linux specifics, but it uses a bunch of external dependencies (like cut, tr, grep, awk, sed, ...) that need to be installed (as per the debian control file at https://github.com/plengauer/opentelemetry-bash/blob/e7ff252a6026fecfc149b8a5472a4512f286e9b2/src/DEBIAN/control).
assuming the same external executables can be installed on a mac system, i dont see why it wouldnt work.

let me think about that more

PS: your point about adding a note about OS support is definitely a good one!

[smith]

(some things in this output might not actually be problems, as I mucked around with the paths so I didn't have to install to / on my Mac, and I haven't set any OTEL environment variables to actually try to see if any data is sent.)

Any use of /proc isn't going to work but I'm pretty sure there's native MacOS alternatives to anything being used here.

I think there's also some MacOS differences in naming and CLI flags (Some BSD-isms, some Mac specific) like it's nc not netcat.

bash-5.2$ . ./src/usr/bin/otel.sh
bash: /proc/23404/cmdline: No such file or directory
bash: /proc//cmdline: No such file or directory
WARNING When using OpenTelemetry in an interactive shell for the first time after startup, it may take some time to create the instrumentation cache! Subsequent interactive shells will start faster. This performance impact does not apply in non-interactive shells, like scripts or invocations with -c.
bash: type: busybox: not found
bash: type: podman: not found
bash: type: taskset: not found
bash: type: ionice: not found
bash: type: flock: not found
bash: type: dumb-init: not found
bash: type: ncat: not found
bash: type: netcat: not found
bash: type: node: not found
bash: type: nodejs: not found
bash: type: parallel: not found
bash: type: parallel.moreutils: not found
bash: /proc/29875/cmdline: No such file or directory
bash: /proc/29875/cmdline: No such file or directory
bash: type: ash: not found
bash: /proc/29875/cmdline: No such file or directory
bash: /proc/29875/cmdline: No such file or directory
bash: /proc/29875/cmdline: No such file or directory
Detector <__main__.AwsEC2ResourceDetector object at 0x101115fa0> took longer than 5 seconds, skipping
Detector <__main__.OracleResourceDetector object at 0x1035f8620> took longer than 5 seconds, skipping
^C
bash-5.2$ SDK Error: SPAN_START /var/folders/hw/917m5r6d33780w6mvptjr50c0000gn/T/tmp.tuuxSftRe7_opentelemetry_shell_29875.span_handle.pipe   SERVER
Traceback (most recent call last):
  File "/Users/smith/Desktop/opentelemetry-bash-4.23.1/src/usr/bin/otelsdk.py", line 122, in main
    handle(scope, version, tokens[0], tokens[1] if len(tokens) > 1 else None)
  File "/Users/smith/Desktop/opentelemetry-bash-4.23.1/src/usr/bin/otelsdk.py", line 232, in handle
    name = tokens[4]
           ~~~~~~^^^
IndexError: list index out of range

I might dig a litter deeper and hack on it if I get any time. Thanks for looking at it.

[plengauer]

Needs
*) a dedicated build step to build whatever thr native mac package type is in build.yml
*) package meta info in meta dir
*) a mac job like the linux/windows shell jobs in test
Test_shell.yml
*) replacing all accesses to /proc with something equivalent. This should not be dynamic, but rather functions should be defined differently once. For that, check if the dir /proc exists
*) everywhere where there is something os specific, there needs to a new case. For example, where dpkg is used
*) tests that are designed for Linux envs, like debconf should be skipped on mac
*) readme needs an entry that mac is supported additional to windows and linux
Linux
*) the root level install scripts needs adjustments to handle