[HN Gopher] Ncdu 2: Less hungry and more Ziggy
___________________________________________________________________
Ncdu 2: Less hungry and more Ziggy
Author : signa11
Score : 192 points
Date : 2021-07-25 13:15 UTC (9 hours ago)
(HTM) web link (dev.yorhel.nl)
(TXT) w3m dump (dev.yorhel.nl)
| hvdijk wrote:
| Nice to know that the C version will still be maintained as well,
| there are systems where setting up Zig would be a hassle.
|
| > Ncdu 2.0 doesn't work well with non-UTF-8 locales anymore, but
| I don't expect this to be a problem nowadays.
|
| I can believe this, but has there been any investigation into how
| common non-UTF-8 locales are nowadays? GNOME has been broken with
| non-UTF-8 locales for years (I can find a 6-year-old bug report
| that still has not been resolved) so that may have pushed users
| that previously were using non-UTF-8 locales to UTF-8, but that
| is only GNOME and does not apply to users of any other
| environment, who may have continued using non-UTF-8 locales
| without issues.
| gmfawcett wrote:
| One thing I really appreciate about ncdu, that seems to be
| missing from its work-alikes (gdu, pdu,etc.), is the option to
| export scan results to disk & import them later. Not a feature
| that helps every day, but extremely handy sometimes.
| rashil2000 wrote:
| gdu added that feature just a couple of releases ago.
| gmfawcett wrote:
| Wow! you weren't kidding, the feature appears in release
| 5.3.0 (5 days ago!).
| saagarjha wrote:
| Seems like a known limitation that may be addressed at some
| point:
|
| > Exporting an in-memory tree to a file. Ncdu already has
| export/import options, but exporting requires a separate
| command invocation - it's not currently possible to write an
| export while you're in the directory browser. The new data
| model could support this feature, but I'm still unsure how to
| make it available in the UI.
| rmetzler wrote:
| Thanks so much for ncdu. I install it on all servers, because
| it's so helfen when you need to find out what takes all the
| storage.
| jorangreef wrote:
| For another cool Zig project also on HN at the moment, see River,
| a dynamic tiling Wayland compositor:
| https://news.ycombinator.com/item?id=27948650
| saagarjha wrote:
| This is how you do a migration to another language: you lay out
| the benefits, fully accept the drawbacks, and try your best to be
| reasonably supportive of people who, for various reasons, cannot
| use the new version. It's refreshing to see considering that the
| usual maintainer response to "I'm sorry, but I need to use the C
| version" I see in these kinds of situations is a combination of
| gaslighting ("your usecase is not really valid or is too niche
| for me to care", "are you telling me that you want security
| vulnerabilities") and outright refusal to accept that changes can
| mean that some people will be adversely affected. The author
| wanted use Zig, they did it, and they are polite enough to
| continue to provide basic maintenance for the C code for those
| that really need it.
| dralley wrote:
| >> and try your best to be reasonably supportive of people who,
| for various reasons, cannot use the new version.
|
| Keep in mind that "maintainence" according to them means
| "pretty much what I've been doing for the past few years: not
| particularly active in terms of development, just occasional
| improvements and fixes here and there." If you're trying to
| apply this to situations such as "py-cryptography" -- they are
| not very comparable.
|
| Pretty much every license in existence has a line like the
| following: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY
| OF ANY KIND, EXPRESS OR IMPLIED". This is especially true when
| the upstream never declared "support" for a given use case to
| begin with, such as different Libc implementations, big-endian
| platforms, etc...
|
| Don't complain about free beer.
| zserge wrote:
| Just started learning Zig, but I'm already amazed by the
| language. Feels so intuitive, simple and productive, really a
| good choice for quick prototyping. I'm glad to see Zig being used
| as a "successor" to C in projects like this.
| Rendello wrote:
| ncdu is one of my favourite tools, and Zig one of my favourite
| languages.
|
| For like me who are curious:
|
| - C version source:
| https://code.blicky.net/yorhel/ncdu/src/branch/master/
|
| - Zig version source:
| https://code.blicky.net/yorhel/ncdu/src/branch/zig
|
| The code is nice and very well commented.
| wott wrote:
| > - C version source:
| https://code.blicky.net/yorhel/ncdu/src/branch/master/
|
| > The code is nice and very well commented.
|
| I opened the first file in _src /_: _browser.c_. Let 's take
| the function _browse_draw_mtime()_ and start picking nits :-)
|
| It has a buffer of 26 chars, which will (for a regular C
| string) mean 25 characters + 1 NUL terminator.
| char mbuf[26];
|
| But in the end, it prints with the _printf()_ -like function:
|
| printw("%26s", mbuf);
|
| the count there is supposed to exclude the NUL terminator. So
| it should be 25 and not 26. Note that it cannot cause a
| problem, but it may indicate that the author didn't carefully
| grasp the exact definition of the format.
|
| Before that, in a branch the _mbuf_ buffer is filled with the
| _strftime()_ function. This function is stupidly defined by the
| C standard and POSIX didn 't make it better. It is not the
| author's fault, but one has to account for its flaws.
| strftime(mbuf, sizeof(mbuf), "%Y-%m-%d %H:%M:%S %z",
| localtime(&t));
|
| One would assume that the result string is truncated if it
| happens that the result would be too long, so that code would
| be fine. Well, not quite, it just protects from writing after
| the buffer. The standards say that in cases when the buffer is
| not long enough, the content of the result string is
| indeterminate :-/ Actually, it could even be not a string (not
| a properly terminated string).
|
| So one should check the value returned by _strftime()_ , check
| if it is 0, and act accordingly.
|
| Again, it is not dangerous, since the _printw( "%26s", mbuf)_
| won't read after the buffer. But it may write garbage, for
| example after year 9999, when the expected result string is too
| long for the buffer.
|
| -------------
|
| Then in the last file, _util.c_ , there are those macros:
| #define oom_msg "\nOut of memory, press enter to try again or
| Ctrl-C to give up.\n"
|
| and #define wrap_oom(f) \
|
| which at some point does: write(2, oom_msg,
| sizeof(oom_msg));
|
| This is going to emit a NUL character after the newline,
| because _sizeof()_ of a string literal accounts for it. So, to
| stop after the newline is emitted, it should be
| _sizeof(oom_msg)-1_.
| [deleted]
| formerly_proven wrote:
| D vs Zig vs Go for practical, pragmatic development of possibly-
| cross-platform tools? Fight.
| smoldesu wrote:
| I don't like any of those languages very much, but Zig seems
| perfectly fine for this sort of stuff. From the very beginning,
| I've seen people say that Zig should be used to offer easy,
| human-readable rewrites of basic C utilities without
| sacrificing execution speed. Meanwhile, I think Go would be
| much too heavy for a program like this, and D seems to be a
| little out of it's depths in this conversation.
| goodpoint wrote:
| Nim
| nahuel0x wrote:
| I'm not sure if it's really a problem for ncdu use case, but in
| Golang all the file I/O operations consume threads (in contrast
| with network ones), so is not easy to parallelize them:
| https://github.com/golang/go/issues/6817
|
| Btw, you forgot Rust :)
| drran wrote:
| In Rust, it's easy: https://github.com/bootandy/dust/blob/mas
| ter/src/dir_walker....
|
| (Dust is "du + rust").
| qmmmur wrote:
| Nim
| dnautics wrote:
| CLIs: For now, go. In 3 years? Zig.
| 1MachineElf wrote:
| Discussed previously:
| https://news.ycombinator.com/item?id=27943097
| ComputerGuru wrote:
| I didn't realize ncdu (1 or 2!) was still maintained. I have some
| fixes for WSL compatibility I need to upstream (but first, let me
| see if 2 already fixes them).
| d33 wrote:
| Hi, thanks for working on an ncdu rewrite! In case you're looking
| for feature requests, there are a few things I wish that were
| supported OOTB:
|
| 1. breadth-first search? sometimes most of the directories are
| tiny and when one with a lot of files is found, I'd like it to be
| measured as the last one. I think that right now directory tree
| is explored using BFS, 2. add a way to display currently
| calculated directory tree state. Not sure about ncdu2, but ncdu
| doesn't show much apart from the current item, number of files
| and total size. I'd like to be able to use the approximate
| information it has gathered so far
|
| And once again, thanks for the great work! I really appreciate
| it.
| ducktective wrote:
| I can vouch for ncdu...does one thing and does it well. Also see:
|
| https://github.com/jarun/nnn/
|
| https://github.com/bootandy/dust
|
| > There is, after all, nothing more annoying than having to get
| re-acquainted with every piece of software you've installed every
| time you decide to update...
|
| _Looking at you $EVERY_MODERN_GUI_APP_
| namibj wrote:
| nnn switched the keybindings around 3+ times while I was using
| it, and I don't tend to use this kind of stuff more than a few
| times a month, so it takes a long time to memorize them. It's a
| nice tool; I wish it's keybindings didn't forcibly evolve so
| fast.
| ziotom78 wrote:
| I love Ncdu, it's one of the first things I install in computers
| I need to manage remotely. Good to know that version 2 is
| underway. Thanks!
| agumonkey wrote:
| tmux, ncdu, htop .. there's a bunch of utils of similar quality
| CyberShadow wrote:
| Very cool. In my mind, ncdu is "the" TUI tool for disk usage
| analysis. I copied its UI in making btdu, a similar tool
| specifically for btrfs filesystems. Written in D!
|
| https://github.com/CyberShadow/btdu/blob/master/ARCHITECTURE...
___________________________________________________________________
(page generated 2021-07-25 23:01 UTC)