[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#60591: `realpath` behaves differently when the target directory/file
bug#60591: `realpath` behaves differently when the target directory/file does not exist on Mac M1
Fri, 6 Jan 2023 15:00:29 +0000
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0
tag 60591 notabug
On 05/01/2023 22:42, Tao Zhou wrote:
Hi I recently noticed something weird with the `realpath` on my Mac Pro M1.
When I try to call `realpath` on a directory/file that does not exist, it
throws `No such file or directory` error, compared to another regular Linux
machine, the `realpath` there will just return a valid path, unless it's a
nested structure and parent does not exist.
$ realpath b
realpath: b: No such file or directory // from the mac pro M1
/b // from other linux machines
$ realpath b/c
realpath: b/c: No such file or directory // from both mac pro M1 and other
The `uname -a` of my mac pro M1: `22.2.0 Darwin Kernel Version 22.2.0: Fri
Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000 arm64`
I presume you're using the macOS realpath(1) here, which
seems to be a simple wrapper around realpath(2),
and so will just give that error for non existent files.
Whereas the coreutils realpath(1) provides more functionality. Specifically:
"By default, all but the last component of the specified files must exist".
To change change and get the macos default behavior you could use
the -e option. Another option is to `brew install coreutils` on your mac
and use greadlink instead.