VMWare Unity mode
Anyone else tried this?? Took me a bit to get it to work with Ubuntu (Doesn't like Ubuntu Unity) but it was well worth it. I can now use my Windows, and have access to my bash shell without ever having to switch back and forth.
Bump. If anyone has experience here, I'm trying to figure out how (or if) I can get my Ubuntu keyboard shortcuts to work even though Windows is the host. I really just want to ctrl alt t to get my terminal up faster (as that's all I really care about anyway). Is this possible?
I suppose that you could try to change the host key http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008036
Or change the hotkey in the guest.
Also, guake
Or change the hotkey in the guest.
Also, guake
Last edited on
Can't you just use Cygwin? It seems kind of silly to run an entire OS just for a shell.
Cygwin doesn't integrate well with Windows because Windows isn't like UNIX, where the GUI sits atop regular command-line tools (which is a much, much better system). In Windows, the command-line is more of an after-thought, and Cygwin can't really change that. I would guess that this is related to why Windows programmers need an IDE. UNIX programmers don't, because UNIX is an IDE.
That must be why earlier today I was doing my own preprocessing of a source by passing it through several layers of sed, grep, and m4, all without leaving the regular Windows command line. Because Cygwin doesn't integrate well.
What does one thing have to do with the other? If there's any reason why emulation isn't flawless is because UNIX's file hierarchy isn't quite like Windows'. Other than that, Cygwin has bee dragging its feet on certain features, like symlinks and hardlinks.
There's certainly no reason why the design of the GUI should have any effect on the behavior of the command line. The idea is just ludicrous.
If I could roll my eyes any harder, they'd probably pop out of my sockets.
| Cygwin doesn't integrate well with Windows because Windows isn't like UNIX, where the GUI sits atop regular command-line tools |
There's certainly no reason why the design of the GUI should have any effect on the behavior of the command line. The idea is just ludicrous.
| I would guess that this is related to why Windows programmers need an IDE. UNIX programmers don't, because UNIX is an IDE. |
| helios wrote: |
|---|
| That must be why earlier today I was doing my own preprocessing of a source by passing it through several layers of sed, grep, and m4, all without leaving the regular Windows command line. Because Cygwin doesn't integrate well. |
I don't remember saying it wasn't possible to use pipes, or that you couldn't have Cygwin's /bin in your PATH. That's not what I was talking about. I'm not talking about Cygwin integrating with the cmd, I'm talking about cmd (and Cygwin) not integrating with Windows' GUI at all.
What does one thing have to do with the other? There's certainly no reason why the design of the GUI should have any effect on the behavior of the command line. The idea is just ludicrous. |
I don't see what you're talking about in either of these sentences.
| If there's any reason why emulation isn't flawless is because UNIX's file hierarchy isn't quite like Windows'. |
That's one way to put it. I know that the way Windows organises programs is more neat-and-tidy, but program binaries not being in the PATH by default is extremely irritating, and the extra organisation you get from encapsulating programs into a separate directories loses to the benefits of having every executable in one of a few well-defined directories, and then having all the configuration files in another, and so on. For one thing, you don't have to have shortcuts to executables everywhere.
| Other than that, Cygwin has bee dragging its feet on certain features, like symlinks and hardlinks. |
I don't see how Cygwin would implement symlinks and hardlinks. Although hardlinks are actually supported natively by NTFS, Windows doesn't have symlinks, it has shortcuts, which are completely different and nowhere near as useful.
If I could roll my eyes any harder, they'd probably pop out of my sockets. |
Good refutation. It's a joke, but it's still true, UNIX can be considered an IDE. Every development tool is a single command away.
Last edited on
| I'm talking about cmd (and Cygwin) not integrating with Windows' GUI at all. |
| That's one way to put it. I know that the way Windows organises programs is more neat-and-tidy, but program binaries not being in the PATH by default is extremely irritating, and the extra organisation you get from encapsulating programs into a separate directories loses to the benefits of having every executable in one of a few well-defined directories, and then having all the configuration files in another, and so on. For one thing, you don't have to have shortcuts to executables everywhere. |
I was referring to the fact that Windows doesn't make absolutely everything accessible from a single directory tree. Possibly permissions could be a problem, too.
| I don't see how Cygwin would implement symlinks and hardlinks. |
| Windows doesn't have symlinks |
| UNIX can be considered an IDE. Every development tool is a single command away. |
I don't think anyone would agree that this counts as "integrated". The tools don't necessarily interact much with each other, for one. You won't be able to, in vi, step through a program running in gdb by simply running vi and gdb, for example. I'm not saying it can't be done, I'm saying it's not a behavior that follows ipso facto from running the programs under UNIX.
Also, any system can be configured to run programs to any desired level of convenience. An IDE should do more than the basic OS functions.
closed account (1yR4jE8b)
Windows has supported symlinks in NTFS since Xp via the linkd command, and vista onward using mklink.
As much as I enjoyed reading this debate, it doesn't really apply to what I'm using it for. I have applications I use on a day to day basis at work that run from Windows, though I also use *nix for various things. Such as SSH is the major one, and I much prefer to use a *nix SSH from the CLI as opposed to using Putty on Windows (has issues with some of the network equipment I work with, for some reason). Also have servers that run on *nix (such as our SNMP server which I deal with on occasion) that it just feels more natural to SSH from a Linux environment than an emulation on Windows side.
But then again, I have never used Cygwin. I might grab that today and see how it works.
But then again, I have never used Cygwin. I might grab that today and see how it works.
| helios wrote: |
|---|
| File symlinks have been supported since Vista. Directory symlinks since XP, if not earlier. Check mklink. |
| darkestfright wrote: |
|---|
| Windows has supported symlinks in NTFS since Xp via the linkd command, and vista onward using mklink. |
Ok, never mind. I'll be using that a little more. I knew NTFS supported hardlinks but I though Windows' idea of a symlink was a .lnk file.
| I was referring to the fact that Windows doesn't make absolutely everything accessible from a single directory tree. Possibly permissions could be a problem, too. |
NTFS does actually support mounting volumes, i.e., you could mount D: to C:\D. I don't know the command, but it's possible since Windows 2000: http://en.wikipedia.org/wiki/NTFS_volume_mount_point
What I was talking about with the PATH thing is that on UNIX you can run any program from the command-line if it's installed to the correct directory. On Windows, programs install themselves all over the place (Chrome, for example, installs to your AppData folder for some reason, and I don't think there's an option to change it) and rarely add themselves to the PATH. Windows doesn't rely on its shell. The shell seems like it's there as an afterthought, whereas on UNIX it's at the forefront of the system. You can get away with only ever using the GUI most of the time on most distros, but you're still using the command-line tools indirectly because GNOME et al. use them. The GUI sits on top of the text UI. I think that's a better system, especially for programmers.
| helios wrote: |
|---|
| Come to think of it, hardlinks are actual system hardlinks, I think. |
When you make a new file, the fs allocates a new inode and then puts the file's name and inode number in the directory listing (directories on UNIX are text files containing a two-column list of inode numbers and filenames). When you make a hardlink, the fs doesn't allocate a new inode, it puts the hardlink's name and the target's inode number in the directory. I like to think of hardlinks as C++ references, and symlinks as pointers.
Symlinks are simulated with regular files that contain the path to the target. This can be pretty annoying if you're untaring something with links inside.[/quote]
| helios wrote: |
|---|
| I don't think anyone would agree that this counts as "integrated" |
Lots of people agree. Here's an article about it (admittedly it doesn't argue the point very well): http://blog.sanctum.geek.nz/unix-as-ide-introduction/
Topic archived. No new replies allowed.