Feels like there are a lot of fancy human-used terminal listing tools these days, and to me all of them feel like a waste of time.
1) There's so many assumptions made about the terminals and fonts these will run in. Are you really using emojis in your terminal workflows? And if so, why? do you sacrifice monospace for it? do you expect the tool to work on a new system (or remote system)?
2) What are you missing in ls? Can your tool even do all that ls can? If you need to sift through a lot of files, why are you listing files in the terminal? Why not use a search tool, terminal or graphical.
3) Your tool is not mandated by POSIX, ls is. ls will survive as long as we have Unix-like OSes, it will always be available in all Unix-like OSes. Your tool will survive as long as the maintainer feels like maintaining it.
In the end, if someone wants to develop an ls-like tool just to get the experience of designing, developing, and maintaining software, I'm all for it. But the technical reasons for adopting this are slim to none.
I do also want to say that a more structured API for machine readable listing of files and certain attributes could be very useful (mime type, project specific file type data, e.g. OpenAPI schema lookup, special magic bytes, etc), but that that is a different type of project than these yassified ls clones.
1) Except it doesn't work on the standard set of terminals installed on most systems. SSHing into some vanilla flavored system (a VPS on AWS/linode, <insert company>'s internal servers, your raspberry PI) and using these tools does not work out of the box on any system
2) What _exactly_ is the use case?
3) If you can install non-posix tools, why not use a full-featured file manager? And if there is no use-case for a program, why am I installing more custom software on my system. ls is already installed, you still have to convince me that installing a less portable version of ls is worth more than the trouble of an additional dependency
P.S. regarding 3, I would not point this out if you had not claimed my post was "Some strawman arguments", but: your 3) is an actual strawman argument. You have created a strawman version of me that you are hinting only uses POSIX programs.
P.P.S. there is a real feature that would be useful for an ls-like program, which is listing directories with a huge number of files. Standard implementations of ls cannot handle reading directories with millions of files (even though the filesystem could) because of a misconfigured buffer size:
http://be-n.com/spw/you-can-list-a-million-files-in-a-direct...
Generally shouldn’t ssh into production servers. Exceptions can use ansible if needed. Simply not caring they are different is an option too, if a small fraction of time.
1) There's so many assumptions made about the terminals and fonts these will run in. Are you really using emojis in your terminal workflows? And if so, why? do you sacrifice monospace for it? do you expect the tool to work on a new system (or remote system)?
2) What are you missing in ls? Can your tool even do all that ls can? If you need to sift through a lot of files, why are you listing files in the terminal? Why not use a search tool, terminal or graphical.
3) Your tool is not mandated by POSIX, ls is. ls will survive as long as we have Unix-like OSes, it will always be available in all Unix-like OSes. Your tool will survive as long as the maintainer feels like maintaining it.
In the end, if someone wants to develop an ls-like tool just to get the experience of designing, developing, and maintaining software, I'm all for it. But the technical reasons for adopting this are slim to none.
I do also want to say that a more structured API for machine readable listing of files and certain attributes could be very useful (mime type, project specific file type data, e.g. OpenAPI schema lookup, special magic bytes, etc), but that that is a different type of project than these yassified ls clones.