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.
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."
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.
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.
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?
> 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.
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.
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.
