Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: tere – A Faster Alternative to cd+ls

github.com

Post reply on HN
Print view View original

181–190 of 206 posts

Re: Show HN: tere – A Faster Alternative to cd+ls

#181

Post by nicoburns »

mynameisvlad wrote: post #104
reaperducer wrote: post #86

Earlier quoted context omitted.

hashbrown, smawk, corasick, parking_lot, itoa, ryu Writing in Rust looks like casting spells in an Infocom game. Gnusto rezrov!

Really? itoa is one of your "magic incantations"? https://en.m.wikibooks.org/wiki/C_Programming/stdlib.h/itoa I get the others, but that ones a pretty standard type converter, the opposite of the C standard atoi

In fairness, C standard library functions mostly look like magic incantations to me (I think due in large part to the old-school convention of abbreviating function names). malloc, sprintf, atoi, etc don't exactly read like english... (unless you happen to already know what they stand for)

Re: Show HN: tere – A Faster Alternative to cd+ls

#182

Post by jhgb »

nicoburns wrote: post #180
jhgb wrote: post #78

Earlier quoted context omitted.

I wonder, have you considered D? Seems almost ideal to me for this kind of small tooling, and it's unlikely to break because of dependency version changes caused by the thirty-seventh party.

Rust is also unlikely to break because of dependency version changes caused by the thirty-seventh party. Despite similarly large dependency trees, the Rust ecosystem takes backwards compatibility much more seriously than e.g. the JavaScript ecosystem.

Well, I should hope so. Nevertheless every dependency removed completely removes even the possibility of such breakage.

Re: Show HN: tere – A Faster Alternative to cd+ls

#183

Post by nicoburns »

jhgb wrote: post #182
nicoburns wrote: post #180

Earlier quoted context omitted.

Rust is also unlikely to break because of dependency version changes caused by the thirty-seventh party. Despite similarly large dependency trees, the Rust ecosystem takes backwards compatibility much more seriously than e.g. the JavaScript ecosystem.

Well, I should hope so. Nevertheless every dependency removed completely removes even the possibility of such breakage.

I mean sure, but it means you have to maintain that functionality yourself. Often DIY implementations are not as robust as the versions in battle tested libraries with lots of eyes. So you can easily end up with more problems overall.

Re: Show HN: tere – A Faster Alternative to cd+ls

#184

Post by ac29 »

jhgb wrote: post #174
omni wrote: post #163

Earlier quoted context omitted.

I can assure you this Rust library did not invent the term https://trends.google.com/trends/explore?date=all&geo=US&q=s...

Sadly all I'm constantly getting is "429. That’s an error."

https://en.wikipedia.org/wiki/SerDes

Re: Show HN: tere – A Faster Alternative to cd+ls

#186

Post by tux2bsd »

ghostly_s wrote: post #148

Do people actually still use cd + ls? At least in bash, you get a similar experience just typing a cd command and tab-completing the path elements - bash shows a listing of matches when your command is ambiguous, no `ls` required.I'll still check it out as I can see fuzzy-search being more useful but muscle memory is hard to change.

not entirely. e.g.

cd tab tab directories listed

cat tab tab files listed

(this^^ is on Debian, it can probably be changed but I've not looked into it)

it's pretty annoying when I'm halfway through and want to use tab tab as a periscope to see all file+dirs

Re: Show HN: tere – A Faster Alternative to cd+ls

#187

Post by [deleted] »

lloeki wrote: post #37

Congrats for getting this out! > I also wanted an excuse to learn This is the best reason ever, and not just for you: seeing your GIF I thought "could I achieve that with fzf?". Turns out, yes I can: function fcd() { local dir; while true; do # exit with ^D dir="$(ls -a1p | grep '/$' | grep -v '^./$' | fzf --height 40% --reverse --no-multi --preview 'pwd' --preview-window=up,1,border-none --no-info)" if [[ -z "${dir}…

[deleted]

Re: Show HN: tere – A Faster Alternative to cd+ls

#188

Post by alerighi »

nibbleshifter wrote: post #155
saagarjha wrote: post #144

Earlier quoted context omitted.

Atrocious but exceptionally battle-tested?

It was the best option a long while ago, and basically resulted in a kind of vendor lock in of sorts. Musl is far superior as a libc, but most Linux software is written for glibc and has quirks that make porting hard.

Musl is liked since it has a non-copyleft license and thus can be used to produce statically-linked executable that are distributed with proprietary licenses. Also Musl is smaller than GLibc thus more suitable for embedded systems.

Anyway, GLibc is just better, both in terms of performance (algorithms are more optimized, at the cost of a bigger executable size) and in terms of available features.

Re: Show HN: tere – A Faster Alternative to cd+ls

#189

Post by capdeck »

mgunyho wrote: post #40
lloeki wrote: post #37

Congrats for getting this out! > I also wanted an excuse to learn This is the best reason ever, and not just for you: seeing your GIF I thought "could I achieve that with fzf?". Turns out, yes I can: function fcd() { local dir; while true; do # exit with ^D dir="$(ls -a1p | grep '/$' | grep -v '^./$' | fzf --height 40% --reverse --no-multi --preview 'pwd' --preview-window=up,1,border-none --no-info)" if [[ -z "${dir}…

Thanks for the kind words! :) While digging up alternatives (of course after I had already written most of the functionality), I briefly tried out fzf. I think at that time I couldn't find an example snippet like yours to do the cding, so I didn't look into it much more. With some basic settings, it was also not easy (or even possible?) to go up in the folder tree, but I see that your example handles that. If you're…

What about `skim` - integrating it as a library? fzf is nice, but it is external - you have to pre-install and configure it.

Re: Show HN: tere – A Faster Alternative to cd+ls

#190

Post by enriquto »

alerighi wrote: post #188
nibbleshifter wrote: post #155

Earlier quoted context omitted.

It was the best option a long while ago, and basically resulted in a kind of vendor lock in of sorts. Musl is far superior as a libc, but most Linux software is written for glibc and has quirks that make porting hard.

Musl is liked since it has a non-copyleft license and thus can be used to produce statically-linked executable that are distributed with proprietary licenses. Also Musl is smaller than GLibc thus more suitable for embedded systems. Anyway, GLibc is just better, both in terms of performance (algorithms are more optimized, at the cost of a bigger executable size) and in terms of available features.

> Musl is liked since it has a non-copyleft license

Not only for that. As much as I love copyleft, I'm really happy that musl exists so that I can easily test my programs locally for portability. Compiling stuff with different compilers and libraries exposes at once all sorts of weird bugs before you get to publish your codes.

Post reply on HN