This question already has an answer here:
Strange output from PHPUnit
(1 answer)
Closed 8 years ago.
When I run PHPUnit in Windows on WAMP, I sometimes get weird output like this:
PHPUnit 3.7.22 by Sebastian Bergmann.
Configuration read from D:\MrDWorkspace\Zend\mrdelivery\phpunit.xml
←[41;37mF←[0m.... <-------- this is the weird output
What does it mean?
These are color codes for screen displays. If you are using a simple DOS window, these do not work, and may be turned off from the command line (omit the --colors option). Command Line parameters may be found in the PHPUnit Manual.
It is possible to run a 'smarter' shell in Windows (PowerShell or something) which will then show the colors properly.
You can do this using the ANSICON
Download the ANSICON.
Extract the files to c:\ansicon\ (For
example).
Go to ANSICON folder using "cd c:\ansicon" on the console
(cmd), and then type “ansicon -i” without the quotes.
Add "c:\ansicon" to your path environment variable.
Enjoy!
Note: Windows 32 bits = x86 folder, and Windows 64 bits = x64 folder.
Related
This question already has answers here:
How to find correct executable with Sys.which on Windows
(2 answers)
Closed 2 years ago.
I'm trying to debug why I'm suddenly getting the error
tar.exe: Error exit delayed from previous errors.
on running install_github. Thinking there might be a problem with the tar program, I came across this oddity:
> Sys.getenv("PATH")
[1] "C:\\Program Files (x86)\\Microsoft SDKs\\Azure\\CLI2\\wbin;C:\\Rtools\\bin;C:\\Windows\\system32;[...]"
> Sys.which("tar")
tar
"C:\\WINDOWS\\SYSTEM32\\tar.exe"
> file.exists("C:\\Rtools\\bin\\tar.exe")
[1] TRUE
Why is R using the system tar, as opposed to the Rtools-supplied tar, when the Rtools directory is earlier in the path?
OS is Windows 10 2004 (build 19041.330), R 4.0.0.
This appears to be a known problem, for... several years now:
How to find correct executable with Sys.which on Windows
I tried to find documentation for this. I came across this:
https://cran.r-project.org/manuals.html
and in turn this:
https://cran.r-project.org/doc/manuals/r-release/fullrefman.pdf
but it turns out that PDF is specific to Unix, and omits Windows specific parts.
I am not sure of any official Windows PDF. So failing that, you can look at the
source directly:
The search path for command may be system-dependent: it will include the
bin directory, the working directory and the Windows system directories
before PATH.
https://github.com/wch/r-source/blob/92712b53/src/library/base/man/system.Rd#L77-L79
Note on the same page, I also see this:
This interface has become rather complicated over the years: see system2
for a more portable and flexible interface which is recommended for new code.
(If the Windows PDF is hosted in an official place, someone please let me know).
I am a newbie to UNIX, i want to print tree structure of files in a directory. below image is example in DOS, what will be the command of Unix to achieve same objective
I think you are looking for the "tree" command. If you are having issues running it you might have to find out how to install it on your specific distribution. For ubuntu installs you can find instructions here:
https://askubuntu.com/questions/507588/not-able-to-install-tree-comand-in-ubuntu
Not sure what you mean by "on Unix". What OS are you running, specifically? Tree should be compatible on Unix systems. You may just have to compile it for your particular OS.
This command prints output like the following (on cygwin):
I'm using Fedora 21 with GNU Emacs 24.5.1 and ESS version 15.03. In GUI mode I can use C-RET to pass code from an R script I'm editing to an inferior R process (it starts one up if I haven't yet), but that doesn't seem to work in console mode. Now C-RET just creates a new line in my R script. I've tried this using both emacs and emacs-nox installations.
I compiled ESS from source instead of using the outdated version in Fedora's package manager. Could that have anything to do with it?
The problem is that C-RET isn't a valid sequence in the terminal, so the C- is getting ignored and it's just interpreting the RET. See this answer for more explanation. Following some of the links there will take you to some workarounds, but they are not ideal. It doesn't look like there are any ways to completely change this behavior in the terminal (but I'd love to be told I'm wrong).
I am using Scinote 5.4.0 with OSX 10.7.4. I am unable to execute script files from the console using the exec("path") command; when I do so, only the first line of the script file is read.
Example:
-->exec("plot1.sce")
-->x=[0:.1:10]'; //(the first line of my code)
If however I "execute with echo" from the editor Scinote, the script will run just fine.
Does anybody know what is going on? (The script files I am trying to run are in my present working directory).
Thanks!
Update: I just installed Scilab on an identical machine and the same thing is happening.
Update: Per Scilab's bugtracker, it appears to be caused by Scinote defaulting to cr eol on a mac. I don't really know what this means or how to fix it, but the adventure continues!
Update: I found the solution!:http://comments.gmane.org/gmane.comp.mathematics.scilab.user/6184
In the preferences, I changed the eol to Unix, and the default file encoding to iso-8859-1. I restarted and exec is now working!
The link is not easy to follow so here's the answer (pasted)
The problem is actually scinote's, not scilab's. I don't have a Lion
machine to check if I'm correct, but it seems scinote's file encoding
is no longer compatible in ML. I discovered that when I opened scinote
generated files with a different text editor (vi) the new lines
weren't encoded right for my machine. The other give-away was that
executing scripts written prior to upgrading worked fine.
Go to preferences and in the scinotes tab, switch default file
encoding to iso-8859-1. I also switched the end-of-line to Unix.
I installed Windows 10 (64bit). Since then, Isabelle HOL is no longer starting, even after a re-installation (which ran through smoothly). The error message is the following: "Startup Error: Error starting Java VM". This happens with the two versions I tested (2013-2 and 2015).
The jvm.dll which is specified in the configuration file, exists in the right folder. Additionally, I have installed Java SDK in newest version (8.51) in both, 32bit and 64bit.
Is there a known compatibility problem with Windows 10? Isabelle used to work with Windows 7 and 8.
Thank you for you help.
Update (150822)
From the developer's mailing list, there's a link to a test release:
NEWS: updated to jdk-8u60, with support for x86_64-windows
www4.in.tum.de/~wenzelm/test/Isabelle_21-Aug-2015
That's working different from Isabelle2015, in how it does some things with paths, so it might find the things it needs for Windows 10, or it may not. However, even if it works, there may be some incompatibilities with Isabelle2015 (in theorem proving).
Regardless, Isabelle only gets released 1 to 2 times a year, and I wouldn't expect anything special to be released for Windows 10 within 4 to 6 months. The links above, though, show that M.Wenzel can package together a test release, but he mainly operates on the user's mailing list.
In my batch file below, I set HOMEDRIVE and HOMEPATH, which you don't need if you want .isabelle to be in C:\user.
In this test release, those settings don't affect my home path. It also appears that USER_HOME is used, though my setting of USER_HOME doesn't make my batch file work for this test release.
Anyway, this test release has changed the way it works to discover things, and accomodates Windows even more, as shown by the new behaviour of the function File.platform_path.
It's working different enough, and requires enough changes, that I should stay with Isabelle2015, or I'll be out of sync with the official release.)
Original
(Zeroeth: Problems like this generally get hashed out on the mailing list, but I go ahead show you how I start Isabelle using a batch file, which I started doing before I had to start doing it.)
First, the Java that Isabelle uses is in this folder:
Isabelle2015\contrib\jdk\x86-cygwin\jre
Doing a normal Java install for Windows is not going to change which Java that Isabelle uses.
Below, I give you a batch file and bash file to start Isabelle/jEdit, which is an alternative to using Isabelle2015\Isabelle2015.exe.
For myself, what I've done is manually replace the 32-bit jre folder shown above with the jre in jre-8u45-windows-x64.tar.gz. (I renamed the old 32-bit folder. The most recent Java tar files can be found at the download page.)
Consequently, if I try to start up Isabelle with Isabelle2015.exe, I also get a popup that says, "Startup Error, Error starting Java VM", but starting Isabelle with the batch/bash combination works for me on Windows 8.1.
What I show you below may not fix your problem, but I guess Isabelle2015.exe has to get some info from the OS to work right, and maybe that's changed with Windows 10:
https://lists.cam.ac.uk/mailman/htdig/cl-isabelle-users/2014-December/msg00033.html
You put the batch and bash file below in the folder that you have or want your .isabelle folder. Change ISAHOME below to where your Isabelle distribution is. PATH needs the Cygwin bin in the path, and the path for isabelle, which I set in the batch file.
FILE: start-isabelle.bat
:: Isabelle2015.exe uses these directly. Setting HOME or USER_HOME doesn't work
set HOMEDRIVE=%~d0
set HOMEPATH=%~p0
:: Cygwin uses HOME, and this is how HOME is set in Cygwin-Terminal.bat
set HOME=%HOMEDRIVE%%HOMEPATH%
:: ADD PATHS: 'cygwin/bin' to start terminal, 'Isabelle2015/bin' for 'isabelle'
set ISAHOME=E:\E_2\d ev\Isabelle2015
set PATH=%PATH%;%ISAHOME%/contrib/cygwin/bin;%ISAHOME%/bin;
set CHERE_INVOKING=true
::MINTTY CONSOLE
start /MIN mintty.exe -i /Cygwin-Terminal.ico "%~dp0start-isabelle.bash"
:: REGULAR WINDOWS CONSOLE
::bash --login -i "%~dp0start-isabelle.bash"
FILE: start-isabelle.bash
#!/usr/bin/env bash
#
isabelle jedit -l HOL
With 64-bit Java, I can increase the size of the memory that Isabelle uses, by making this change in .isabelle\Isabelle2015\etc\settings:
JEDIT_JAVA_OPTIONS="-Xms1g -Xmx4g -Xss4m"
or
JEDIT_JAVA_OPTIONS="-Xms1024m -Xmx4096m -Xss4m"
With 32-bit Java, when I do that, Isabelle will start but then terminate.