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

161–170 of 206 posts

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

#161

Post by mixmastamyk »

chrismorgan wrote: post #139
mgunyho wrote: post #108

Earlier quoted context omitted.

Indeed, Python would be a good language to implement this in terms of ease of development, but it's very difficult to distribute a standalone binary (which I wanted to do). The built-in curses support of Python is also not cross-platform I think.

It’s a funny thing I’ve noticed about scripting languages: they’re generally easier to get going with yourself, but they’re horrible for distribution/deployment, and if you have to integrate code written in other languages (even C libraries with Python bindings, or similar—things like wxWidgets or GTK), that rapidly escalates to a nightmare . Meanwhile, ahead-of-time compiled languages like Rust and Go are simply a b…

There are several working options for packaging Python apps, some existing for twenty years. Sure, while a little more complicated than compiling a static executable, it is hardly a "nightmare." It's basically writing a config file, and adding another stanza to a Makefile or modern equivalent.

Reminds me of the idea regularly pushed here that you need a virtualenv even for thirty-line scripts. I read these kind of takes here often and am a bit baffled by them. Maybe it is because developers have lost administrator skills over time, that this feels like an insurmountable challenge?

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

#162

Post by bradwood »

eikenberry wrote: post #159
bradwood wrote: post #156

One of my pet peeves is CLI newbies who always have the need to cd into some directory before running a command. I learnt pretty early on that this was stupid. Just run your command from the repo root or $HOME.

To be fair most of those newbies are probably writing scripts that use relative directories so they require them being run in the same directory. Newbies tend to reinforce bad habits like that which makes it harder to break out of those ruts.

(cd ./some/path; ./script.sh)

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

#163

Post by omni »

jhgb wrote: post #97
omni wrote: post #76

Earlier quoted context omitted.

Serde is a common term meaning "serialization/deserialization," seems pretty descript to me.

You're saying it's "a common term", but I'd literally never heard it before a Rust library with this exact name appeared. Isn't this by any chance circular reasoning? That it became "a common term" because of this library? In that case you couldn't justify the name of the library by saying that it was "a common term" at that time.

I can assure you this Rust library did not invent the term

https://trends.google.com/trends/explore?date=all&geo=US&q=s...

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

#164

Post by mixmastamyk »

This is quite neat so I feel slightly embarrassed to share my low-tech solution. Just run a "dir" after each "cd" (which is my alias for "ls -l --si ...").

It's written for fish, but could be ported to bash easily:

    # cat ~/.config/fish/functions/cd.fish 
    function cd

        builtin cd $argv;
        if test $status -gt 0  # there was an error, stop
            return
        end

        # auto print dir info
        if test "$argv" != ""  # not home though
            dir
        end
    end
There's probably a way to optimize out the "test " call as well, but I haven't got around to it.

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

#165

Post by sayanarijit »

mgunyho wrote: post #142
chrismorgan wrote: post #139

Earlier quoted context omitted.

It’s a funny thing I’ve noticed about scripting languages: they’re generally easier to get going with yourself, but they’re horrible for distribution/deployment, and if you have to integrate code written in other languages (even C libraries with Python bindings, or similar—things like wxWidgets or GTK), that rapidly escalates to a nightmare . Meanwhile, ahead-of-time compiled languages like Rust and Go are simply a b…

That's true, although I think in the case of Go, it is a central design decision to make single-binaries easy so it's more of an exception to the rule. I don't think it's an inherent feature of scripting languages that they are hard to distribute. I'm pretty sure it's possible to package up a tiny Lua interpreter (or e.g. QuickJS) and all necessary scripts into a standalone file.

Lua is only a configuration language without luarocks. With luarocks, we're back to the root of the argument - dependency vs standard library.

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

#166

Post by topspin »

bscphil wrote: post #138
res0nat0r wrote: post #95

Earlier quoted context omitted.

Cargo.lock is the wrong place to be looking, there really are only 7 direct dependencies, https://github.com/mgunyho/tere/blob/master/Cargo.toml#L14-L... The deps for each of these packages is really out of the authors hands, this is really the same for any programming language though which need to pull in dependencies of their own.

That's true, but OP did ask a question "How come...". Your answer is that the Rust ecosystem is to blame for encouraging micro-dependencies, like Node.js, and not the author. I think that's a pretty reasonable take! But it doesn't mean that there's not a problem.

Code reuse was once considered a virtue.

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

#167

Post by sayanarijit »

mixmastamyk wrote: post #161
chrismorgan wrote: post #139

Earlier quoted context omitted.

It’s a funny thing I’ve noticed about scripting languages: they’re generally easier to get going with yourself, but they’re horrible for distribution/deployment, and if you have to integrate code written in other languages (even C libraries with Python bindings, or similar—things like wxWidgets or GTK), that rapidly escalates to a nightmare . Meanwhile, ahead-of-time compiled languages like Rust and Go are simply a b…

There are several working options for packaging Python apps, some existing for twenty years. Sure, while a little more complicated than compiling a static executable, it is hardly a "nightmare." It's basically writing a config file, and adding another stanza to a Makefile or modern equivalent. Reminds me of the idea regularly pushed here that you need a virtualenv even for thirty-line scripts. I read these kind of ta…

That static executable will basically contain the whole python interpreter with a huge standard library. Maybe makes sense for a gui app, but I'd avoid installing a whole python interpreter for each of my little cli tools.

Don't forget the startup time overhead of first loading a whole interpreter into memory, then loading a python program into the interpreter.

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

#168

Post by make3 »

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}…

you should put this on github

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

#169

Post by mixmastamyk »

sayanarijit wrote: post #167
mixmastamyk wrote: post #161

Earlier quoted context omitted.

There are several working options for packaging Python apps, some existing for twenty years. Sure, while a little more complicated than compiling a static executable, it is hardly a "nightmare." It's basically writing a config file, and adding another stanza to a Makefile or modern equivalent. Reminds me of the idea regularly pushed here that you need a virtualenv even for thirty-line scripts. I read these kind of ta…

That static executable will basically contain the whole python interpreter with a huge standard library. Maybe makes sense for a gui app, but I'd avoid installing a whole python interpreter for each of my little cli tools. Don't forget the startup time overhead of first loading a whole interpreter into memory, then loading a python program into the interpreter.

There are multiple options for these requirements as well. I understand that solutions are sometimes clumsy, but the end-user won't know the difference.

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

#170

Post by avgcorrection »

nonameiguess wrote: post #93
scrollaway wrote: post #34

Earlier quoted context omitted.

The "too many dependencies" meme is far too often an example of Chesterton's Fence. The answer to your question "How come a simple thing is more complex than I first thought?" is: "Because you've spent less time thinking about it than the author".

This isn't true, though. If this had been an older GNU utility, the dependencies likely would have been libterm and libc. Not because it would have been less complex, but because of the ecosystem choice in C applications to have larger, fully-featured libraries versus the micro-libraries Rust seems to have inherited from JavaScript conventions. Whether this is better or worse seems to be a matter of contention for a…

Doesn’t C come out of that weird do-one-thing-and-do-it-well culture?
Post reply on HN