Display directories with trailing slashes

[rockandska]

HI,

It will be great if there will be a possibility to have directories displayed with a trailing "/" (as an option or not).
When you don't use colors, there is no way to distinct directories from files.

Regards,

[sharkdp]

Thank you for the feedback.

I don't think there is any precedent for this (ls or find). I'd rather not add a trailing slash to directory names.

[tavianator]

There is precedent in ls -p

[sharkdp]

There is precedent in ls -p

Thanks, I didn't know that.

My main point is that I'd rather not add a command-line option for something minor like this, as I really strive to keep the CLI small. So the question becomes: Do we want to add a trailing slash by default? (I'd rather not). If we don't, should there be some other way to make this possible (e.g. a more generic --output-format option)? I currently don't see the need for this.

Silly workaround 😄:

fd … -x ls -p

[rockandska]

In my opinion, if fd should be an alternative to find (gnu?), it should be able to reproduce the same behaviour at the maximum :) and if you would like to add a trailing slash to directories with find (gnu) you could by chaining -type / -printf.
For example:

find . \( -type d -printf '%p/\n' -or -printf '%p\n' \)

And parsing ls ouput is indeed a silly workaround ^^

[sharkdp]

And parsing ls ouput is indeed a silly workaround ^^

fd … -x ls -p does not parse the output of ls. It executes ls -p for every search result and directly shows the ls output. It's not a great solution because it spawns a subprocess for every search result. But it works perfectly fine.

Arguably, using find . \( -type d -printf '%p/\n' -or -printf '%p\n' \) is worse. It's not only much longer to type, it can also not be used as an alias (I believe), because you can not simply append filtering criteria like -name '…'.

In my opinion, if fd should be an alternative to find (gnu?), it should be able to reproduce the same behaviour at the maximum :)

I'm assuming you mean "… at the minimum".

The very first paragraph in the README explicitly says: "fd […] does not seek to mirror all of find's powerful functionality […]". So no, even if find would support this out of the box, we are not necessarily aiming to support this as well.

[sharkdp]

I'd like to close this. Let me know if there is anything left that should be discussed.

[blueforesticarus]

"tar -tf" shows trailing slashes
I'm trying to diff the contents of my tar with the contents of a directory, but only common files

tar -f backup.tar --diff --directory mydir -T common.list

If common.list contains folders, they must have a trailing slash, otherwise tar will complain "./dir Not found in archive"
EDIT: it seems this is not standard behavior, and tar normally accepts the lack of trailing slash fine...

In most scripting use cases, controlling whether you get the trailing slash is important. It is pretty easy to delete the trailing slash with regex, but there is no good way to add the trailing slash without checking the filesystem again to see what is a dir and what isn't. Without the trailing slash, the output of fd is actually missing information, there is no good way to add the trailing slash without checking the filesystem again to see what is a dir and what isn't. Either this should be an option, or it should be the default.

[tmccombs]

Another workaround:

fd -t d -X printf "%s/\n" '{}' & fd -t f -t l 

(although, I think that might miss non-regular, non-link files)

[sharkdp]

In most scripting use cases, controlling whether you get the trailing slash is important. It is pretty easy to delete the trailing slash with regex, but there is no good way to add the trailing slash without checking the filesystem again to see what is a dir and what isn't.

If you are not sure if something is a file or a directory.. you probably also don't care if it has a trailing slash or not. It's not like you can append to the path, for example. Because it could be a file.

It would be great if you could describe a real world use case where you would find the trailing slash useful. I would suspect that most use cases actually lead to a --type=directory/-td search where all results are directories anyways.

Without the trailing slash, the output of fd is actually missing information, there is no good way to add the trailing slash without checking the filesystem again to see what is a dir and what isn't.

True. But as I pointed out above, so do most other programs. That's not necessarily a good reason, but I guess it shows that there aren't too many use cases that would require a trailing slash.

[sersorrel]

fwiw, a real-world use case I've literally just come up with is a script that post-processes the output of fd to add links; obviously it's easy to just take a whole line and transform it into a link, but it would be nice if, for files, I could make the directory-name part of the line link to the directory (e.g. to open in a file manager), and the filename part link directly to the file. As things stand, files and directories are differentiated by colour, but not by anything else, so I'd have to either rely on parsing the colour escape sequences (fraught, since they come from $LS_COLORS) or call stat() for every line of the output to work out whether it's a file or not.

Given that the difference between files and directories (and executables, symlinks, ...) are already illustrated with colour, it would be nice to make those differences accessible to scripts as well, like ls -p or ls -F.

