I've found a few (unfortunately, they are bookmarked at home and I'm at work, so no links), but I was wondering if anyone had any opinions about any of them (love it, hate it, whatever) so I could make a good decision. I think I'm going to use Cygwin for my Unix commands on Windows, but I'm not sure how well that's going to work, so I would love for alternatives and I'm sure there are people out there interested in this who aren't running Cygwin.
These work very well for me: http://unxutils.sourceforge.net/.
Cygwin is not so good on Vista or 64 bit, so I stopped using it a while back.
I use Cygwin, but I have used the Berkley Utilities in the past. They worked well enough, if you are used to DOS and you just want the commands. There are some alternatives listed at TinyApps.
Maybe you could also consider running a command line version of Linux in a virtual machine? Colinux is also an option, but it's immature.
Powershell is what you are looking for, it contains aliases for a lot of UNIX commands and a lot more besides.
John
UnxUtils isn't updated as often and isn't as complete as Cygwin but runs natively just like any other Windows command line utility.
Cygwin acts more like a Linux command line emulator. It does feel pretty clunky but it is easier to port utilities to it and this is more complete than UnxUtils.
I personally don't like Cygwin. It really does seem to be wanting. Unless it has some specific tool you want that only works in Cygwin I'd find native ports.
http://www.activestate.com/Products/activeperl/index.mhtml is a nice Perl package for Windows.
http://www.locate32.net/ - I've always liked locate. Much faster than Grep for finding files by name.
Microsoft distributes a UNIX API compatibility layer for Windows NT-based OSes, as well as many common UNIX command line utilities that run on top of this compatibility layer. Unlike Cygwin, it doesn't sit on top of the Win32 subsystem, but instead interfaces with the NT native APIs directly. It supports features that may be difficult to implement on top of Win32, such as case-sensitive filenames and fork().
The Windows 2K/XP version is called Windows Services for UNIX (SFU). SFU is a free download from Microsoft, and also includes an NFS server and client.
The Windows Vista version is called Subsystem for UNIX-based Applications (SUA). SUA is included in the Enterprise and Ultimate editions of Windows Vista, but does not include any NFS support.
Neither SFU nor SUA include an X server. It is possible (but possibly ironic?) to use the free Cygwin X server with SFU/SUA applications.
The Wikipedia entries on SFU and Interix have more details and history.
Linux/BSD :)
Why vote down this question? It's obviously meant to be tongue in cheek is it worth the voter and the receiver losing rep over? Can't you people leave anything at zero and mark up the answers you want to see float rather than mark down the funny one liners?
In answer to the question I've used Cygwin in the past but always found it clunky and wanting. I don't think it's the tools problem but mine but I have book marked Eric's suggestion of unxutils for when my new windows machine arrives tomorrow.
I use Cygwin alot.
I use it for any mvn commands, find, grep, perl scp and all the other stuff i got used to use all the years I only worked on FreeBSD desktops and servers.
I have my old .vimrc, .zshrc, my .ssh/config and all the other nice stuff. I use rxvt.exe instead of cmd.exe which made all the difference for me! Resize, decent buffer, fonts and so on.
andLinux is a distribution of coLinux, which runs the entire Linux kernel inside Windows (with better performance than a VM). Then, with the help of Xming (an X windows server for Windows), you can have Linux windows mingle along side Windows windows.
With that, pretty much everything Linux-based will just work. You're not limited to just the tools that have been ported to Cygwin, you can apt-get anything you want.
andLinux also includes a few niceties, such as desktop shortcuts to launch Linux apps, a launcher that lives in your tray, and context menu items (right click a text file and you can open it in Kate)
The downsides of andLinux are:
Accessing the Linux filesystem is tricky. You have to set up Samba in both directions.
Connecting to a Linux program from a remote connection is also tricky (but possible)
Related
Before I knew about the remote WSL extension for vscode, I had been using bash in it by selecting it as the default shell from the terminal option. What is the advantage of using remote WSL if all I wanted was to just use bash as the default terminal?
Hi Rohan and welcome to SO!
I'll have a shot at answering this, though someone more knowledgeable might have better insight.
When you load VSCode in windows, it accesses your various PC resources as windows resources. For example your files will be from the windows folder structure. Even if you use WSL bash as your terminal, VSCode is still acting on a windows basis.
If you use the remote WSL extension, it leverages VSCodes separation of UI and Backend by remotely starting a VSCode backend in the WSL layer, and connecting the windows UI to that backend ('remotely' although on the same PC). Due to running the backend in a linux environment, the files are loaded as linux files and handled via the WSL system, rather than normal windows access.
With regard to the question 'What is the advantage?' I would suggest the advantage is that now instead of having a split between VSCode in windows and command line in WSL, you now have both acting in harmony through WSL. It should provide some benefits (especially when WSL2 hits properly and performance increases) around things not messing in a windows manner on files you are trying to use in a linux way, and just make things feel a bit more connected.
However if you're using WSL bash just as a command line replacement and not using it for it's linux goodness (though I don't know if this would be the case), there may be less of an advantage.
It's a stepping stone to switching to devcontainers, which are really neat.
This page might help more, but that's my understanding! https://code.visualstudio.com/docs/remote/wsl
I am having issues with finding all of the necessary files to actually install Cygwin correctly when not using the premade setup utility. The reason behind this is the fact that my company computer blocks the usage of the .exe, and won't give me clearance to install it, (they say it isn't needed for the job) but expects me to perform certain tasks that Cygwin would make much simpler.
So my question is thus; is there somewhere/someone that would have a list of packages that I would need to manually install from one of the mirrors to make Cygwin run correctly?
Well,
This is a new answer to an old question, but it might be helpful for someone...
Just run the installer with -B switch, for example:
setup-x86_64.exe -B
You should install it then on a path where you have rights.
If you don't need the full POSIX compatibility (which I'm guessing you don't, if the Unix subsystem isn't required for your job), I'd generally suggest you go with Mingw rather than Cygwin.
Sadly, Mingw also has an installer these days. It probably also requires admin (try it and see). However, you can download the individual components you need if you want to do it that way. That shouldn't require admin, so it would probably get you exactly what you want.
Mingw is also more corporate-friendly from a licensing standpoint, as its compiler doesn't render code built with it GPL like Cygwin's does.
Generally the rule is:
If you want to use Unixy tools to help with your native Windows development, you want Mingw.
If want to port a full (POSIX) Unix program to windows, you want Cygwin (and perhaps a support deal with Red Hat to get around the licensing problem).
There's a writeup on getting Cygwin [to work] on portable storage devices.
Boiling it down, you'd have to do this on a machine that does give you .exe/admin access to write to a 'stick, then run from the stick at work.
On the off-chance that super-lockdown-site allows you to run USB devices.
Use the GNUWIN32 utilities instead. http://gnuwin32.sourceforge.net/
That way you can choose only the .exe installs that you need, and it will be much easier to justify specific utilities than a humongous system install. If you hunt around on the site you can find the files directory where you can download a single utility, and if you get the -bin.zip version, then you can extract just the needed .exe file which would be even easier to justify and would not require your IT people to test an untrusted install package.
Stupid draconian rules or no, I would not recommend trying to thwart your employers rules. Try working to improve the situation or find another one.
But technically speaking if you can get a complete Cygwin install somewhere, you can copy the entire cygwin folder enmasse. There are a few things that you will want to change similarly to how I configured my cygwin installation to run from a thumb drive. I actually installed on my HD, copied it to the thumbdrive and then changed the batch file and a few other things to make it work. Here are the details: http://fadedbluesky.com/2011/portable-cygwin/
You could try installing it on another machine outside of work. After installing, copy the installed product's tree and Registry keys and environment settings to a CD or flash drive. Then you would have a DIY installation that you can copy and import settings manually. The installer doesn't do a whole lot else.
Don't count on job security if you're bypassing IT mandates after being explicitly told no, though. Getting an exception to the rule by submitting proper documentation through the proper process is usually the way to go.
You'll also have to hope that they aren't blocking the Cygwin programs and any Registry edits as well. It's not hard to find this sort of thing on a machine, either.
I have to start using CVS at my new company so that I can play nicely with the developers who are all *nix users. I happen to be a Windows Vista user and unfortunately do not have the ability to switch anytime soon. I am also not exactly a command line guru yet, so any simplified method is ideal for me.
I discovered TortoiseCVS today and it seems pretty straight forward, even though it says it is not directly supported on Vista, which worries me a little.
My questions:
Do you use CVS on Windows (Vista)?
What method do you use? (Tortoise CVS? Another option?)
Does your method get along well with repositories setup on/by *nix machines?
Any other advice for the noob? (Thanks)
I know many people who required a gentle introduction to cvs and ended up using WinCVS with no real difficulty. I know many others who are using the cvs client in Eclipse. This usage includes projects which are not otherwise managed by Eclipse. As for myself, I stick to the command-line myself because I feel the lack of GUI abstractions helps me to always understand exactly what CVS is doing. All three solutions work well on Vista, 32 and 64 bit. Our shop uses Mac, Linux, Solaris, and Windows, with the server on a Linux machine, and we never have any problems with compatibility.
There's one issue you should be aware of regardless of your choice of cvs client for cross-platform goodness, though. Most cvs clients convert between Unix newlines (on the server) and Windows newlines (on the client) by default. You should understand that this conversion is happening and be aware of the consequences.
This conversion will cause real problems if you try to commit a file with Unix newlines. So, you need to avoid, for example, copying files from a Unix repository to your Windows box, editing them, and committing them unless you've done the newline conversion. We had some real problems with this in my shop, and I instituted a strict policy that people should only communicate files between machines by committing them to CVS. Never, for example, by email, shared network directories, etc.
If your CVS repository has any binary files, some may not have been properly tagged as binary files. In *nix-only shop, nobody would notice, as the binary flag won't affect most binary files. But in a cross-platform shop, the binary flag routinely affects how cvs treats files, since it will disable any attempts at newline conversion. Typically, any file which was committed from a Unix box will be correctly represented in the repository, so you can fix the problem on the Windows end by merely changing the tag and re-updating. I.e.,
cvs admin -kb file
cvs update -A file
There are some other avenues you can take to interact with your *nix bretheren.
Install VirtualBox and a distribution of Linux so you can natively run the same toolset.
Install VirtualBox and a copy of Windows XP, which is known to work with TortoiseCVS.
You can find VMWare appliances pre-loaded with a linux distribution, which you can import into VMWare Player or VirtualBox. From there you just need to connect up to your shared drive the same way that they do.
Please note that CVS is no longer being maintained. You should really be moving to SVN, git, or some other version control system.
If you're using an IDE like Visual Studio or Eclipse, you should look for the appropriate plugin that integrates with your environment. Those might be better supported (though TortoiseCVS is likely just fine, even if the developers don't want to make any claims).
I'm doing a fair bit of work in Ruby recently, and using
ruby script/console
Is absolutely critical. However, I'm really disappointed with the default Windows console in Vista, especially in that there's a really annoying bug where moving the cursor back when at the bottom of the screen irregularly causes it to jump back. Anyone have a decent console app they use in Windows?
I use Console2.
I like the tabbed interface and that copy works properly if text breaks at the end of a line.
Are you resizing the console window? I've found that the ruby scripts (irb, etc) that use the readline library don't work correctly with resized console windows (in XP or Vista).
Effectively I believe that the readline library expects the console window to be 80 characters wide, anything else and it goes bezerk. So far I haven't found a way to fix it on windows without giving up other nice features.
I have had some pleasant experiences with rxvt (comes with cygwin, does not need an x server running). Putty is also often mentioned as a good alternative.
You could also try to get xterm working :)
Powershell
Windows PowerShell is Microsoft's task automation framework, consisting of a command-line shell and associated scripting language built on top of, and integrated with the .NET Framework. PowerShell provides full access to COM and WMI, enabling administrators to perform administrative tasks on both local and remote Windows systems.
As a LAMP developer considering moving to a .Net IIS platform, one of my concerns is the loss of productivity due to lack of shell... Has anyone else had this experience? Is there possibly a Linux shell equivalent for Windows?
Depending on what version of IIS you're considering, I would second lbrandy's recommendation to check out PowerShell. Microsoft is working on a PowerShell provider for IIS (specifically version 7). There is a decent post about this at http://blogs.iis.net/thomad/archive/2008/04/14/iis-7-0-powershell-provider-tech-preview-1.aspx. The upcoming version of PowerShell will also add remoting capabilities so that you can remotely manage machines. PowerShell is quite different from *NIX shells, though, so that is something to consider.
Hope this helps.
Are you asking about Linux shell as in an environment to work in? For that CygWin I think has been around the longest and is pretty robust: http://www.cygwin.com/
A while ago I found a windows port of all the popular linux commands I use (ls, grep, diff) and I simply unzip those to a file, add it to my PATH environment and then can run from there: http://unxutils.sourceforge.net/
Or are you talking about executing shell commands from within your code? If you're in the .NET sphere, there is the Process.Start() method that will give you a lot of options.
Hope this helps!
I assume you don't mean cygwin, right?
How about powershell, then?
If you're referring to simply accessing your IIS server from a remote location, remote desktop generally solves that problem. Assuming your server has a static IP address or a host name you can access from the internet, remote desktop is a simple and relatively secure solution.
Is there a problem with this answer? Now I have negative reputation...
The best way I can think of would be to use Cygwin over an OpenSSH connection.
Here's a document that explains how to do just that:
http://www.ucl.ac.uk/cert/openssh_rdp_vnc.pdf
Remote shell doesn't solve the productivity issue. (It merely makes things possible.)
From what I've heard, everything that the future Microsoft GUI:s do will be possible to do with powershell since the GUI:s use the same API:s as those that are available from powershell.
Personally, I love cygwin but cygwin can not help you manage Microsoft applications.
You might be surprised, however, how powerfull the Windows Scripting Host is when coupled with Window Management Instrumentation. I think IIS is fully manageable with WMI or some COM objects that can be easilly used from a JScript WSH script.
You should make your choice of server platform based on the environment as a whole, and that includes the admin/management interfaces supplied.
I'm afraid that if you don't like the way Windows implements management of IIS, then that's too bad. Having said that, a bit of delving around in the WMI interfaces will generally yield a solution that you should find usable. I used to do quite a bit of WMI scripting (mostly via PowerShell) in order to have a reliable environment rebuild capability.
If you want a Linux shell on Windows, install the Windows Subsystem for Linux on Windows 10 :
The Windows Subsystem for Linux lets developers run a GNU/Linux environment -- including most command-line tools, utilities, and applications -- directly on Windows, unmodified, without the overhead of a traditional virtual machine or dualboot setup.