From: Nathan R. <zer...@ho...> - 2012-09-04 23:25:23
|
Hello, I have recently been doing some remote Linux development using PuTTY, and I've grown to intensely dislike the Windows command prompt window (which is was MSYS uses) in comparison (for example, that fact that you can't properly maximize it, and other such user-unfriendly limitations). I am wondering whether it's possible to use PuTTY as a local MSYS terminal. Has anyone done this before? Thanks, Nate |
From: Greg C. <gch...@sb...> - 2012-09-05 00:04:22
|
On 2012-09-04 23:25Z, Nathan Ridge wrote: [...] > I am wondering whether it's possible to use PuTTY as a local MSYS > terminal. Has anyone done this before? Have you tried mintty, which is based on putty and can be installed with mingw-get? |
From: Charles W. <cwi...@us...> - 2012-09-05 04:41:10
|
On 9/4/2012 8:04 PM, Greg Chicares wrote: > On 2012-09-04 23:25Z, Nathan Ridge wrote: > [...] >> I am wondering whether it's possible to use PuTTY as a local MSYS >> terminal. Has anyone done this before? > > Have you tried mintty, which is based on putty and can be > installed with mingw-get? Another alternative is to use mingw-get to install "the console2 installer" msys-console. Then, you run the /usr/bin/console-config script and it will download, configure, install (and, if all goes well) create a shortcut for you all in one step. This dance is required because console2 is open source, but can't be compiled with our tools. Hence we are reluctant to directly distribute their pre-compiled binaries from our repository... mintty is great, and I use it all the time with cygwin. But there is one big drawback (google "cygwin pty native applications" for an explanation). console2 doesn't have that problem, which is far more prevalent in the msys/mingw milieu than in cygwin. -- Chuck |
From: Earnie B. <ea...@us...> - 2012-09-05 11:52:57
|
On Wed, Sep 5, 2012 at 12:40 AM, Charles Wilson wrote: > which is far more > prevalent in the msys/mingw milieu than in cygwin. > Because our intent is to deal more with the "native" application than Cygwin is. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-09-05 19:12:09
|
On 05/09/12 05:40, Charles Wilson wrote: >> Have you tried mintty, which is based on putty and can be >> installed with mingw-get? > > Another alternative is to use mingw-get to install "the console2 > installer" msys-console. Then, you run the /usr/bin/console-config > script and it will download, configure, install (and, if all goes well) > create a shortcut for you all in one step. > > This dance is required because console2 is open source, ... Yes, but it isn't free, (in any sense other than as in beer). > but can't be compiled with our tools. Not as it stands, anyway, without significant porting effort. > Hence we are reluctant to directly distribute their pre-compiled > binaries from our repository... On the contrary, I would dearly like to be able to distribute it. The reason we don't has nothing to do with reluctance; it is fundamentally a licensing issue. The author of Console2 uses MSVC to build it, and he refuses to even contemplate any alternative. His builds are dependent, (or at least were when I evaluated it), on MSVC specific DLLs, which Microsoft have declared to be non-distributable without a paid-for developer licence. Since we do not have such a licence, we cannot legally redistribute such packages [*]. [*] I suspect that his use of, and dependency on such non-distributable components may actually place the developer of Console2 in violation of the GPL, (under which he purports to distribute). IANAL, but how can he confer the right to redistribute, (as is required by the GPL), when his package depends on non-distributable, non-free components? -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2012-09-05 22:30:29
|
On 9/5/2012 8:58 AM, Keith Marshall wrote: > The author of Console2 uses MSVC to build it, and he refuses to even > contemplate any alternative. His builds are dependent, (or at least > were when I evaluated it), on MSVC specific DLLs, which Microsoft have > declared to be non-distributable without a paid-for developer licence. > Since we do not have such a licence, we cannot legally redistribute such > packages [*]. > > [*] I suspect that his use of, and dependency on such non-distributable > components may actually place the developer of Console2 in violation of > the GPL, (under which he purports to distribute). IANAL, but how can he > confer the right to redistribute, (as is required by the GPL), when his > package depends on non-distributable, non-free components? GPLv3, if I understand correctly, mitigates this issue by defining "System Libraries" as: > The "System Libraries" of an executable work include anything, other > than the work as a whole, that (a) is included in the normal form of > packaging a Major Component, but which is not part of that Major > Component, and (b) serves only to enable use of the work with that > Major Component, or to implement a Standard Interface for which an > implementation is available to the public in source code form. A > "Major Component", in this context, means a major essential component > (kernel, window system, and so on) of the specific operating system > (if any) on which the executable work runs, or a compiler used to > produce the work, or an object code interpreter used to run it. > > The "Corresponding Source" for a work in object code form means all > the source code needed to generate, install, and (for an executable > work) run the object code and to modify the work, including scripts to > control those activities. However, it does not include the work's > System Libraries, ... and in section 6: > A separable portion of the object code, whose source code is excluded > from the Corresponding Source as a System Library, need not be > included in conveying the object code work. So, as long as the console2 devs don't actually distribute the msvcrt runtime DLLs and simply expect the end user to manually go to microsoft.com to get the appropriate vcredist package, I think they're in the clear -- under GPLv3. (Now, if they DO include those DLLs, then *they* are not infringing -- and *I* can avoid infringing by removing those DLLs from the package before I distribute them; but if I don't do that, and redistribute the binary packages WITH the msvcrt dlls then I would be infringing unless I, too, had an MS developer license. As it turns out, their binary packages do not include the msvcrtXX.dll runtimes). But that's all academic, because it seems Console2 is under GPLv2: http://console.git.sourceforge.net/git/gitweb.cgi?p=console/console;a=blob_plain;f=help/html/copyright.html;hb=HEAD GPLv2 is completely different because under that regime, system libraries basically meant stuff usually distributed with the operating system -- which explicitly did NOT include the various msvcrtXX.dll runtimes. So they weren't excluded from the "set of stuff you need to distribute source code for" under the viral nature of the regular GPL. I'm not sure what the situation is if, with source code under the GPLv2, you distribute your compiled binary but do NOT ship the msvcrtXX.dlls, even if MS gives you permission. Under GPLv3 you're in the clear, but that runtime is NOT considered a system library under GPLv2, so it is, just by virtue of linking, considered part of the "derived work" you have created from the GPLv2 source code. So even if you don't ship that "part" of the derived work, somebody would still have the right to ask you for the source code of ALL of the "derived work" -- including the msvcrtXX.dll you did not actually distribute! This, in fact, is exactly the situation the Console2 devs are in. And it's the situation WE do not want to be in. IANAL, etc etc etc. -- Chuck |
From: Maximus <Con...@gm...> - 2012-09-06 05:45:11
|
Keith Marshall <keithmarshall@...> writes: > > On 05/09/12 05:40, Charles Wilson wrote: > >> Have you tried mintty, which is based on putty and can be > >> installed with mingw-get? ConEmu is free, opensource, and may be compiled with mingw (gcc). Are you interested in it? |
From: waterlan <wat...@xs...> - 2012-09-06 09:28:56
|
Maximus schreef op 2012-09-06 07:39: > ConEmu is free, opensource, and may be compiled with mingw (gcc). Are you > interested in it? Hi, I did not hear of ConEmu before. I tried it (stable version), and my first impression is very good. Even east-Asian Unicode characters display pretty well, which was not working in the latest Console2 versions anymore. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Erwin W. <wat...@xs...> - 2012-09-06 22:50:33
|
waterlan schreef, Op 6-9-2012 11:28: > > Maximus schreef op 2012-09-06 07:39: > >> ConEmu is free, opensource, and may be compiled with mingw (gcc). Are you >> interested in it? >> > Hi, > > I did not hear of ConEmu before. I tried it (stable version), and my first impression is very good. Even east-Asian Unicode characters display pretty well, which was not working in the latest Console2 versions anymore. > ConEmu is really cool. I think I'm going to leave Console2 behind. I tried to compile the source with mingw32, but it fails pretty soon. Are you not distributing source tarballs? I could only check out the source with svn. waterlan@localhost ~/src/conemu/conemu-maximus5-read-only/ConEmu/src $ make -f makefile_all_gcc WIDE=1 prebuild cleaning ===========ConEmu make[1]: Entering directory `/c/Users/waterlan/src/conemu/conemu-maximus5-read-only/ConEmu/src/ConEmu' compiling Attach.cpp In file included from ConEmu.h:80:0, from Attach.cpp:32: GestureEngine.h:75:42: error: 'HGESTUREINFO' has not been declared GestureEngine.h:75:69: error: 'PGESTUREINFO' has not been declared GestureEngine.h:77:84: error: 'PGESTURECONFIG' has not been declared In file included from ConEmu.h:80:0, from Attach.cpp:32: GestureEngine.h:79:50: error: 'HGESTUREINFO' has not been declared In file included from Attach.cpp:32:0: ConEmu.h: In member function 'void CConEmuMain::<anonymous struct>::ReloadWheelScroll()': ConEmu.h:227:31: error: 'SPI_GETWHEELSCROLLCHARS' was not declared in this scope Attach.cpp: In static member function 'static bool CAttachDlg::StartAttach(HWND, DWORD, DWORD, AttachProcessType, BOOL)': Attach.cpp:710:24: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] make[1]: *** [../../gcc/conemu/Attach.o] Error 1 make[1]: Leaving directory `/c/Users/waterlan/src/conemu/conemu-maximus5-read-only/ConEmu/src/ConEmu' make: *** [ConEmu] Error 2 -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Maximus <Con...@gm...> - 2012-09-07 05:26:20
|
Hi, Erwin Waterlander <waterlan@...> writes: > I tried to compile the source with mingw32, but it fails pretty soon. Hm. Some WinApi's headers not found in mingw32. I'll take a look. > Are you not distributing source tarballs? I could only check out the > source with svn. No tarball, only svn. This is true. regards |
From: Keith M. <kei...@us...> - 2012-09-07 21:47:15
|
On 06/09/12 10:28, waterlan wrote: > Maximus schreef op 2012-09-06 07:39: >> ConEmu is free, opensource, and may be compiled with mingw (gcc). Are you >> interested in it? We might be, subject to the following conditions: 1) It would need to be packaged in mingw-get friendly tarballs. 2) Release specific source tarballs need to be made available. 3) The source should build OOTB, under MSYS, with MinGW tools. 4) Default configuration should immediately invoke MSYS shell. Would you be willing to contribute packages on such a basis? > I did not hear of ConEmu before. I tried it (stable version), I tried both the stable, and the latest development versions. > and my first impression is very good. My first impression was disappointing. Yes, it *looks* nice when running cmd.exe, but I had trouble getting MSYS sh.exe to start in a virtual WinXP 32-bit session, under VirtualBox on my LinuxMint 64-bit Debian Edition host; it simply aborted instantly, with no diagnostics whatsoever, when trying to start it from a cmd.exe shell. Trying to start it as the primary shell, in a new tab, yielded: ConEmuC: Root process was alive less than 10 sec, ExitCode=128. Press Enter or Esc to close console... and other than going away completely, on pressing either enter or esc, that tab was dead; (I couldn't even copy that message to paste it here; I had to transcribe it manually). Persevering, I discovered that I could start it from a cmd.exe session, if that session itself was started with the ConEmuHk option disabled. However, I still can't start it as the primary shell in a new tab, with C:\MinGW\MSYS\1.0\bin\sh.exe --login -i as the specified tab command line; that still yields the same failure condition/message. (This same command works fine, when specified as the command to start a new Console2 tab). I can start MSYS shell at new tab initiation, (with ConEmuHk disabled), if I specify the command as %ComSpec% /c C:\MinGW\MSYS\1.0\bin\sh.exe --login -i but it seems wrong that I should need this indirect invocation. > Even east-Asian Unicode characters display pretty well, which was not > working in the latest Console2 versions anymore. I can't comment on that, since Asian languages are meaningless to me; for the Western European languages which can actually understand, I find that Console2 works well for me; in spite of its lack of freeness, I won't be ditching it just yet. -- Regards, Keith. |
From: Erwin W. <wat...@xs...> - 2012-09-07 22:57:16
|
Keith Marshall schreef, Op 7-9-2012 23:47: > On 06/09/12 10:28, waterlan wrote: >> Maximus schreef op 2012-09-06 07:39: >>> ConEmu is free, opensource, and may be compiled with mingw (gcc). Are you >>> interested in it? > We might be, subject to the following conditions: > > 1) It would need to be packaged in mingw-get friendly tarballs. > 2) Release specific source tarballs need to be made available. > 3) The source should build OOTB, under MSYS, with MinGW tools. > 4) Default configuration should immediately invoke MSYS shell. > > Would you be willing to contribute packages on such a basis? > >> I did not hear of ConEmu before. I tried it (stable version), > I tried both the stable, and the latest development versions. > >> and my first impression is very good. > My first impression was disappointing. Yes, it *looks* nice when > running cmd.exe, but I had trouble getting MSYS sh.exe to start in a > virtual WinXP 32-bit session, under VirtualBox on my LinuxMint 64-bit > Debian Edition host; it simply aborted instantly, with no diagnostics > whatsoever, when trying to start it from a cmd.exe shell. Trying to > start it as the primary shell, in a new tab, yielded: > > ConEmuC: Root process was alive less than 10 sec, ExitCode=128. > Press Enter or Esc to close console... > > and other than going away completely, on pressing either enter or esc, > that tab was dead; (I couldn't even copy that message to paste it here; > I had to transcribe it manually). > > Persevering, I discovered that I could start it from a cmd.exe session, > if that session itself was started with the ConEmuHk option disabled. > However, I still can't start it as the primary shell in a new tab, with > > C:\MinGW\MSYS\1.0\bin\sh.exe --login -i > > as the specified tab command line; that still yields the same failure > condition/message. (This same command works fine, when specified as the > command to start a new Console2 tab). > > I can start MSYS shell at new tab initiation, (with ConEmuHk disabled), > if I specify the command as > > %ComSpec% /c C:\MinGW\MSYS\1.0\bin\sh.exe --login -i > > but it seems wrong that I should need this indirect invocation. > >> Even east-Asian Unicode characters display pretty well, which was not >> working in the latest Console2 versions anymore. > I can't comment on that, since Asian languages are meaningless to me; > for the Western European languages which can actually understand, I find > that Console2 works well for me; in spite of its lack of freeness, I > won't be ditching it just yet. > After using it some more I also experienced several crashes. Mainly with the 64 bit version (stable and latest) on Windows 7. For instance when you type an unknown option. I tried "conemu64 -h" to get some help, and got similar results as "Root process was alive less than 10 sec...". Conemu64 /? worked fine. And the 64 bit version also hangs when I press the [X] in the upper right corner to close conemu. When I run the 32 bit version on 32 bit Vista it seems more stable. Still I think that Conemu has the potential to become very good. Maximus just needs to iron out some bugs, and I think he is willing to. When MSYS2 arrives, which will support Unicode, ConEmu could be the ideal console. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Maximus <Con...@gm...> - 2012-09-07 23:41:28
|
Keith Marshall <keithmarshall@...> writes: > >> ConEmu is free, opensource, and may be compiled with mingw (gcc). Are you > >> interested in it? > > We might be, subject to the following conditions: > > 1) It would need to be packaged in mingw-get friendly tarballs. > 2) Release specific source tarballs need to be made available. What can I read about requirements for tarballs? Naming, subfolders, smth else? > 3) The source should build OOTB, under MSYS, with MinGW tools. Sources on my svn was updated today. 32bit build passed with mingw. > 4) Default configuration should immediately invoke MSYS shell. "sh.exe --login -i" ? I have a question. How conemu can find "sh.exe"? If conemu.exe may be installed into same folder as "sh.exe" - no problem. Otherwise it may be hard to choose "default shell". E.g. user may install TCC/LE, which alse may be used as known shell by conemu. > My first impression was disappointing. Yes, it *looks* nice when > running cmd.exe, but I had trouble getting MSYS sh.exe to start in a > virtual WinXP 32-bit session, under VirtualBox on my LinuxMint 64-bit > Debian Edition host; it simply aborted instantly, with no diagnostics > whatsoever, when trying to start it from a cmd.exe shell. Trying to > start it as the primary shell, in a new tab, yielded: > > ConEmuC: Root process was alive less than 10 sec, ExitCode=128. > Press Enter or Esc to close console... This upset me. This message means "sh.exe" was unexpectedly terminated. Supposing because of conemuhk.dll. But I had never seen this problem before. No more diagnostic info may be provided at moment, because exception (supposed) occures in "sh.exe" process. Can you provide more details about configuration? msys version, env vars, paths of msys and conemu... Thought, logs may help - open "Settings" dialog, goto "Debug" page, check "Shell and processes" and try to start new tab with "sh.exe --login -i" as root. Dont close "Settings" dialog, closing - stops logging. |
From: Erwin W. <wat...@xs...> - 2012-09-08 06:52:13
|
Maximus schreef, Op 8-9-2012 1:41: > Keith Marshall <keithmarshall@...> writes: > > > >> 4) Default configuration should immediately invoke MSYS shell. > > > "sh.exe --login -i" ? > > I have a question. How conemu can find "sh.exe"? If conemu.exe may be installed > into same folder as "sh.exe" - no problem. Otherwise it may be hard to > choose "default shell". E.g. user may install TCC/LE, which alse may be used as > known shell by conemu. > I think that ConEmu's default shell should stay cmd.exe. Cmd.exe is the best know shell and always present on Windows. Msys shell users are a small minority. But one should be able to change the default shell and set it for instance to MSYS' sh.exe. A ConEmu version distributed by MinGW should be configured to have MSYS sh.exe as default shell. The standard location of MSYS shell is: c:\mingw\msys\1.0\bin\sh.exe --login -i But people may have installed mingw/msys elsewhere. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Maximus <Con...@gm...> - 2012-09-08 00:13:40
|
Erwin Waterlander <waterlan@...> writes: > After using it some more I also experienced several crashes. Mainly with > the 64 bit version (stable and latest) on Windows 7. For instance when > you type an unknown option. I tried "conemu64 -h" to get some help, and > got similar results as "Root process was alive less than 10 sec...". Generally speaking, this case is not a crash. This is a problem of parameters translation. When command line starts with "/" (e.g. "/?") - it treated as switches (with possible "/cmd ..." parm at the end). Otherwise - parameters concatenated with default shell command line. So, I suppose, you'll get smth like "cmd -k". This (may be strange) behavior was created for case, when something dropped with mouse from explorer (for example) on the conemu shortcut. > Conemu64 /? worked fine. And the 64 bit version also hangs when I press > the [X] in the upper right corner to close conemu. > When I run the 32 bit version on 32 bit Vista it seems more stable. "Hangs" on cross pressing is strange. May you provide mem.dumps of processes (conemu64, conemuc64 and "shell")? > Maximus just needs to iron out some bugs, and I think he is willing to. Of course, I'm interested in bugfixes. As soon, as I have time to them. As usual, bugfix comes quickly, except issues which I can't reproduce in my environment or can't find the source of problem. |
From: Maximus <Con...@gm...> - 2012-09-08 00:32:55
|
Keith Marshall <keithmarshall@...> writes: > 4) Default configuration should immediately invoke MSYS shell. Btw, can you reveal the difference between "sh.exe" and "bash.exe"? Can't find info about this. Regards. |
From: LRN <lr...@gm...> - 2012-09-08 00:58:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08.09.2012 4:32, Maximus wrote: > Keith Marshall <keithmarshall@...> writes: >> 4) Default configuration should immediately invoke MSYS shell. > > Btw, can you reveal the difference between "sh.exe" and "bash.exe"? > Can't find info about this. > See [1] [1] http://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQSpg+AAoJEOs4Jb6SI2Cw0XYH/j+/eJWd29/vZoNCQ/3yGgys 8DqXlk0zisF77CDLgdWa7Y7LXAkUxJ36WThLmkoNjgl48HsA9ekES2cIWQ0C4QRg ZyR2m4lDDB3D2hHLK5zrMPEd7fceuwZlODuvmWaQzw20q8uwt0+foEk+MY3pRjVK ul3iijfVSIb82DnP/H3+vKHdKySzG6KwtNCDJ0nxBkcp/5PwZD9TEvf53O1ozp3d 9pxR5UogwfMOMu1HZPNX22CNDQoL9UyXeDXTFnZRN2a4Tx9y+NWK4b2ozgCMVKVm dwLpugJH7Y/HGySqp9ESc5Cwoxl9gWV7yydMDO9bS/z2xA/odwBmC1KryQlnwis= =83Zs -----END PGP SIGNATURE----- |
From: Maximus <Con...@gm...> - 2012-09-08 01:00:06
|
Keith Marshall <keithmarshall@...> writes: > I can start MSYS shell at new tab initiation, (with ConEmuHk disabled), > if I specify the command as > > %ComSpec% /c C:\MinGW\MSYS\1.0\bin\sh.exe --login -i > > but it seems wrong that I should need this indirect invocation. One tip. If you want to play with conemu (not waiting for the fix of the problem), just delete conemuhk.dll and conemuhk64.dll and uncheck "Inject ConEmuHk". This workaround, but you'll lose come features (like ansi-sequences, and some others). Regards. |
From: Maximus <Con...@gm...> - 2012-09-08 11:43:08
|
Erwin Waterlander <waterlan@...> writes: > I think that ConEmu's default shell should stay cmd.exe. Cmd.exe is the > best know shell and always present on Windows. Msys shell users are a > small minority. But one should be able to change the default shell and > set it for instance to MSYS' sh.exe. A ConEmu version distributed by > MinGW should be configured to have MSYS sh.exe as default shell. > > The standard location of MSYS shell is: > c:\mingw\msys\1.0\bin\sh.exe --login -i > > But people may have installed mingw/msys elsewhere. Current ConEmu version supports more than one default shell. Here is the rules of shell selection (in case of empty config, no shell selected in config obviously): 1. When ConEmu found "far.exe" near to itself (same folder or parent folder of "ConEmu.exe"), it starts Far Manager. 2. When TakeCommand or TCC/LE installed on PC, ConEmu starts "tcc.exe" 3. Otherwise, ConEmu starts "cmd.exe". Thought, I can add same step for "sh.exe" like "far.exe". But there is a question, if ConEmu will be distributed by MinGW, what folder it will be installed in? Note, there are some subfolders in ConEmu package (PE files, docs, license, Far Manager related files, and so on). Hope, it is not a problem? Another note (working in current version), all required files (ConEmu.exe, ConEmuC.exe, ConEmuCD.dll, ConEmuHk.dll and their 64-bit versions) may be placed in one folder, without subfolders. ConEmu supports this mode, but its internal autoupdate feature will fail in such config at moment. |
From: LRN <lr...@gm...> - 2012-09-08 13:14:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08.09.2012 15:42, Maximus wrote: > Erwin Waterlander <waterlan@...> writes: > >> I think that ConEmu's default shell should stay cmd.exe. Cmd.exe >> is the best know shell and always present on Windows. Msys shell >> users are a small minority. But one should be able to change the >> default shell and set it for instance to MSYS' sh.exe. A ConEmu >> version distributed by MinGW should be configured to have MSYS >> sh.exe as default shell. >> >> The standard location of MSYS shell is: >> c:\mingw\msys\1.0\bin\sh.exe --login -i >> >> But people may have installed mingw/msys elsewhere. > > Current ConEmu version supports more than one default shell. Here > is the rules of shell selection (in case of empty config, no shell > selected in config obviously): > > 1. When ConEmu found "far.exe" near to itself (same folder or > parent folder of "ConEmu.exe"), it starts Far Manager. 2. When > TakeCommand or TCC/LE installed on PC, ConEmu starts "tcc.exe" 3. > Otherwise, ConEmu starts "cmd.exe". > > Thought, I can add same step for "sh.exe" like "far.exe". But there > is a question, if ConEmu will be distributed by MinGW, what folder > it will be installed in? > > Note, there are some subfolders in ConEmu package (PE files, docs, > license, Far Manager related files, and so on). Hope, it is not a > problem? > > Another note (working in current version), all required files > (ConEmu.exe, ConEmuC.exe, ConEmuCD.dll, ConEmuHk.dll and their > 64-bit versions) may be placed in one folder, without subfolders. > ConEmu supports this mode, but its internal autoupdate feature will > fail in such config at moment. Well, MinGW follows *nix layout to some extent. That is, * executables (.exe files and scripts) are installed in /mingw/bin * shared libraries (.dll) are installed in /mingw/bin (this is unposixly, normally they go into /lib subdir, but on W32 you can't put shared libraries away, unless you have custom runtime linking code) * global configuration files go into /mingw/etc * shared data (icons, documentation, language files, manpages, some helper scripts, examples) to into /mingw/share/<packagename>/<something> * static libraries and import libraries (.a and .dll.a) go into /mingw/lib * includes go into /mingw/include * helper executables (not designed to be run directly) go into /mingw/bin/libexec/ (this is rare; i remember only git and gcc/binutils using this directory, so i'm not sure about details) * there's also /mingw/var, not sure what's it official purpose (it holds mingw-get databases and archives in /var/lib/mingw-get, for example). * then there's user's home directory for user-specific configuration files Programs adapted to this scheme usually ask Windows about their location (get module path; dlls do this with their HINSTANCE that they get in DllMain, executables do it with NULL HINSTANCE), check to see if they are in a /bin subdirectory, and if they are, assume that parent directory is /mingw root, and then figure out everything from there. Since shared libraries and executables are not separated, it won't be pose a problem for you - just put them all into /mingw/bin However, x86 vs x86_64 thing is more complex. If you have one ConEmu that then loads different shared libraries depending on the mode (x86 or x86_64), then it's probably ok. If you actually have two completely different sets of shared libraries and executables that have identical names, but are built for different architectures, then you obviously can't dump them all into /mingw/bin. Users will have to choose between x86 and x86_64 packages (unusual situation for mingw.org, historically it's been 100% x86, and when mingw-w64 is used, i think it's customary to have entire /mingw be either x86 or x86_64, but not a mix of both). I'm also assuming that being a native application, ConEmu will live in /mingw, not in /usr. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQS0SqAAoJEOs4Jb6SI2CwYPQH/2CouJ+6v7DHaY6xXM/FJNwr v0w77irLKpcN/bfIr3C+caTkdPV85bG8Uq3l79frxUcEDRF3oCuUlRtb3kqr5CSO 1/fdWpZipdKfvmiSGxJ+VuBjWHlqNz8yWSgr0SU93a8XefxHH59v+av2SH5sfrYx x+US2mVbyXu+EJVY3OLqNcYW6FKk9hIz3MpHjdzWlzFr3lhYupclScTRmpbFzTFe W6upl316g78ujgTyvo8o3Jbf77ljpXYe81je5iquZfPOsgB9oiYvn+I/W2ApEYWr GWD0SXdp8aOYFxnE96yqT8erL08c7/bEbro3x6xgV4ZfxFh4SDMNLV+T8CTcfNk= =qs3Z -----END PGP SIGNATURE----- |
From: Erwin W. <wat...@xs...> - 2012-09-08 17:28:23
|
Maximus schreef, Op 8-9-2012 13:42: > Erwin Waterlander <waterlan@...> writes: > >> I think that ConEmu's default shell should stay cmd.exe. Cmd.exe is the >> best know shell and always present on Windows. Msys shell users are a >> small minority. But one should be able to change the default shell and >> set it for instance to MSYS' sh.exe. A ConEmu version distributed by >> MinGW should be configured to have MSYS sh.exe as default shell. >> >> The standard location of MSYS shell is: >> c:\mingw\msys\1.0\bin\sh.exe --login -i >> >> But people may have installed mingw/msys elsewhere. > Current ConEmu version supports more than one default shell. > Here is the rules of shell selection (in case of empty config, > no shell selected in config obviously): > > 1. When ConEmu found "far.exe" near to itself > (same folder or parent folder of "ConEmu.exe"), it starts Far Manager. > 2. When TakeCommand or TCC/LE installed on PC, ConEmu starts "tcc.exe" > 3. Otherwise, ConEmu starts "cmd.exe". > > Thought, I can add same step for "sh.exe" like "far.exe". > But there is a question, if ConEmu will be distributed by MinGW, > what folder it will be installed in? > I think it is better that you give the user total control via a configuration file. ConEmu should not make assumptions. Is it possible to set the default shell with a configuration file? regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Erwin W. <wat...@xs...> - 2012-09-08 17:20:46
|
Maximus schreef, Op 8-9-2012 2:32: > Keith Marshall <keithmarshall@...> writes: > > > >> 4) Default configuration should immediately invoke MSYS shell. > > > Btw, can you reveal the difference between "sh.exe" and "bash.exe"? Can't find > info about this. > sh.exe is often a copy of bash.exe. When bash.exe is started as sh.exe it runs in POSIX mode, meaning it supports everything that is defined in the POSIX shell specification and not much more. If you run bash.exe you can use all the extra features that are not in POSIX. The problem with using advanced bash features is that they may not work in other or older shells. Being conservative and sticking to POSIX makes that your shell scripts have big chance running OK in all Bourne type shells. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: George K. <xke...@ne...> - 2012-09-08 23:54:53
|
On 9/8/2012 5:20 PM, Erwin Waterlander wrote: > sh.exe is often a copy of bash.exe. When bash.exe is started as sh.exe > it runs in POSIX mode, meaning it supports everything that is defined > in the POSIX shell specification and not much more. If you run > bash.exe you can use all the extra features that are not in POSIX. The > problem with using advanced bash features is that they may not work in > other or older shells. Being conservative and sticking to POSIX makes > that your shell scripts have big chance running OK in all Bourne type > shells. regards, Actually, bash in POSIX mode (sh.exe) can still use many extra features that are not in POSIX, because POSIX mode never turns off those features. Another shell, the Almquist Shell, has fewer extra features. MSYS packages the Debian Almquist Shell in msys-dash. I have not installed dash, because bash can already run all my shell scripts. --George Koehler |
From: Maximus <Con...@gm...> - 2012-09-08 20:12:27
|
LRN <lrn1986@...> writes: > Since shared libraries and executables are not separated, it won't be > pose a problem for you - just put them all into /mingw/bin > However, x86 vs x86_64 thing is more complex. If you have one ConEmu > that then loads different shared libraries depending on the mode (x86 > or x86_64), then it's probably ok. > If you actually have two completely different sets of shared libraries > and executables that have identical names, but are built for different > architectures, then you obviously can't dump them all into /mingw/bin. > Users will have to choose between x86 and x86_64 packages (unusual > situation for mingw.org, historically it's been 100% x86, and when > mingw-w64 is used, i think it's customary to have entire /mingw be > either x86 or x86_64, but not a mix of both). Thanks for thorough explanation. ConEmu has one package, containing both 32bit and 64bit versions, names are different, so all files may be placed in one folder without problems. |
From: Maximus <Con...@gm...> - 2012-09-08 20:20:10
|
Erwin Waterlander <waterlan@...> writes: > > Maximus schreef, Op 8-9-2012 13:42: > > Erwin Waterlander <waterlan@...> writes: > > > > 1. When ConEmu found "far.exe" near to itself > > (same folder or parent folder of "ConEmu.exe"), it starts Far Manager. > > 2. When TakeCommand or TCC/LE installed on PC, ConEmu starts "tcc.exe" > > 3. Otherwise, ConEmu starts "cmd.exe". > > > > Thought, I can add same step for "sh.exe" like "far.exe". > > But there is a question, if ConEmu will be distributed by MinGW, > > what folder it will be installed in? > > > > I think it is better that you give the user total control via a > configuration file. ConEmu should not make assumptions. Is it possible > to set the default shell with a configuration file? Of course, user has total control over configuration. User may manually choose startup shell, or several startup tabs. Automatic shell selection may occures only on "clear" configuration, when user had not choose shell manually. regards |