Install Octave Windows Cygwin Alternative

Note: the main Octave Symbolic package developer (Colin) has no direct Windows access so this is likely to be a bit rough! Help much appreciated: please be bold, edit and improve this documentation.

• Cygwin Alternative Windows 10

Prepare your PC. Download Cygwin. Actual installation of Cygwin. Download the source code for your favorite Octave version. Configure, compile and install Octave. Download gnuplot. Connect gnuplot to Octave, and other nitty-gritty. Alternative gnuplot options.

First get Octave! The latest version can be downloaded from https://www.octave.org. Install with default options.
Octave should be started from the 'Octave (GUI)' or 'Octave (CLI)' launchers - or from the octave.bat file in the Octave binaries directory. This will ensure that the system path is correctly set.

Option 1: Self-contained 'bundle' package

Probably the easiest way to get started. No dependencies, includes a Python interpreter and SymPy.

1. download the symbolic-win-py-bundle-x.y.z.zip file at our github releases page.
2. start Octave, change folder to where your downloads are.
3. type pkg install symbolic-win-py-bundle-x.y.z.zip
4. type pkg load symbolic
5. type syms x

Option 2: Installing Python and SymPy with Anaconda

Anaconda is a popular way to install Python and friends on Windows. It comes with SymPy reinstalled.

1. Install Anaconda.

2. Install Symbolic from within Octave by typing pkg install -forge symbolic. This automatically downloads the latest version.

We need to make Symbolic use the Python interpreter from Anaconda. Type the following in Octave:

3. setenv PYTHON /anaconda3/bin/python

To test your setup, type:

4. pkg load symbolic
5. Try syms x and factor(x^2-x-6)

Debugging: try sympref reset and sympref diagnose.

Updating SymPy: if you installed Anaconda a long time ago, you can update to the latest SymPy following instructions found here.

Option 3: manual installation of Python and SymPy

1. Download the Python .msi installer from https://www.python.org/downloads/.

   • In 2016, tested with version 2.7.10 version and it works fine.
   • Install with the following option 'Add python.exe to path' set to 'Will be installed on local hard drive' in the Customize Python dialog.
   • When installing on Windows 10, I had to leave the box '[ ] install for all users' *unchecked. I filed Issue #371 about this.

2. Install the SymPy package using the Python package manager, pip.

   • If python is installed properly, it can be run from the command line. Open a Windows Command Prompt or PowerShell (in Windows 10, right click the Start button, and select Command prompt or PowerShell)
   • At the prompt type pip install sympy. This should download and install the sympy package and its dependency mpmath.
   • If you do not have Administrator privileges, you may receive an error message and need to locally install the packages instead. The command for local package installation is: pip install --user sympy

3. Start Octave from the Octave(GUI) or Octave(CLI) launchers - or from the octave.bat.

4. Run the Octave command: pkg install -forge symbolic. This automatically downloads the latest version. Some people have reported some (harmless?) warnings about directory creation.

5. Load the symbolic package with the Octave command: pkg load symbolic

6. Try the command syms x and then factor(x^2-x-6)

Please add them here. I've added a couple things I don't understand very well. You can/should also file issues.

I want nice unicode output

You can! Try sympref display unicode. You may need to download a different font: https://github.com/cbm755/octsympy/issues/912#issuecomment-426572475

I get an error about python_ipc_popen2 undefined

Try restarting Octave. This error occurs when something changes the files in the Symbolic package while its running. I guess it could be triggered by a virus scanner or some indexing software, see https://github.com/cbm755/octsympy/issues/424 .It is also triggered by reinstalling or upgrading Symbolic while symbolic objects are in use.

'ut8_heavy.pl' Perl warnings

This has been fixed in Octave 5.1. Previously, many people are saw lots of warnings during install:

Windows XP

As of 2.3.0, no particular action should be necessary.

Paths

How paths are supposed to work on modern Windows? Do Python installers take care of this for you? If you open a 'cmd.exe' command line, does 'python' work? If so, how about 'import sympy'?

SymPy

Does it matter where SymPy is installed? My experimenting with the self-contained package suggests it does.

32 vs 64 bit windows?

Does the self-contained package work on both? MXE Octave seems to support both.

Update 1/9/2014: TL;DR version: Go to bottom of this post for a way to get Cygwin to be able to call non-Cygwin programs.

After having spent the time to make some bash scripts that happen to be of significant size, newer versions of Cygwin have broken them. These scripts call into native Win32 applications that don't link with Cygwin, which is apparently not officially supported by Cygwin.

This has come as a surprise to me, as for years I was under the impression that Cygwin could be used in a more mixed environment that combines both native non-Cygwin Win32 apps, and POSIX programs using the Cygwin compatibility layer. But apparently only the POSIX compatibility layer is really supported, and if native Win32 non-Cygwin apps work then it is considered a happy coincidence.

I found this out from an incompatibility I ran into with running programs compiled against the .NET Framework from within Cygwin. This used to work fine, but was broken a few months ago. Specifically, standard output from a .NET program that is piped to any other Win32 program's standard input will generally cause the receiving Win32 program to get a premature end-of-file signal because Cygwin recently switched to message pipes from byte pipes a few months ago - and message pipes appear to be incompatible with any receiving app using Visual C++ or .NET Framework. This is because .NET issues a null write to the standard output, which is only passed on to the receiving app if a message pipe is used. The receiving app successfully reads zero bytes, so thinks it is end-of-file. The project lead doesn't appear to consider this to be a real problem, since they apparently don't really support running non-Cygwin programs from within Cygwin (surprise!).

To quote the project lead Christopher Faylor from multiple e-mails on the mailing list:

What you are seeing may be because Cygwin was changed to use message-type pipes a couple of revisions ago. This is not going to change. The change was adopted to fix a problem with Cygwin programs and those are obviously our #1 priority.

Regardless of how many people use Visual C++ or .NET they are really not our target audience. It's nice when things work for people who don't want to use UNIX tools but they are not our primary focus. Fixing problems for people who want to use non-Cygwin stuff is not something that I find a high priority.

From pipe.cc: Note that the write side of the pipe is opened as PIPE_TYPE_MESSAGE. This seems to more closely mimic Linux pipe behavior and is definitely required for pty handling since fhandler_pty_master writes to the pipe in chunks, terminated by newline when CANON mode is specified.

The above comment shows an 'and' relationship here. Message type pipes more closely mimic Linux (UNIX) pipe behavior AND are definitely required for ptys.

I agree with James that the runtimes are probably buggy BUT I also agree that cygwin should be able to have a handle these scenarios.

Your complete agreement with each other is not going to have much effect. Cygwin source code is not changed by voting.

Even if this one issue is ultimately fixed somehow - who knows - they might break something else in 3 months and not care to fix the regression. They might consider a patch, but it would take me quite awhile to figure out something that works. I think my time is better spent elsewhere, because it's clear that they are quite willing to break compatibility with native Win32 apps and don't want to waste more time on getting Win32 apps to work. So I guess Cygwin shouldn't be considered a stable platform for mixed Win32/Cygwin environments - what are my alternatives? Where should I start that would avoid a complete rewrite into something other than bash? I don't use more than the base Cygwin installation + some basic perl scripts.

UPDATE: After the posting of this original question, they did eventually a new pipe_byte flag in the CYGWIN environment variable: look at the documentation. If this flag is set, it will fix the problem discussed above. When invoking a non-Cygwin Win32 program, always make sure that the pipe_byte flag is set.

However, I have since uncovered an incompatibility with .NET Framework 4.0 and Cygwin. Previous versions of .NET Framework don't have this issue. I mentioned the issue first on the Cygwin mailing list here:

Getting no fruitful responses, I investigated further and found that Cygwin is creating overlapped pipes, which causes the problem. Note that trying to use non-overlapped Win32 API calls with an overlapped pipe is undefined, and most (all?) Win32 non-Cygwin programs don't use overlapped I/O with their standard file handles. I submitted a patch that creates a pipe_nooverlap flag in the CYGWIN environment variable that prevents this from happening:

Unfortunately, they have rejected the patch, so you'll never see this in the main Cygwin DLL:

The reasoning for rejecting the patch:

1. It was implied that I broke the signal implementation in Cygwin; I have not found this to be the case, as signals still use overlapped pipes.
2. They don't feel like adding an environment variable flag, even though it is apparently fixing problems.
3. They don't want to support code that even has the option of having non-overlapped pipes.

With reasoning and attitudes like this, I'm afraid I can't think of any way to change the patch to suit their requirements.. they seem determined to forbid non-overlapped pipes from ever being used. I have been using the patch for awhile now, and have not had any problems with it. Also, I can't think of any situations that the pipe_nooverlap flag will break (see my follow-up e-mail on their mailing list), but I left it as a flag just in case there is trouble.

So, if you want to call non-Cygwin Win32 or .NET Framework programs from Cygwin, you need to do the following:

1. Apply my patch to the source of whatever Cygwin version you are using. Do not expect this patch to show up in future Cygwin versions.
2. Set the pipe_byte and pipe_nooverlap flags in the CYGWIN environment variable.

This works.. for now!!! I post this in case it helps anyone else who still wants to use Cygwin for some things.

James Johnston

Cygwin Alternative Windows 10

James Johnston

5 Answers

The best alternative I found is Gow (Gnu On Windows).

It's a lightweight alternative to Cygwin, about 10 times lighter.As far as I know the 130 tools installed with Gow are regular Win32 applications.

Arialdo MartiniArialdo Martini

2016 Answer

I built Cash this year, a cross-platform implementation of Linux commands running on Node.js.

This supports both global installations of each command in your path, or an interactive shell with full support for bash-like syntax, command piping, autocompletion and history.

This additionally runs win32 apps within the shell.

dthreedthree

There may be fewer 'supported' packages, in that you have to install things by hand, but there won't be:

• Path issues (cygpath is a non-solution, as you can't always shove it in)
• Programs confused by cygwin packages reporting their OS as 'cygwin'
• .dll/.so/.lib/.a confusion

And there is much better interop with windows applications.

user1244215user1244215

Prodigy the fat of the land rarlab. Cygnal is my project to create a modified Cygwin, serving as a run-time support library for applications intended to run as native Windows programs, following external conventions familiar to Windows users.

The idea is that you can use the full Cygwin environment to develop, using its default toolchain: the same compiler that makes Cygwin executables.Then you can deploy your program as a Cygnal program by bundling it with the modified cygwin1.dll from the Cygnal project.

This is especially useful for programs that have a lot of POSIX dependencies and need a decently feature-rich, good quality POSIX implementation.

The project lead doesn't appear to consider this to be a real problem, since they apparently don't really support running non-Cygwin programs from within Cygwin (surprise!).

By contrast, in the Cygnal project, this sort of thing is considered an issue for which a reasonable solution will be merged.

KazKaz

I used to use cygwin mainly for the X11 server feature. It was useful to run any tools on a remote server and export the display to local cygwin. I find that I can achieve the same thing using Xming server which is a lot lighter.

Not the answer you're looking for? Browse other questions tagged windowsbashcygwin or ask your own question.