[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60591: `realpath` behaves differently when the target directory/file

From: Pádraig Brady
Subject: bug#60591: `realpath` behaves differently when the target directory/file does not exist on Mac M1
Date: Fri, 6 Jan 2023 15:00:29 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0

tag 60591 notabug
close 60591

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.

Example as:

$ pwd
$ ls
$ 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
linux machines

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]