Winsh (a.k.a. “winsh”)

Overview

This web page documents some software that may be distributed from this website and other websites.

This software provided from here is basically a distribution. The creator of this distribution does have programming experience, but did not use such skills much, if at all, when creating any software from here. The actual programming (creating the main set of instructions) and design (like choosing to use a DLL file) was done by others.

Recommendation

Later 2017

If usage of GPLv2 is tolerable, you may wish to try one or more of these:

win-bash
Download from: bash/wnbsh11u.zip is described more in the win-bash section below.
busybox

e.g. to list contents on D:\

\temp\busybox.exe sh -l -c "/temp/busybox.exe ls -l --color=never //$(uname -n)/d$"

When you run the command, the current directory will default to the user's home directory (as seen by using: busybox sh -l -c "pwd")

Supported shells include ash, bash, and sh. The home page notes, “The BusyBox shell is based on ash.”

It seems the program does care what its name is. Therefore, a name like busybox.exe is accepted, or busyboxs.exe (if you want a shorter name than busybox_safe.exe), but unrecognized names like bsybxsf.exe (for busybox_safe.exe) will not work. The program must recognize its own filename. A well-known feature of busybox is that it can check its filename and act like the program that typically uses that filename, so if you name the program "ls.exe" then it will act like the ls command.

busybox-w32 v1.28.0-FRP-1601-gc87d9b4b2 executable bundle

The documentation indicates that passing -X to the shell, as the first parameter, will disable some code that changes backslashes to slashes. This may be referring specifically to the environment, and the difference can be noticed by comparing the following command to a variation that does not have the -X:

busybox sh -X -c "echo $WINDIR"

About colors in ls

color can be used with ls --color=always
However, part of the source code (busybox-w32 Config.src file) enables the color, but also comes with this commentary:

Saying yes here will turn coloring on by default,
even if no "--color" option is given to the ls command.
This is not recommended, since the colors are not
configurable, and the output may not be legible on
many output screens.

Indeed, looking at the Source code for busybox-w32's ls command shows that the “env” command is used once to chck LS_COLORS and just sets whether to show colors. (For an environment variable dedicated to the specific cause of just determining whether colors show or not, using CLICOLOR may have been a more appropriate choice, on the grounds that FreeBSD's ls command has specific support for using that named variable for that specific purpose. Mac OSX also supports that. However, that does not seem to be supported by busybox-w32)

The colors used by busybox-w32 involve showing directories as blue on black. Depending on the precise color of blue that gets used, that can be very difficult to see on some output devices (strangely, seeming to affect projectors more commonly than standard monitors). Solutions may involve:

  • downloading some different software like msls which supports configurable colors
  • or adjusting the terminal, perhaps so that blue appears as something like 0x5555FF (85,85,255) instead of 0x0000FF (0,0,255).
Perhaps see Updates to Microsoft Windows Console Colors, Understanding settings, Default color schemes, Registry entry for default colors for Windows 10 16256.

For instance, the following (untested) combination, generally favoring Microsoft's attempts to make things easier on high contrast display, but retaining the older yellow due to comment feedback that it looked too close to white:

