Lsd: Request: Enable --tree to be used with --directory-only (-d)

Created on 1 Nov 2019  ยท  15Comments  ยท  Source: Peltoche/lsd

lsd 0.16.0

Expected behavior

# "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

kinenhancement

Most helpful comment

I'd like to call for this to be re-opened. ๐Ÿ“‚

Conflict-Free

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?

More Consistent

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.

All 15 comments

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

Screenshot 2020-03-29 at 00 15 55

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

  1. Only list directories, not files
  2. Only list the directory specified (which, imo, seems a little pointless?)

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. ๐Ÿ“‚

Conflict-Free

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?

More Consistent

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:

  • [ ] Update -d option
  • [ ] if -d is set and the meta is not a directory, skip the inner display display.rs#L125

Does 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:

  1. lsd -d should function the same as ls -d
  2. lsd --tree -d should function the same as tree -d

I 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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jcassee picture jcassee  ยท  5Comments

augustobmoura picture augustobmoura  ยท  5Comments

lez picture lez  ยท  3Comments

meain picture meain  ยท  8Comments

EppO picture EppO  ยท  3Comments