Show HN: I made an ls alternative for my personal use
github.com
github.com
While these may be sufficient for a naive developer, this oversight then breaks many downstream tools.
Again though, thanks for sharing. Bringing your own spin and ideas into the world can be anxiety inducing and I'm pleased you went about this in a helpful and measured way!
The software is provided as is, in the hope it will be useful, but without any warranty whatsoever.
All free and open source software licenses contain some version of the above statement.
All of this is implicitly for personal use. In the sense that it's not a product, just something people made because they needed a problem solved.
However, this is a website of opinions, and gp's opinion is valid, because this forum is where opinions go. It's not as though gp said to stop doing this project.
This pedantic finger wagging is just so rote.
These hidden "expectations" that people seem to have regarding free and open source software can be incredibly demoralizing. It's something I wish would change. That's why I commented on it.
Taking this to a logical conclusion; If a plumber/lawyer/<professional> offers services for free, and those services end up killing, or massively damaging someone, can they just say the same thing to absolve themselves of all liability?
I also wish to change things, in the opposite direction. FOSS devs should explicitly mark things as not-for-prod; rather than pushing things as prod-ready when they aren't. I think some kind of change will come upon FOSS in the future so people can rely on it, and sadly I think that change will be adoption by corporates (w/ legal budgets) rather than the FOSS devs/ORGs themselves becoming more mature.
There is a world of difference between what professionals such as doctors do and what free and open source developers do. It's not even remotely the same. I know because I happen to be both.
And even if they were in any way comparable, professionals get paid handsomely precisely because of the liability and responsibility. If people want this out of free software developers, they should start paying them some serious money.
> I also wish to change things, in the opposite direction.
If you want this, hire a professional to do it for you instead of pushing unwanted responsibility and liability onto the rest of us. I've got more than enough of that at my actual job and I absolutely do not want it in my free software development hobby. Adding liability to free software will kill it.
> FOSS devs should explicitly mark things as not-for-prod; rather than pushing things as prod-ready when they aren't.
It already is. Everything under a free or open source software license is already marked as such. The license says so. You use it at your own risk. Up to you to determine if that's good enough for you to use in production.
You are right - there is less in the way of personal liability in the case of devs (but for the odd PII here and there), Precisely why I think there will be a disruption coming.
> professionals get paid handsomely precisely because of the liability and responsibility
Devs are, or can also be, well-paid 'professionals'. And all are still capable of free, pro-bono work.
> instead of pushing unwanted responsibility and liability onto the rest of us
I'm not sure what you think I said..
"rather than pushing things as prod-ready when they aren't"
Is wrt the promotion of something as ready-for-production.
I'm not addressing the legal status as dictated by the (unproven) licence, which isn't relevant wrt liability anyway.
One says that open source projects should clearly state when they are not meant as a serious replacement for standard tools. The other says that they disagree and that open source projects don't have to give any warning.
I guess I am a little in-between: if you open source your code, I don't think you have anything to do (it's already nice to put an open source license on it). If you advertise your open source tool (e.g. on this website), then it is polite to set expectations.
Feature-request: bring back clickable ls results!
Bonus points for defining a new term type and standard for this.
> Feature-request: bring back clickable ls results!
$ man ls | grep '\--hyperlink' -A 1
--hyperlink[=WHEN]
hyperlink file names WHENYou see, Genera knows the actual type of everything that is clickable. When a program needs an input, objects of the wrong type _lose their interactivity_ for the duration. So if you list the files in some directory, the names of those files are indeed links that you can click on. Clicking on one would bring up a context menu of relevant actions (view, edit, print, delete, etc). If a program asks for a filename as input then clicking on a file instead supplies the file object to the program. Clicking on objects of other types does nothing.
I have this side-project fantasy of a very simple terminal pipe-types project. The basic idea is a set of very basic standardized types, demarcated using escape sequences. Dates, filenames, URLs, numbers, possibly one or two number units as well (time periods, file sizes only).
Tools that already produce columnar data (ls) get a flag that lets them output this format, and tools that work with piped data (cut, sort, uniq) get equivalents or modes that let them easily work with this.
Essentially, simple typed tables held in text, with enhancements for existing tooling to know how to deal with it. Would make my day-to-day on the command line much easier.
But note that on the Lisp Machine/Genera, every type has a presentation and can be “printed” to the REPL. This includes any new classes that you create as part of your own programs. It’s not just a small list of standard types, but every type.
The standard tutorial for the system is to implement Conway’s Game of Life. It has you create a class to hold the game board and then guides you through the process of defining a presentation for it so that the it can be displayed easily.
...glom on to this: "+JSONSchema" with some sort of UNIX-ish taxonomy. Everything from `man test`, add in `man du`, `date`, `... ago` (relative time) as you'd mentioned.
`jc ls | add_schema...` => `jq ...`
...or `jc ls --with-schema | jq ...`
(it appears as though `jc` already supports schema's, so perhaps it'd be `jc ls --with-types` or something, but there's your starting point!)
https://news.ycombinator.com/item?id=40100069
"prefer shallow arrays of 'records', possibly with a deeply nested 'uri'-style identifier"
...the clutch result is: "it can be loaded into a database and treated as a table".
The origin of this technique for me was someone saying back in 2000'ish timeframe (and effectively modernized here):
sqlite-utils insert example.db ls_part <( jc ls -lart )
sqlite3 example.db --json \
"SELECT COUNT(*) AS c, flags FROM ls_lart GROUP BY flags"
[
{
"c": 9,
"flags": "-rw-r--r--"
},
{
"c": 2,
"flags": "drwxr-xr-x"
}
]
This particular example is "dumb" (but ayyyy, I didn't get a UUOC cat award!) in that you can easily muddle through it in different (existing pipeline) ways, but SQL crushes the primitive POSIX relationship tooling (so old, ugly, and unused they're tough to find!), eg: `comm`, `paste`, `uniq`, `awk`
See also:
* NuShell (https://www.nushell.sh/)
You should be able to get this to work on Unix with plan9port.
Efficient file listing: Optimized for speed, even in large directories
What exactly is it doing differently to optimize for speed? Isn't it just using the regular fs lib?
Checkout the man page: https://www.mankier.com/1/gio
highlights:
- showing progress in `cp` equivalent
- Easy cli interface to freedesktop trash (!)
- tree command
- filesystem changes monitor (inotify wrapper)
This is basically a Show HN without a summary I think.
fwiw:
I wonder if it was always like this or we're getting further and further from the idea of keeping programs simple and open.
This project in particular is not being sold as a drop-in replacement for ls.
This tool by triyanox -- just from the screen shot if you click through -- will also colorize permission masks and sizes, dates, user & group.
Two settings for ls make some of the colouring less useful to me.
BLOCK_SIZE='1 formats sizes in bytes with comma separators. TIME_STYLE=long-iso formats the dates sensibly.
This means entries line up in neater columns.
-rwxr-xr-x 1 root root 852 2024-02-23 22:31 zsh5
-rwxr-xr-x 1 root root 1,022,760 2024-08-09 04:33 zstd
lrwxrwxrwx 1 root root 4 2024-08-09 04:33 zstdcat -> zstdIn `lc`, mentioned a bit this thread, you can actually color the age like a "heat map" if you want. I.e. more recent times are more toward the red side of the rainbow and older ages toward the other "cooler" side ("cold storage"). Or whatever color scheme you like. So, if you know you're looking for something recent, the color pops out at you. If you like that kind of thing.
Among a few things it does that `ls` (and other alternatives like `eza` don't do) are: - icons (SVG icons in terminals that support it, Nerd Fonts otherwise) - advanced filtering using regex - advanced sorting across multiple sort bases - styles and colors using customisable rules
For someone wanting to make the output of `ls` prettier (with a few extra bells and whistles) without having to relearn a new workflow, something like an `ls` replacement makes more sense.
[1]: https://pls.cli.rs [2]: https://dystroy.org/broot/
`eza --long --hyperlink --header --all --icons --git --sort name`
also the hyperlink thing is useful
I see a screenshot that looks like the output of ls, ok it has colors, and some filenames have "!!" behind it. Great success?
While I like it and it's a good idea, I think the reality is that developers capable enough to write shared library/DLL plugins are more likely to just submit PRs and make such stuff built-in but maybe optional.
> more likely to just submit PRs and make such stuff built-in but maybe optional.
Which are more likely to just be rejected by the more conservative maintainers of the tool. That's the empowering beauty of plugins - no such barriers
[1]: https://pls.cli.rs
What good is a ls alternative if I need to install it everywhere I need ls? I'd prefer using the standard ls even if it is not ideal. But maybe that's just me.
(Thinking it was Ubuntu server, but guessing someone will correct me)
Nowadays, and possibly for the better (every line of code is a potential bug and every bug is a potential vulnerability) it seems like systems don’t want to include this sort of stuff. So, I’m sure if the decision were made today, tmux or screen, tmux would win. Unfortunately, “none” seems like the real future option…
I spend maybe 1% of my working hours (being generous) using `ls` and something like 50% (likely more) using my editor.
If there is some alternative to `ls` that makes my `ls` workflows 2x faster, my productivity increases by 0.5%. If I use a sub-optimal editor that makes my workflow 2x slower, I lose 25% of my productivity.
When I need to login to a remote box, I am also very likely to need to use `ls` since I am less familiar than on my own machine, whereas I am unlikely to do any sort of heavy development work (typically I just need to edit a couple configuration files, or do some git operations).
Imagine a car mechanic that won't use a big hydraulic lift that hoists a car in seconds and lets him walk under it, claiming that by using a manually cranked portable jack, he can be almost as productive when fixing something by the roadside with emergency equipment as he is in his garage.
If you ever meet such a mechanic you can be sure that he programs computers as a hobby.
I developed on SCO (and, later, Unixware) on a PC, all of the clients were running the gamut of Unix OSes: HPUX, DGUX, AIX, SunOS, you name it.
Most of the time was spent on our box in the office, but I was constantly bouncing back and forth to client systems. Either on site, or over the modem. Having to juggle Termcaps and the whole thing. It was polyglot machine/OS world back then.
Just had to learn to get the best out of a baseline set of Unix tools. vi instead of emacs, awk instead of perl. Master those and never be left wanting on a new environment, so I can hit the ground running. No need to "bootstrap" (if the client would even let you, not always). Couldn't even rely on a C compiler.
This doesn't mean there's no value in developing one's own tools. Contributing to other projects can be quite difficult and time consuning. GNU projects are even more so.
We shouldn't limit ourselves to POSIX stuff either. Better software and tools can and should be built. Every attempt is valuable. And who knows? It might just turn into a staple of Linux distributions some day.
man dir_colors
But recently, there were two submissions here that actually turn the "rewrite in Rust" meme into something substantial.
The two factions of C++ https://news.ycombinator.com/item?id=42231489 On "Safe" C++ https://news.ycombinator.com/item?id=42186475
Be warned that the second one is a really long read!
For reference, those are the ones I am familiar with. They are somehow active in contrast to things like exa which is not maintained anymore.
eza: (https://github.com/eza-community/eza)
lsd: (https://github.com/Peltoche/lsd)
colorls: (https://github.com/athityakumar/colorls)
g: (https://github.com/Equationzhao/g)
ls++: (https://github.com/trapd00r/LS_COLORS)
logo-ls: (https://github.com/canta2899/logo-ls) - this is forked because main development stopped 4 years ago.
Any more?
Personally I prefer eza and wrote a zsh plugin that is basically aliases that matches what I have from my muscle memory.
I guess this is a mini lament that many of these tools are moving away from the Unix philosophy of do one thing well, and make it easy to chain.
And a last very small lament that BeOS didn’t succeed, and their filesystem-as-a-database approach didn’t become more standard.
It does indeed also include other functionality that might traditionally be left to other tools (like filtering files). But this is nothing that GNU grep wasn't already doing itself anyway.
IMO, it's better to view the Unix philosophy as a means to an end and not an end to itself. And IMO, it's important to weigh the benefits of coupling to the user experience.
it won't be a means to an end any more if you don't preserve it, so not breaking that aspect of it has to be one of your ends. if you use it to take ls to a new place but that place is not within the ecosystem, it will be an evolutionary dead end, or worse, the first meteor in the meteor storm that ends all life.
current/traditional unix may not be the be-all/end-all, but replacing it/changing it requires viewing it comprehensively and changing all the tools at once or having a plan to. A good example of this is Plan9
it is an end to itself. the reason it's a means to an end is because that was its end goal. in being a means to an end, it is an end (its end) unto itself, opposite to what you said, imho
> in being a means to an end, it is an end (its end) unto itself
This either makes zero sense or is vacuously true and clearly not in conflict with what I'm saying.
The point is that many pay lip service to the Unix philosophy as if it were an end. But it isn't.
Headings on when isatty and off when piping the output put me off when I first tried ripgrep. I don't expect the tools to change their output format on me.
Luckily, you made this behavior configurable, so I'm a happy convert now.
You probably do! If you've ever used `ls`, then it does exactly this.
I meant the "shape" of the output. It just doesn't follow the principle of least surprise.
edit: you probably meant the columns. I forgot about that, I haven't parsed ls(1) output in ages ;)
I would be quite surprised if you didn't rely on this without even knowing it. Even a simple `ls | wc -l` relies on it.
I say this because it's tiring to see folks lament about this feature in ripgrep as if it's something new that ripgrep does. It's not. It's a well established idiom among Unix command line tools.
No. To quote that article
> A bunch of C functions are now encouraged to report EILSEQ if the last component of a pathname to a file they are to create contains a newline
This, yes, makes newlines in filenames effectively illegal on operating systems strictly conforming to the new POSIX standard. However, older systems will not be enforcing this and any operating system which exposes a syscall interface that does not require libc (such as Linux) is also not required to emit any errors. The only time even in the future that you should NOT worry about handling the newline case is on filesystems where it's is expressly forbidden, such as NTFS.
> However, older systems will not be enforcing this
Eventually, newlines in filenames will go the way of /usr/xpg4/bin/sh.
I'd like to note that up until this point, there hasn't (and isn't) been a fully POSIX compliant way to do many shell operations on newline containing filenames. They are already effectively unsupported, and the standard that adds support also discourages them from being created and used. The best way to handle them up until this point has been to not use sh(1).
So, ls can be chained very nicely, which I do every day, even without thinking.
You don't need to have a "structured data with fields" to parse it. You just need to think it like a tabular data with line/column numbers (ls -l, etc.) or just line numbers (ls -1).
So, as long as ls does one thing well, it's alright.
Ah, some of the "enhanced" ls tools can't distinguish between pipe and a terminal, and always print color/format escape codes to pipe too, doubling the fun of using them. So, thanks, I'll stick with my standard ls. That one works.
You do if you want to have nice things like being able to format your output without having to worry about breaking the dumb tools down the pipe, which can't sort the numbers they don't see:
- 2.1K (this isn't the same as the second) - 2.1K - 2.1M
Also, why do I need to count columns like a cave man in 'sort -k 5' instead of doing the obvious "sort by size"?
> print color/format escape codes to pipe too
A problem that would disappear with... structured data!
> Ah, some of the "enhanced" ls tools
so use the other "some" that can?
Then you sort at the point you can see the numbers and discard them later.
> Also, why do I need to count columns like a cave man in 'sort -k 5' instead of doing the obvious "sort by size"
awk can sort the columns for you. Plus, ls can already sort by size. Try "ls -lS " for biggest file first, or "ls -lSr" for smallest file first. Add "-h" to make human readable.
> A problem that would disappear with... structured data!
No. A problem that would disappear with "a small if block which asks which environment I'm in". If you're in a shell "-t" test in sh/bash will tell you that. If you're coding a tool, there are standard ways to do that (via termcap IIRC). Standard UNIX tools are doing this for decades now.
IOW, structured data is not a cure for laziness...
> so use the other "some" that can?
Yes, because their authors are not that lazy.
This sort of human overhead is only needed to compensate for the deficiencies of the data structures
> ls can already sort by size
That's the benefit of integration you're arguing against with your deficient piping suggestions
> IOW, structured data is not a cure for laziness...
It is precisely what good design is for - it reduces the need for various dumb workarounds that bad design requires, which means you can be more lazy and avoid said workaround
> Yes, because their authors are not that lazy.
This just ignores the argument, which was "some better new tools don't do that" isn't relevant when some better new tools also do that
If they want something that is easy to use in a non-scriptable way, maybe they should replicate Norton Commander instead.
Like don't get me wrong, if they had fun, that's great.
But all i use ls for is getting a list of files. I barely ever even use the -la options. There just doesn't seem like a lot of room for improvement in something so simple.
$ du -a | grep blblNot a big surface area, some easy improvements. A whole lot less stressful than rewriting grep (although I'm massively grateful Burnt Sushi did such a crazy thing)
Certainly I use these less than plain "ls," but digging through hidden files and folders and looking at timestamps is very important for me.
Hidden files are almost always of interest to me since my job involves configuring servers.
It helps to start with a more extensible/less built-in idea of "file type". "odd permissions" are another type that might interest someone, for example, such as "setgid but not group-executable" or "writable but not readable" or etc.
Yes, I know one can also use `find` or etc. for that, but there's no crime in there being >1 way to see things and, for some people, colors can make things really stand out - as can sort order which is another more color-blind possibility in `lc` as well as the simple filter-or-not of ls -a/-A.
But as I added more and more features to it, it has become a good tool that does a number of things that `ls` doesn't do (unless you chain it with other tools like `sort` or `grep`) and even other `ls` replacements don't do.
So even though `ls` is fantastic as-is, it's always fun to build something of your own, add a little more polish in areas that matter to you and put it out there to see if it resonates with more people.
[1]: https://pls.cli.rs
lc is a highly configurable "multi-dimensional"[1] file lister written in Nim focused on flexibility and configurability.
Key features:
- Multi-level sorting by combinations of attributes like size, time, and file type, with user-defined precedence
- Configurable file kind sorting order
- Value-dependent coloring for file attributes such as timestamps, permissions, or sizes.
- Abbreviations: Automatically shorten filenames, user/group names or symlink targets.
- File type classification: Integrates libmagic for file type inspection.
- Hyperlink support
- Per-directory configs: custom behaviors for specific directories using local tweak files (.lc).
- Lightweight (~900 lines of code) with only author's CLI library "cligen" and Nim's stdlib as dependencies.
and more.
[1]: https://github.com/c-blake/lc#vector-typemulti-dimensionalit...
[1]: https://pls.cli.rs [2]: https://pls.cli.rs/about/comparison/
# Different options to search for files
# da=36 cyan timestamps
alias ls="EZA_COLORS='da=36' eza --time-style=relative --color-scale=age"
alias lsa="ls --almost-all" # ignore . ..
alias l="ls --long --classify=always" # show file indicators
alias la="l --almost-all"
# Tree view
alias ltreea="ls --tree"
alias ltree="ltreea --level=2"
# Sort by time or size
alias lt="ls --long --sort=time"
alias lta="lt --almost-all"
# lsd is faster than eza
alias lss="lsd --long --total-size --sort=size --reverse"
alias lssa="lss --almost-all"
lla seems to go beyond what ls should do for some reason. Why show git and code complexity info? Just use tools dedicated for these things, otherwise, it will be an unmaintainable mess. If you can solve a problem easily with external tools, then there's no reason to add a feature for it.
But before inviting others to use something, please think of how to make its use more clear. After all, I assume you post this so that people use it, not only admire your coding skills. There is a group of people who have learned to read and rely on man pages.
For example, the top-level README says:
> -s, --sort <CRITERIA>: Sort by "name", "size", or "date"
OK, does "date" refer to creation date, modification date, access date? I can understand "size", but does it produce smallest-first or largest-first? It might not matter if... ah, no, there is no -r/--reverse flag. Can I have more than one "criteria" (since the plural is used)?
Getting answers for such questions now means I have to go read the code in src/args.rs and follow to the implementation of the various functions. And in a few days, when I have the same questions again and I have forgotten the options, I will again have to dive into the code.
Please consider providing a short man page. It documents the "calling interface" to your program and makes it easier to use. I usually start writing one even before implementing the whole thing, to clearly articulate what I expect the program to do.
paste <(lc -1m25 ../..) <(lc -1m25 ..) <(lc -1m25 .)