I just want to say that I am excited about Rust, it’s gotten me interested in programming again, and the tools on this list have gotten me excited about the command line for the first time in years. I recently switched back to Linux from macOS after more than a decade of loyalty to Apple, in part because I’m currently more excited about projects like these than I am about Apple’s GUIs.
@sharkdp, @burntsushi, and everyone else working in this space, thank you for your efforts, and don’t let the haters get you down.
Being the maintainer of three of these tools and a long time command-line enthusiast, it’s just sad to read a comment like this.
I can understand that people do not want to try out new tools. Fine. But why criticize them without even taking a proper look?
As others have already pointed out, most of these tools are not breaking pipeline usage. The README for bat has a whole section on “integration with other tools”, showing multiple examples of pipeline usage. fd’s README also points out several examples on how to pipe fd’s output to other programs (e.g. xargs, parallel, as-tree).
I have a feeling that a lot of people react allergic to colorized command-line output, and I absolutely do not understand why. Just because a tool doesn’t look like 1970 doesn’t mean that it’s not a proper citizen of the command-line world. But that’s not even the point. My tools do not provide colorized output to look “fancy”. They use colorized output because I think it’s actually pretty damn useful. Also, there is always the possibility to easily switch them off if you really don’t like it (set NO_COLOR or use --color=never in an alias).
Finally, I am really sick of the implied “rewritten in Rust” stigma. No, I did not write these tools in Rust because I wanted to demonstrate something. Or to show off. I simply like to try different programming languages from time to time and I think that Rust is an awesome fit for command-line tools. fd was actually started as a C++ project. I just moved it to Rust at some point. Mainly because of boost packaging issues and because I discovered the awesome Rust libraries by @burntsushi. Criticizing a tool for the language it’s written in is fine as long as there is an actual argument why that programming language was a poor choice for the job.
I have a feeling that a lot of people react allergic to colorized command-line output, and I absolutely do not understand why.
First, let me say that I really appreciate the effort in trying to keep moving things forward. That means change, and change is not always good.
I’m pretty allergic to colors in command line tools - but that is mostly because of awful default logging/outpu formats from ruby/rails - and not for tools like these that properly detect piping etc.
I’m also slow to adopt new tools - I still tend to prefer gnu find to fd, haven’t quite been able to put fzf to work - but I’m not quite hopeless - I do use ripgrep quite a bit.
I think quality matters (more) when using colorization - and it takes a village to get there. The recent generations of colorized interactive ruby output is a boon (on Linux) - it looks good, and if I copy from gnome terminal and paste into nvim - the escape séquences vanish. But on windows servers with the standard windows console - even the line breaks do not work properly, and colorization is hit and miss (colors or escape sequences? It depends…).
Many of us need to work on various heterogeneous deployment servers not under our control - and that makes us thirsty for the simplest tools - to the point of sometimes preferring a predictable dull rock to a scalpel that might shatter at any moment. But it sometimes makes the transitionfrom skinning rabbit to preformingbbrain surgery… More challenging.
I have a feeling that a lot of people react allergic to colorized command-line output, and I absolutely do not understand why.
First, let me say that I really appreciate the effort in trying to keep moving things forward. That means change, and change is not always good.
I’m pretty allergic to colors in command line tools - but that is mostly because of awful default logging/outpu formats from ruby/rails - and not for tools like these that properly detect piping etc.
I’m also slow to adopt new tools - I still tend to prefer gnu find to fd, haven’t quite been able to put fzf to work - but I’m not quite hopeless - I do use ripgrep quite a bit.
I think quality matters (more) when using colorization - and it takes a village to get there. The recent generations of colorized interactive ruby output is a boon (on Linux) - it looks good, and if I copy from gnome terminal and paste into nvim - the escape séquences vanish. But on windows servers with the standard windows console - even the line breaks do not work properly, and colorization is hit and miss (colors or escape sequences? It depends…).
Many of us need to work on various heterogeneous deployment servers not under our control - and that makes us thirsty for the simplest tools - to the point of sometimes preferring a predictable dull rock to a scalpel that might shatter at any moment. But it sometimes makes the transitionfrom skinning rabbit to preformingbbrain surgery… More challenging.
sad as in trump-sad or you are sad? if the latter, i’m sorry.
Sorry, this seems completely uncalled for. One of the reasons I like this site is its relative lack of political drama and focus on technology. I don’t know what Donald Trump has to do with this technical disagreement, but I don’t think he’s relevant to it, and I don’t think the mention of him will resolve anything.
sad as in trump-sad or you are sad? if the latter, i’m sorry.
It makes me sad because you invest countless hours into a project and then someone disregards it within seconds with a low-effort comment like this. Other people looking at this thread will see the wrong statements (“breaking pipelines”) and might take them for granted.
i dislike it because it’s an ugly hack on top of emulated 70s hardware, and breaks.
I absolutely agree with you on this point. I just don’t see any alternative. Is someone working on a completely redesigned, modern terminal API? It could probably still support ANSI escape codes for backwards compatibility.
somehow git diff is broken on one of my machines where the automatically invoked “less” isn’t rendering escapes but printing them verbatim.
I know you are probably not looking for a solution, but the problem might be that the -R/--RAW-CONTROL-CHARS command-line option is not passed to less on that system. It tells less to interpret those escape sequences. I guess most distributions set LESS="-R" by default.
the title of the article says “rewritten in rust” as if it’s a seal of quality. i wouldn’t otherwise have made fun of that.
That’s your interpretation, but okay. I see your point. It’s definitely not a seal of quality per se. There are, however, a few things that can be inferred from a choice of programming language (expected startup latency, memory safety guarantees, portability, ease of distribution, …). As stated above, I think that Rust is actually an excellent choice for command line tools. Because it delivers on all of the mentioned aspects. That doesn’t mean that it’s the only choice though.
I maintain a terminal library in D and yeah it is interesting to do it well on Windows (especially if you want to do a gui and a cli in the same exe… I thought that was impossible until I did it with a pile of hacks) but I didn’t even try the msys then, yikes, what a hassle.
But one of the decisions I made with my library is it is invalid to use the Terminal structure on a pipe. So I force you to branch outside instead of trying to transparently handle both. I kinda regret that since so many programs can benefit from the “just-works” aspect, but it is true you can often do much better UIs if the application just branches at the top level.
Thanks! I like the SW_HIDE idea, though I went with a different approach. What I ended up doing is making a .bat file that calls the exe and just instructed the cli users to use that instead of the exe itself which worked cuz a bunch of cli users were used to a bat file anyway (it used to do chcp and when I looked at it, I told them about WriteConsoleW and that chcp hack is terrible, but the batch file was still there so that meant I could reuse it here).
Then the exe checks AttachConsole parent and reopens the stdin/out to it… as long as they were already null (otherwise they were previously redirected and don’t want to overwrite that).
Otherwise though the exe itself is the Windows subsystem so the double click and shortcut users just work without any flicker. Then the bat file causes the command shell to wait until the program finishes so the prompt and the output don’t stomp on each other.
The only thing kinda iffy to me is if the output is piped. For the console, WriteConsoleW with utf-16 just works. But for the pipe, I output utf-8 and it seems to be fine and the users happy with it, but I remain unsure what it should really do. I suspect Windows detects based on the first two bytes from some tests but I’m not fully happy with that part yet. Especially since you can pipe binary data too so idk.
Though, even if the fancy looking output was a better user experience (usually, I don’t think it is), switching output is also not particularly friendly; Now I need to think about two different formats when I use the tool.
Breaking pipelines is not an issue if you still have the coreutils implementations still around. e.g: use bat and exa for regular use but when you need pipes use cat and ls. I don’t see a problem with this and I think the concepts nushell (also mentioned in the article) brings to the table are definitely useful, albeit not implemented there for the first time.
i just think it’s a bit weird to hype the console (look ma, no gui!) and at the same time ignore the concepts which make it so powerful. some of these tools are okish, but colorization and emulating guis are great at preventing the piping of output to further processing.
tools and pipelines together are bigger than their parts.
and i think that rust is overhyped, but that’s my problem ;)
and at the same time ignore the concepts which make it so powerful
If this were true, then we wouldn’t have used tty detection to change the output format to be compatible with pipelines.
Which, by the way, is exactly what ls has been doing for years. Its default output format to a tty isn’t pipeline friendly. Maybe we’ve been learning from older tools more than you think.
It’s just funny when I see people raging about this for the Rust tools (it seems to happen quite frequently), but nobody thinks to do it for any of the older tools. And it’s even better when people use this as a launching point to accuse us of ignorance. Give me a break.
I think you will find people (suckless type people) do complain about gnu coreutils doing stuff like this. I admit it is useful and nice lots of the time too.
Plan 9 ls doesn’t do anything different, and in fact, has no way to do it short of becoming a graphical program: there’s no concept of “terminal width”. You need to open the draw device and get the window size, look at the (possibly variable-width) font, and compute line widths.
There are also no control characters that handle cursor positioning, other than ‘\b’. The plan 9 console is a simple textual transcript. If you want graphics, use graphics – it doesn’t pop open a new window, so there’s no reason to support semigraphical features when full graphics are available.
Correct – Plan 9 doesn’t. The philosophy behind it is discussed in cat -v Considered Harmful by Pike and Kernighan (page 5).
Though, to be technical, the Plan9 console isn’t really a tty, so Plan9 ls was designed for a slightly different environment. However, the design of ls (and the Plan 9 console) are rooted in this philosophy.
it’s not that i dislike the functionality but how it’s implemented. i’d be interested in having such tools build in a composable way, out of multiple commands. default invokations then could be build via shellscript (and shipped together with the commands).
And do you use Plan9’s version of ls to avoid the “nice” display output of the BSD and GNU versions of ls? If not, why do you use tools that ignore the concepts of composition?
it’s not that i dislike the functionality but how it’s implemented
That’s surprising, and even re-reading your comments above, I don’t really see this coming across. You seem to be ranting against the functionality itself and how it breaks pipelining. But we handle those cases by disabling the “nice” functionality so that pipelining works.
i’d be interested in having such tools build in a composable way
Easier said than done. Everyone worships at the alter of perfect composition (including myself), but actually achieving it is another matter entirely. It seems pretty unfair to hold that against us. It’s not unreasonable to think that in certain environments, composition, development effort and the user experience are at odds with one another. (Where the development effort to make some of these nicer features truly compositional is probably on the order of “build a new kind of shell environment and convince everyone to use it,” which really isn’t feasible.) People actually building these tools have to pick a design point in this space, and we get rewarded with people calling us ignorant. Go figure.
And do you use Plan9’s version of ls to avoid the “nice” display output of the BSD and GNU versions of ls? If not, why do you use tools that ignore the concepts of composition?
i’ve tried to use the tools of plan9port by putting them in front of $PATH, unfortunatly the assumptions about the environment are sufficiently different from linux so that i’ve had other problems then.
That’s surprising, and even re-reading your comments above, I don’t really see this coming across. You seem to be ranting against the functionality itself and how it breaks pipelining. But we handle those cases by disabling the “nice” functionality so that pipelining works.
i dislike the complexity such tools introduce by putting together unrelated things like colorization and git handling (sorry, bat is the first thing in the list..). i dislike magic as i’ve put so much time into debugging it when it breaks.
Easier said than done. Everyone worships at the alter of perfect composition (including myself), but actually achieving it is another matter entirely.
indeed.
It seems pretty unfair to hold that against us. It’s not unreasonable to think that in certain environments, composition, development effort and the user experience are at odds with one another. (Where the development effort to make some of these nicer features truly compositional is probably on the order of “build a new kind of shell environment and convince everyone to use it,” which really isn’t feasible.) People actually building these tools have to pick a design point in this space, and we get rewarded with people calling us ignorant. Go figure.
i don’t know, you got rewarded with upvotes :) i’ve never called people ignorant, i’ve said that i find it weird to use an environment which lives by simplicity and then building things which combine several complicated tasks into one.
i just think it’s a bit weird to hype the console (look ma, no gui!) and at the same time ignore the concepts which make it so powerful
Emphasis mine. Sure looks like you’re calling us ignorant to me.
It’d just be nice to see folks be consistent. If you’re going to get all cranky about new tools introducing features that aren’t compositional, then at least get cranky about all the old tools that do it too. Because then, just maybe, it’s not just a bunch of overhyped new-fangled nonsense, and maybe there’s actually something to it. The giants we stand on also made choices that sacrifice composition.
the funny thing is that no one has thrown the old “then write it yourself” in my direction, which only would be fair.
I try to avoid saying things like that in discussions such as these. I think it’s overused as a way to dismiss others’ concerns. And of course, most people are already aware that such a thing is possible and don’t need to be reminded of it. I might as well just say nothing at all at that point.
I just find your particular form of criticism to be popular yet shallow. People love to jump all over these new fangled tools as if their authors are blubbering idiots that totally ignored the entire history of computing or are blissfully unaware of the Unix philosophy. It’s a lazy critique because violating composition is nothing new. We’re just doubling down, people don’t like it and for some reason like to insult the authors of these tools or at least denigrate their work. It’s annoying. (It’s a pretty common tactic used in lazy online banter, and is used in all manner of scenarios. I think we’d all be a lot better off if we held ourselves to a higher standard of discourse.)
Let’s assume you were used to using cat somefile | less (ignoring for a moment that you could just less somefile) and swapped in an alternate tool for cat, let’s say mycat. Now mycat has a bunch of cool features like colorized output or wizbang progress bars (again, ignoring that many find colored output or wizbang features distasteful….). When just using mycat somefile everything looks great! But then you pipe mycat somefile | less and get all kinds of garbage, if less even works at all!
This is one way to breaki pipelining. The reason it happens is mycat is probably using a bunch of TTY control codes, or ANSI color codes to implement all those features. However, when that output is piped through to less, the pipe isn’t a TTY it’s just a raw text stream. So those control codes don’t get interpreted and instead just appear on the screen in raw form.
mycat can fix this by first checking if stdout is a TTY or not, and if so printing it’s control codes, but if not just printing raw text.
There are other ways you can break pipelining, such as not handling a SIGPIPE correctly (trying to write to pipe who’s reading end has been closed).
Rust has facilities to handle these cases, and most common Rust applications handle these cases just fine. It is however a common footgun since if you’re implementing a new tool and not familiar with how all this traditionally works you may not know to check for these kinds of things.
I like the tendency by Go and now Rust of writing small utilities that are improvements of existing utilities.
Looks very cool!
But the name…. dup? Aside from that being a built-in in many versions of Forth like languages, it should be mnemonically associated with something that involves two of something.
I agree. I didn’t really think long before naming this dup. The project has now been renamed to diskus (short for “disk usage”, also: a German word for the disc in Discus throw).
I made the github issue thinking you might have had strong feelings, but you listened and came up with a much more appropiate name. If only all my interactions with other developers were so reasonable.
i don’t get the point. if you want du to be faster, make it faster and upstream the changes. why add more baggage that i have to drag around whenever i’m at a new computer?
is this just people padding their githubs to impress employers?
I guess duparallel? But yes, it sounds like something that would find duplicates instead of calculating directory sizes. Hardest thing in computer science?… :)
I just want to say that I am excited about Rust, it’s gotten me interested in programming again, and the tools on this list have gotten me excited about the command line for the first time in years. I recently switched back to Linux from macOS after more than a decade of loyalty to Apple, in part because I’m currently more excited about projects like these than I am about Apple’s GUIs.
@sharkdp, @burntsushi, and everyone else working in this space, thank you for your efforts, and don’t let the haters get you down.
Much appreciated. :-)
Thank you for the feedback!
Being the maintainer of three of these tools and a long time command-line enthusiast, it’s just sad to read a comment like this.
I can understand that people do not want to try out new tools. Fine. But why criticize them without even taking a proper look?
As others have already pointed out, most of these tools are not breaking pipeline usage. The README for
bathas a whole section on “integration with other tools”, showing multiple examples of pipeline usage.fd’s README also points out several examples on how to pipefd’s output to other programs (e.g.xargs,parallel,as-tree).I have a feeling that a lot of people react allergic to colorized command-line output, and I absolutely do not understand why. Just because a tool doesn’t look like 1970 doesn’t mean that it’s not a proper citizen of the command-line world. But that’s not even the point. My tools do not provide colorized output to look “fancy”. They use colorized output because I think it’s actually pretty damn useful. Also, there is always the possibility to easily switch them off if you really don’t like it (set
NO_COLORor use--color=neverin an alias).Finally, I am really sick of the implied “rewritten in Rust” stigma. No, I did not write these tools in Rust because I wanted to demonstrate something. Or to show off. I simply like to try different programming languages from time to time and I think that Rust is an awesome fit for command-line tools.
fdwas actually started as a C++ project. I just moved it to Rust at some point. Mainly because of boost packaging issues and because I discovered the awesome Rust libraries by @burntsushi. Criticizing a tool for the language it’s written in is fine as long as there is an actual argument why that programming language was a poor choice for the job.First, let me say that I really appreciate the effort in trying to keep moving things forward. That means change, and change is not always good.
I’m pretty allergic to colors in command line tools - but that is mostly because of awful default logging/outpu formats from ruby/rails - and not for tools like these that properly detect piping etc.
I’m also slow to adopt new tools - I still tend to prefer gnu find to fd, haven’t quite been able to put fzf to work - but I’m not quite hopeless - I do use ripgrep quite a bit.
I think quality matters (more) when using colorization - and it takes a village to get there. The recent generations of colorized interactive ruby output is a boon (on Linux) - it looks good, and if I copy from gnome terminal and paste into nvim - the escape séquences vanish. But on windows servers with the standard windows console - even the line breaks do not work properly, and colorization is hit and miss (colors or escape sequences? It depends…).
Many of us need to work on various heterogeneous deployment servers not under our control - and that makes us thirsty for the simplest tools - to the point of sometimes preferring a predictable dull rock to a scalpel that might shatter at any moment. But it sometimes makes the transitionfrom skinning rabbit to preformingbbrain surgery… More challenging.
First, let me say that I really appreciate the effort in trying to keep moving things forward. That means change, and change is not always good.
I’m pretty allergic to colors in command line tools - but that is mostly because of awful default logging/outpu formats from ruby/rails - and not for tools like these that properly detect piping etc.
I’m also slow to adopt new tools - I still tend to prefer gnu find to fd, haven’t quite been able to put fzf to work - but I’m not quite hopeless - I do use ripgrep quite a bit.
I think quality matters (more) when using colorization - and it takes a village to get there. The recent generations of colorized interactive ruby output is a boon (on Linux) - it looks good, and if I copy from gnome terminal and paste into nvim - the escape séquences vanish. But on windows servers with the standard windows console - even the line breaks do not work properly, and colorization is hit and miss (colors or escape sequences? It depends…).
Many of us need to work on various heterogeneous deployment servers not under our control - and that makes us thirsty for the simplest tools - to the point of sometimes preferring a predictable dull rock to a scalpel that might shatter at any moment. But it sometimes makes the transitionfrom skinning rabbit to preformingbbrain surgery… More challenging.
Sorry, this seems completely uncalled for. One of the reasons I like this site is its relative lack of political drama and focus on technology. I don’t know what Donald Trump has to do with this technical disagreement, but I don’t think he’s relevant to it, and I don’t think the mention of him will resolve anything.
*sigh
i’ll just let myself out. thanks for all the fish.
Thank you for the response.
It makes me sad because you invest countless hours into a project and then someone disregards it within seconds with a low-effort comment like this. Other people looking at this thread will see the wrong statements (“breaking pipelines”) and might take them for granted.
I absolutely agree with you on this point. I just don’t see any alternative. Is someone working on a completely redesigned, modern terminal API? It could probably still support ANSI escape codes for backwards compatibility.
I know you are probably not looking for a solution, but the problem might be that the
-R/--RAW-CONTROL-CHARScommand-line option is not passed tolesson that system. It tellslessto interpret those escape sequences. I guess most distributions setLESS="-R"by default.That’s your interpretation, but okay. I see your point. It’s definitely not a seal of quality per se. There are, however, a few things that can be inferred from a choice of programming language (expected startup latency, memory safety guarantees, portability, ease of distribution, …). As stated above, I think that Rust is actually an excellent choice for command line tools. Because it delivers on all of the mentioned aspects. That doesn’t mean that it’s the only choice though.
Most of the plumbing-replacement tools actually detect pipes and switch to machine-friendly output.
I can confirm this for
fd,batandexa. I just had a quick look at those and at a first glance all of them seem to support pipelines just fine.let me flame in peace!!1
thanks, i wasn’t aware of that magick.
Its pretty common actually https://man7.org/linux/man-pages/man3/isatty.3.html not unique to rust for that matter.
Simply as easy as if (isatty(fileno(stdout))) … else …
But! Quite annoying to do correctly on Windows in a way that works in both the cmd and MSYS shells: https://github.com/softprops/atty/blob/7b5df17888997d57c2c1c8f91da1db5691f49953/src/lib.rs#L101-L154
That one was quite fun to figure out. I cribbed it from some other project, but can’t remember which one.
I maintain a terminal library in D and yeah it is interesting to do it well on Windows (especially if you want to do a gui and a cli in the same exe… I thought that was impossible until I did it with a pile of hacks) but I didn’t even try the msys then, yikes, what a hassle.
But one of the decisions I made with my library is it is invalid to use the Terminal structure on a pipe. So I force you to branch outside instead of trying to transparently handle both. I kinda regret that since so many programs can benefit from the “just-works” aspect, but it is true you can often do much better UIs if the application just branches at the top level.
I struggled with this as well, and made a post about it which may be of interest: https://www.devever.net/~hl/win32con
Thanks! I like the SW_HIDE idea, though I went with a different approach. What I ended up doing is making a .bat file that calls the exe and just instructed the cli users to use that instead of the exe itself which worked cuz a bunch of cli users were used to a bat file anyway (it used to do
chcpand when I looked at it, I told them about WriteConsoleW and that chcp hack is terrible, but the batch file was still there so that meant I could reuse it here).Then the exe checks AttachConsole parent and reopens the stdin/out to it… as long as they were already null (otherwise they were previously redirected and don’t want to overwrite that).
Otherwise though the exe itself is the Windows subsystem so the double click and shortcut users just work without any flicker. Then the bat file causes the command shell to wait until the program finishes so the prompt and the output don’t stomp on each other.
The only thing kinda iffy to me is if the output is piped. For the console, WriteConsoleW with utf-16 just works. But for the pipe, I output utf-8 and it seems to be fine and the users happy with it, but I remain unsure what it should really do. I suspect Windows detects based on the first two bytes from some tests but I’m not fully happy with that part yet. Especially since you can pipe binary data too so idk.
I’ve never used windows so I’ll take your word for it >.<
Though, even if the fancy looking output was a better user experience (usually, I don’t think it is), switching output is also not particularly friendly; Now I need to think about two different formats when I use the tool.
Breaking pipelines is not an issue if you still have the coreutils implementations
stillaround. e.g: usebatandexafor regular use but when you need pipes usecatandls. I don’t see a problem with this and I think the concepts nushell (also mentioned in the article) brings to the table are definitely useful, albeit not implemented there for the first time.Edit: typo, crossed out extra word
of course there are the standard tools.
i just think it’s a bit weird to hype the console (look ma, no gui!) and at the same time ignore the concepts which make it so powerful. some of these tools are okish, but colorization and emulating guis are great at preventing the piping of output to further processing.
tools and pipelines together are bigger than their parts.
and i think that rust is overhyped, but that’s my problem ;)
If this were true, then we wouldn’t have used tty detection to change the output format to be compatible with pipelines.
Which, by the way, is exactly what
lshas been doing for years. Its default output format to a tty isn’t pipeline friendly. Maybe we’ve been learning from older tools more than you think.It can also be quite confusing to have the output change when you aren’t looking at it.
It’s just funny when I see people raging about this for the Rust tools (it seems to happen quite frequently), but nobody thinks to do it for any of the older tools. And it’s even better when people use this as a launching point to accuse us of ignorance. Give me a break.
I think you will find people (suckless type people) do complain about gnu coreutils doing stuff like this. I admit it is useful and nice lots of the time too.
BSD
lsdoes it too. Or at least, the BSDlscommand on my mac mini box does.Does there exist a version of
lsthat doesn’t do this?The coffee is still kicking in but I don’t think Plan9 ls does this.
Plan 9 ls doesn’t do anything different, and in fact, has no way to do it short of becoming a graphical program: there’s no concept of “terminal width”. You need to open the draw device and get the window size, look at the (possibly variable-width) font, and compute line widths.
There are also no control characters that handle cursor positioning, other than ‘\b’. The plan 9 console is a simple textual transcript. If you want graphics, use graphics – it doesn’t pop open a new window, so there’s no reason to support semigraphical features when full graphics are available.
Correct – Plan 9 doesn’t. The philosophy behind it is discussed in
cat -vConsidered Harmful by Pike and Kernighan (page 5).Though, to be technical, the Plan9 console isn’t really a tty, so Plan9
lswas designed for a slightly different environment. However, the design ofls(and the Plan 9 console) are rooted in this philosophy.I don’t think sbase ls does:
https://git.suckless.org/sbase/file/ls.c.html
OpenBSD and NetBSD’s ls do not have this flag (-G).
plan9 ls? ;)
it’s not that i dislike the functionality but how it’s implemented. i’d be interested in having such tools build in a composable way, out of multiple commands. default invokations then could be build via shellscript (and shipped together with the commands).
And do you use Plan9’s version of
lsto avoid the “nice” display output of the BSD and GNU versions ofls? If not, why do you use tools that ignore the concepts of composition?That’s surprising, and even re-reading your comments above, I don’t really see this coming across. You seem to be ranting against the functionality itself and how it breaks pipelining. But we handle those cases by disabling the “nice” functionality so that pipelining works.
Easier said than done. Everyone worships at the alter of perfect composition (including myself), but actually achieving it is another matter entirely. It seems pretty unfair to hold that against us. It’s not unreasonable to think that in certain environments, composition, development effort and the user experience are at odds with one another. (Where the development effort to make some of these nicer features truly compositional is probably on the order of “build a new kind of shell environment and convince everyone to use it,” which really isn’t feasible.) People actually building these tools have to pick a design point in this space, and we get rewarded with people calling us ignorant. Go figure.
i’ve tried to use the tools of plan9port by putting them in front of $PATH, unfortunatly the assumptions about the environment are sufficiently different from linux so that i’ve had other problems then.
i dislike the complexity such tools introduce by putting together unrelated things like colorization and git handling (sorry, bat is the first thing in the list..). i dislike magic as i’ve put so much time into debugging it when it breaks.
indeed.
i don’t know, you got rewarded with upvotes :) i’ve never called people ignorant, i’ve said that i find it weird to use an environment which lives by simplicity and then building things which combine several complicated tasks into one.
You said:
Emphasis mine. Sure looks like you’re calling us ignorant to me.
It’d just be nice to see folks be consistent. If you’re going to get all cranky about new tools introducing features that aren’t compositional, then at least get cranky about all the old tools that do it too. Because then, just maybe, it’s not just a bunch of overhyped new-fangled nonsense, and maybe there’s actually something to it. The giants we stand on also made choices that sacrifice composition.
i didn’t know that ignoring things, as in “conscious decision” is the same as being ignorant, but then, i’m no native speaker.
believe me, i’m cranky about most old (like the gnu stuff?) tools too. that’s why i’d like to see new tools which aren’t like the old ones.
the funny thing is that no one has thrown the old “then write it yourself” in my direction, which only would be fair.
I try to avoid saying things like that in discussions such as these. I think it’s overused as a way to dismiss others’ concerns. And of course, most people are already aware that such a thing is possible and don’t need to be reminded of it. I might as well just say nothing at all at that point.
I just find your particular form of criticism to be popular yet shallow. People love to jump all over these new fangled tools as if their authors are blubbering idiots that totally ignored the entire history of computing or are blissfully unaware of the Unix philosophy. It’s a lazy critique because violating composition is nothing new. We’re just doubling down, people don’t like it and for some reason like to insult the authors of these tools or at least denigrate their work. It’s annoying. (It’s a pretty common tactic used in lazy online banter, and is used in all manner of scenarios. I think we’d all be a lot better off if we held ourselves to a higher standard of discourse.)
Could you elaborate a bit more on breaking pipelines?
Let’s assume you were used to using
cat somefile | less(ignoring for a moment that you could justless somefile) and swapped in an alternate tool forcat, let’s saymycat. Nowmycathas a bunch of cool features like colorized output or wizbang progress bars (again, ignoring that many find colored output or wizbang features distasteful….). When just usingmycat somefileeverything looks great! But then you pipemycat somefile | lessand get all kinds of garbage, iflesseven works at all!This is one way to breaki pipelining. The reason it happens is
mycatis probably using a bunch of TTY control codes, or ANSI color codes to implement all those features. However, when that output is piped through toless, the pipe isn’t a TTY it’s just a raw text stream. So those control codes don’t get interpreted and instead just appear on the screen in raw form.mycatcan fix this by first checking if stdout is a TTY or not, and if so printing it’s control codes, but if not just printing raw text.There are other ways you can break pipelining, such as not handling a
SIGPIPEcorrectly (trying to write to pipe who’s reading end has been closed).Rust has facilities to handle these cases, and most common Rust applications handle these cases just fine. It is however a common footgun since if you’re implementing a new tool and not familiar with how all this traditionally works you may not know to check for these kinds of things.
I like the tendency by Go and now Rust of writing small utilities that are improvements of existing utilities.
Looks very cool!
But the name…. dup? Aside from that being a built-in in many versions of Forth like languages, it should be mnemonically associated with something that involves two of something.
I agree. I didn’t really think long before naming this
dup. The project has now been renamed todiskus(short for “disk usage”, also: a German word for the disc in Discus throw).Bless you!
I made the github issue thinking you might have had strong feelings, but you listened and came up with a much more appropiate name. If only all my interactions with other developers were so reasonable.
maybe author didn’t care for the sound of
dushi don’t get the point. if you want du to be faster, make it faster and upstream the changes. why add more baggage that i have to drag around whenever i’m at a new computer?
is this just people padding their githubs to impress employers?
I guess duparallel? But yes, it sounds like something that would find duplicates instead of calculating directory sizes. Hardest thing in computer science?… :)