Re: MinTTY

[Angelo Graziosi]

Andy Koppe ha scritto:



So what do you do when you need the tilde in other applications, e.g. 
for typing the bitwise-not operator in C?


As I have explained in my OP: AltGr+ì or ALT+126 code work just fine
with other consoles and/or applications.

For completeness, on MinTTY, AltGr+other keys work just fine. For
example, AltGr+è prints '[', AltGr+'+' prints ']', etc.: only AltGr+ì
does not work!

At the moment, as workaround, in MinTTY I can insert '~', using
'PgUP/PgDown' keys...


Cheers,
   Angelo.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: MinTTY

[Andy Koppe]

Gary R. Van Sickle wrote:


-i" on the shortcut's command line.  That would be a nice one to have in the
configuration dialogs, but I don't see how you avoid the registry in that
case.  Maybe just going with "bash --login -i" as the default if you don't
tell it otherwise would be a 90% solution.  


MinTTY's current behaviour is the same as rxvt's and xterm's, and I 
think it makes sense not to execute the profile when starting a new 
terminal from within an existing session using just 'rxvt&' or 'mintty&'.



I don't recall what Setup.exe's
Shortcut capabilities are, but if it's capable enough, the setup package
could tack that on the end when it generates a shortcut for it.


That's definitely the way to go.


- The ability to configure it via dialogs, especially such 21st century
things as fg/bg/cursor colors and the font and point size to use, is most
excellent and most welcome.


:)


- From the web page: "Mousewheel events can be sent as arrow keys. (This
allows mousewheel scrolling e.g. in less.)"  All I get is dings, and I don't
see any documentation as to how to set this up.


Yep, unfortunately no docs yet. (Issue 2.)

