From: "Pádraig Brady" <P@draigBrady.com>
To: Tao Zhou <iamzhoutao92@gmail.com>, 60591@debbugs.gnu.org
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 [thread overview]
Message-ID: <bf3b9a99-f0e8-158e-e6d8-09d8c4d2cea6@draigBrady.com> (raw)
In-Reply-To: <CAMdiJ0Gh76z32otULbPo+yjvfbV4BX-DP4ywYTNZRxR2eqgqog@mail.gmail.com>
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
prev parent reply other threads:[~2023-01-06 15:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-05 22:42 bug#60591: `realpath` behaves differently when the target directory/file does not exist on Mac M1 Tao Zhou
2023-01-06 15:00 ` Pádraig Brady [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-coreutils
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bf3b9a99-f0e8-158e-e6d8-09d8c4d2cea6@draigBrady.com \
--to=p@draigbrady.com \
--cc=60591@debbugs.gnu.org \
--cc=iamzhoutao92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).