echo Colors referenced in BBGGRR format (unlike the common #RRGGBB from HTML) echo make Red easier on high contrast
REG ADD HKCU\Console /v ColorTable4 /t REG_DWORD /d 0x1f0fc5 /f
REG ADD HKCU\Console /v ColorTable12 /t REG_DWORD /d 0x5648e7 /f
echo make bold Green brighter by using old settings
REG ADD HKCU\Console /v ColorTable10 /t REG_DWORD /d 0x00ff00 /f
echo Make Olive easier on high contrast displays
REG ADD HKCU\Console /v ColorTable6 /t REG_DWORD /d 0x009cc1 /f
echo Make Yellow more unique from white, by using older value
REG ADD HKCU\Console /v ColorTable14 /t REG_DWORD /d 0x00ffff /f
echo for Blue, Purple/Magenta, Cyan/Teal (light blue), and White, favor
echo newer settings for high contrast displays
echo Blue
REG ADD HKCU\Console /v ColorTable1 /t REG_DWORD /d 0xda3700 /f
REG ADD HKCU\Console /v ColorTable9 /t REG_DWORD /d 0xff783b /f
echo Purple/Magenta
REG ADD HKCU\Console /v ColorTable5 /t REG_DWORD /d 0x981788 /f
REG ADD HKCU\Console /v ColorTable13 /t REG_DWORD /d 0x9e00b4 /f
echo Cyan/Teal (Light Blue)
REG ADD HKCU\Console /v ColorTable3 /t REG_DWORD /d 0xdd963a /f
REG ADD HKCU\Console /v ColorTable11 /t REG_DWORD /d 0xd6d661 /f
echo white
REG ADD HKCU\Console /v ColorTable7 /t REG_DWORD /d 0xcccccc /f
echo make white easier on high contrast
REG ADD HKCU\Console /v ColorTable15 /t REG_DWORD /d 0xf2f2f2 /f

Mid 2017

(being edited... the latest recommendation may be changing soon.) Git for Windows 2.10.0, https://github.com/git-for-windows/git/wiki/FAQ https://git-for-windows.github.io/requirements.html bash bash 4.4.012-1-i686 (tar.xz) download URL dash dash 0.5.9.1-1-i686 (tar.xz) download URL fish fish 2.6.0.1-i686 (tar.xz) download URL (needs more DLLs) bc bc 1.0.6-3-i686 (tar.xz) download URL runtime https://sf.net/projects/msys2/files/REPOS/MSYS2/i686/msys2-w32api-runtime-5.0.0.4849.1259532f-1-i686.pkg.tar.xz/download

2017 July (first half) and Earlier

If you're looking for an easy-to-use shell, this is the current recommendation: mksh Win32 Beta 14 (zipped archive with source and binary executable). This does not require tinkering with downloading extra DLL files, and it has been more stable than some of the other alternatives.

Having said that, these files have received very little testing by the author of this text, at the time of this writing. (That may change very substantially, very soon.)

Compatability

This software is meant to be sh-compatible.

Someday, a version may be released to be compatible with OpenBSD's ksh, because that is a nice mix of features and complexity.

At the moment, bash compatability is provided. This provides even more features, at the costs of additional complexity and license restrictions.

License

GPLv2

Here are the shell-specific license details:

bash
bash has been GPLv2 but newer versions are likely GPLv3

dash and mksh licensing info has been moved from here, to be nearer the information of specific releases.

Download

Pre-built executable files: check out subdirectories underneath: this location. (Individual options are also described below.)

Note: There is absolutely no guarantee that this local archive will be updated frequently. (This may be based on some fairly old code.)

At the time of this writing, there may be multiple files required. Unless otherwise specified, unzip all files in a subdirectory. (Also, if there are any additional text files and/or additional HTML files, those might be helpful in getting things to work satisfyingly.)

Source code

For bash and msys-core, the process is the same: see the location near where the binary executable files are located. Instead of downloading the file that includes “-bin.” in the filename, choose the file that has “-src.” in the filename.

For “Git for Windows”, information is likely available by the msysGit project.

Binaries
Shells

Here are some specific releases:

dash

If you want a graphical installer, the easiest way may be to use one of the available installers that also installs some other software, including Git.

However, if you want to download a smaller amount, you can use some of these files. Note that using these files may require some ability to handle archive files.

dash 0.5.8
License info

No change has been made to the licensing of this software. This is probably GPLv2 because that is what Git for Windows uses, possibly because that is what bash has used, or because of Git's license.

The dash program itself has this as a license:

dash 0.5.8-2.3 copyright (redirects to: dash 0.5.8-2.3 Copyright) looks rather BSD-like, except for a single mksignames.c file.

executable
dash 0.5.8 32-bit (x86) release for Microsoft Windows

Choose from any of these files. (Only one of these files will be needed.) (Then grab the required DLL file.)

64-bit also available
Required DLL file

If you are using a 32-bit executable, you probably need to be using a 32-bit version of the required DLL file.

Version 2.5.1

Version 2.5.1 works. Get the DLL file from msys2 runtime version 2.5.1

Version 2.5.0

This may also work.

dash 0.5.9.1
license info
Same as the dash 0.5.8 release; see that release for license info.
executable

Choose from the 32-bit version, or 64-bit version. Also get the required DLL file.

Requires msys2 runtime DLL file (newer than what dash 0.5.8 requires).

dash 0.5.5c

The dash release provided here was previously described as the “(winsh release)”, which basially referred to the executable files being compressed with UPX. That compression seems to have caused some problems, though. The current thought is that using a compressed DLL file works okay, but compressing the executable files may not work quite as well.

License

No change has been made to the licensing of this software. This is probably GPLv2 because that is what msysGit uses, possibly because that is what bash has used, or because of Git's license. No substantial enhancements have been added (simply using UPX to create a smaller executable), and no license change is intended.

The dash program itself has this as a license:

dash 0.5.8-2.3 copyright (redirects to: dash 0.5.8-2.3 Copyright) looks rather BSD-like, except for a single mksignames.c file.

Executable file

dash (MSYS) 0.5.5.1_2-1 binary executable files for Microsoft Windows (contents extracted and then zipped locally, with an executable file inside, as dash/dsh055ze.zip)

This requires a DLL file.

If you want to try using a UPXed executable, you can see: dash.exe 0.5.5c (UPXed) (for MSYS) (zipped) (but be sure to test such a UPXed file before relying on it; don't just run it, but make sure it can run other software (like CMD) without showing an error message).

The recommended DLL file is found in msysCORE 1.0.18-1 for msys 1.0.18 (UPXed, and then zipped) (bshup193/193msys1.zip) (as described further by Executables exiting). (See: msys CORE 1.0.)
mksh
mksh (Win32 port)
license info
Terms and Conditions for mksh

mksh home page has a section called “OS: Windows” which hyperlinks to a “wlog entry”. That has hyperlinked to mksh Win32 Beta 14 (zipped archive with source and binary executable). (So that is a more official release than what is described by the rest of this page.)

This file is zipped locally as mkshwb14.zip

mksh (from msysGit)

The mksh release provided here was previously described as the “(winsh release)”, which basially referred to the executable files being compressed with UPX. That compression seems to have caused some problems, though. The current thought is that using a compressed DLL file works okay, but compressing the executable files may not work quite as well.

license info

No change has been made to the licensing of this software. This is probably GPLv2 because that is what msysGit has used, possibly because that is what bash has used, or because of Git's license. No substantial enhancements have been added (simply using UPX to create a smaller executable).

Terms and Conditions for mksh

mksh:
First, grab one of these executables:

Also, grab a support library.
This requires a DLL file. The recommended one is found in msysCORE 1.0.18-1 for msys 1.0.18 (UPXed, and then zipped) (bshup193/193msys1.zip) (as described further by Executables exiting).

bash (winsh releases)
win-bash

  • win-bash compressed with UPX
  • The uncompressed version, and some other executable files (which do seem to require included DLL files) are available as part of win-bash download area : get the win-bash.sf.net's shell.w32-ix86.zip file (zipped locally as bash/wnbash11.zip) (As of late 2017, the offered files are over six years old, dated 2011-March-17. The README.txt file offered by that website location simply says “Version 1.1.” (and then 0x0a), and is different than the README.txt in that zip file.)
  • home page

If a person just wants “bash for Microsoft Windows”, without utilizing Cygwin (or code libraries derived from Cygwin), this fits that description perfectly, although the code is notably dated. For a newer option, busybox-w32 may provide another solution that doesn't use Cygwin, and may have some newer code, although provides different overhead (in the form of coming with additional code besides just what's needed for bash's implementation).

Prior releases from here
These bash releases provided here was previously described as the “(winsh release)”, which basially referred to the executable files being compressed with UPX. That compression seems to have caused some problems, though. The current thought is that using a compressed DLL file works okay, but compressing the executable files may not work quite as well.
bash 193
bash 193:
bash 193 (UPXed) (zipped) requires a number of binary files, which are packaged together at bash 193 release's DLL files. (This is the recommended download package for bash users. The individual DLL files can also be obtained, as noted in the Creation section.)
bash 192
bash 192:
bash 192 (UPXed) (zipped) contains the main executable file,
and msys-1.0.dll (UPXed) for bash 192
Support files

Obtain these files when documented as needed:

[#msys20dl]: msys2 runtime 2 DLL file
[#msyr25u8]: msys2 runtime version 2.5.1 (DLL file)

Version 2.5.1 supports Windows XP (possibly SP3 only?) and Windows Server 2003 (probably also latest-service-pack only?). [Msys2-users] Announcement: msys2-runtime 2.5.1 -- last version to support XP/2003, not available for XP x64

See: msys2 runtime package 2.5.1 for i686 (x86 32-bit) UPXed (with --ultra-brute) (zipped).

Source code is available: msys2 runtime package 2.5.1-1 source code (tar gzip) (zipped locally as msyr25sc.zip)

version 2.5.0

MSYS2 runtime 2.5.0 might be closer to the version used by Git for Windows 2.10.0.

You can get msys2 runtime package 2.5.0.17080.ac97025-1 for i686 (x86 32-bit) UPXed (with --ultra-brute) (zipped).

If you don't want to risk involvement with UPX compression then you can get from msys2 runtime package 2.5.0.17080.ac97025-1 for i686 (x86 32-bit) .tar.xz download URL.

This is near the version used by Git for Windows 2.10.0. That page hyperlinks to Git for Windows 2.10.0 source code (tar.gz file) (zipped locally as sheldata/gtwnxpsc.zip), and what seems to be an unnecessarily large variation: Git for Windows 2.10.0 source code (unnecessarily large Zipped version)

Git for Windows FAQ says, “NOTE: Git for Windows version 2.10.0 was the last version supporting Windows XP and Server 2003.” That FAQ hyperlinks to Git for Windows: Requirements which says “As of Git for Windows v2.10.1, Windows Vista or later are required. The last version of Git for Windows to support Windows XP and Windows Server 2003 is v2.10.0.”

Other versions
Other versions are available. There are both newer 2.5.x versions and even newer 2.x versions. They can be found at MSYS2 file repositories: i686 (x86 32-bit).
[#msyscor1]: msysCORE 1.0 runtime DLL file
msysCORE 1.0.18-1

msysCORE 1.0.18-1 for msys 1.0.18 (UPXed, and then zipped) (bshup193/193msys1.zip)

Other software
Collections
[#coreutil]: coreutils

See: MSYS: coreutils e.g. coreutils 5.97 for MSYS 1.0.13 (LZMA'ed), which can be extracted with 7-Zip.

Will need:

GNU on Windows

Gnu on Windows: Home page has a URL starting with “wiki”.

To download, see: Gnu on Windows: releases

Other resources include: Gnu on Windows: FAQ and Gnu on Windows: executables list and Gnu on Windows: Github page

Listing files

ls is often not available. Using "echo *" may often do the trick.

Copying files
You may want to use xcopy or robocopy.
bzip2
Consider: bzip2 (32-bit x86, 64-bit, or ARM) from LTR-Data tools for Microsoft Windows. This is a native app, so it doesn't require the overhead of MSYS.
cp
Similar options

The following software may help to accomplish the same goal:

Consider: strarc.zip from LTR-Data tools for Microsoft Windows. This is a native app, so it doesn't require the overhead of MSYS. This application is actually designed for being able to back up files, but can be used to copy files. (In fact, the author recommends doing that as a modern approach to handle situations that could be done using the older xcopynt program. This is noted on the author's web page in the section about the xcopynt.zip file.)

consider: xcopynt.zip from LTR-Data tools for Microsoft Windows. This is a native app, so it doesn't require the overhead of MSYS.

Compatible options

consider what is shown by the coreutil section for options that may use command line parameters like those found on typical Unix machines. This may involve software that has GPL licensing and may involve using Cygwin or derived binary files.

cut
Consider: cut (32-bit x86, 64-bit or ARM) from LTR-Data tools for Microsoft Windows. This is a native app, so it doesn't require the overhead of MSYS.
dd
Consider: rawcopy (32-bit x86, 64-bit or ARM) from LTR-Data tools for Microsoft Windows. This is a native app, so it doesn't require the overhead of MSYS.
finger
Consider: finger from LTR-Data tools for Microsoft Windows. This is a native app, so it doesn't require the overhead of MSYS.
grep
For a solution using GPLv2 licensing, see msls.
hostname

Microsoft Windows may have a “whoami”. The info can also be found using SYSTEMINFO or WMIC COMPUTERSYSTEM GET NAME.

Perhaps consider: gethost (or gethostw) from LTR-Data tools for Microsoft Windows. This is a native app, so it doesn't require the overhead of MSYS.

ls
Similar options

The following software may help to accomplish the same goal as the traditional Unix command called ls (specifically, the goal of listing files and showing some details about the files, including file sizes):

Perhaps consider: sizdir32 or sizeof from LTR-Data tools for Microsoft Windows. This is a native app, so it doesn't require the overhead of MSYS.

[#msls]: msls

GPLv2 software designed to act very much like the typical Unix ls command, but with some added command line parameters to support showing details common on the Microsoft Windows platform (such as NTFS-specific details). For Win95+/NT4+ including at least Windows 10.

Note: the installer tends to dump files into %TMP%\ (typically a temp directory under an individual user's section, equivilent to %TEMP% and %LOCALAPPDATA%\TEMP) so if you want the files extracted somewhere else, you'll need to specify the desired location to the self-extracting ZIP file's installer interface.

Bundled executable files include: ls.exe, dircolors.exe, and grep.exe

msls home page, msls documentation, msls 4.7.315 (obtained via HTTP), msls 4.7.315 (obtained via FTP) msls 4.7.315 source code (obtained via HTTP), msls 4.7.315 sousrce code (obtained via FTP)

coreutil

consider what is shown by the coreutil section for options that may use command line parameters like those found on typical Unix machines. This may involve software that has GPL licensing and may involve using Cygwin or derived binary files.

mv
Similar options

The following software may help to accomplish the same goal as the traditional Unix command called ls (specifically, moving files)

movent

Perhaps consider: movent from LTR-Data tools for Microsoft Windows. This is a native app, so it doesn't require the overhead of MSYS.

coreutil

consider what is shown by the coreutil section for options that may use command line parameters like those found on typical Unix machines. This may involve software that has GPL licensing and may involve using Cygwin or derived binary files.

nano
GNU nano 1.08 for CygWin, nano project page
sed

See: ][CyberPillar][ info: sed for DOS/Windows

Perhaps consider: reptxt32 from LTR-Data tools for Microsoft Windows. This is a native app, so it doesn't require the overhead of MSYS.

Usage

When starting dash, the / directory might be the directory that the program was started from. /usr may be mapped to something like %USERPROFILE%. Specific details probably vary a bit based on which shell is used, so experiment to determine what happens (if you need to navigate the filesystem).

Using “ls” won't work unless you have it installed. Try “echo *” and/or pwd.

Icons

The files may have been obtained without icons.

Some might be found in the default icons file

or within: (and some others: see: Microsoft Windows files containing icons (slideshow, image 2).

Known Problem(s)

[#dsh055cw] Executables exiting

2017-July-16: The latest recommendation is to not UPX the executable files (although UPX'sing the *.dll file seems to work okay). This might be an issue related or similar to a need to "rebase" as described by Git for Windows: 32-bit issues. (This page refers to --enable-auto-image-base which might be a compile-time option and might only apply to 64-bit.)

Some older findings:

Warning: some of the files here have been found to be rather unreliable... and weirdly so. (This may even have been noticed when replacing the msys-1.0.dll file with a newer version.) The specific issue is that it just quit. The weird part is that one copy would seem to work perfectly, while another copy would just quit.

Some copies of the executable will work fine. But other copies of the program just quit (without showing a prompt), despite bit-for-bit confirmation that the executable file and the DLL file contained identical bits to files that worked just fine.

This was initially believed to affect dash 0.5.5c, but once the apparent fix was found, mksh executables were also working better too.

Some experimentation indicated that some DLL files may work more reliably than others. Try using the msysCORE 1.0.18-1 for msys 1.0.18 (UPXed, and then zipped) (bshup193/193msys1.zip) which came with the “bash 193” release. If that doesn't work, try using all of the DLL files from bash 193 DLL files.

stability

It seems that running “pwd” can crash the dash (winsh release). There have been experiences where running “pwd” right away will lead to a crash, but running “echo” and then later running “pwd” will work fine.

$ pwd
      0 [main] dash 11144 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
   6392 [main] dash 11144 open_stackdumpfile: Dumping stack trace to dash.exe.stackdump

Some documentation about this has been found:
Git for Windows: 32-bit issues describes this well. (Having reviewed this, I searched again for a reliable solution that could work in 32-bit Microsoft Windows environments, and so far have been content with the ability for BusyBox to operate.)

It seems like when dash closes, programs that dash started may also close. (Furthermore, it does not close gracefully, which means that the program does not prompt about saving unsaved work.) e.g., if you ran "notepad &", the and then dash closes, the Notepad window would also close.

Having chid processes close may be an intentional design. About child processes, perhaps see: Unix Stack Exchange: closing. (The disown command might be helpful? Stack Exchange: nohup/disown, using disown)

Older Update

Three different Unix shells have been found as part of the files distributed by MSYS. They may be found here:

The rest of this web page describes a release of a package which this web page names “winsh”.

Creation

What's here (and not)

This section documents how some files were created, and does not (directly) contain a bunch of details about how some other files are created.

Note that this may basically just involve downloading archives that contain one or more files, such as an EXE file or a DLL file. Then, the useful files get compressed and packaged. This section doesn't describe the process of making the files that appeared in the download archives used in the step of creating these files.

Releases:

dash 0.5.5c

dash 0.5.5c UPXed on January 12, 2016.

There was a dash 0.5.5c support library (UPXed) (zipped): msys-1.0.dll file from msysCORE-1.0.13-2 from msys-1.0.13 file created. However, the DLL files released with bash 193 seem to have worked better, and are recommended to use (instead of the one from this dsupl055.zip support library). (This is discussed further by Executables exiting. The dsupl055.zip library is remaining here for the sake of completeness (since it did work, sometimes), but is not recommended.

mksh 40.0.0c release

There are actually two mksh executables being released. One is based on mksh 40.0.0c for msys-1.0.17 and the other is mksh 111111 (or mksh-111111-1) (for msys-1.0.17)

The creator of this package simply UPXed the executable files and packaged the results. No information is currently available here regarding functional differences. mksh 40.0.0c was released November 27, 2011, nine days after mksh 111111's November 18, 2011 release (based on modification dates of folders found from “mksh for MSYS” area.

bash 193

Intended as an update to bash192, it was followed with essentially the same process except for using a newer bash.exe executable and a newer msys DLL file. Before applying the UPX compression, the files were obtained from the SourceForge URLs shown below.

The three DLL files, after being UPXed, were combined into one Zip file: b193dlls.zip

This was released here on January 12, 2016.

bash 192

Earlier notes indicated this was based on “bash 1.92”. (I do not offhand recall where that version number came from.) This was likely released April 14, 2014.

This section describes how the “winsh” executable file, bashed on bash 1.92, was created.

Currently winsh\ is based on bash.

Process of making winsh:

To test:

Project notes

The “Git for Windows” software is related to msysGit and MinGW. See Git for Windows: README.md file for an overview about these similarities.

Cygwin has ties to Red Hat, a company that was previously known as Cygnus Software.

MinGW does not require Cygwin DLLs (or similar, like MSYS), but may be able to use such DLL files... so something compiled with MinGW might or might no require Cygwin code). MinGW “does not have a Unix emulation layer like Cygwin” (quoting thomasrutter's answer to Łukasz Lew's StackOverflow.com question on the difference between Cygwin and MinGW ). ak2's comment mentions that the bundled bash “depends on the MSYS DLL, which is a fork of the Cygwin DLL.” However, the gcc program from MinGW is a native program.

MSYS is meant to be a trimmed down Cygwin.

MSYS2 is also meant to be a trimmed down Cygwin.