Hacker News Reader

Comment by mlangdon | Hacker News Reader

For those stuck with windows for some reason, note that Cygwin[1] is a not too painful way to get that *nix feeling. Note that things get a little weird if you start, e.g., running python from Cygwin.

[1] http://www.cygwin.com

View on HN

If I may offer a dissenting opinion?

If you are on Windows, you would gain quite a bit more from learning Powershell, not Unix. Powershell has taken many lessons from Unix, and (dare I say) improved on many things. It's absolutely worth learning, if you are going to work extensively on Windows.

This is probably true, if you're mostly only going to work in Windows.

But if you're going to work in *nix and Windows, your bash/cygwin skills/experience will be useful in both locations, and much of your work will be reusable between the two worlds.

Powershell is Windows-only, which is fine if your life is Windows-only or Windows-heavy.

Not that there's anything wrong with knowing and using Powershell.

I would submit that using the native shell and scripting language of the Microsoft ecosystem might be beneficial for those working in that ecosystem [1].

Here's a nice response to the question of whether PowerShell is ready to replace Cygwin [2], circa 2009

Cheers!

[1] https://ramblingcookiemonster.wordpress.com/2013/12/07/why-p...

[2] http://stackoverflow.com/a/573861/3067642

There are plenty of times you will be stuck with platform in one setting when you don't use it otherwise. Obviously, in this situation, it's better to focus on something that will run on both platforms, even if it can be iffy on one of them.

The grandparent clearly frames it like this; "if you're stuck with Windows...". He's not saying "If Windows is your choice of operating system...".

How does it get weird with python? I do this day in, day out. I installed cygwin's python. When I'm in cygwin that's the python that runs, and when I'm in Windows it's my Windows python that runs.

Virtually all the scripts I write run without problems in either environment, because it's python. Scripts that other people wrote for Windows run fine in cygwin. There are occasions where I have to account for differences in the OS, but mostly never.

I'll give an anectode from just last night. I wanted to fetch some online video, so I went ahead and downloaded youtube-dl-*.tar.gz, extracted it, and then tried to run it, all inside a cygwin session. For some reason, it did nothing. I ran file on the script and it claimed it was a data file. I run less on it and damn, it's a binary file. I was definitely surprised but didn't want to waste more time on it after fiddling for 10 minutes, I run the native Windows Python on the exact same file and it just worked.

I didn't look back so I don't know what was the main reason but I can say there are some problems.

  2424  pip install youtube-dl
  2425  which youtube-dl
  2426  youtube-dl --help
  2427  youtube-dl https://www.youtube.com/watch?v=WS-JcaPFzp4

  [youtube] WS-JcaPFzp4: Downloading webpage
  [youtube] WS-JcaPFzp4: Extracting video information
  [youtube] WS-JcaPFzp4: Downloading DASH manifest
  [download] Destination: The Renaissance and the cuckoo clock-WS-JcaPFzp4.mp4
  [download] 100% of 7.98MiB in 00:02

  2428  python --version
  2429  which python
  2430  history |tail

This worked fine for me. It installed, help was available, I downloaded the video and watched it.

I suspect one of two things, although it could be something else. You might be using the windows installation of python, rather than the cygwin installation. In most cases that works fine, but cygwin's python is compiled to expect a cygwin/unix-like environment, and windows python is compiled to expect windows. Sometimes weirdness ensues, and it's better to use cygwin's python in cygwin.

My other suspicion is that the installation of youtube-dl didn't happen correctly. Notice above that I used pip, which is offered in the installation instructions. If you've installed pip that's usually your best/first option. Their first instructions involve downloading the gz (as you did). I did that with wget in python, then noticed the installation is an extraction and a chmod; I'm usually more comfortable trying pip in that circmstance.

I've placed my email in my profile if you want to chat about this. I'll leave it there until I remember to remove it.

Edit: you can run the python shell, and it will summarize python's construction:

  $ python
  Python 2.7.8 (default, Jul 28 2014, 01:34:03)
  [GCC 4.8.3] on cygwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>>

From a windows cmd.exe shell:

  python
  Python 2.7.6 |Anaconda 2.1.0 (64-bit)| (default, Nov 11 2013, 10:49:15) [MSC v.1500 64 bit (AMD64)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>>

Followup: I discovered/realized that, even though I was using cygwin's python, the windows python (Anaconda in my case) was still in my cygwin path, because the cygwin path has the windows path elements in it. You can see that if you run this, and see two pythons:

  which -a python

I discovered this when I ran pip and ipython in cygwin, and they "worked," i.e. something ran, but not right.

I put this at the end of my .bashrc to remove windows python from cygwin's path:

  export PATH=$(echo $PATH |sed -e "s/:[^:]*Anaconda[^:]*:/:/g" |sed -e "s/:[^:]*Anaconda[^:]*:/:/g")

There were two anaconda directories in the path, and /g should have taken care of both, but my RE-fu is apparently lacking, so brute force.

Cygwin has pitfalls.

Sorry I just saw your reply and I'm not on Windows right now. I'll check when I boot it.

Reply on news.ycombinator.com