When on the alternate screen and not in application mouse mode, 
mousewheel-up/down sends arrow-up/down combined with the scroll modifier 
configured under Keys, so with the default Shift you get ^[[1;2A and 
^[[1;2B. (Replace the 2 with 3 for Alt or 5 for Ctrl).


The thinking behind that is that this replaces the terminal scrollback 
when on the alternate screen, and that plain arrows mean cursor movement 
rather than scrolling. And a word of warning: the feature doesn't work 
in Vista when the scrollbar is shown. Looks like the inactive scrollbar 
is swallowing the mousewheel events.


Activate mousewheel scrolling in 'less' with the following two lines in 
your .lesskey file. Don't forget to run 'lesskey' to compile it into 
less's internal format.


\eO1;2A back-line
\eO1;2B forw-line

Btw, it's 'O' rather than '[' here, because 'less' switches into 
"application cursor key" mode. (Yep, the world of terminals is full of 
fascinating yet strangely pointless details like that.)



- OMG FULL-SCREEN MODE!  Where we're going, we don't need roads!  Dude, if
you tell me that it uses DirectX and a multi-hundred-dollar video card to
throw up a full-screen 80x24 text interface I will laugh for a week ;-)!


Don't worry, it's plain ol' Win32. Another goodie from PuTTY. Combine 
fullscreen with transparency and an auto-hiding taskbar for maximum geek 
cred. :)



MinTTY:
$ set | grep TERM
TERM=xterm


The proper thing to do would be to set TERM to "mintty", but that would 
require termcap and terminfo entries. I guess that might be worth 
considering for a MinTTY package, although iirc KDE's Konsole and 
GNOME's terminal also just set it to "xterm", because like MinTTY they 
aim to be compatible with (the default config of) xterm. Would make life 
easier for everyone to settle on that as a standard.



- It should default to "Show scrollbar" being on.  For a while there I
thought I didn't have a scrollback buffer.


Agreed, switching it off by default took the minimalism a bit too far. 
Issue 19.



- The default Lucida 9-point seems rather too small to me.  Now, my eyes are
no spring chickens anymore, but even so, I think 12 point would be a better
default.


I'd realised that before seeing your mail and already increased it to 
10point in 0.3.1. That's also the default in PuTTY and Windows Notepad, 
and pretty similar in size to the bitmap font in the Windows console. 
Obviously matter of personal preference though, hence the option. (No 
kidding.)



- When you open the Options dialog, it takes two clicks to select one of the
option catagories in the tree pane on the left, as if the first is getting
ignored for some reason.


Ah yes, I never did get round to investigate that one. Issue 20.


- It doesn't handle resizing correctly.  I.e., with my urxvt-X.exe+Xwin
setup, if I do "echo $PATH" (which goes way over 80 chars) and then I resize
the window, the previously-printed path gets re-layed-out to fill the entire
client area.  With MinTTY, that doesn't happen.  No relayout happens on
either increasing or decreasing the window width (and hence the number of
columns).  Subsequently printed output does however take the new number of
columns into account.  To me, this is the most significant issue I've seen
so far.


Plain rxvt and xterm do the same, and it would be quite a big and risky 
change in code I don't know much about to implement relayouting.


Simon Tatham has a PuTTY wish for an apparently simpler version of this:
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/resize-no-truncate.html

(Btw, resizes are signalled to applications, so relayouting does work in 
apps that handle that signal, e.g. less.)



- I don't see a config option to set the number of lines of scrollback
buffer.  Whatever it is defaulting to seems like plenty, but it would 

Re: MinTTY

[Andy Koppe]

As I have explained in my OP: AltGr+ì or ALT+126 code work just fine
with other consoles and/or applications.


If I switch my machine to the Italian keyboard, Windows applications 
such as Notepad, Word or Mozilla Thunderbird do nothing when I press 
AltGr+ì. (I can type the accented ì alright.) This also applies to the 
Windows console and the default Cygwin terminal running inside that. 
Looking at the Italian keyboard layout in MSKLC, this is because nothing 
has been assigned to AltGr+ì (i.e. the key to the left of backspace).


As I explained, the other terminals you mentioned are X applications, 
and X has its own separate keyboard layout infrastructure. MinTTY is a 
native Windows application though, hence it depends on this key being 
supported in the Windows keyboard layout.


I already accepted the Alt+NumPad issue.

Andy


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

cmd.exe from Cygwin

[Jeenu V]

Hi,

I've to run some windows commands repeatedly. Since I'm familiar and
comfortable with BASH, I thought I would perform the 'intelligent'
decisions using BASH scripts and run rest using cmd.exe invoked from
Cygwin bash shell. But this is the problem I face:

The program I intend to run with cmd.exe (with /c switch) fails to run
as it couldn't access some Windows paths. Please take a look like this
command, for example:

N:\src\CEDAR\GENERIC\base\bsp\hwip_arm\rvemuboard\ct1136\test>cmd /c
bldmake bldfiles ARMV6
sh: E:SymbianM04765_Symbian_OS_v9.5binTechViewepoc32toolsbldmake.bat:
command not found

There are two things that I'm surprised about:
1) How come a command launched from cmd.exe spits an error message
starting with 'sh:'?
2) Why are back-slashes stripped-off from the path in output message?

Also it came to my notice that cmd.exe invoked from a Cygwin bash
shell doesn't really behave like the Windows cmd.exe. For example, if
you press up-arrow, the cursor goes flying over the window and the
display sometimes goes for a toss. Keys like F7 and F8 doesn't work
either.

It would suffice--as of now, at least--if I could launch a
cmd.exe--separate and independent--window from a Cygwin shell. I could
try

explorer.exe c:\windows\system32\cmd.exe

but I'm unable to pass parameters to cmd.exe (say /c or a batch file name).

Please help.

-- 
Thanks
Jeenu

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cmd.exe from Cygwin

[Lee]

On 1/2/09, Jeenu V  wrote:
> Hi,
>
> I've to run some windows commands repeatedly. Since I'm familiar and
> comfortable with BASH, I thought I would perform the 'intelligent'
> decisions using BASH scripts and run rest using cmd.exe invoked from
> Cygwin bash shell. But this is the problem I face:
>
> The program I intend to run with cmd.exe (with /c switch) fails to run
> as it couldn't access some Windows paths. Please take a look like this
> command, for example:

The backslash is an escape character, so you need to get it treated as
a character somehow - escaping ("\\") or inside quotes works for me:

$ cmd /c c:\util\showdev.bat
'c:utilshowdev.bat' is not recognized as an internal or external command,
operable program or batch file.

$ cmd /c c:\\util\\showdev.bat
C:\cygwin\home\Lee>set devmgr_show_nonpresent_devices=1
C:\cygwin\home\Lee>cd\windows\system32
C:\Windows\System32>start devmgmt.msc

$ cmd /c "c:\util\showdev.bat"
C:\cygwin\home\Lee>set devmgr_show_nonpresent_devices=1
C:\cygwin\home\Lee>cd\windows\system32
C:\Windows\System32>start devmgmt.msc

Regards,
Lee


>
> N:\src\CEDAR\GENERIC\base\bsp\hwip_arm\rvemuboard\ct1136\test>cmd /c
> bldmake bldfiles ARMV6
> sh: E:SymbianM04765_Symbian_OS_v9.5binTechViewepoc32toolsbldmake.bat:
> command not found
>
> There are two things that I'm surprised about:
> 1) How come a command launched from cmd.exe spits an error message
> starting with 'sh:'?
> 2) Why are back-slashes stripped-off from the path in output message?
>
> Also it came to my notice that cmd.exe invoked from a Cygwin bash
> shell doesn't really behave like the Windows cmd.exe. For example, if
> you press up-arrow, the cursor goes flying over the window and the
> display sometimes goes for a toss. Keys like F7 and F8 doesn't work
> either.
>
> It would suffice--as of now, at least--if I could launch a
> cmd.exe--separate and independent--window from a Cygwin shell. I could
> try
>
> explorer.exe c:\windows\system32\cmd.exe
>
> but I'm unable to pass parameters to cmd.exe (say /c or a batch file name).
>
> Please help.
>
> --
> Thanks
> Jeenu
>
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
>
>

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cmd.exe from Cygwin

