Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

exa -laa <dir> marks <dir> as a broken symbolic link if it's relative #952

Open
Frederick888 opened this issue Sep 15, 2021 · 0 comments · May be fixed by #1018
Open

exa -laa <dir> marks <dir> as a broken symbolic link if it's relative #952

Frederick888 opened this issue Sep 15, 2021 · 0 comments · May be fixed by #1018

Comments

@Frederick888
Copy link

$ exa --version
exa - list files on the command-line
v0.10.1 [+git]
https://the.exa.website/

For example,

mkdir /tmp/test
cd /tmp/test
mkdir foo
touch bar.txt
cd foo
ln -s ../../test
cd ..

Now if I run exa -laa foo, the link is cyan as expected:
image

However if I exa -laa foo/test, the link is red:
image

Just a guess, is this because exa always treats relative symbolic links as relative to current working directory?

Frederick888 added a commit to Frederick888/exa that referenced this issue Jan 29, 2022
Without this canonicalisation, if the directory is a symbolic link to
another directory, later at `reorient_target_path` [1], File and path
argument look like:

- self: File {
    name: "."
    ext: None
    path: "/tmp/test2"
    metadata: {...}
    parent_dir: Some({
      contents: vec![]
      path: "/tmp/test2"
    })
    is_all_all: true
  }
- path: "test1"

...where /tmp/test2 is a symlink to /tmp/test1 and command being used is
`exa -laa /tmp/test2`.

So the result of `parent.join(&*path)` becomes `/tmp/test2/test1`, which
doesn't exist.

The canonicalisation also makes the behaviours of `exa -laa /tmp/test2`
and `exa -laa /tmp/test2/` consistent, where `.` is not treated as a
symlink in either case. This is a bit different from coreutils `ls`
though.

Closes ogham#952.

[1] https://github.com/ogham/exa/blob/42659f93456d9ff7cc1096cbd84d778ede26d76e/src/fs/file.rs#L215-L217
Frederick888 added a commit to Frederick888/exa that referenced this issue Jan 29, 2022
Without this canonicalisation, if the directory is a symbolic link to
another directory, later at `reorient_target_path` [1], File and path
argument look like:

- self: File {
    name: "."
    ext: None
    path: "/tmp/test2"
    metadata: {...}
    parent_dir: Some({
      contents: vec![]
      path: "/tmp/test2"
    })
    is_all_all: true
  }
- path: "test1"

...where /tmp/test2 is a symlink to /tmp/test1 and command being used is
`exa -laa /tmp/test2`.

So the result of `dir.join(&*path)` becomes `/tmp/test2/test1`, which
doesn't exist.

The canonicalisation also makes the behaviours of `exa -laa /tmp/test2`
and `exa -laa /tmp/test2/` consistent, where `.` is not treated as a
symlink in either case. This is a bit different from coreutils `ls`
though.

Closes ogham#952.

[1] https://github.com/ogham/exa/blob/42659f93456d9ff7cc1096cbd84d778ede26d76e/src/fs/file.rs#L215-L217
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant