MS Windows and UNIX?

[ddanbe]

Will the console prompt ever support unix commands Like in the Apple Terminal?

[djjeavons]

Hi

Are you referring to commands such as ls, pwd etc. on a windows command prompt? If so, I doubt it. But if you want that functionality and more in a native Windows environment, you could give cygwin a go.

Otherwise, I may have misunderstood your question.

HTH

[ddanbe]

Hi djjeavons thanks for the answer. Cygwin seems to do the trick, I'll have a look at it. But I was just pondering if Windows 8..10 could or would do the same for the console app, so I that I don't have to install something else.

[djjeavons]

I'm no expert, but Mac I belive is a port of BSD which is a unix like kernel where as the Command Prompt in Windows is purely Microsoft. I don't see why they would want to incorporate unix like commands.

There is of course PowerShell which gives you some form of scripting ability like you have in unix like systems.

[Slavi]

What I've done is install unix commands to CMD, i think the packet is called gnu commands for windows or something similiar, and as far as I remember I actually made a post about it in the geeks lounge some time ago(I am a terminal kind of guy, that pack came as a miracle to me for those times when I have to go to windows)

Although cygwin is the ultimate solution so to speak, I've been trying to avoid it

EDIT: Found the link Click Here

[rubberman]

On Windows systems, Cygwin provides a Linux-type command environment with all the usual tools, including GCC compilers, bash shell, c-shell, and such. It works very well. I used to use its xorg X-Windows server in order to run X applications on remote servers that I had connected to with ssh or Putty (using the -X option to forward X-Windows protocol messages to Cygwin).

[ddanbe]

OK guys, thank you all again. I know I can install a tool to simulate the "vi" editor etc. But, why can it not be incorporated in the command prompt, or is this not possible?

[mike_2000_17]

It cannot be incorporated into the command prompt because of batch file scripts that need to remain compatible. Basically, if there are batch files that use variable names that are also Unix command names, then those scripts would be broken.

Then, in order to be relevant as a Unix-like terminal, the command prompt would have to acquire certain special behaviors that are common in shell environments, like pipes, globbing, file redirection, process detach / attach, etc.., which is where all of the real power of shell environments comes from. And the problem with this is that it taps into the fundamental concept of how files work. Unix-like systems are very much structured around the philosophy that "everything is a file, and a file could be anything", which is extremely powerful and works on the basis of relaxed requirements when it comes to the behaviour of basic operations like reading / writing files (e.g., a read operation might hang indefinitely, block for a long time, return an immediate error, suspend the thread, etc..., a file might not have an end-of-file, and so on). If Windows wanted to support this type of flexibility at its core, a lot of things would have to change in a fundamental way in Windows, and it's likely to break a large amount of existing applications.

So, the problem really boils down to the fact that Microsoft made a whole bunch of really bad design decisions for the core functionality of DOS, way back in the day, and there is essentially no escape from these core problems, at least, not at a fundamental level. You can't really blame Microsoft for having made those mistakes, because DOS was a brand-new haphazard OS that was rushed to market. While Unix had benefitted from decades of experience working out problems and redesigning their API to suite the needs of their user-base, mostly research institutes, which was a large enough user-base to test everything out, yet small enough to be able to make major changes without too much hurt.

Anyways, there is essentially only one way to "repair" this and try to provide a more powerful environment, which is to have a new platform or framework that sits on top of Windows. That is basically what Microsoft has done (or try to do) with .NET and PowerShell, although the ".NET" part is pretty distasteful to most, as it seems kind of antithetical to doing work in the command-line / terminal.

So, the only real option is Cygwin, which creates POSIX (Unix-like) environment that sits on top of Windows (it's basically an API compatibility layer), and that works really nice for anything from just having a nice bash command-line environment, to being able to run Unix applications (and even an X Server for GUI applications). Cygwin is pretty much the first thing that I install when I get a new Windows PC.

[ddanbe]

Thanks for your deep knowledge Mike. It seems to clarify a lot of things for me.

[rubberman]

Actually, if your PATH environment includes the cygwin bin directory, then you should be able to run vi (vi.exe) from the command line. It should start up the cygwin services so it can run properly. I think I did that once upon a time, but so long ago I can't be sure (senior moment)! :-)