[Jeenu V]

Thanks for the reply.

>
> The backslash is an escape character, so you need to get it treated as
> a character somehow - escaping ("\\") or inside quotes works for me:
>

I'm aware of this.

>> N:\src\CEDAR\GENERIC\base\bsp\hwip_arm\rvemuboard\ct1136\test>cmd /c
>> bldmake bldfiles ARMV6
>> sh: E:SymbianM04765_Symbian_OS_v9.5binTechViewepoc32toolsbldmake.bat:
>> command not found

 If you see above example, all I run is a command 'bldmake' which
neither contain back-slash nor white-space. So there's no need to
quote the file name here. What 'bldmake' really is--whether .bat, .com
or .exe--it's for cmd.exe to find out, of course using %PATH%. In my
case, going by the output, it did locate a .bat file with the name
'bldmake'. However, I suspect, something went wrong in the path
translation. But the 'sh: ' in the error output rings in my head.

Talking about black-slashes: assuming it's a .bat file, as long as the
content is interpreted by cmd.exe, the back-slashes inside the script
shouldn't make a difference.

>> It would suffice--as of now, at least--if I could launch a
>> cmd.exe--separate and independent--window from a Cygwin shell. I could
>> try

Update: I tried with cygstart.exe, I don't see a difference from
starting it with cygstart.exe and the above example. I.e. back-slashes
are truncated and output said 'sh: '.

-- 
Thanks
Jeenu

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] [1.5] Updated: {gettext/gettext-devel/libgettextpo0/libintl8/libasprintf0}-0.17-3

[cygwin]

gettext is the GNU package which provides 'national language support'
for other programs. It includes a number of utility programs.

This is a packaging and bugfix update of the gettext package(s).  This
will most likely be the final gettext update for the cygwin-1.5
distribution; future development will continue with gettext-0.17-10 for
cygwin-1.7.

gettext-0.17-3
gettext-devel-0.17-3
libintl8-0.17-3
libgettextpo0-0.17-3
libasprintf0-0.17-3

CHANGES (gettext-0.17-1 ---> gettext-0.17-10):
(includes changes in the released but un-announced gettext-0.17-2)

* Fixed packaging bug in setup.hint for libasprintf0
* Fixed a bug in lib-link.m4 exposed when dependent libraries
  are installed in different directories. Also fixed upstream
  (in future gettext-0.18).
* Fixed an issue in the rpath (e.g. lib-link.m4) test suite
  where only the installed .m4 files were tested, rather than
  the in-package ones. This explains (and corrects) the
  odd rpath test results in gettext-0.17-1. See
  http://cygwin.com/ml/cygwin-announce/2008-11/msg00015.html
* Modified the rpath (e.g. lib-link.m4) test suite so that the
  tests continue to pass. As it happens, in gettext-0.15.1-X
  and previous, these tests never should have passed; they
  were erroneously linking statically. Now they link shared,
  and can't "find" their dependent DLLs without $PATH
  manipulation.  This is the correct behavior; but as we
  "expect" the test suite to pass, the test suite now also
  manipulates $PATH.
* Some modifications to gettext-runtime test_lock program to
  enable conditional execution of some subtests, and conditional
  debug/trace output (see below). This test appears twice --
  once in gettext-runtime and again in gettext-tools/gnulib-tests.
  Only the former was modified.

TESTSUITE RESULTS:

gettext-tools
===
All 300 tests passed (27 tests were not run)

gettext-tools/gnulib-tests
===
1 of 47 tests failed
(2 tests were not run)

the test_once subtest of test_link.exe fails. It is a duplicate of the
gettext-runtime test of the same name (see below). Sometimes, the test
must be killed manually, or it sometimes coredumps.

This is a new regression, but appears to be related to cygwin
thread/signal code, and not gettext, because it passed in gettext-0.17-1.


gettext-runtime
===
The test_lock, test_rwlock, and test_recursive_lock subtests all pass,
but the test_once subtest fails: sometimes it coredumps, and sometimes
it hangs and must be killed manually). Under cygwin-1.5, the test_once
subtest always segfaults unless compiled with -O0,  in which case it may
hang and must be killed manually.

However, when recompiled with debugging output, it succeeds (unless the
debugging output is sent to /dev/null, in which case it also hangs) --
this behavior is consistent on both cygwin-1.5 and -1.7.  This points to
a race condition of some kind, which (may, if conditions are right) lead
to stack overflow problem in the thread and/or signal handling code of
cygwin, or threads "missing" their signal and then waiting forever for
the signal that already arrived.


gettext-rpath
===
All 30 tests passed

The lib-link test suite has been modified for cygwin, in two ways:
(1) the test scripts extend the PATH to include the installation
directories of the sub-dependent libraries, and
(2) the Makefiles for the executable tests extend the PATH to
include the installation directory of the direct dependent
library.
In this way, the PATH is sure to include all directories which contain
the DLLs used by the test application. However, all of these changes are
simply workarounds for the primary defect on windows: there IS no RPATH
support. Modifying the $PATH is no different than modifying
$LD_LIBRARY_PATH on other platforms -- and all of these rpath tests are
*supposed* to be checking that RPATH support actually works *without*
manipulating $LD_LIBRARY_PATH.

No matter how you slice it on windows, it doesn't. So ALL of these
changes are "cheating". Earlier versions of gettext (0.15 and before)
*erroneously* passed many of these tests *without* the workaround above
-- because the tests in which the dependent and sub-dependent libraries
were installed into different prefixes did NOT actually link against
those DLLs, but linked statically. So, naturally, there was no runtime
"can't find the DLL" issue. This was "fixed" in gettext-0.17 -- so now
these tests began to fail, as they always should have done, without the
workarounds described above.

--
Charles Wilson
gettext volunteer maintainer for cygwin



To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This dow

[ANNOUNCEMENT] [1.7] Updated: {gettext/gettext-devel/libgettextpo0/libintl8/libasprintf0}-0.17-10

[cygwin]

gettext is the GNU package which provides 'national language support'
for other programs. It includes a number of utility programs.

This is the first release specific for cygwin-1.7.  The only differences
between this package and the simultaneously-released gettext-0.17-3
for cygwin-1.5 are (1) compiled against the cygwin-1.7 DLL and its
import library, and (2) documentation changes.

COMPILER USED: gcc-3.4.4-3 and g++-3.4.4-3
This is important to note, because libasprintf0 is a C++ library. Later
updates MAY use gcc-4.3, but will be accompanied by DLL version number
bumps for all C and C++ dlls.

These packages should be updated together with libiconv 1.12-10:

libiconv-1.12-10
libiconv2-1.12-10
libcharset1-1.12-10

gettext-0.17-10
gettext-devel-0.17-10
libintl8-0.17-10
libgettextpo0-0.17-10
libasprintf0-0.17-10

CHANGES (gettext-0.17-1 ---> gettext-0.17-10):
(includes changes in the released but un-announced gettext-0.17-2)

* Fixed packaging bug in setup.hint for libasprintf0
* Fixed a bug in lib-link.m4 exposed when dependent libraries
  are installed in different directories. Also fixed upstream
  (in future gettext-0.18).
* Fixed an issue in the rpath (e.g. lib-link.m4) test suite
  where only the installed .m4 files were tested, rather than
  the in-package ones. This explains (and corrects) the
  odd rpath test results in gettext-0.17-1. See
  http://cygwin.com/ml/cygwin-announce/2008-11/msg00015.html
* Modified the rpath (e.g. lib-link.m4) test suite so that the
  tests continue to pass. As it happens, in gettext-0.15.1-X
  and previous, these tests never should have passed; they
  were erroneously linking statically. Now they link shared,
  and can't "find" their dependent DLLs without $PATH
  manipulation.  This is the correct behavior; but as we
  "expect" the test suite to pass, the test suite now also
  manipulates $PATH.
* Some modifications to gettext-runtime test_lock program to
  enable conditional execution of some subtests, and conditional
  debug/trace output (see below). This test appears twice --
  once in gettext-runtime and again in gettext-tools/gnulib-tests.
  Only the former was modified.

TESTSUITE RESULTS:

gettext-tools
===
All 300 tests passed (27 tests were not run)

gettext-tools/gnulib-tests
===
1 of 47 tests failed
(2 tests were not run)

the test_once subtest of test_link.exe fails. It is a duplicate of the
gettext-runtime test of the same name (see below). Sometimes, the test
must be killed manually, or it sometimes coredumps.

This is a new regression, but appears to be related to cygwin
thread/signal code, and not gettext, because it passed in gettext-0.17-1.


gettext-runtime
===
The test_lock, test_rwlock, and test_recursive_lock subtests all pass,
but the test_once subtest fails: sometimes it coredumps, and sometimes
it hangs and must be killed manually). Under cygwin-1.5, the test_once
subtest always segfaults unless compiled with -O0,  in which case it may
hang and must be killed manually.

However, when recompiled with debugging output, it succeeds (unless the
debugging output is sent to /dev/null, in which case it also hangs) --
this behavior is consistent on both cygwin-1.5 and -1.7.  This points to
a race condition of some kind, which (may, if conditions are right) lead
to stack overflow problem in the thread and/or signal handling code of
cygwin, or threads "missing" their signal and then waiting forever for
the signal that already arrived.


gettext-rpath
===
All 30 tests passed

The lib-link test suite has been modified for cygwin, in two ways:
(1) the test scripts extend the PATH to include the installation
directories of the sub-dependent libraries, and
(2) the Makefiles for the executable tests extend the PATH to
include the installation directory of the direct dependent
library.
In this way, the PATH is sure to include all directories which contain
the DLLs used by the test application. However, all of these changes are
simply workarounds for the primary defect on windows: there IS no RPATH
support. Modifying the $PATH is no different than modifying
$LD_LIBRARY_PATH on other platforms -- and all of these rpath tests are
*supposed* to be checking that RPATH support actually works *without*
manipulating $LD_LIBRARY_PATH.

No matter how you slice it on windows, it doesn't. So ALL of these
changes are "cheating". Earlier versions of gettext (0.15 and before)
*erroneously* passed many of these tests *without* the workaround above
-- because the tests in which the dependent and sub-dependent libraries
were installed into different prefixes did NOT actually link against
those DLLs, but linked statically. So, naturally, there was no runtime
"can't find the DLL" is

[ANNOUNCEMENT] [1.7] Updated: {libiconv/libiconv2/libcharset1}-0.12-10

[cygwin]

The GNU libiconv package provides an iconv() implementation, for use on
systems which don't have one, or whose implementation cannot convert
from/to Unicode.

This is the first release specific for cygwin-1.7.  The only differences
between this package and the earlier libiconv-0.12-1 (released for both
cygwin-1.5 and cygwin-1.7) are (1) compiled against the cygwin-1.7 DLL
and its import library, and (2) documentation changes. There is no
corresponding "simultaneously released" version of libiconv solely for
cygwin-1.5; libiconv-0.12-1 will most likely be the final libiconv
update for the cygwin-1.5 distribution, and future libiconv development
will continue with this libiconv-0.12-10 package for cygwin-1.7 only.

COMPILER USED: gcc-3.4.4-3 and g++-3.4.4-3
Later updates MAY use gcc-4.3, but will be accompanied by DLL version
number bumps for all C dlls.

Changes (libiconv-0.12-1 ---> libiconv-0.12-10)

* Fork from cygwin-1.5 package development stream
* Updated packaging to use (cygwin-1.7-specific) cygport 0.9.2
  rather than legacy cygport 0.4.x.

TESTSUITE RESULTS:
All tests pass.

--
Charles Wilson
libiconv volunteer maintainer for cygwin



To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: MinTTY

[Buchbinder, Barry (NIH/NIAID) [E]]

Thorsten Kampe wrote on Thursday, January 01, 2009 11:37 AM:
> * Buchbinder, Barry (NIH/NIAID) [E] (Wed, 31 Dec 2008 15:03:48 -0500)>
>> Thorsten Kampe wrote on Wednesday, December 31, 2008 9:40 AM:
>>> you have to use "start".
>>
>> Or "cygstart.exe"?
>
> Right. Although there is no real advantage to use that instead of
> start.

On XP there is no start.exe.  (98se )  So you have to use
cmd /c start

The main advantage of cygstart is that it understands POSIX paths.

