GNU bug report logs - #70639
Bug or Misleading Description of realpath command

Previous Next

Package: coreutils;

Reported by: Hazel Cooney <evancooney71 <at> gmail.com>

Date: Mon, 29 Apr 2024 01:57:02 UTC

Severity: normal

To reply to this bug, email your comments to 70639 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#70639; Package coreutils. (Mon, 29 Apr 2024 01:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hazel Cooney <evancooney71 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Mon, 29 Apr 2024 01:57:02 GMT) Full text and rfc822 format available.

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

From: Hazel Cooney <evancooney71 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Bug or Misleading Description of realpath command
Date: Sun, 28 Apr 2024 18:37:51 -0500
[Message part 1 (text/plain, inline)]
Hello,
I don't know if this was my misuse of the command or whether this was a
bug, but it seems like the realpath command does not work as expected in
some cases. I have a folder in my home directory called "music_copy" and I
tried to use a command string to print the full paths to the files and
directories inside it by using the command ls music_copy | xargs realpath ,
but it didn't work as expected. I expected the output to contain the full
paths to the files, but instead realpath outputted that the files were in
/home/lakec, which they weren't. I attached a picture of the output of the
commands I used.

This might also be a documentation issue, because it seems to me like
realpath was just "tricked" because the names of the files printed by ls
didn't have enough context for realpath to figure out what the path was. If
I changed to the music_copy directory and then ran the ls | xargs realpath,
realpath gave the correct output. It might be worth saying something about
that in the man page for realpath. I haven't checked the info page yet.

To reproduce this bug, create a directory with some files in it. Then, go
to the directory that contains the one you just made. Type ls new_directory
| xargs realpath.

I am using EndeavourOS Linux (It should be called GNU/Linux but that's the
name they use) with kernel version 6.8.7-arch1-1 , ls version 9.5, xargs
version 4.9.0. and realpath version 9.5.
Here's a screenshot of the commands I used. I also have "ls" aliased to "ls
--color=auto" in the .bashrc if you're wondering.
[image: image.png]
Thank you!
[Message part 2 (text/html, inline)]
[image.png (image/png, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#70639; Package coreutils. (Mon, 29 Apr 2024 02:19:01 GMT) Full text and rfc822 format available.

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

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Hazel Cooney <evancooney71 <at> gmail.com>, 70639 <at> debbugs.gnu.org
Subject: Re: bug#70639: Bug or Misleading Description of realpath command
Date: Sun, 28 Apr 2024 19:18:05 -0700
On 4/28/24 4:37 PM, Hazel Cooney wrote:
> To reproduce this bug, create a directory with some files in it. Then, go
> to the directory that contains the one you just made. Type ls new_directory
> | xargs realpath.

Using 'build-aux' for my directory instead of music_copy. We have this
for build-aux:

    ls build-aux
    announce-gen    config.libpath    depcomp ....

From the 'realpath' info page we have:

   By default, all but the last component of the specified files must
   exist.

Then when we perform the 'ls build-aux | xargs realpath', we don't
change our current working directory. So that is why we get:

    # Notice 'build-aux' is missing after gnulib.
    $ ls build-aux | xargs realpath
    /home/collin/.local/src/gnulib/announce-gen
    /home/collin/.local/src/gnulib/ar-lib
    /home/collin/.local/src/gnulib/bootstrap

There might be a better way to write it, but I would do this:

    $ for file in build-aux/*; do echo $file; done | xargs realpath
    /home/collin/.local/src/gnulib/build-aux/announce-gen
    /home/collin/.local/src/gnulib/build-aux/ar-lib
    /home/collin/.local/src/gnulib/build-aux/bootstrap

Since unlike 'ls' that loop does not remove the directory name:

   $ for file in build-aux/*; do echo $file; done
   build-aux/announce-gen
   build-aux/ar-lib
   build-aux/bootstrap

Does that explination help? Or I misunderstanding your issue?

Collin




This bug report was last modified 17 days ago.

Previous Next


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