GNU bug report logs - #60591
`realpath` behaves differently when the target directory/file does not exist on Mac M1

Previous Next

Full log

Message #12 received at control <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Tao Zhou <iamzhoutao92 <at> gmail.com>, 60591 <at> debbugs.gnu.org
Subject: Re: 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

tag 60591 notabug
close 60591
stop

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
> a
> $ 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.

cheers,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.