As it stands, I can’t quite understand;
Is Cygwin treated as a windows subsystem, or is it in itself a part of windows as well?
This opens other questions;
If it is, in fact, a subsystem; what do I do to include windows as part of that subsystem or vice versa; make cygwin a part of windows?
How do symlinks come into play?
Are symlinks the way to connect those two?
And do the permission settings also connect when you make cygwin a part of windows or vice versa?
Thank you in advance,
Sincerely
~D.Fairway
It is NOT a windows subsystem.
Cygwin is a user space POSIX enviroment
Further info on Cygwin Documentation
https://cygwin.com/faq.html#faq.what.what
https://cygwin.com/cygwin-ug-net/overview.html#what-is-it
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.
If I want to create a *nix symlink, I'll call symlink();, if i'm running a script on windows and I want to create a shortcut, I'd use Win32::Shortcut.
But what if I want to create a Windows shortcut if running a script from a *nix machine?
I'm accessing a SMB share on a Windows Server 2003 machine from my *nix machine.
Well, I don't know if Samba provides an API for that. On the other hand, Windows shortcuts are just .lnk files in a specific format.
It's been a long time since the initial question, but I've had the same issue and found a solution.
I wrote an application whose goal is to allow anyone to create lnk files from any OS.
I started writting it in bash and then I converted it in C (the sources are available).
It's still fresh, so except me nobody tested yet, but you can have a look here :
http://www.mamachine.org/mslink/index.en.html
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)
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.