Hacker News new | comments | ask | show | jobs | submit login
Show HN: Funky – Easier, flexible, and more interactive shell functions (github.com)
78 points by bbugyi200 3 months ago | hide | past | web | favorite | 23 comments



"Python Meets ZSH" is a very weird way to describe this. What this looks like is more of a zsh alias/function manager.

Which is pretty cool, btw! But if you are actually interested in "Python Meets ZSH", have a look at Xonsh instead :)

https://xon.sh/


You beat me to it, was gonna mention xonsh too...


took me forever to actually figure out what this software is supposed to do. the gif intro was too fast and hard to read on my phone. consider adding one or two sentences summarising project


Yeah, you're completely right. Even though I've found it really useful myself, I've had a hard time explaining exactly why its useful. I plan on adding a better description section soon as well as a blog post with more extensive examples.


Phones are BAD, limited and limiting platforms :-)

Not your faults but we all need to ditch from those black boxes if we want to evolve instead to go to well colored jails.

Anyway IMO the best description is: "wrapper to execute scripts in a context depending on local directory instead being shell-wide, simple CLI provided to use and manage all scripts."


Could you explain it then? Just gave up after a few moments...


Funky manages funks, which are just basically (exactly really) shell functions. What makes them cool is how easy they are to define and the way that Funky manages them.

One of it's key features is that it enables you to define shell functions that are local to a specific directory, but Funky also does a bit more behind the scenes to add some value. For example it also:

* Checks for aliases of the same name and disables them if any exist (this can cause annoying ZSH errors if you tried to define the function manually).

* Appends special bash paraemeters (e.g. "$@") when appropriate so funks act more like aliases without the drawbacks.

* Tries to predict how ZSH completion should be defined, running a `compdef` command if it succeeds. (It needs a little more work in this area I think.)

And I think there's definitely some potential for greater functionality going forward.


Nice, I'll give a try :-) IMO it's another step toward a transformation from classic shells to modern REPL, xonsh is one, eshell (Emacs) is another and probably many others exists.

Traditional shells have some nice things mostly due to the power of UNIX software, but also limitations for the very same reason.

Personally having choose to live in Emacs I notice a significant reduction of shell usage, eshell included, but it still can't substitute a real terminal for me, I tried xonsh and find the same: sometime python power rocks, sometimes does not. Perhaps we still need many new step before achieve a new game changing interface...


What the hell is a “funk”?

I’m getting tired of people making up ad-hoc cutesy names for no reason whatsoever. E.g. why do we call Rust packages “crates”?


This person's project is called "funky" and it involves a new approach to creating shell functions. It doesn't take great linguistic genius to intuit what a "funk" might be.


When Mozilla Firefox was new, a friend told me she wouldn't use it, because the name sounded like it was invented by a five year old boy. "Internet Explorer" was a much more sensible name, she said. I disagree with her about that, but not sure where I stand on your argument.


Well, Firefox is sensible compared to Iceweasel.

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


Technically, rust’s packages are called packages, and they’re made up of one or more crates.

“Compilation unit” just doesn’t roll off the tounge the same way as “crate.”

(And “funk” is how many pronounce “func” as in “function”, they’re using the short name to reinforce the tool’s name. That’s not “no reason.”)


But a lot of people already know what a "compilation unit" is, or have heard of it, or have some intuition for what it means. So why make up a new word for it?

"Rolls off the tongue" is at best an "eh" reason, at worst just an opinion about how a word sounds to some people, which isn't a very strong argument for coming up with new words.


Naming things is a classically hard problem in our field. There’s always room to improve.


So why is "crate" such an improvement over "compilation unit" that it warrants inventing a new term? Especially when a large number of engineers learning Rust come from a language that uses "compilation unit"?


More come from those that don’t than those that do, these days.

Conciseness is a virtue. Additionally, “compilation unit” can also be misleading; for example, incremental recompilation compiles just a portion of a compilation unit, so it’s not really a unit anymore.


Well, it's 1 syllable instead of 6.


It's a stronger argument than I’m getting tired of...


See, “compilation unit” tells the uninitiated reader many things: it’s something that gets compiled or at least has to do something with compilation. And it’s a “unit”, so it’s probably a chunk of source code that gets compiled together. It brings to mind analogous concepts from other languages/ecosystems so we can place it somewhere in our mental model from the outset.

On the other hand “crate” tells you nothing at all.


>E.g. why do we call Rust packages “crates”?

This is off-topic, but I was curious enough to go looking. It seems there has been a thing called a "crate" ever since the first commit in Graydon's personal repo [1], though I'm not sure it had the same meaning as it does now.

[1] https://github.com/graydon/rust-prehistory/commit/b0fd440798...


Well, it's a shell.

PATH is a global namespace. We probably shouldn't just go making ambiguous binary names to be used by a shell.

Granted, that is just a weakness of shell design.


How is this any better than the usual bash C-x C-e?




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: