I would like to open the Cygwin Bash in the active lister, just as I can do with CLI COMMANDPROMPT=here.
However, the bash-launcher is a MSDOS batch script. I could transport the batch script into the Dopus command but still, I do not know how to make that open bash in the active lister.
Any ideas ?
Does the batch file open Bash in the current directory it is launched from? If so I expect you just need to make an MS-DOS Batch Function button which runs the batch file.
If that doesn't work try adding
CD {sourcepath$}
as the first line of the button, with the batch file as the second line.
If that still doesn't work then there is presumably a way to give the batch file an argument for the directory it starts in? But I'm guessing you just need to run the batch file and the important thing is to make the button the MS-DOS Batch Function function type.
It may have to do with the version of Windows each user has, but lately on my XP Pro machine I've found I rarely need to set a DOpus button up as an MSDOS function in order to run an external script such as a batch file. DOpus runs it just fine as a standard function (including when I send external control codes to it). The times I do need to configure a button as an MSDOS function are in special situations when I'm either running "DOS" commands from within a DOpus button, or when I have special "things" to do with the external control codes I'm sending to the external script.
Andreas I'm not familiar with Cygwin Bash but if you're still having trouble launching it, try posting the contents of the batch script here so we can see what it does.
My guess that it needs to be a batch file is that I'm assuming Bash wants to take over the console window (DOS window) that it's running in, which won't exist if it's not an MS-DOS Function type.
If Bash opens a new window then it probably isn't imporant what type of function it is.
[quote="amix"]I would like to open the Cygwin Bash in the active lister, just as I can do with CLI COMMANDPROMPT=here.
[/quote]
To do this, create a button in DirOpus that starts your CygWin bat file:
"C:\Program Files\CygWin\cygwin_dopus.bat" {sourcepath}
Use a cygwin_dopus.bat that looks like this:
@echo off
set HOME=%1
C:\Program Files\cygwin\bin\bash --login -i
HOME and PATH are environment variables that are automatically converted into Cygwin's format, i.e from "c:\temp" to "/cygdrive/c/temp"
The default Cygwin bash startup script changes the directory to HOME, which should correspond to the path of the active lister.
First I do not have, nor do I know Cygwin. But if the commands listed above in cygwin_dopus.bat above are all that is required, just put them in an Opus button, and skip creating and calling cygwin_dopus.bat altogether.
NOTE: Ensure the Opus button is set to Function: MS-DOS Batch Function.
@externalonly
@noexpandenv
Set "HOME={sourcepath$|noterm}"
"%ProgramFiles%\Cygwin\bin\bash" --login -i
Yes, your solution works.
Thanks!
Hmm...must be something irregular here. It does not work for me (WinXP Pro). I used the last solution, putting all into a button finally, chose "run as MS-DOS batch function" but it does not work.
Very strange, since it did not work when trying to simply run a batch file, as posted in my first message, nor does it run now, that I chose to embed all the commands. The normal MS-DOS console (CMD.EXE) opens fine.
What exactly doesn't work with the 'first' method Amix?
Ken, I don't think your 'run all commands in an opus button' idea will work because I don't think that the cygwin process will have access to HOME variable being set in the same button... unless you've reviewed some of the changes in v9 and have reason to believe this is tweaked - I thought I skimmmed through some documentation regarding this sort of thing, but I'm tied up at work and can't double-check it...
Solved with the first method I tried. It was a problem with 4NT, that I had interpreted false.
Never mind - potty mouth... I stand corrected.
I have set this up this command which preserves the original $HOME functionality:
!Standard Function (Opus or external)
"%ProgramFiles%\Cygwin\bin\zsh" --login -c "cd '{sourcepath$|noterm}' ; exec /bin/zsh"
If you prefer, like me, using PuTTYcyg, try this:
!Standard Function (Opus or external)
putty.exe -load "myprofile" -cygterm "zsh --login -c \"cd '{sourcepath$|noterm}' ; exec /bin/zsh\""
Omit -load "myprofile" if you don't want to load a saved Putty profile. I'm using such a profile to set a custom color scheme in Putty.
Replace "zsh" with "bash", if you're using Bash (cygwin default) as your favourite shell
Not to bump a year old thread, but keeping the information consolidated is probably more important than trying to avoid the psychological trauma that some people seem to experience from the horrors of a necro-bump. 
I have a question for the Cygwin experts out there.
kingding's solution is perfect, especially since losing $HOME is not an option for me:
[quote="kingding"]I have set this up this command which preserves the original $HOME functionality:
!Standard Function (Opus or external)
"%ProgramFiles%\Cygwin\bin\zsh" --login -c "cd '{sourcepath$|noterm}' ; exec /bin/zsh"[/quote]
The only problem (not his fault) is that it won't work if the directory contains embedded spaces. Now, bash, and other shells running under Cygwin, do support embedded spaces, but like Windows, the path needs to be quoted.
The problem I am running into is in the shell's initial invocation where it internally converts the DOS formatted directory provided ({sourcepath$|noterm}) into a Unix formatted directory. In other words, "D:\dir1\dir2" into "/d/dir1/dir2" (or /cygdrive/d/dir1/dir2 if you didn't change the prefix in the registry like I always do).
I think I have tried every possible combination of quoting ( ' ` " ) and tricks, but I just cannot get the shell to convert a path with embedded spaces.
So to the Cygwin experts, is there a way to do this, or am just out luck?
Try adding @nofilenamequoting as a separate line at the start of the command.
Without that Opus will automatically put " quotes around the source path when it contains a space, which will mess up the other quotes in this case.
Already tried that. 
Okay, I figured out the problem. In my .bashrc script (executed at login), I'm overriding the cd command, and that's where the error was being generated. Adding quotes there is what I needed to do:
[code]# A new version of "cd" which
cd() {
builtin cd "$1"
pwd
}[/code]
Sorry for the interruption. 
Can you use the short path? Then there would never be embedded spaces.
You mean use {sourcepathshort$} instead {sourcepath$}? Actually, yes, I imagine that would have worked had I thought of it.
As an aside, I am glad I didn't, though, because that would have hidden the flaw in my .bashrc script. I wrote my customized version of script literally 8 or 9 years ago and have been reusing it ever since.
I never ran into this flaw because within the bash shell, the directories either get quoted semi-automatically (depending on how I retrieve the name) or the embedded space automatically get escaped (i.e., the shell puts a \ in front) when I'm just using auto-completion.
So in the end, I'm glad I didn't think of using {sourcepathshort$}.
