“ls -l” doesn't show symlinks source paths

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












Before I reinstalled MacOS, ls -l showed symlinks with their source path. Now ls -l shows symlinks as regular files - without the source path.



How can I make it show the source path?



I'm on a clean MacOS installation with ZSH and a basic .zshrc file.



Here's an image where etc is showed with it's source:



enter image description here










share|improve this question























  • unix.meta.stackexchange.com/questions/4086 Also, you have asked about the behaviour of ls -l but have shown the behaviour of ll. Show the behaviour of the command that you are asking about.
    – JdeBP
    Dec 3 at 11:43






  • 1




    Yes, please show us the output of /bin/ls -l. If that works, show us the output of type ll and type ls.
    – terdon
    Dec 3 at 13:03














up vote
1
down vote

favorite












Before I reinstalled MacOS, ls -l showed symlinks with their source path. Now ls -l shows symlinks as regular files - without the source path.



How can I make it show the source path?



I'm on a clean MacOS installation with ZSH and a basic .zshrc file.



Here's an image where etc is showed with it's source:



enter image description here










share|improve this question























  • unix.meta.stackexchange.com/questions/4086 Also, you have asked about the behaviour of ls -l but have shown the behaviour of ll. Show the behaviour of the command that you are asking about.
    – JdeBP
    Dec 3 at 11:43






  • 1




    Yes, please show us the output of /bin/ls -l. If that works, show us the output of type ll and type ls.
    – terdon
    Dec 3 at 13:03












up vote
1
down vote

favorite









up vote
1
down vote

favorite











Before I reinstalled MacOS, ls -l showed symlinks with their source path. Now ls -l shows symlinks as regular files - without the source path.



How can I make it show the source path?



I'm on a clean MacOS installation with ZSH and a basic .zshrc file.



Here's an image where etc is showed with it's source:



enter image description here










share|improve this question















Before I reinstalled MacOS, ls -l showed symlinks with their source path. Now ls -l shows symlinks as regular files - without the source path.



How can I make it show the source path?



I'm on a clean MacOS installation with ZSH and a basic .zshrc file.



Here's an image where etc is showed with it's source:



enter image description here







zsh symlink






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 3 at 12:15









Rui F Ribeiro

38.5k1479128




38.5k1479128










asked Dec 3 at 11:13









Emanuil Rusev

1085




1085











  • unix.meta.stackexchange.com/questions/4086 Also, you have asked about the behaviour of ls -l but have shown the behaviour of ll. Show the behaviour of the command that you are asking about.
    – JdeBP
    Dec 3 at 11:43






  • 1




    Yes, please show us the output of /bin/ls -l. If that works, show us the output of type ll and type ls.
    – terdon
    Dec 3 at 13:03
















  • unix.meta.stackexchange.com/questions/4086 Also, you have asked about the behaviour of ls -l but have shown the behaviour of ll. Show the behaviour of the command that you are asking about.
    – JdeBP
    Dec 3 at 11:43






  • 1




    Yes, please show us the output of /bin/ls -l. If that works, show us the output of type ll and type ls.
    – terdon
    Dec 3 at 13:03















unix.meta.stackexchange.com/questions/4086 Also, you have asked about the behaviour of ls -l but have shown the behaviour of ll. Show the behaviour of the command that you are asking about.
– JdeBP
Dec 3 at 11:43




unix.meta.stackexchange.com/questions/4086 Also, you have asked about the behaviour of ls -l but have shown the behaviour of ll. Show the behaviour of the command that you are asking about.
– JdeBP
Dec 3 at 11:43




1




1




Yes, please show us the output of /bin/ls -l. If that works, show us the output of type ll and type ls.
– terdon
Dec 3 at 13:03




Yes, please show us the output of /bin/ls -l. If that works, show us the output of type ll and type ls.
– terdon
Dec 3 at 13:03










1 Answer
1






active

oldest

votes

















up vote
1
down vote



accepted










It's possible ls is reporting the file system correctly but instead your folders are hardlinked instead.



However without seeing the output from ls that you are now seeing (rather than what you are expecting to see), any answer here would be largely speculative.




@JdeBP: Also, you have asked about the behaviour of ls -l but have shown the behaviour of ll. Show the behaviour of the command that you are asking about




ll is usually just an alias for ls -l (for example, defined in the users ~/.bashrc)



(sorry, I couldn't reply to you directly as don't have enough reputation to leave a comment)






share|improve this answer






















  • "usually" is not good enough. I've seen enough variations on these over the years to not take what they may expand to for granted, and to not take for granted that ls itself is not a shell function/alias.
    – JdeBP
    Dec 3 at 12:44






  • 1




    You're right, it was a hard link, all makes sense now. Thank you so much for the thoughtful response!
    – Emanuil Rusev
    Dec 3 at 13:22










Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485663%2fls-l-doesnt-show-symlinks-source-paths%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote



accepted










It's possible ls is reporting the file system correctly but instead your folders are hardlinked instead.



However without seeing the output from ls that you are now seeing (rather than what you are expecting to see), any answer here would be largely speculative.




@JdeBP: Also, you have asked about the behaviour of ls -l but have shown the behaviour of ll. Show the behaviour of the command that you are asking about




ll is usually just an alias for ls -l (for example, defined in the users ~/.bashrc)



(sorry, I couldn't reply to you directly as don't have enough reputation to leave a comment)






share|improve this answer






















  • "usually" is not good enough. I've seen enough variations on these over the years to not take what they may expand to for granted, and to not take for granted that ls itself is not a shell function/alias.
    – JdeBP
    Dec 3 at 12:44






  • 1




    You're right, it was a hard link, all makes sense now. Thank you so much for the thoughtful response!
    – Emanuil Rusev
    Dec 3 at 13:22














up vote
1
down vote



accepted










It's possible ls is reporting the file system correctly but instead your folders are hardlinked instead.



However without seeing the output from ls that you are now seeing (rather than what you are expecting to see), any answer here would be largely speculative.




@JdeBP: Also, you have asked about the behaviour of ls -l but have shown the behaviour of ll. Show the behaviour of the command that you are asking about




ll is usually just an alias for ls -l (for example, defined in the users ~/.bashrc)



(sorry, I couldn't reply to you directly as don't have enough reputation to leave a comment)






share|improve this answer






















  • "usually" is not good enough. I've seen enough variations on these over the years to not take what they may expand to for granted, and to not take for granted that ls itself is not a shell function/alias.
    – JdeBP
    Dec 3 at 12:44






  • 1




    You're right, it was a hard link, all makes sense now. Thank you so much for the thoughtful response!
    – Emanuil Rusev
    Dec 3 at 13:22












up vote
1
down vote



accepted







up vote
1
down vote



accepted






It's possible ls is reporting the file system correctly but instead your folders are hardlinked instead.



However without seeing the output from ls that you are now seeing (rather than what you are expecting to see), any answer here would be largely speculative.




@JdeBP: Also, you have asked about the behaviour of ls -l but have shown the behaviour of ll. Show the behaviour of the command that you are asking about




ll is usually just an alias for ls -l (for example, defined in the users ~/.bashrc)



(sorry, I couldn't reply to you directly as don't have enough reputation to leave a comment)






share|improve this answer














It's possible ls is reporting the file system correctly but instead your folders are hardlinked instead.



However without seeing the output from ls that you are now seeing (rather than what you are expecting to see), any answer here would be largely speculative.




@JdeBP: Also, you have asked about the behaviour of ls -l but have shown the behaviour of ll. Show the behaviour of the command that you are asking about




ll is usually just an alias for ls -l (for example, defined in the users ~/.bashrc)



(sorry, I couldn't reply to you directly as don't have enough reputation to leave a comment)







share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 3 at 12:17

























answered Dec 3 at 12:11









laumars

262




262











  • "usually" is not good enough. I've seen enough variations on these over the years to not take what they may expand to for granted, and to not take for granted that ls itself is not a shell function/alias.
    – JdeBP
    Dec 3 at 12:44






  • 1




    You're right, it was a hard link, all makes sense now. Thank you so much for the thoughtful response!
    – Emanuil Rusev
    Dec 3 at 13:22
















  • "usually" is not good enough. I've seen enough variations on these over the years to not take what they may expand to for granted, and to not take for granted that ls itself is not a shell function/alias.
    – JdeBP
    Dec 3 at 12:44






  • 1




    You're right, it was a hard link, all makes sense now. Thank you so much for the thoughtful response!
    – Emanuil Rusev
    Dec 3 at 13:22















"usually" is not good enough. I've seen enough variations on these over the years to not take what they may expand to for granted, and to not take for granted that ls itself is not a shell function/alias.
– JdeBP
Dec 3 at 12:44




"usually" is not good enough. I've seen enough variations on these over the years to not take what they may expand to for granted, and to not take for granted that ls itself is not a shell function/alias.
– JdeBP
Dec 3 at 12:44




1




1




You're right, it was a hard link, all makes sense now. Thank you so much for the thoughtful response!
– Emanuil Rusev
Dec 3 at 13:22




You're right, it was a hard link, all makes sense now. Thank you so much for the thoughtful response!
– Emanuil Rusev
Dec 3 at 13:22

















draft saved

draft discarded
















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485663%2fls-l-doesnt-show-symlinks-source-paths%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay