Linux-flavored Windows | Hacker News Reader

Linux-flavored Windows

eamann.com

41 pointseamann48 comments

This is a weird article. It ignores powershell entirely and I really disagree about cygwin being this bloaty and difficult thing to install. If you just want basic unix utilities then cygwin is a breeze to install and use.

On top of it, you can download compilations of standard gnu unix untils at sourceforge compiled for windows. I have a standard unixutils folder on the c: root of the drive of all my computers so I can easily access stuff like wget, netcat, grep, etc. Works well enough.

Scripting in Powershell is nothing like scripting in Bash. I like and use Powershell on a daily basis - but can't re-use my PS scripts on a Mac because the shells are nothing alike. The point was to achieve OS parity.

For a newcomer, no, Cygwin is not a breeze to install and use. The documentation is abysmal, the download takes forever (unless you know ahead of time which tools to install and which to omit), knowing which packages to install to enable specific features is impossible for someone without experience, and there is no native uninstaller.

Why is this person even bothering to use windows instead of running a unixy desktop plus wine or Windows in a VM? For your requirements, its asinine to buy a windows box. If you're working in windows, might as well spend 20 minutes learning the basics of powershell. Not sure why this is a controversial suggestion. Leave windows if its all too bothersome.

This is directly addressed in the article. He is a .Net developer.

So am I for pay cheque reasons.

For the sake of sanity though, I use Linux with a windows VM.

Sometimes you also need programs that don't have good Linux versions and bad Wine support. I tend to find GUI heavy applications are a pain to use in a VM.

Agree, apart from PowerShell which is a bastardised mutant crawling snail spawn of satan. It's like using a VAX 11/780 over a 300bps dialup. SMS messages have a higher throughput.

This is almost entirely because it uses the CLR which has terrible inefficiency due to immutable strings, the CLR startup time and insane cost of reflection.

> the CLR which has terrible inefficiency due to immutable strings, the CLR startup time and insane cost of reflection

That's true, PowerShell is slower than bash. It does more, and that has a cost.

That said: it's by far the best designed shell in terms of syntax, and actually separating presentation from logic.

