Respect `docker` being an alias

[paracycle]

There are setups where the docker executable is an alias to another CLI which is a drop in replacement for docker, like podman.

Currently, this tool does not pick up those kinds of aliases, and fails with:

$ ./rails-new foo
thread 'main' panicked at src/main.rs:26:10:
Failed to execute process: Os { code: 2, kind: NotFound, message: "No such file or directory" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I think this might be because we are spawning a new process and not launching the new process in sub-shell.

[Quinncuatro]

Interesting. I was running OrbStack when I tried this the first time and it handled the underlying alias just fine.

[guycall]

I am getting similar issue. Brand new M3 macbook (Sonoma 14.5).

• Installed podman via homebrew.
• Downloaded v0.3.0 of rails-new-aarch64-apple-darwin.tar.gz
• Aliased docker to podman

% docker --version
podman version 5.1.2

% RUST_BACKTRACE=full ./rails-new blog  --devcontainer 
thread 'main' panicked at src/main.rs:32:6:
Failed to execute process: Os { code: 2, kind: NotFound, message: "No such file or directory" }
stack backtrace:
   0:        0x10041ef54 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h0aa20ca08aeb683c
   1:        0x100437340 - core::fmt::write::h168dbafcf35bac68
   2:        0x10041d0a4 - std::io::Write::write_fmt::hdb0dd3f09dcf2281
   3:        0x10041ed88 - std::sys_common::backtrace::print::h57b289e4b951ee17
   4:        0x100420314 - std::panicking::default_hook::{{closure}}::h783b6c512154ec65
   5:        0x10042005c - std::panicking::default_hook::hcdfa9e1e0f234a4f
   6:        0x100420750 - std::panicking::rust_panic_with_hook::h9aea678ca49d64cf
   7:        0x100420644 - std::panicking::begin_panic_handler::{{closure}}::ha16c3377e66deceb
   8:        0x10041f3d8 - std::sys_common::backtrace::__rust_end_short_backtrace::hea8fdda1ea8a4c0e
   9:        0x1004203cc - _rust_begin_unwind
  10:        0x10043dfe4 - core::panicking::panic_fmt::h1cb43b60f5788132
  11:        0x10043e2e0 - core::result::unwrap_failed::h71a35eff74d84b68
  12:        0x1003be4c0 - rails_new::main::h8db199c942077a3a
  13:        0x1003b7c88 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5b842c3ce86abb26
  14:        0x1003bddc0 - std::rt::lang_start::{{closure}}::h8db2c1c6adb7c728
  15:        0x1004194c4 - std::rt::lang_start_internal::h0e09503d2b7f298e
  16:        0x1003be70c - _main

[guycall]

Resolved by creating symlink: sudo ln -sf /opt/homebrew/bin/podman /usr/local/bin/docker

[seisenreich]

Same here. M1 Mac Sonoma 14.7.1 (23H222).
Podman installed manually via using latest official github release mac os arm package.

symlinking is a workaround, yes, but it should not be necessary to find this out on your own.

[xanadiu]

I have Podman installed and would love to have a handy way to let rails-new know about it.

So I agree with @seisenreich that a symlink is only a workaround and not the favourite method.