willdoescode / nat

`ls` alternative with useful info and a splash of color 🎨

Home Page:https://git.io/natls

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Can not list root directory /

SebastianSchildt opened this issue · comments

It can not list fs root "/"

$ nat /
Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }

but

$ ls /
Applications	Library		Users		bin		dev		home		private		tmp		var
EFI-Backups	System		Volumes		cores		etc		opt		sbin		usr

This is on OS X 10.15

Okay, the root cause is a symlink that points to a non-existing file. nat can not deal with that

"the better ls" lmao. Two rust files, not even on homebrew, one option (-f), can't list "/", written by somoene who probably spent more time on his github about section than his code.

And a big German newspaper made an article about it: https://www.heise.de/news/In-Rust-geschrieben-und-uebersichtlicher-nat-will-ls-ersetzen-4937429.html

While it might technically be true, that this a few thousand lightyears behind ls in.. everything it is also true, the the account that created this has a factor 30 higher activity on Github last year than you....

Going back to-topic, I replaced calls to metadatawith symlink_metadata , which quit unintuitively does not follow symlinks, and thus doesn't fail when encountering a dangling one.

I think a better solutions is changing this

  let entries = fs::read_dir(directory)?
    .map(|res| res.map(|e| e.path()))
    .collect::<Result<Vec<_>, io::Error>>()?;

to create a Vector containing the pathes/dsiplay strings and all metadata, to get rid of the metadata calls all over the place (I think it only possible by hand, creating a mutable vector and filling it. Then it could also detect what a symlink is, and change the string to "symlinkname->symlinktarget" as in ls. but maybe there is some RUST-fu magician out there how can map the hell out of it, doing it in one go...)

Also I think using the ?operator after having read the initial directory list is a bad design choice for this tool, because it will make the program fall over whenever stumbling across some unexpected things...

commented

Thanks to @SebastianSchildt symlinks now work. Thread closed.