lsd 0.16.0
# "real" tree:
tree -d
.
โโโ ci
โโโ src
โโโ meta
3 directories
md5-8d21e6552b7c547b8a2d2fc1718f272f
.
โโโ ๏ ci
โโโ ๏ src
โโโ ๏ meta
## Actual behavior
```bash
lsd --tree -d
error: The argument '--tree' cannot be used with '--directory-only'
USAGE:
lsd --blocks <blocks>... --color <color>... --date <date>... --directory-only --group-dirs <group-dirs>... --icon <icon>... --icon-theme <icon-theme>... --size <size>... --tree
For more information try --help
With an exit code 1
Hi @AndydeCleyre, thanks for the report.
At first glance this should be easily fixed. I look into it now.
I'm not sure if the expected behaviour here is valid
For instance, with --directory-only I get

Going by the help string for -d:
-d, --directory-only Display directories themselves, and not their contents
So I guess the name of the flag is a little ambiguous, if anything. It could be taken to mean
If 1, then it seems like --directory-only might need fixing (as per my example above - I do have a lot inside of ~/src!)
Otherwise I don't think this issue is valid, though maybe the docs could do with an adjustment.
@elliebike I am not sure why this is a thing, but -d is supposed to display the directory that is provided. The behavior seems to be consistent with ls.
I don't think -d in tree has the same meaning as -d in ls.
Alright, this means I can't alias tree to lsd --tree directly. FWIW, for anyone else looking to achieve something like that, I'm now using this in my Zsh profile:
if (( $+commands[lsd] )); then
alias ls="lsd"
tree () {
local depth dirsonly
while [[ $1 == -L || $1 == -d ]]; do
if [[ $1 == -L ]]; then
depth=(--depth $2)
shift 2
fi
if [[ $1 == -d ]]; then
dirsonly=1
shift
fi
done
if [[ $dirsonly ]]; then
lsd --tree $depth --icon always --color always $@ | grep ๏
else
lsd --tree $depth $@
fi
}
else
alias ls="ls --color=auto"
alias tree="tree -C"
fi
Just thought I would share it here. The -d flag is so that you can do lsd folder-with-folders-starting-with-lot-of-letters/a* -d to get the list of dirs starting with a. Otherwise it will print out the contents of the dirs starting with a.
I'd like to call for this to be re-opened. ๐
I don't see why lsd --tree -d and lsd -d can't co-exist.
Certainly if the command can detect that they _can't_ be used together, then it could adjust some state inside to allow for the expected behavior, right?
The behavior seems to be consistent with ls.
Allowing this behavior would _NOT_ make it _inconsistent_ with ls, and _would_ make it consistent with tree.
Since ls does not have --tree, we have no reason to expect that the behavior of lsd --tree -d would be to throw an error in the same way that ls --tree -d throws an error.
However, since lsd does have --tree, we have every reason to expect that it _would_ behave consistently with itself, and with tree.
Just peeking around the code, it looks like this would only need a few changes:
-d optionDisplayDirectoriesOnly to enum flags.rs#L244Display flags.rs#L47-d is set and the meta is not a directory, skip the inner display display.rs#L125Does that sound right?
@Peltoche Would you mind weighing in on this proposal? ^^
I would be willing to provide a PR for this.
@coolaj86 The feature in itself would be a good addition, but I don't think -d as the flag for it might be the best option.
-d's long version should have been --directory (this is what it is in gnu ls) in that it prints the dir instead of contents. Having the long flag as --directory-only I believe is the reason for some of this confusion.
I think we could probably have another flag --only-dirs and have the same thing usable for both normal ls or ls --tree.
@meain These are my concerns:
lsd -d should function the same as ls -dlsd --tree -d should function the same as tree -dI think it would be great to retro-actively add the --directory alias for compatibility with ls.
I do not think it would serve well to break compatibility with tree.
My goal here is to have lsd as a drop-in replacement for the general use case of tree in the same way that it's a drop-in replacement for the general use case of ls.
Do we agree or disagree?
@coolaj86 I see your point in keeping in consistent with tree, that makes a lot of sense.
Since we are currently erroring out with --tree -d, I don't think we will be taking away anything either.
Also, adding --directory would be a good addition too. Thanks.
I'm proposing this as a mob programming session for the Utah Rust meetup in November or December. If someone wants to PR it before then, feel free, but if not I think that we'll do it.
Tonight is the night.
@coolaj86 There is actually an open PR for this right now #426. It is almost complete. However there are a few good-first-issue items that I think could be tackled.
@meain we re-implemented it as an exercise and then I rebased from that PR.
Reading through we didn't quite understand: What's wrong with that PR? It doesn't have YAML tests? I'm not quite clear on how to create the yaml test myself.
Most helpful comment
I'd like to call for this to be re-opened. ๐
Conflict-Free
I don't see why
lsd --tree -dandlsd -dcan't co-exist.Certainly if the command can detect that they _can't_ be used together, then it could adjust some state inside to allow for the expected behavior, right?
More Consistent
Allowing this behavior would _NOT_ make it _inconsistent_ with
ls, and _would_ make it consistent withtree.Since
lsdoes not have--tree, we have no reason to expect that the behavior oflsd --tree -dwould be to throw an error in the same way thatls --tree -dthrows an error.However, since
lsddoes have--tree, we have every reason to expect that it _would_ behave consistently with itself, and withtree.