#2149 Bash standalone without a complete MSYS package - package with all needed.

MSYS
doc
nobody
None
Support
self-service
Unknown
False
2014-05-05
2013-12-15
Kurtmn
No

Hi,

Have been looking around, not finding an easy solution in your repository. Have a fix Windows/"Unix" layout since 25 years back, using MKS Toolkit, UnixUtls etc. All working except zsh going highwire under win7. After looking at a number of broken shells, I ended up at MSYS Bash, that seems to be a plausible replacement to my previous zsh/ksh-setup.

Except that I do not want to install the whole MSYS package, I just need the bash.exe. Have previously done the mistake of installing AT&T Ksh package, that is similar to MSYS and it wreaked havoc with my well proven installations, forcing a windows reinstall to correct.

Now I am stuck on the msys-regex-1.dll, maybe more lacking, but non of the repository files I found in the repository seems to have these included. Since I likely not alone among the UnixUtil users having this problem, could I request for you making a standalone bash-package, so we can replace the broken zsh included.

I have seen references to the missing file in my google searches, indicating I am not alone. Also I am not inclined to download it from these sites, since it can be tampered with.

Cheers/KurtMn

Discussion

  • Keith Marshall
    Keith Marshall
    2013-12-15

    Why struggle to resolve dependencies manually? That's why we provide mingw-get ... to facilitate exactly this.

    1. Use the big green button, on our SF project summary page, to download and run the mingw-get-setup.exe tool.

    2. Let it install mingw-get.

    3. Proceed to the package selection step, but decline the "Basic Setup" choices, and switch to "All Packages" view.

    4. Drill down to the MSYS packages, locate the msys-tiny package, select it, and "Mark for Installation".

    5. From the "Installation" menu, invoke the "Apply Changes option.

    That, I think, should fulfil your minimal bash shell requirement, with all dependencies appropriately resolved.

     
  • Kurtmn
    Kurtmn
    2013-12-15

    Thanks,

    became a bit complex since the GUI install indicated above was not executing but I had to work via a command line.

    But in the end it did work, I got only the bash part and could copy bash.exe and the DLL:s to my /bin from the /MinGW/msys/bin directory. When all fixed it was easy to delete the /MinGW directory, removing the redundant files.

    For those looking for a UnixUtils zsh replacement, I still has some troubles, bash not reading the .bashrc/.profile/.bash_profile files, not setting my correct environment.

    Fixed that with following startline in the icon: "c:\bin/bash.exe --rcfile c:\etc.bashrc". After that all seems to work fine and my old UnixUtil-tools is responding as they should.

    Also, note that MSYS-bash has a cygwin-like PATH, not UnixUtils zsh Windows-like PATH. Right format is [export PATH="/c/bin:/c/usr/bin:/c/etc" ].

     
    Last edit: Kurtmn 2013-12-15
    • Keith Marshall
      Keith Marshall
      2013-12-15

      became a bit complex since the GUI install indicated above was not executing but I had to work via a command line.

      In what way was the "GUI install not executing"? It WJFFM. Of course, if you prefer a CLI

      mingw-get install msys-tiny
      

      should also get the job done.

      But in the end it did work, I got only the bash part and could copy bash.exe and the DLL:s to my /bin from the /MinGW/msys/bin directory.

      I wouldn't have done that, but if it works for you, good luck with it. Do make sure that you keep a /etc directory alongside your relocated /bin, or some things may not work correctly.

      When all fixed it was easy to delete the /MinGW directory, removing the redundant files.

      This will have destroyed your installation record, making it more difficult for you to track future upgrades, or to install additional features, if you should ever require them.

      I still has some troubles, bash not reading the .bashrc/.profile/.bash_profile files, not setting my correct environment.

      The files in question are $HOME/.bash_profile, $HOME/.bash_login, $HOME/.profile, and $HOME/.bashrc; obviously, for any of these to be invoked, the $HOME environment variable must be assigned. Normally, this is done by /etc/profile, which itself is only run when the shell is invoked with the --login option; this option is also required if any of the first three of the aforementioned startup files is to be invoked, (other than explicitly by the user), in which case, only the first of the three to be found, (searching in the order specified), will be invoked.

      OTOH, the $HOME/.bashrc file will be invoked, (other than explicitly), only by an interactive shell which is invoked without the --login option.

      Also, note that MSYS-bash has a cygwin-like PATH ...

      Actually, it's a POSIX style PATH specification, (as is cygwin's), due to MSYS itself having evolved from an early version of cygwin.

      Right format is [export PATH="/c/bin:/c/usr/bin:/c/etc"

      If C:/bin is where you've placed msys-1.0.dll, then

      export PATH=/bin
      

      or

      export PATH=/bin:/etc
      

      would be entirely equivalent to that. (It isn't wrong, but it's certainly unusual, and not normally recommended, to include /etc in $PATH). It is redundant to specify both /bin and /usr/bin, because MSYS maps / and /usr internally, to refer to the same location. You are correct, however, that if you do need to refer to the Windows drive specs, (C:, D:, etc.), you refer to them as /c, /d, ... respectively, (and not as cygwin would refer to them, as /cygdrive/c/, /cygdrive/d/, etc.)

       
  • Kurtmn
    Kurtmn
    2013-12-15

    Hi,

    The Mingw-get did not execute when clicking on the icon, it told me that I had to run the command line option. Why? I removed it, so I cannot answer. But I have a fairly basic win7 64bit.

    Your correct regarding HOME, it was not defined, since zsh looked in ../etc wherever installed after zshrc. Explaines the issues with .bashrc. However, using --rcfile solved that issue. It was not meant as any critique towards you, but information to other UnixUtil-users looking for a functional shell. Like me, I guess most have a c:/bin, c:/etc, c:/usr/bin directory structur and since a relation to Cygwin exist, I guess, when on disk D: the PATH need to point to /bin in C: to get to the binaries, aka. PATH=/c/bin. zsh uses c:/bin, so for us coming from there, my wording was as a help to those guys, more than to MSYS users.

    But thanks again, I seem to have a working installation again, thats the main reason.

     
    • Keith Marshall
      Keith Marshall
      2013-12-15

      The Mingw-get did not execute when clicking on the icon, it told me that I had to run the command line option. Why?

      That suggests that you deselected the option to install the GUI front end. However, my instructions didn't require you to install that; had you continued the mingw-get-setup to its ultimate conclusion, you could have completed the entire process, in GUI mode, from mingw-get-setup.exe itself, using its built-in temporary image of the GUI.

      It was not meant as any critique towards you, but information to other UnixUtil-users looking for a functional shell.

      I kind of realised that; however, while what you said nas not entirely incorrect, neither was it entirely correct.

      Like me, I guess most have a c:/bin, c:/etc, c:/usr/bin directory structur and since a relation to Cygwin exist, I guess, when on disk D: the PATH need to point to /bin in C: to get to the binaries,

      No, that is not so. When the running MSYS shell is either C:/bin/sh.exe or C:/bin/bash.exe, (both of which will require C:/bin/msys-1.0.dll), then that shell knows implicitly that /bin means C:/bin, regardless of what your current drive may be -- indeed, the entire concept of current drive has no meaning whatsoever, within the shell context.

      aka. PATH=/c/bin. zsh uses c:/bin

      Maybe so, but MSYS shell does not need PATH=/c/bin; PATH=/bin is sufficient, and the shell will add the C: prefix back in, for the benefit of any non-MSYS child which you may invoke from it. This happens automatically, so you have no need to even think about it, never mind being concerned about it.

       
  • Keith Marshall
    Keith Marshall
    2014-05-05

    • status: unread --> doc
    • Resolution: none --> self-service