Show contents of symbolic link
Solution 1
One likely cause for the seeming difference in the output of ls -l
between zsh and bash is the use of Tab
-completion with AUTO_REMOVE_SLASH
enabled in zsh (which is the default).
AUTO_REMOVE_SLASH <D>
When the last character resulting from a completion is a slash and the next character typed is a word delimiter, a slash, or a character that ends a command (such as a semicolon or an ampersand), remove the slash.
When typing ls -l symb
Tab, both zsh
and bash
will complete this to ls -l symboliclink/
(note the /
at the end). The difference is that zsh
(with enabled AUTO_REMOVE_SLASH
) will remove the slash, if you just press Enter (i.e. end the command) there.
So you will effectively run ls -l symboliclink/
in bash, which tells ls -l
to look behind the link. But in zsh you will run ls -l symboliclink
, which tells ls -l
that you want to see the information about the link and not the target directory.
ls
without option -l
will always show the contents of the target directory, regardless of there being an /
at the end or not.
In order to get zsh to not remove the slash at the end, it is sufficient to just type it explicitly after TAB
-completion. Usually this will not visibly change the completed text, but if you type a space or confirm the command, the /
will remain. "Usually" because it is possible to set a highlighting for automatically added suffix characters, for example magenta and bold:
zle_highlight[(r)suffix:*]="suffix:fg=magenta,bold"
(Note: this may not work when using the external ZSH Syntax Highlighting plugin)
Another solution is (obviously) to disable AUTO_REMOVE_SLASH
. This can be done with
setopt noautoremoveslash
Solution 2
This is ls
option -H
:
ls -lH symboliclink
From man 1p ls
:
-H
If a symbolic link referencing a file of type directory is specified on the command line, ls shall evaluate the file information and file type to be those of the file referenced by the link, and not the link itself; however, ls shall write the name of the link itself and not the file referenced by the link.
Also note option -L
-L
Evaluate the file information and file type for all symbolic links (whether named on the command line or encountered in a file hierarchy) to be those of the file referenced by the link, and not the link itself; however, ls shall write the name of the link itself and not the file referenced by the link. When -L is used with -l, write the contents of symbolic links in the long format (see the STDOUT section).
Solution 3
Simply add a '/' at the end.
ls -l symboliclink/
Solution 4
The behavior of the ls
program does not depend on the shell that calls it. If you observe different behavior with ls
in bash and in zsh, it's because you have an alias (or function) called ls
in one of the shells but not in the other. The behavior you're observing in zsh corresponds to what ls
does, so you must be calling it with additional options in bash.
You may have aliased ls
to ls -H
or ls -L
, to make it dereference symbolic links. This is a bad idea because you then can't get information about the symlinks themselves, other than by bypassing the alias (\ls
).
When a file is a symbolic link to a directory, you can act on the directory rather than the file by adding a slash at the end: ls -l symboliclink/
is equivalent to ls -l symboliclink/.
. See When is a symlink treated as the thing it links to, and as a symlink?
Related videos on Youtube
![pfnuesel](https://i.stack.imgur.com/FRW2s.gif?s=256&g=1)
pfnuesel
Updated on September 18, 2022Comments
-
pfnuesel almost 2 years
In
zsh
, I make a symbolic link$ ln -s ~/Documents symboliclink
and then I want to know what's inside this symbolic link.
$ ls -l symboliclink > lrwxrwxrwx 1 user user 21 Oct 10 15:56 symboliclink -> /home/user/Documents
This shows only the symbolic link, not what's inside it. If i use
ls
only, it lists the contents, but if I used the-l
flag, it doesn't. This works inbash
both forls
andls -l
. How can I get that behavior inzsh
as well?-
pfnuesel over 7 yearsWhy the downvote?
-
-
MikeA over 7 yearsI'm curious if that is documented somewhere or just behavior you noticed?