GNU bug report logs -
#70639
Bug or Misleading Description of realpath command
Previous Next
To reply to this bug, email your comments to 70639 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
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):
[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):
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 208 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.