(also, apart from anything else, I just like seeing trailing slashes on directories? it makes them more visually distinct from files, so I have ls -F aliased to ls in my shell.)

[tmccombs]

I'm not saying this is a good solution, but in a scripting environment, you could set LS_COLORS to something you know how to parse.

[sharkdp]

I'm going to reopen this. Please vote with 👍 (you would like to see trailing slashes for directories by default) and 👎 (you would rather not see trailing slashes) on this comment to indicate your preference. I think I'm inclined to add this to fd by default. I don't really see any drawbacks. If anyone does, please write a comment.

What I would vote against is having a new command line option for this.

Compare:

[blueforesticarus]

On balance, getting rid of the / is easy: | rg '/$' -r ''
I think it is a good default, but changing it will definitely break things for some people.

If you do make a cmd arg, it should probably be a more general "output format" type thing

[sharkdp]

I'm not saying that it doesn't, but .. in which reasonable scenario would it really break things?

Another thing to worry about is the --exec commands.

[blueforesticarus]

For an example. I currently have scripts in which the output of fd is compared to the output of tar -t and I strip the trailing slashes from the tar output because fd currently doesn't print them.

Basically any situation where you compare fd's output to something else will have to be corrected.

... now that I'm thinking about it, It might break alot of my stuff, god only knows.
I wouldn't be surprised if it stopped Xorg from starting.
But most people's OS isn't ducked taped togeather with fd and ripgrep, so I think you are fine.

[sharkdp]

Basically any situation where you compare fd's output to something else will have to be corrected.

Right. That's actually a good point.

[luukvbaal]

I'd very much like to see this added. Use case is to prepend icons with this iconlookup script I wrote. Using the -F flag from tree and ls I'm able to distuingish directores, sockets, executables, doors and FIFO's as per tree manpage:
-F Append a '/' for directories, a '=' for socket files, a '*' for executable files, a '>' for doors (Solaris) and a '|' for FIFO's, as per ls -F.

Would be great to see this functionality in fd for use with fzf.

[PatrickF1]

I think I'm inclined to add this to fd by default. I don't really see any drawbacks. If anyone does, please write a comment.

Pro: helps identity directories if color is ever disabled
Con: IMO the / at the end is a bit ugly. What if the / was also colorized?

[sersorrel]

I feel that the trailing / should not be coloured, since e.g. ls -F colours the filename but not the /.

[sharkdp]

How about someone tries to implement this so we can see how it would look like? I think it shouldn't be too hard.

[sharkdp]

Adding this to the "fd 9" milestone. Which doesn't necessarily mean that we implement this. But I want to settle this question.

[yyogo]

Just thought of something: GNU ls has the --indicator-style flag:

‘--indicator-style=word’
    Append a character indicator with style word to entry names, as follows:
    ‘none’
        Do not append any character indicator; this is the default. 
    ‘slash’
        Append ‘/’ for directories. This is the same as the -p option. 
    ‘file-type’
        Append ‘/’ for directories, ‘@’ for symbolic links, ‘|’ for FIFOs, ‘=’ for sockets, and nothing for regular files. This is the same as the --file-type option. 
    ‘classify’
        Append ‘*’ for executable regular files, otherwise behave as for ‘file-type’. This is the same as the -F or --classify option. 

Maybe it would be better to add something similar instead of just the path separator?

[rk3141]

Could i try working on this issue?

[yyogo]

@Rishit-Khandelwal there's already #812 (just for the trailing slashes, not --indicator-style, you can use it as a reference for that though)

[rk3141]

So should i work on --indicator-style instead?

[FilipeBento]

Hello, I am fairly new to github issues. I am just curious to know if this is under development right now. To be honest, my use case is different. When I use fd with fzf, I use the CTRL-T command which lists everything recursively, files and dirs. It's hard to distinguish files from dirs. the / at the end would be help greatly. I understand my use case is very specific. Let me know if this is going to be implemented or if you're aware of a workaround. Happy New Year! :)

[sharkdp]

This is being worked on in #812, as described above.

[FilipeBento]

Thank you for your response and your work, David.

…

On Sun, Jan 23, 2022, 12:15 David Peter ***@***.***> wrote: This is being worked on in #812 <#812>, as described above. — Reply to this email directly, view it on GitHub <#436 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWMCNMYPWPUDCSDP4AG3EDUXPWNZANCNFSM4HLGE3TQ> . You are receiving this because you commented.Message ID: ***@***.***>

[sharkdp]

closed in #812.