Initial release of FLI - really tiny and fast (like a ๐Ÿชฐ) directory listing tool.

Initial Why: need some easy readable ls like tool for rpi to use via ssh.

Current Why: check if with Rust one can build core utils like tools faster and smaller.

  • Size:

18K - RPI ZERO W

51KB - Mac

  • Default mode streams readdir() => stdout with zero heap allocation.

  • Nice readabilty thx to (๐Ÿ“„ and ๐Ÿ—‚๏ธ) instead of text coloring

  • Written in no_std #rust + libc.

https:// github.com/tracyspacy/fli

all 2 comments

sorted by: hot top controversial new old

Wicked dude

  • source
  • [โ€“] 2 points 4 months ago

    Noice! :โ -โ D

  • source
  • 2 comments in c/rust@programming.dev view that post
    [โ€“] 5 points 4 months ago (1 child)
        "-C", "link-arg=-lstdc++",
        "-C", "link-arg=-lsupc++",
        "-C", "link-arg=-lgcc_s"
    

    Now, that's just funny. But hey, you're using -Os to keep that binary size low ๐Ÿ˜‡

    And what's with the global allocator being initialized in a module? (didn't/don't know if that even works)

    If you want to do things really minimally, check out the rustix crate which wraps syscalls directly.

    Otherwise, and if loading huge shared libraries is fine, then you might as well not go nostd at all, since you can just pass -C prefer-dynamic for that elusive magically-small std-using binary ๐Ÿ™„

  • source
  • hideshow 1 child comment
  • [โ€“] [S] 2 points 4 months ago

    "-C", "link-arg=-lstdc++", "-C", "link-arg=-lsupc++", "-C", "link-arg=-lgcc_s"

    good catch!

    rustix - take a look, thx.

    no_std was my deliberate choice. -C prefer-dynamic - it feels that it may be a more fragile option and add some hassles with cross compiling - something like error while loading shared libraries: ... so I have to provide libstd.so as well together with binary to rpi .. where is the gain?

  • source
  • parent