Full binary being placed in /etc/path.d on macOS
invisiblethreat opened this issue · 5 comments
Bug description
The macOS installer places a full binary in /etc/path.d
rather than a text file with a path to super-analyzer
. This causes the entire binary to be sourced/eval'd via /usr/libexec/path_helper -s
, which leads to erratic pathing, and in my case, an unmatched "
. This behavior can stop programs that use login shells from executing properly(RStudio requires a login shell and fails to launch because of this, for example).
To Reproduce
Steps to reproduce the behavior (example):
- Download
super
0.5.0 for macOS - Run the installer
- Inspect
/etc/path.d/
forsuper-analyzer
- Run
file /etc/path.d/super-analyzer
to verify that it's a Mach-0 binary and not a text file
Expected behavior
A text file should be placed at /etc/path.d/super-analyzerthat will allow for
/usr/libexec/path_helper` to find the binary.
Setup
- OS: macOS 10.14.2
- SUPER Version: 0.5.0
Additional context
I went looking for installer files to submit a PR, but could not find them.
Hi! Actually, the package is not generated automatically yet, even though we are thinking on doing it. @SergioD0l generates them, he can probably give some insights on it.
If the configuration is able to be checked in, I'd help out. There were other things that I noticed while running the installer- nothing critical, more just polishing up some of the titles and whatnot.
Thanks for this project!
Thanks! We could really use some help with MacOS build automation. In fact, apart from creating the packages, we would like to integrate it with homebrew too (#168).
So, the travis build script contains the configuration for tests and releases. We would need a new job such as this (we probably don't need the docker service for MacOS builds):
- name: "MacOS packaging"
os: macos
rust: stable
stage: test
env: CACHE_NAME=MACOS
services: docker
script: ./travis-helper.sh dist_test macos
And then add the required code would go in the travis-helper.sh file. At the end of the file you have the code doing the actual builds for all platforms. Finally, each release has a shell script that creates the release, such as this.
Feel free to create any extra needed configuration file for making the release, and let me know if you need any help with how to build the Rust code.
I blew up 2 days trying to debug an issue on a completely different program (SConstruct, which uses /etc/paths.d
to find directories). Nothing that is not an ASCII file with a list of paths should ever end up in /etc/paths.d/
! Meh... :-)
Hi! The problem has been fixed for the 0.5.1 SUPER version, i'm gonna close this issue.