71–80 of 95 posts
Earlier quoted context omitted.
Cygwin gives you (seamless) access to the Windows file system. Is it possible to (say) 'sed ... | wc' a file in the host's directories from a VM?
yes. for example in virtual box you can mount host's directory tree within the vm either in rw/ro mode. from then on, things are seamless.
Earlier quoted context omitted.
Being able to use a real shell with all the tools I'm used to when developing on Windows. Cygwin in combination with MinGW and the Windows native version of GVim lets me have almost exactly the same environment as I do on Linux and Mac OS X.
You could mount the Windows filesystem from the Linux VM, and use the shell tools that way. I agree, though, it's still better to have Cygwin, because you can alt-tab and such.
Earlier quoted context omitted.
I recently decided to learn ed, as I felt it couldn't hurt to be familiar with it, and I was surprised to see that it wasn't installed in Arch Linux by default.
If one has bash as the default shell, why not ex as the standard line-oriented text editor? Postscript - ex is the version of ed rolled up in vim, which extends the command set of ed. vi, by contrast, handles colon commands by invoking ed externally.
Is there an SSH server for Windows that will work with this?
Earlier quoted context omitted.
I recently decided to learn ed, as I felt it couldn't hurt to be familiar with it, and I was surprised to see that it wasn't installed in Arch Linux by default.
If one has bash as the default shell, why not ex as the standard line-oriented text editor? Postscript - ex is the version of ed rolled up in vim, which extends the command set of ed. vi, by contrast, handles colon commands by invoking ed externally.
Actually vi and ex came about at the same time. You can see the POSIX standard mentions [1] ex and vi (not vim) together, and you can also refer to [2], under the "First appeared" column.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex...
We really need to port Homebrew to Windows so that projects like this can be the base, but people can pull in packages on top of it, like a lightweight Cygwin but more Windows'y.
"apt-cyg is a command-line installer for Cygwin which cooperates with Cygwin Setup and uses the same repository. The syntax is similar to apt-get. Usage examples:"
"apt-cyg install " to install packages
"apt-cyg remove " to remove packages
"apt-cyg update" to update setup.ini
"apt-cyg show" to show installed packages
"apt-cyg find " to find packages matching patterns
"apt-cyg describe " to describe packages matching patterns
"apt-cyg packageof " to locate parent packagesEarlier quoted context omitted.
Everything you just said (packages are files, simple, uses existing tools for self update) applies to MacPorts too. The only real differences seem to be the use of Ruby, and an attempt to avoid replacing OS dependencies -- even if the replacements are newer. In fact, MacPorts actually supports generating Debian packages and an apt repository straight from its port files. As for Windows, Cygwin already provides binari…
Macports builds something of a sandbox, which from the users point of view is neither small nor simple. It is easier for the Macports team to make sense of bug reports with a sandbox, however, which is, I assume, why they do it. It is explicitly the reason they forbid installing to /usr/local.
Earlier quoted context omitted.
Macports builds something of a sandbox, which from the users point of view is neither small nor simple. It is easier for the Macports team to make sense of bug reports with a sandbox, however, which is, I assume, why they do it. It is explicitly the reason they forbid installing to /usr/local.
Macports used to not build this "sandbox", but learned the lesson that relying on Apple as your only source of updates to critical base libraries was fraught with peril: not only do you not get updates you might need ("upgrade to 10.6" is not a reasonable response to someone who just wants to use a project that needs a slightly newer version of libcurl), but sometimes Apple can ship changes that break compatibility w…
I do not like to criticise open-source projects, but the (reasonably polite) hostility that stating this simple fact has attracted does make me think that the supporters of Macports have stopped seeing things from the user's point of view.
If you want a packaging system whose job is to protect you from the risk of certain rare but possibly messy mishaps, then Macports might well be what you want. I recommend being less risk averse, and use a mixture of Homebrew and installing to /usr/local. It will cost some research and reinstall time now and then, but it will result in a system that is easier to get an overview on.
The talk I have seen of "destroying" one's system installing via Homebrew is pure FUD, and I do not know what lies behind it.
Earlier quoted context omitted.
If one has bash as the default shell, why not ex as the standard line-oriented text editor? Postscript - ex is the version of ed rolled up in vim, which extends the command set of ed. vi, by contrast, handles colon commands by invoking ed externally.
"ex is the version of ed rolled up in vim, which extends the command set of ed. vi, by contrast, handles colon commands by invoking ed externally." Actually vi and ex came about at the same time. You can see the POSIX standard mentions [1] ex and vi (not vim) together, and you can also refer to [2], under the "First appeared" column. [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex... [2] http://en.wi…