We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
GNU ls uses ls --l as a shortcut for --literal:
ls
ls --l
--literal
$ ls --l aa.txt foo.8b79 foo.eWmR hello.txt test_dir $ ls --literal aa.txt foo.8b79 foo.eWmR hello.txt test_dir
uutils ls, on the other hand, uses ls --l as a shortcut for --long (our extension to GNU ls):
--long
$ cargo run ls --l total 12 -rw-r--r-- 1 dho dho 2 Apr 10 16:04 aa.txt -rw------- 1 dho dho 0 May 16 09:31 foo.8b79 -rw------- 1 dho dho 0 May 16 09:22 foo.eWmR -rw-r--r-- 1 dho dho 12 Jun 21 14:51 hello.txt drwxr-xr-x 2 dho dho 4096 Jun 21 11:54 test_dir $ cargo run ls --literal aa.txt foo.8b79 foo.eWmR hello.txt test_dir
The text was updated successfully, but these errors were encountered:
@cakebaker, what is your preferred solution here? Should we remove --long?
Sorry, something went wrong.
I don't have a preferred solution here and the proposed solution in the PR looks good to me.
I think we should make the decision whether to remove --long independent of this issue. And because it is tested and documented, I tend to keep it.
I was thinking it's a bit confusing as it is now with the workaround. But I do like having --long too, so I guess we'll keep it for now.
Successfully merging a pull request may close this issue.
GNU
ls
usesls --l
as a shortcut for--literal
:uutils
ls
, on the other hand, usesls --l
as a shortcut for--long
(our extension to GNUls
):The text was updated successfully, but these errors were encountered: