Desk: A lightweight workspace manager for the shell | Hacker News Reader

Desk: A lightweight workspace manager for the shell

github.com

124 pointsingve26 comments

self plug: http://direnv.net/ does basically the same but without having to start new sub-shells. Just `cd` into a folder, if it has an .envrc file it's loaded. If you `cd` out of the folder all the changed environment variables are restored.

Very cool project -- definitely recommend anyone interested in desk checks this out.

From what I can tell, though, desk's design allows for slightly different uses: namely (because desk consolidates configuration into one directory), desk configuration is more easily shareable across computers. In order to recreate your direnv setup on another machine, you'd have to go and symlink all your direnv files manually (unless they're somehow embedded in the repos or folders you're working in).

Direnv doesn't (AFAICT) attempt to surface documentation for the shell files it executes, whereas a lot of desk's value is in displaying a quick reference for common tasks within a workspace.

Does it have a trust model to prevent loading a .envrc from unknown origin?

Yes, the file path+content checksum is verified against a whitelist before execution. Typing `direnv allow [PATH]` adds it to the whitelist.

I believe this was on the front page of HN 20 days ago. This time the URL has a hash fragment. See here for 9 comments:

https://news.ycombinator.com/item?id=10445461

Am I understanding this right? This is basically just a command to call bash scripts that live in a certain directory? Why not just use:

. path/to/ez_lisp.sh

----------------------

or use an alias like:

desk() {

  . path/to/$1

}

I'm a newb. So sorry if this is just over my head.

Yes and no... the details are a little different, because we're using subshells and not sourcing scripts directly in the current process (cleanup is easier that way -- you just `exit`). But in effect, yeah, this is minor window dressing around executing an initializing shell script in a sandbox. I find the interface and the doc surfacing useful.

In the nearterm I'm going to be working on supporting imports -- i.e., you `git clone` down a project that has a deskfile at its root, then you're able to import it (maybe as a fancy symlink) into your own deskfiles. That'd give you immediate, programmtic context for working on the project.

Looks like you're right. From TFA (in the Readme):

"I have a hard time calling this a "workspace manager" with a straight face -- it's basically just a shell script that sources another shell script in a new shell."

Or just a simple tmux session?

It's more than just a tmux session, because it's also setting up an environment for the "workspace" as well. You might even use it with tmux to quickly load the appropriate environment in a new session.

Worth checking out tmuxinator which essentially does this. The way I use tmuxinator, I just type 'mux <name>' and it'll load a tmux session with all my panes, directories, and applications loaded and running.

Or you can save up all of your tmux sessions and setup your environment. There's a way to save tmux session in disk.

I really want to support open source efforts. But I really can't if there's a project developed without any googling before the first line of code. We have terminal multiplexers. I don't know but I wouldn't be surprised if he had one when computer still meant big tubes and real typewriters being connected to screens. This project doesn't offer anything that screen or tmux can't do, as far as I understand the README. And it also doesn't mention its biggest two competitors.

Please, to save your own time and energy (if not the time and energy of other people) search for a solution before you build one. Only if you have found the two or three solutions that the community likes most and you are still unsatisfied, only then start coding. And set yourself a real goal about what your tool should be doing that the others don't.

In this example tmux is quite interesting. Screen was around for ages. But a few things were not possible with the screen code base, like splitting your screen in whatever way you want. And some things simply were not really user friendly, like the config. With this in mind a guy named Nicholas Marriott sat down and started coding his alternative.

That's how you do it. Stick his picture on your wall. Follow his path. Start with googling for your problem, not with coding.

PS: I think the idea of having different desktops in graphical shells in fact came from people wanting to have the terminal multiplexing feature in their graphical environment as well. So Desk is like taking your calculator apart to develop a method to calculate with pen and paper.

> I really want to support open source efforts.

That's great. But even if you don't, the beauty is that the code is out there now.

> Only if you have found the two or three solutions that the community likes most and you are still unsatisfied, only then start coding.

Nah. I mean, sure, if it was for an actual business decision or for something that directly affects productivity workflow, due diligence is warranted.

But I'm never going to tell someone that they shouldn't have made something. Tell them there's something better, yes. Tell them that a different project does it in a more intuitive or robust way, certainly.

This nose-thumbing trend of not just ignoring code you don't like, but actively discouraging the release of code you might not approve of?

Yeah, no.

I thought I said what's to do (to google). But maybe my English is just not good enough to express myself.

> Please, to save your own time and energy (if not the time and energy of other people) search for a solution before you build one. Only if you have found the two or three solutions that the community likes most and you are still unsatisfied, only then start coding.

I hope no-one reading this thread gets the impression that most open-source software engineers would agree with this. That's one of the beauties of the ecosystem -- everyone can code and publish what they damn well want.

> I really want to support open source efforts. But I really can't if there's a project developed without any googling before the first line of code.

How is your "support" of open source software negatively impacted by this, as you perceive it, malpractice? It makes choice of OSS solutions harder for you?

Yes, most agree with this. Before there was google it was called RTFM. And of course everybody can do what they want. There won't be an exam tomorrow of how many people have read my comment and got to the conclusion that yes, to provide value to the community it's a smart thing to find out what the community has produced first, and distinguish your addition.

Could you say the author didn't care about what he adds to the community? Sure you could. But then one had to wonder why he added his project to HN or wrote a Readme in the first place.

There are several things you are not getting. One of them is the totally unnecessary barrier to entry that your attitude would create. This is a community that is attempting to make itself more approachable and enterable, not less. There's nothing wrong with reinventing the wheel in your own time, especially if you learn from the experience.

Love tmux, fail to see how desk and tmux are related. I think you missed the point.

Wheb i boot up, i still have to ^R to cd to the right location, and then ^R again to "compile" etc.

I'm looking forward to trying this out, direnv (mentionned above) seems like an even better idea.

I have four directories which I frequently use. For one of them, I commit as let's say me@example.com and in the other three as me@example.edu.

So first of all, I have a bash function declared in my bashrc which takes one argument -- the domain -- and sets a few evironment variables such as GIT_AUTHOR_EMAIL and GIT_COMMITER_EMAIL.

Next I have one two-letter alias and three three-letter aliases which all cd to their respective paths and call the function to set the env vars.

Finally, I have two-letter aliases to git add, git diff, git commit, git push and so on.

Dead simple and works great. All I need is my bashrc.

You can actually save tmux sessions on disk, and you can script tmux, too. I have a tmux session that creates a directory if it doesn't exist yet, then it clones git repos there, then it creates a window for each of them, cds into it, loads the corresponding virtualenv (Python stuff), installs the required packages from a .txt file (also Python stuff) then prints me a tree of the last 10 commits and the current status of the repo (if it's not new I want to see if I forgot to commit something before I checked out the day before). All tmux. I only have to write "work<Enter>" into any shell and that's what I get.

Hope you could learn something, because that's the reason I'm writing here.

Nobody has asked you to support it and nobody is going to ask you for permission before writing something they want to use. I'm glad they shared us with us and I'm sorry you don't like it but that's not their problem and frankly whether you like it or not is none of their business or ours. I don't understand the frame of mind that makes someone comment on a freely produced and shared passion project with "you suck".

Regardless, this solves a very different problem to screen/tmux and they don't compete in any way. In fact IMO both would work best when used together.

There's a lot to be said for the features this tool DOESN'T maintain.

>But a few things were not possible with the screen code base, like splitting your screen in whatever way you want.

Does tmux improve over screen's `C-a S` / `C-a |` ?

I think in screen you can't have 4 panes in the same window, right? Hope that answers that question, because I'm not sure how to google what your two commands mean.

You can have four panes in the same window, I don't think there's any limit.

Those two commands bisect one pane two either horizontally or vertically, and they can be called repeatedly.

Reply on news.ycombinator.com