Eg, print me a list of processes started in the last hour (from memory, I don't normally use Windows)

    ps | ? StartTime -gt $1HourAgo | kill

Notice the lack of silly things like creating regexs to represent time?

Unix shells are MS Word. Powershell is LaTeX.

And look at all the people who use LaTeX!

(This is pretty much a textbook example of the New Jersey worse-is-better style...fitting, since it involves Unix directly.)

Absolutely not. It's terrible. Some more reasons to hate it:

1. It can throw a message box or prompt on the screen without any notice. Precisely how this is handled from a scheduled task is "interesting".

2. If you're non US locale, you get different date formats pop out of get-date, gci and CLR DateTime. This at some points in time scares the living fuck out of me as an implicit cast to string can swap day/month around.

3. Changes every year or two. Features features features. Gotta learn them all. Pokemon time.

4. Module system is a piece of shit.

5. Signing is so friction inducing that everyone just turns it off to get shit done.

you compare to bash here. Bash doesn't do much at all. This is the point. It leverages other tools to do the work. In your example you mention regex for parsing dates. This is a bad approach. "date +%s" returns sortable integers which you should work with.

PowerShell is Word. LaTeX is a felt tip. Bash is a fountain pen and a steady hand.

Totally agreed re: module system and interactivity. As I mentioned, it's only in terms of syntax I think Powershell is excellent.

> "date +%s" returns sortable integers which you should work with.

Date returns text, not integers. Your shell doesn't understand that there are not more than 60 seconds in a minute.

You might argue that people shouldn't use a shell to parse dates, and pass the text onto a proper tool to read it. That doesn't change the fact that Unix admins, like Perl developers, try and do this all the time. Maybe the best thing about posh it stops people from doing stupid things.

The LaTeX/Word analogy was simple: powershell separates content from presentation. bash does not.

This isn't an issue of shell syntax, you're pointing out that the ps tool emits structured output which can be queried in standard ways by downstream filters. Which is great, as a user feature.

Now explain how to write a "ps-like" command which emits mostly the same stuff and coexists in the same universe. Now things flip: unix is straightforward and easy (everyone understands how to emit text, and you can do it from literally every programming environment there is) and windows is arcane and inscrutable, and works only with whatever .NET framework understands that log stream.

Fast forward a few decades, and examine the size of the ecosystems built around "simple tools and text streams" vs. "custom logging format plus cute syntax".

It's a forest for the trees argument. Microsoft, as always, optimized for the wrong part of the problem. In this case: the admin experience is great, at the expense of the developers of the tools those admins would need to run.

> Which is great, as a user feature.

Yes, exactly.

There are far, far more users than complementors (tool creators) in this space. Optimising for users is excellent, and smart tool creators will see and appreciate the benefits.

Except they don't, as witnessed by this thread. Powershell is a ghost town. No one uses it, because there are no meaningful tools that use it. With ssh and rsync and git and bash and whatnot, I can script up a remote deployment or replication system for a simple task in a few hours. To extend your ps example, I can throw in a little awk or perl and spit out a clean report of suspected memory hogs.

Where is the powershell ecosystem? It doesn't have one, sorry. Syntax can only take you so far, and as I pointed out Powershell designed for syntactic power at the expense of extensibility. And it made the wrong choice.

> Powershell designed for syntactic power at the expense of extensibility. And it made the wrong choice.

A decent syntax is orthogonal to extensibility: Powershell uses .net because Microsoft likes .net. A Python, Ruby or node-based equivalent wouldn't use .net, and still have a clean syntax.

It's not a weird article at all. And from what you posted, you didn't even read it.

The author mentioned in the very beginning of the article that they wanted something that would work cleanly across their other (*NIX) platforms. Powershell, while fantastic, is not cross-platform.

And Cygwin does some funny stuff that also makes client configuration a bit of extra work if you're, again, dealing with multiple platforms.

To be pedantic, the article mentions that he's using "the Windows command line", and not Bash. So Powershell's non-cross-platformness does not seem to be breaking his goals any more than that.

To be further pedantic, the article is about maintain a relatively-close command line environment between Windows, Linux, and OS X. The parent commenter failed to notice this.

(I haven't read the article yet) What, it doesn't recommend bash but the default Windows shell? That's really weird, bash makes the shell by itself 10 times more versatile, regardless of what commands are available.

Edit:

> using a text-only interface is extremely foreign.

Oh I see, he's newb (as in the normal meaning of the word, not mocking). That explains.

For me, what's horrible about Cygwin is that a lot of things that perform just fine on a normal Unix are horribly slow. Just try running an Autoconf "configure" script sometime. I'm told this is because emulating fork() is very expensive in Windows (in contrast to the Unix model where it's very cheap.)

<shameless plug> You can get pretty good working enviroment using msysgit + clink + conemu. It takes a while to set all up.

For the lazy there is http://bliker.github.io/cmder

That looks amazing.

That is pretty great. Thanks for the link! Would be cool to also have an installer option but it's also nice being able to stick it on a USB device.

Why not throw Chocolatey in there as well for quasi package management?

I use GnuWin32 and I'm pretty happy with it:

http://gnuwin32.sourceforge.net/

DISCLAIMER: I just copy/pasted the steps to install GnuWin32 from a text file with instructions that meets my needs. This means that I deliberately did things that the documentation doesn't recommend (setx /M PATH...), so I suggest to read the documentation first.

  download.bat
  install.bat C:\GnuWin32
  xcopy /i /e /c "C:\GnuWin32\Start Menu" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\GnuWin32"
  setx /M INFOPATH C:\GnuWin32\info
  setx /M WGETRC C:\GnuWin32\etc\wgetrc
  setx /M A2PS_CONFIG C:\GnuWin32\etc\a2ps.cfg
  setx TEMP ^%USERPROFILE^%\AppData\Local\Temp
  setx TMP ^%USERPROFILE^%\AppData\Local\Temp
  setx TMPDIR ^%USERPROFILE^%\AppData\Local\Temp
  setx /M LANG EN
  setx /M LANGUAGE EN
  setx /M PATH "C:\GnuWin32;%PATH%

GnuWin32 makes the default command-line shell a bit more bearable...it sadly is still no replacement for a competent bash. Msys Git does a good job there.

I still would recommend it as a "Good Thing" to have, much like sysinternals ( technet.microsoft.com/en-us/sysinternals/‎ ) if you're on Windows.

I'm not sure what problems the author had with Cygwin that he didn't with Git's msys environment. I'm not denying that there were problems, I'm just curious what they were.

I guess the problems come once anybody tries to mix the environments at once: Git installs msys, the user additionally installs Cygwin and if both are in the path the confusion is certain.

Is there a problem simply using the version of git that comes with Cygwin? Seems to work for me.

Also worth mentioning is the GnuWin32 project (http://gnuwin32.sourceforge.net/). It provides native Windows builds of many GNU utilities, including a few handy ones missing from the Git distribution like file and wget.

If you're serious about using Vim on Windows, check out gvim (http://www.vim.org/download.php#pc) which adds some nice Windows integration.

I would also echo the author's point about avoiding Cygwin. It gives you the worst of both worlds: you can't access Windows facilities, and many Linux programs don't quite work right. By far a better solution is to use a native Windows shell (Powershell) together with native Windows builds of various GNU utilities (from a Git install, GnuWin32, MinGW, etc). Powershell gives you fluent access to a wide variety of Windows-specific API's, and you don't have to sacrifice the convenience of a Linux command line environment.

Seems like it would be easier to just install Linux in a VM for your Unix work, or a Windows VM under a Linux host.

First, you don't need to modify path, you can just open and use the "git bash" (which is just the bundled bash configured with git in path) for everything. It even has convenient shell-extension to open it in arbitrary directories.

Secondly, if you like MSYS (which is the environment bundled with git usually), then you can just download it directly. That way you can choose which tools you'll want, and stay up-to-date.

edit: interesting how many people seem to be more familiar with gnuwin32 than msys, considering that gnuwin32 seems pretty dead as a project and never was as comprehensive as msys.

This is the link to the environment - https://github.com/msysgit/msysgit

It's kind of like some of this with some other stuff thrown in -

http://gnuwin32.sourceforge.net/packages.html

http://sourceforge.net/projects/unxutils/

As others have pointed out, the reason why this works is that Git for Windows is bundled with msys.

You could achieve the same ends by installing msys standalone, but I guess many already have Git for Windows so this is a simpler path.

The key benefits msys has over cygwin, from my experience, are how lightweight it is, and how easy and fast it is to set up. I wrangled with cygwin for far too long (for no good purpose) before switching to msys and then GNU/Linux.

What I would like to see is Windows-like or Mac-like Linux environment or distribution. Not everyone wants and needs to know computer and it's OS inside out, and those people have no place in Linux world, only Windows and Mac. You do need to carry knowledge and unnecessary labor that needs to be done and unwanted information that needs to be absorbed in order to work with Linux is inadequate and unacceptable.

That's more or less what Ubuntu is.

I use Ubuntu on the desktop without knowing the OS or my computer inside out. Just like when I used Windows years ago, every time I have a problem I google it or figure it out. Occasionally I struggle with a problem I can't find how to solve -- exactly like I remember it used to be with Windows.

If Ubuntu is not your cup of tea, there are other user-friendly distros.

You clearly have no clue about the state of GNU/Linux. So sick of seeing this stuff reiterated so many times.

Perhaps you can explain?

I would prefer a Windows-flavored Linux tbh ;)

I've been fine for years with just adding MSLS when I have to use the widows command line. http://utools.com/msls.htm

I agree that this is a weird article, but I also like the idea of adding the git bin to path. I'm going to try that.

I hate developing in windows because of the command line. This actually improves it quite a bit :)

The ssh bundled with Git is not a good port. It still uses ANSI version console API which mess up non-English characters. Note that there ARE APIs (like WriteConsoleW) supporting Unicode and produces nice multilingual output.

Maybe I have to remake a ssh using Node. Node has a NICE tty port.

Powershell

I enjoy Powershell as well, but the Basic-style command structure is a bit frustrating. Particularly when trying to achieve parity between a Windows "shell", a Linux shell, and a Mac terminal "shell." Comma-delimited args in commands don't fit the bill there.

> Comma-delimited args in commands

Not quite sure what you mean.You don't need to use comma unless you explicitly want an array of values. So for example a rather simplistic cmdlet/function like this,

  Function Foo([string] $text, [int] $count) {
    #Produce repeated text
    $text * $count
  }

can be called in any of the following ways:

  Foo "ab" 3    ---> "ababab"
  Foo -text a -count 3 --> "ababab"
  Foo -t a -c 3   ---> "ababab" [Automatically disambiguated]

And we are not even using features of cmdlets like parameter aliasing.

Maybe I understood your concern wrong?

Just use GNU/Linux!

So GnuWin32 is included with git then?

Reply on news.ycombinator.com