lsd-rs / lsd Goto Github PK
View Code? Open in Web Editor NEWThe next gen ls command
License: Apache License 2.0
The next gen ls command
License: Apache License 2.0
Create the option --icons
like:
lsd --icons=none # Do not display icons
lsd --icons=unicode # Display only unicode icons
lsd --icons=default # Display the default (current) icon set
The unicode type is for the user who doesn't want to download a specific font. It should be available with all the classic fonts and terminals.
This is on ubuntu 18.04.1
lsd to give a listing
$ lsd
cannot open directory'.': Permission denied (os error 13)
Current outpout:
tmp test % ⎈ prodild prod lsd -l
.rw-r--r-- peltoche users 0 B Mon Dec 10 10:16:50 2018 AAAAA
.rw-r--r-- peltoche users 0 B Mon Dec 10 10:16:57 2018 BBBB
.rw-r--r-- peltoche users 0 B Mon Dec 10 10:16:53 2018 aaaaa
.rw-r--r-- peltoche users 0 B Mon Dec 10 10:16:59 2018 bbbbb
expected output:
tmp test % ⎈ prodild prod \ls -l
total 0
-rw-r--r-- 1 peltoche users 0 Dec 10 10:16 aaaaa
-rw-r--r-- 1 peltoche users 0 Dec 10 10:16 AAAAA
-rw-r--r-- 1 peltoche users 0 Dec 10 10:16 BBBB
-rw-r--r-- 1 peltoche users 0 Dec 10 10:16 bbbbb
Icons can be a problem when interactive with pipes, to be more compatible with ls
. For example:
$ lsd | grep 'foo.txt' | xargs rm # not work
$ ls | grep 'foo.txt' | xargs rm # works
PS. Is it a bug for lsd
to print an extra line?
i.e. lsd | wc -l
(always) == ls | wc -l
+ 1
This allow to stop the recursive loop after a specified depth.
ls --tree --depth 3
It would be great if there were an option to not put the directories first. The current default behavior is different than the behavior of ls
, which makes it kind of confusing. We have these fancy icons and colors so it's already easy to tell which items are directories!
Current behavior:
drwxr-xr-x user group - Tue Dec 4 20:27:57 2018 Afolder
drwxr-xr-x user group - Tue Dec 4 20:27:51 2018 Bfolder
drwxr-xr-x user group - Fri Jan 11 19:47:11 2019 Zfolder
.rw-r--r-- user group 6 KB Fri Jan 11 18:56:06 2019 Afile
.rw-r--r-- user group 97 B Sat Nov 4 18:14:08 2017 Bfile
.rw-r--r-- user group 88 B Sat Nov 4 18:14:13 2017 Zfile
desired behavior:
.rw-r--r-- user group 6 KB Fri Jan 11 18:56:06 2019 Afile
drwxr-xr-x user group - Tue Dec 4 20:27:57 2018 Afolder
.rw-r--r-- user group 97 B Sat Nov 4 18:14:08 2017 Bfile
drwxr-xr-x user group - Tue Dec 4 20:27:51 2018 Bfolder
.rw-r--r-- user group 88 B Sat Nov 4 18:14:13 2017 Zfile
drwxr-xr-x user group - Fri Jan 11 19:47:11 2019 Zfolder
I got this error msg after installing rustfmt(Don't know if this matters).
env: macOS 10.12.6 with rustup 1.16.0 and cargo 1.31.0
The detail is:
thread 'main' panicked at 'failed to get the group name', libcore/option.rs:1008:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::continue_panic_fmt
6: rust_begin_unwind
7: core::panicking::panic_fmt
8: core::option::expect_failed
9: <lsd::meta::owner::Owner as core::convert::From<&'a std::fs::Metadata>>::from
10: lsd::meta::Meta::from_path
11: lsd::core::Core::list_folder_content
12: lsd::core::Core::run_inner
13: lsd::core::Core::run
14: lsd::main
15: std::rt::lang_start::{{closure}}
16: std::panicking::try::do_call
17: __rust_maybe_catch_panic
18: std::rt::lang_start_internal
19: main
Hey, can you help to add Windows support?
This is an example
dtolnay/cargo-llvm-lines@197316f.
I'm a beginner for rust,unfortunately i can not do it by myself.
If anyone can do this,thanks very much.
In the releases page the 0.9.0 is barren, no changelog and no release binaries.
First of all, thanks for a very handy tool.
I noticed that the sorted list is displayed sidewise by lsd
, whereas ls
displays it from top to bottom. It just makes it difficult to find a file as we would be looking at the list in a different direction. Can the display be made similar to that of ls
?
Are there any plans to implement all switches of ls
?
I don't know why you need a special font?
Is it just because the default unicode icons for folders (📁) are too big?
I'm asking because the unicode characters are supported by default in my terminal, but not the special fonts.
I think the symbols you need can definitely be found in default unicode: 🗋 🗁🗎 🔗
Of course you could still keep support for the people that wanted prettier fonts, but I think it would be nice if lsd worked out of the box with standard unicode.
If you think this is a good idea, I will try to make a patch that uses the unicode symbols if the custom font can't be found.
When attached to my company's LAN, LSD works as per the "Expected behaviour". However, when attached to my home network, LSD fails as per the "Actual behaviour".
I can see that this is is related to: #48 which is now closed.
I'm suspecting this is down to the fact that when I'm not on the office LAN, my "group" shows up as a number, rather than an actual name, so no name exists.
Is it possible to request that this fails gracefully?
Office LAN
➜ ~ ls -l
drwx--x--- myusername MYCOMPANY\Users - Thu Sep 27 12:24:30 2018 Applications
Home LAN
➜ ~ ls -l
drwx--x--- myusername 123456 - Thu Sep 27 12:24:30 2018 Applications
Office LAN behaves as expected.
Home LAN
➜ ~ RUST_BACKTRACE=1 ls -l
thread 'main' panicked at 'failed to get the group name', libcore/option.rs:1008:5
stack backtrace:
0: <unknown>
1: <unknown>
2: <unknown>
3: <unknown>
4: <unknown>
5: <unknown>
6: <unknown>
7: <unknown>
8: <unknown>
9: <unknown>
10: <unknown>
11: <unknown>
12: <unknown>
13: <unknown>
14: <unknown>
15: <unknown>
16: <unknown>
17: <unknown>
18: <unknown>
19: <unknown>
run lsd --icon=never
and icons are not shown
run lsd --icon=never | grep something
and the icons appear
.. with the last value counted.
I aliased lsd
with lsd=lsd --icon=never
, then I want icons to print, but:
$ lsd --icon=auto
error: The argument '--icon <icon>' was provided more than once, but cannot be used multiple times
which is not expected. Consider to adopt this same behaviour as ls
?
This options would be presented as followed:
lsd --color=never # never print the colors
lsd --color=auto # print colors only when the output is a tty
lsd --color=always # always print the colors
ls /etc # with a little terminal
Thanks to D__ from reddit for the report.
(This issue was originally created to respond to a display order issue but it seems it was useless. @loewenheim have proposed a great idea about a Layout enum which is not implemented yet and so the subject have changed from the original purpose.)
This option would allow to change de display direction (left-right or top-down)
How to test:
mkdir /tmp/test
touch /tmp/test/executable
touch /tmp/test/non_executable
chmod 644 /tmp/test/non_executable
chmod 777 /tmp/test/executable
lsd /tmp/test # `executable` should be green and `non_executable` should yellow (the default color)
The default gnu ls adds a * at the end of executable files to mark them.
It also colors them differently, and it highlights in red files that have a setuid bit on.
It would be really useful if lsd did that too to mark them easily.
They could also have an icon (assuming the file doesn't have one already) - I'm thinking the dollar icon for an executable, and a # for a suid, but I don't have strong opinions on this.
Most shells have an LSCOLORS
or LS_COLORS
environment variable which allows users to modify which colors are used by LS for different types and states of filesystem objects. It would be excellent if lsd
supported this.
Add a feature which would let users choose the blocks to be displayed. The blocks could be a comma separated list.
Maybe something like:
lsd --blocks permission,size,name
This would just show these blocks. Maybe even show them in that specific order as well.
It would be great to run the tests and have some linters like clippy.
(following the #42 discussion)
The idea is to be able to recognize all the specific filetypes (char devices / pipes / symlinks / etc) by setting some specific icons. The icons are not defined yet.
The current output is:
drwxr-xr-x peltoche users 4 KB Thu Dec 6 00:34:14 2018 src/
.rw-r--r-- peltoche users 8 KB Thu Dec 6 00:29:01 2018 Cargo.lock
The 4KB is the folder size but doesn't give much information as it's not the content size. In order to simplify the output I propose to make the output looks like:
drwxr-xr-x peltoche users - Thu Dec 6 00:34:14 2018 src/
.rw-r--r-- peltoche users 8 KB Thu Dec 6 00:29:01 2018 Cargo.lock
The size is replaced by a dash -
like the exa
program.
#~> lsd -a | wc
thread 'main' panicked at 'failed to retrieve terminal size', /home/yann/.cargo/registry/src/github.com-1ecc6299db9ec823/lsd-0.6.1/src/display.rs:29:21
Expected behavior: properly pipe contents to next program, expecting infinite width (e.g. "0")
#~> lsd -al > test
Test now contains a lot of unprintable characters, e.g. it looks like this:
�[38;5;33md�[0m�[38;5;40mr�[38;5;192mw�[38;5;124mx�[38;5;40mr�[38;5;168m-�[38;5;124mx�[38;5;40mr�[38;5;168m-�[38;5;124mx�[0m �[38;5;230myann�[0m �[38;5;187musers�[0m �[38;5;229m 4 KB�[0m �[38;5;40mWed Dec 5 04:44:57 2018�[0m �[38;5;33m .git/�[0m
�[38;5;33md�[0m�[38;5;40mr�[38;5;192mw�[38;5;124mx�[38;5;40mr�[38;5;168m-�[38;5;124mx�[38;5;40mr�[38;5;168m-�[38;5;124mx�[0m �[38;5;230myann�[0m �[38;5;187musers�[0m �[38;5;229m 4 KB�[0m �[38;5;40mWed Dec 5 04:23:13 2018�[0m �[38;5;33m src/�[0m
�[38;5;33md�[0m�[38;5;40mr�[38;5;192mw�[38;5;124mx�[38;5;40mr�[38;5;168m-�[38;5;124mx�[38;5;40mr�[38;5;168m-�[38;5;124mx�[0m �[38;5;230myann�[0m �[38;5;187musers�[0m �[38;5;229m 4 KB�[0m �[38;5;40mWed Dec 5 04:24:43 2018�[0m �[38;5;33m target/�[0m
�[38;5;184m.�[0m�[38;5;40mr�[38;5;192mw�[38;5;168m-�[38;5;40mr�[38;5;168m--�[38;5;40mr�[38;5;168m--�[0m �[38;5;230myann�[0m �[38;5;187musers�[0m �[38;5;229m 26 B �[0m �[38;5;40mWed Dec 5 04:23:13 2018�[0m �[38;5;184m .gitignore�[0m
�[38;5;184m.�[0m�[38;5;40mr�[38;5;192mw�[38;5;168m-�[38;5;40mr�[38;5;168m--�[38;5;40mr�[38;5;168m--�[0m �[38;5;230myann�[0m �[38;5;187musers�[0m �[38;5;229m 119 B �[0m �[38;5;40mWed Dec 5 04:23:13 2018�[0m �[38;5;184m .travis.yml�[0m
...
Expected behavior: don't print escape/color codes when not outputting to a terminal
terminal_size()
at program startup and cache the result.None
, disable color formatting for all outputsNone
, either set a reasonable default width for text files in print_grid
or just default to print_one_per_line
insteadAs exa is a popular ls replacement in Rust, speed comparison with it would be more interesting than with ruby-based colorls. Right now I have following results on my potato:
$ hyperfine --warmup 10 -i 'exa -Rla ~' 'target/release/lsd -Rla ~' 'ls -Rla ~'
Benchmark #1: exa -Rla ~
Time (mean ± σ): 7.500 s ± 0.087 s [User: 8.835 s, System: 7.809 s]
Range (min … max): 7.396 s … 7.634 s
Benchmark #2: target/release/lsd -Rla ~
Time (mean ± σ): 9.336 s ± 0.038 s [User: 4.607 s, System: 4.672 s]
Range (min … max): 9.283 s … 9.424 s
Benchmark #3: ls -Rla ~
Time (mean ± σ): 1.913 s ± 0.013 s [User: 821.4 ms, System: 1086.9 ms]
Range (min … max): 1.893 s … 1.931 s
Warning: Ignoring non-zero exit code.
Summary
'ls -Rla ~' ran
3.92 ± 0.05 times faster than 'exa -Rla ~'
4.88 ± 0.04 times faster than 'target/release/lsd -Rla ~'
Current behavior is a little bit confusing when printing tree of several dirs:
$ target/release/lsd --tree ~/dir*
├── subdir11
│ ├── file111
│ └── file112
└── subdir12
│ ├── file121
│ └── file122
├── subdir21
│ ├── file211
│ └── file212
└── subdir22
│ ├── file221
│ └── file222
For comparison:
$ exa -T ~/dir*
/home/user/dir1
├── subdir11
│ ├── file111
│ └── file112
└── subdir12
├── file121
└── file122
/home/user/dir2
├── subdir21
│ ├── file211
│ └── file212
└── subdir22
├── file221
└── file222
And can say that printing │
at the beginning of line after last dir entry makes it even more confusing.
This flag should override all the other flag and make the output similar to the classic ls command
It would be useful for the people like me which set the --color=always
into the flags but sometime need the "classic" output in order to work with pipes.
ls --color=always --classic | xargs rm # should work
Consider a directory with broken symlink:
$ mkdir temp && cd temp
$ ln -s `pwd`/a `pwd`/b
Classic ls shows symlink, and, if you enable color, it will show that it is broken.
$ /bin/ls -la
total 8
drwxr-xr-x 2 kuviman kuviman 4096 Dec 13 22:52 .
drwxr-xr-x 9 kuviman kuviman 4096 Dec 13 22:51 ..
lrwxrwxrwx 1 kuviman kuviman 25 Dec 13 22:52 b -> /home/kuviman/temp/a
But lsd
just throws an error
$ lsd -la
cannot access './b': No such file or directory (os error 2)
It doesn't crash as before(#2), but still would be better if broken symlinks were highlighted red like in ls
/tmp/tmp.EHAycWKNJu $ RUST_BACKTRACE=1 lsd --tree | head -n 5
├── example-file-1
├── example-file-10
├── example-file-11
├── example-file-12
├── example-file-13
lsd does not panic. :)
/tmp/tmp.EHAycWKNJu $ RUST_BACKTRACE=1 lsd --tree | head -n 5
├── example-file-1
├── example-file-10
├── example-file-11
├── example-file-12
├── example-file-13
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:700:9
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
at src/libstd/sys_common/backtrace.rs:59
at src/libstd/panicking.rs:210
3: std::panicking::default_hook
at src/libstd/panicking.rs:224
4: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:487
5: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:394
6: std::panicking::begin_panic_fmt
at src/libstd/panicking.rs:349
7: std::io::stdio::_print
at src/libstd/io/stdio.rs:700
at src/libstd/io/stdio.rs:709
8: lsd::display::Display::print_tree_row
9: lsd::core::Core::display_as_tree
10: lsd::core::Core::run_inner
11: lsd::main
12: std::rt::lang_start::{{closure}}
13: std::panicking::try::do_call
at src/libstd/rt.rs:59
at src/libstd/panicking.rs:306
14: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:102
15: std::rt::lang_start_internal
at src/libstd/panicking.rs:285
at src/libstd/panic.rs:398
at src/libstd/rt.rs:58
16: main
17: __libc_start_main
18: _start
Interestingly, this bug seems to be non-deterministic. If I repeat the command multiple times, the process terminates sometimes with and sometimes without a panic.
Just curious if a sort by mod time (ie, ls -t) is in the plan.....
I don't know how much it should be up to lsd to handle this, but when there is a file with invalid encoding in a folder, lsd crashes with
thread 'main' panicked at 'failed to encode file name', libcore/option.rs:1000:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:477
5: std::panicking::continue_panic_fmt
at libstd/panicking.rs:391
6: rust_begin_unwind
at libstd/panicking.rs:326
7: core::panicking::panic_fmt
at libcore/panicking.rs:77
8: core::option::expect_failed
at libcore/option.rs:1000
9: lsd::meta::Meta::from_path
10: lsd::core::Core::list_folder_content
11: lsd::core::Core::run_inner
12: lsd::core::Core::run_inner
13: lsd::core::Core::run_inner
14: lsd::core::Core::run_inner
15: lsd::main
16: std::rt::lang_start::{{closure}}
17: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:310
18: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:103
19: std::rt::lang_start_internal
at libstd/panicking.rs:289
at libstd/panic.rs:392
at libstd/rt.rs:58
20: main
21: __libc_start_main
22: _start
(following the #65 discussion)
This flag should work as the --color option
As title.
How to test:
mkdir /tmp/test
mkdir /tmp/test/dir
touch /tmp/test/file
chmod u+s /tmp/test/dir /tmp/test/file
lsd /tmp/test # `file` and `dir` should be printed with a red background
In the current stats the ls print the files starting from left to right but the default ls print its content in the top down direction
error[E0658]: access to extern crates through prelude is experimental (see issue #44660)
It's seems to be an issue with the time package.
Thanks to cheapmon from reddit for the report.
I noticed this in my Downloads folder, which has a lot of files.
The error only occurs when calling lsd
without arguments or with -a
. Any other combination of arguments seems to work.
Backtrace:
#~> env RUST_BACKTRACE=1 lsd
thread 'main' panicked at 'failed to print the grid', libcore/option.rs:1000:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:477
5: std::panicking::continue_panic_fmt
at libstd/panicking.rs:391
6: rust_begin_unwind
at libstd/panicking.rs:326
7: core::panicking::panic_fmt
at libcore/panicking.rs:77
8: core::option::expect_failed
at libcore/option.rs:1000
9: lsd::display::Display::print_outputs
10: lsd::core::Core::run_inner
11: lsd::main
12: std::rt::lang_start::{{closure}}
13: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:310
14: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:103
15: std::rt::lang_start_internal
at libstd/panicking.rs:289
at libstd/panic.rs:392s
at libstd/rt.rs:58
16: main
17: __libc_start_main
18: _start
On small SBC systems, lsd
would be extra useful since a lot of interaction happens via ssh
and the console on these systems. An ARM target would be helpful to ease the install.
No ARM target is available, lsd
needs to be build from source, probable issues present
following #42 discussion.
This flag should have the same behavior that the classic ls -F
:
-F, --classify append indicator (one of */=>@|) to entries
@ means symbolic link (or that the file has extended attributes).
* means executable.
= means socket.
| means named pipe.
> means door.
/ means directory.
mkdir /tmp/test
touch /tmp/test/foo
ln -s /tmp/test/foo /tmp/test/bar
lsd -l /tmp/test
Thanks Gisleburt from reddit for the report
For now the project is badly covered by the tests. It can be greatly improved.
It seems like the colors that lsd uses are hard coded. It'd be awesome if it supported custom colors.
I'd love to develop a theme that uses colors for file names and shades of gray for everything else - lighter shade for more recent dates and larger file sizes.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.