I seem to remember that sometimes quoting can be simpler with cygstart
than with `cmd /c start'.

> Okay. Can we say "a little bit lengthy although not as lenghty as
> someone might expect"?

Yes.  :-)

Actually, when I started writing the steps to get at the environmental
variables I was surprised that it was so much longer than I remembered.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.5.25: Cygwin, LAPACK, and ssh -- output "swallowed"

[Jim Kramer]

Eric Hui wrote:
> 
> Jim Kramer wrote:
> 
>> Concise problem description:
>> A C/C++ program that incorporates LAPACK functions "swallows" program 
>> output when run (as a command) over an ssh connection.
> 
> This may be an issue with your path.  In your example 1, try
> 
> ssh hollyberry echo '$PATH'
> 
> The LAPACK dll is in /usr/lib/lapack/, so that will need to be in 
> your path.
> 
> 

Yes, thank you, that resolved it. To be sure I understand why it wasn't
working as I expected:

When sending a command via ssh, no shell is started and therefore the cygwin
environment (in this case, the library path) is not fully configured. So,
the appropriate path needs to be added someplace such that *Windows* (not
Cygwin) can find it (e.g., the Windows PATH environment variable). Do I have
that right?

Also, a follow-up question: is there another method for setting paths that
would work under these circumstances? For instance, symbolic links to the
LAPACK library?

Thank you again for the help,

Jim
-- 
View this message in context: 
http://www.nabble.com/1.5.25%3A-Cygwin%2C-LAPACK%2C-and-sshoutput-%22swallowed%22-tp21243563p21254779.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: MinTTY

[Andy Koppe]

Christopher Faylor wrote:

I finally played around with this a little.  It is nice.   It reminds
me a little bit of Console2 - http://console.sourceforge.net/.

One thing that Console2 does is provide a true "console" interface which
doesn't rely on anything like Cygwin's ptys.  


On the other hand, it isn't actually a terminal emulator as such. What 
it does do is to put a nicer interface on the Windows console, so for 
Cygwin programs you still get Cygwin's console-based terminal.



Console2 apparently uses a polling interface over a captive invisible
console to fool programs into thinking that they are running in a real
Windows console.


It accesses the console's screen contents through Win32's 
GetConsoleScreenBufferInfo() and displays it in its own window while 
hiding the actual console. I can't see a way to combine this sort of 
approach with ptys.



On further reflection, I think that the fact that mintty uses cygwin
ptys may be a show stopper as far as making it the default is concerned.
I don't think we can have the default command line interface misbehave
when it runs some standard Windows programs, like, if memory serves, the
"NET" command in some cases.


As things stand, it's a choice between full support either for Windows 
console applications or for Unix terminal applications. I'd guess that 
the latter is more important to most Cygwin users. Not my call though.



Also, the mouse behavior isn't like xterm or xterm imitators so it
wouldn't necessarily be intuitive for someone coming over from linux.
I'm sure that could be changed though.  Did I miss a configuration
for mouse and cut/paste behavior?


Middle-click paste is always available, and copy-on-select and 
right-click extend can be enabled on the Mouse page of the options. (In 
the latter case, the menu is still available via Shift-right-click and 
the context menu key. The options can also be found in the window menu.)



I still think it would be a nice addition to the list of Cygwin
packages.  It gets my +1 vote.


Thanks!


Oh, and if you want to get rid of the console window when mintty is
started from a bat file, I think FreeConsole() would do the trick.


I'll give that a try. Perhaps I should make it a command line option if 
I can get it to work?


Andy


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: xterm and cut & paste

[Brian Salter-Duke]

On Fri, 02 Jan 2009 06:56:23 +, Fergus  wrote:
> Include -clipboard as an option for XWin.
> e.g.
>run XWin -clipboard -nolisten local -multiwindow 2>nul &
> and then selected text in xterm is automatically copied to the clipboard 
> for onward pasting.
> Fergus

Thanks for that. I find X very confusing and mainly just want a simple
xterm to run mutt, slrn and unix like-codes. I think I may have a messed
up system with not having a clean upgrade to the latest X. I was using
startx and I can not see where XWin is called there. Maybe I'm blind. I
am now using startswin.bat and I've played with startxwin.sh. That
clearly calls XWin and I have the -blipboard argument in and it works
fine.  However the -multiwindow causes an error and it just gives an
xterm, but that is fine for now. I'll look into that later.

Cheers, Brian.
-- 
   Brian Salter-Duke  Melbourne, Australia
 My real address is b_duke(AT)bigpond(DOT)net(DOT)au
Use this for reply or followup.  Registered Linux user 287938.
  Cygwin for Linux on PCs. 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: MinTTY

[Christopher Faylor]

On Fri, Jan 02, 2009 at 10:10:33PM +, Andy Koppe wrote:
> Christopher Faylor wrote:
>> I finally played around with this a little.  It is nice.   It reminds
>> me a little bit of Console2 - http://console.sourceforge.net/.
>> One thing that Console2 does is provide a true "console" interface which
>> doesn't rely on anything like Cygwin's ptys.  
>
> On the other hand, it isn't actually a terminal emulator as such. What it 
> does do is to put a nicer interface on the Windows console, so for Cygwin 
> programs you still get Cygwin's console-based terminal.

That's what I meant by the "console" interface.

>>Console2 apparently uses a polling interface over a captive invisible
>>console to fool programs into thinking that they are running in a real
>>Windows console.
>
>It accesses the console's screen contents through Win32's
>GetConsoleScreenBufferInfo() and displays it in its own window while
>hiding the actual console.  I can't see a way to combine this sort of
>approach with ptys.

If you have a captured interface then a windows console could be treated
like a pty.  Getting more than one of these per process would be tricky
though and it might not be capable of being a general pty interface.

>>On further reflection, I think that the fact that mintty uses cygwin
>>ptys may be a show stopper as far as making it the default is
>>concerned.  I don't think we can have the default command line
>>interface misbehave when it runs some standard Windows programs, like,
>>if memory serves, the "NET" command in some cases.
>
>As things stand, it's a choice between full support either for Windows
>console applications or for Unix terminal applications.  I'd guess that
>the latter is more important to most Cygwin users.  Not my call though.

The fact that windows apps don't like cygwin ptys is why we never made
rxvt the standard interface.  What would be nice is to give the user
some easy way to decide which they want.  We would, of course, still get
people complaining about whichever choice they made, though.

>>Also, the mouse behavior isn't like xterm or xterm imitators so it
>>wouldn't necessarily be intuitive for someone coming over from linux.
>>I'm sure that could be changed though.  Did I miss a configuration for
>>mouse and cut/paste behavior?
>
>Middle-click paste is always available, and copy-on-select and
>right-click extend can be enabled on the Mouse page of the options.
>(In the latter case, the menu is still available via Shift-right-click
>and the context menu key.  The options can also be found in the window
>menu.)

Yeah, sorry.  I found out after I sent the email that I'd previously
installed some "nifty" software (Microsoft's intellipoint) which was
interfering with my mouse clicks.  Middle-click wasn't working right.
Now it is.

>>Oh, and if you want to get rid of the console window when mintty is
>>started from a bat file, I think FreeConsole() would do the trick.
>
>I'll give that a try.  Perhaps I should make it a command line option
>if I can get it to work?

Maybe.  On further thought, it's possible that FreeConsole won't do
the trick either.  A combination of FreeConsole + restarting the
process with CreateProcess might be needed.  Maybe it isn't worth
the effort.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: MinTTY

[Andy Koppe]

Christopher Faylor wrote:

It accesses the console's screen contents through Win32's
GetConsoleScreenBufferInfo() and displays it in its own window while
hiding the actual console.  I can't see a way to combine this sort of
approach with ptys.


If you have a captured interface then a windows console could be treated
like a pty.


I'm afraid I don't quite understand what you're getting at. Isn't this 
what the cygwin terminal is doing already? I see a WriteConsoleOutput 
call in fhandler_console.cc, which manipulates the console screen 
content directly.



The fact that windows apps don't like cygwin ptys is why we never made
rxvt the standard interface.  What would be nice is to give the user
some easy way to decide which they want.  We would, of course, still get
people complaining about whichever choice they made, though.


Agreed. :)


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cmd.exe from Cygwin

[Dave Korn]

Jeenu V wrote:

> The program I intend to run with cmd.exe (with /c switch) fails to run
> as it couldn't access some Windows paths. Please take a look like this
> command, for example:
>
> N:\src\CEDAR\GENERIC\base\bsp\hwip_arm\rvemuboard\ct1136\test>cmd /c
> bldmake bldfiles ARMV6
> sh: E:SymbianM04765_Symbian_OS_v9.5binTechViewepoc32toolsbldmake.bat:
> command not found
>
> There are two things that I'm surprised about:
> 1) How come a command launched from cmd.exe spits an error message
> starting with 'sh:'?
> 2) Why are back-slashes stripped-off from the path in output message?

  My WAG: You're using some kind of embedded toolchain for Symbian that is
based on the gnu tools, and there's some kind of PATH-clash going on between
those and the Cygwin versions.  Maybe it shipped with a mingw32-ish sh.exe
that it's trying to invoke and your Cygwin sh.exe is getting in there first?
We'll need to see your cygcheck output (as described at
http://cygwin.com/problems.html, please take special note of the request to
send it as an attachment rather than inline body text, TIA) to get an idea if
that's happening.

> Also it came to my notice that cmd.exe invoked from a Cygwin bash
> shell doesn't really behave like the Windows cmd.exe. For example, if
> you press up-arrow, the cursor goes flying over the window and the
> display sometimes goes for a toss. Keys like F7 and F8 doesn't work
> either.
>
> It would suffice--as of now, at least--if I could launch a
> cmd.exe--separate and independent--window from a Cygwin shell. I could
> try
>
> explorer.exe c:\windows\system32\cmd.exe
>
> but I'm unable to pass parameters to cmd.exe (say /c or a batch file name).

  That's bizarre but could be related.  For me, just invoking cmd.exe
directly at a Cygwin prompt works fine.

~ $ cmd.exe /c echo "foo"
foo
~ $

  If I want a separate shell, "cygstart cmd.exe" launches it in its own
console window.  Are you running in a console (DOS) window or a terminal such
as rxvt?  It'll only work well in a console.

cheers,
  DaveK

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Inconsistency with sort -n?

[Dave Korn]

Buchbinder, Barry (NIH/NIAID) [E] wrote:
> `sort -n' and `sort -g' work inconsistently with 0 and -0 if there are
> leading spaces.  Sometimes -0 is before 0, as I would expect, and sometimes
> it is afterwards.  Adding `-b' does not seem to help.
>
> Is this where I should report it or should I go upstream?

  Kinda depends where it's coming from. Could be newlib, could be cygwin,
could be sort itself. Either the + and - zeros aren't being correctly
converted to their float representations, or the comparison of + vs. - zero
isn't working right, at a first guess.

> In case you are wondering why I want to do this:  I'm counting items in a
> bin so the bin from -1 to 0 and 0 to +1 are different.

  Hacky work-around: " | sort -r | sort [-n|-g] -s". First alphabetic sort
using -r gets all the negative numbers at the start of the list, then adding
stable flag to the numeric sort preserves their relative ordering when they
compare equal.

> Happy Gregorian New Year!

  Happy Pastafarian Noodly YA!

cheers,
  DaveK

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Re: 1.5.25: Cygwin, LAPACK, and ssh -- output "swallowed"

[Eric Hui]

Jim Kramer wrote:


Eric Hui wrote:

Jim Kramer wrote:


Concise problem description:
A C/C++ program that incorporates LAPACK functions "swallows" program 
output when run (as a command) over an ssh connection.

This may be an issue with your path.  In your example 1, try

ssh hollyberry echo '$PATH'

The LAPACK dll is in /usr/lib/lapack/, so that will need to be in 
your path.





Yes, thank you, that resolved it. To be sure I understand why it wasn't
working as I expected:

When sending a command via ssh, no shell is started and therefore the cygwin
environment (in this case, the library path) is not fully configured. So,
the appropriate path needs to be added someplace such that *Windows* (not
Cygwin) can find it (e.g., the Windows PATH environment variable). Do I have
that right?


Not completely.  I believe that the issue is whether or not it is 
a login shell.  On my system, when a login shell (bash) is 
started, it sources /etc/profile, which in turn sources 
/etc/profile.d/lapack.sh, which adds the appropriate directory to 
the path.


If bash is not run as a login shell (as in your example 1), it 
does not source /etc/profile.



Also, a follow-up question: is there another method for setting paths that
would work under these circumstances? For instance, symbolic links to the
LAPACK library?


Not sure what the recommended method would be.  You could just 
have your .bashrc add the path to the PATH.  It would mean that 
login shells have the path added twice, but it doesn't appear to 
really harm anything.


Perhaps a preferable method might be to wrap your executable with 
a script that sets up the path prior to invoking the executable. 
Then, just invoke the script from ssh.


--
---
Eric C. Hui
---


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Re: 1.5.25: Cygwin, LAPACK, and ssh -- output "swallowed"

[Eric Hui]

Jim Kramer wrote:


Eric Hui wrote:

Jim Kramer wrote:


Concise problem description:
A C/C++ program that incorporates LAPACK functions "swallows" program 
output when run (as a command) over an ssh connection.

This may be an issue with your path.  In your example 1, try

ssh hollyberry echo '$PATH'

The LAPACK dll is in /usr/lib/lapack/, so that will need to be in 
your path.





Yes, thank you, that resolved it. To be sure I understand why it wasn't
working as I expected:

When sending a command via ssh, no shell is started and therefore the cygwin
environment (in this case, the library path) is not fully configured. So,
the appropriate path needs to be added someplace such that *Windows* (not
Cygwin) can find it (e.g., the Windows PATH environment variable). Do I have
that right?


Not completely.  I believe that the issue is whether or not it is 
a login shell.  On my system, when a login shell (bash) is 
started, it sources /etc/profile, which in turn sources 
/etc/profile.d/lapack.sh, which adds the appropriate directory to 
the path.


If bash is not run as a login shell (as in your example 1), it 
does not source /etc/profile.



Also, a follow-up question: is there another method for setting paths that
would work under these circumstances? For instance, symbolic links to the
LAPACK library?


Not sure what the recommended method would be.  You could just 
have your .bashrc add the path to the PATH.  It would mean that 
login shells have the path added twice, but it doesn't appear to 
really harm anything.


Perhaps a preferable method might be to wrap your executable with 
a script that sets up the path prior to invoking the executable. 
Then, just invoke the script from ssh.


--
---
Eric C. Hui
---


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/