happening because he’s not running cygcheck under Cygwin, since
Cygwin won’t start on his system. Hence, c:\cygwin\bin isn’t in the path.
This is also why it skips all the package checks, and why it complains
about things like awk not found.
You don't need mintty to run cygwin. Open a cmd
On Sun, Nov 23, 2014 at 7:37 AM, pichi032 . wrote:
But cygcheck is in the bin folder along with the missing dll .
Is there a way to edit the path so they get recognized ?
Open your Command Prompt the issue the following:
set PATH=C:\PATH\TO\CYGWIN\BIN;%PATH%
After this you should be able to
Regarding the dll it is indeed in the same folder , just checked it. I
even tried installing Cygwin on a friend's computer and it worked on
the first try. Perhaps my sistem is faulty or is there an special way
to install it under windows 8.1 ?
On Sat, Nov 22, 2014 at 5:21 AM, Marco Atzeri
it complains
about things like awk not found.
You don't need mintty to run cygwin. Open a cmd prompt and do
C:\Cygwin\bin\bash -i --login (Or wherever you installed Cygwin).
Don't even need a cmd prompt.
You can just start bash.
True cut if something goes wrong it's real hard to catch
I installed it in my C: drive now.. This is cygcheck output :
By the way Mintty still doesn't work ( Can it possibly be related to
the path with the Nvidia folder ? )
Cygwin Package Information
Package VersionStatus
_autorebase 000291-1 OK
_update-info
On 11/21/2014 4:37 PM, pichi032 . wrote:
I installed it in my C: drive now.. This is cygcheck output :
Not Found: awk
Not Found: bash
Not Found: cat
Not Found: cp
Not Found: cpp (good!)
Not Found: crontab
Found: C:\Windows\system32\find.exe
Not Found: gcc
Not Found: gdb
Not Found: grep
Not
Warning: cygwin1.dll not found on your path
this is curious
It’s happening because he’s not running cygcheck under Cygwin, since Cygwin
won’t start on his system. Hence, c:\cygwin\bin isn’t in the path.
This is also why it skips all the package checks, and why it complains about
things
checks, and why it complains about
things like awk not found.
You don't need mintty to run cygwin. Open a cmd prompt and do
C:\Cygwin\bin\bash -i --login (Or wherever you installed Cygwin).
--
Andrew DeFaria
http://defaria.com
--
Problem reports: http://cygwin.com/problems.html
FAQ
pichi032 . writes:
I installed it in my C: drive now.. This is cygcheck output :
By the way Mintty still doesn't work ( Can it possibly be related to
the path with the Nvidia folder ? )
Go into Windows' system settings and set up an environment variable
CYGWIN_NOWINPATH=1 to test
why it skips all the package checks, and why it complains about
things like awk not found.
You don't need mintty to run cygwin. Open a cmd prompt and do
C:\Cygwin\bin\bash -i --login (Or wherever you installed Cygwin).
Don't even need a cmd prompt.
You can just start bash.
--
WBR,
Andrey
:\cygwin\bin isn’t in the path.
This is also why it skips all the package checks, and why it complains about
things like awk not found.
You don't need mintty to run cygwin. Open a cmd prompt and do
C:\Cygwin\bin\bash -i --login (Or wherever you installed Cygwin).
Don't even need a cmd prompt
On 11/21/2014 7:58 PM, Warren Young wrote:
Warning: cygwin1.dll not found on your path
this is curious
It’s happening because he’s not running cygcheck under Cygwin, since Cygwin
won’t start on his system. Hence, c:\cygwin\bin isn’t in the path.
This is also why it skips all the package
On Nov 19, 2014, at 2:12 PM, pichi032 . perron...@gmail.com wrote:
Cygwin Configuration Diagnostics
I’m afraid it all looks quite normal to me. I can only suggest voodoo:
1. Install to a different directory. If this works, you can try a forced
reinstall to the one you actually wanted to
OK
mintty 1.2-beta1-1OK
p11-kit 0.20.7-1 OK
p11-kit-trust0.20.7-1 OK
popt 1.16-1 OK
rebase 4.4.1-1OK
run 1.3.3-1OK
sed 4.2.2-3
I just read about cygwin and decided to give it a go.. Installed the
64-bit version on Windows 8.1 with default settings but as soon as I
click the Desktop Icon it opens a shell but it immediately closes..
like a glimpse .. I believe that should be Mintty. The path on the
shortcut is the following
On Nov 18, 2014, at 7:56 PM, pichi032 . perron...@gmail.com wrote:
D:\cygwin\bin\mintty.exe -l /Cygwin-Terminal.ico -
What happens if you run that from cmd.exe instead?
If nothing else, you should get some error message that will stick around, so
you can copy it into a reply.
--
Problem
a shell but it immediately closes..
like a glimpse .. I believe that should be Mintty. The path on the
shortcut is the following :
D:\cygwin\bin\mintty.exe -l /Cygwin-Terminal.ico -
any ideas on how to fix this odd issue ?
--
Problem reports: http://cygwin.com/problems.html
FAQ
On Nov 18, 2014, at 8:09 PM, pichi032 . perron...@gmail.com wrote:
same thing.. it glimpses and closes on my face.
How about this, then?
d:\cygwin\bin\mintty.exe /bin/bash -c /bin/sleep 5
--
Problem reports: http://cygwin.com/problems.html
FAQ:
Still the same thing.. and no.. I'm not playing around with u.. =/
On Wed, Nov 19, 2014 at 1:14 AM, Warren Young w...@etr-usa.com wrote:
On Nov 18, 2014, at 8:09 PM, pichi032 . perron...@gmail.com wrote:
same thing.. it glimpses and closes on my face.
How about this, then?
strange thing is that bash works.
On Wed, Nov 19, 2014 at 1:24 AM, pichi032 . perron...@gmail.com wrote:
Still the same thing.. and no.. I'm not playing around with u.. =/
On Wed, Nov 19, 2014 at 1:14 AM, Warren Young w...@etr-usa.com wrote:
On Nov 18, 2014, at 8:09 PM, pichi032 .
On Nov 18, 2014, at 8:24 PM, pichi032 . perron...@gmail.com wrote:
Still the same thing..
In that case, run this from cmd.exe
d:\cygwin\bin\cygcheck -rsv cygcheck.out
Then attach the resulting cygcheck.out file to a reply. Something is broken in
your installation. This command’s
, or the terminal should walk
through the call-tree. Both not very likely to happen.
xterm does the same as mintty BTW.
There must be something more about it:
Mined does resend a received SIGWINCH to its parent (as an application
should indeed) and it's actually received by bash as can be confirmed
On Sat, Oct 18, 2014 at 10:02:33PM +0100, Helmut Karlowski wrote:
When I run for example an editor from a shell in a mintty-window and change
the window-size the editor is informed by a WINCH-signal. That is good. But
the shell it was started from does not know about the change, so after
to happen.
xterm does the same as mintty BTW.
Thanks,
Helmut
--
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
walk
through the call-tree. Both not very likely to happen.
xterm does the same as mintty BTW.
There must be something more about it:
Mined does resend a received SIGWINCH to its parent (as an application
should indeed) and it's actually received by bash as can be confirmed
with 'trap echo WINCH
When I run for example an editor from a shell in a mintty-window and
change the window-size the editor is informed by a WINCH-signal. That is
good. But the shell it was started from does not know about the change, so
after exiting the editor the shell uses the old size. Could mintty send
On 10/16/2014 11:51 PM, John Wiersba wrote:
So maybe you want: run /bin/bash -c /path/to/hashbang/script
This worked for me with a trival mintty-starting hash-bang bash script.
I found your reply on the mailing list archives and quoted it above. Yes,
the same approach worked for me (in my
I'm trying to create a windows shortcut which will start mintty indirectlyby
running a (perl) script which will exec mintty. I know I can start mintty.exe
directly via the shortcut, but the purpose of my script is to wrap the
invocation in the proper environment and arguments.
I'm
On 10/16/2014 10:44 AM, John Wiersba wrote:
I'm trying to create a windows shortcut which will start mintty indirectlyby
running a (perl) script which will exec mintty. I know I can start mintty.exe
directly via the shortcut, but the purpose of my script is to wrap the
invocation
I'm trying to create a Windows shortcut which will start mintty indirectly by
running a (perl) script which will exec mintty. I know I can start mintty.exe
directly via the shortcut, but the purpose of my script is to wrap the
invocation in the proper environment and arguments.
I'm
On 10/16/2014 3:43 PM, John Wiersba wrote:
I'm trying to create a Windows shortcut which will start mintty indirectly by
running a (perl) script which will exec mintty. I know I can start mintty.exe
directly via the shortcut, but the purpose of my script is to wrap the
invocation
...@cs.umass.edu
To: cygwin@cygwin.com
Cc: jrw32...@yahoo.com
Sent: Thursday, October 16, 2014 7:34 PM
Subject: Re: Starting mintty via run.exe
On 10/16/2014 3:43 PM, John Wiersba wrote:
I'm trying to create a Windows shortcut which will start mintty
indirectly by running a (perl) script which
- Original Message -
From: Eliot Moss m...@cs.umass.edu
To: cygwin@cygwin.com
Subject: Re: Starting mintty via run.exe
I think it may be designed to deal only with actual executables (.exe files).
The wording of the man page is ambiguous, but suggestive of this in that it
speaks
I am using mintty with option Text.locale=fr_FR and Character set=UTF-8
Why, then, python3 reports a different encoding (ANSI_X3.4-1968) for
stdout and stdin?
$ cat toto.py
import sys
print(sys.stdin.encoding)
print(sys.stdout.encoding)
$ python3 toto.py
ANSI_X3.4-1968
ANSI_X3.4-1968
Thanks
I am using mintty with option Text.locale=fr_FR and Character set=UTF-8
Why, then, python3 reports a different encoding (ANSI_X3.4-1968) for
stdout and stdin?
I found the issue:
I had LANG=fr_FR.UTF-8 and at the same time LC_ALL=C
I removed LC_ALL=C and my python3 script works with UTF-8 i/o
On Tue, Jul 8, 2014 at 8:00 PM, Andrey Repin anrdae...@yandex.ru wrote:
Greetings, Pawel Jasinski!
The way I understand it, mintty sets the LANG variable according to
user settings.
Would it make sense for mintty to invoke cmd /c chcp selected
(SetConsoleOutputCP)?
mintty does not use
The way I understand it, mintty sets the LANG variable according to
user settings.
Would it make sense for mintty to invoke cmd /c chcp selected
(SetConsoleOutputCP)?
mintty does not use the console at all. A chcp call doesn't make
any sense.
Sorry for asking stupid question. My knowledge
Greetings, Pawel Jasinski!
The way I understand it, mintty sets the LANG variable according to
user settings.
Would it make sense for mintty to invoke cmd /c chcp selected
(SetConsoleOutputCP)?
mintty does not use the console at all. A chcp call doesn't make
any sense.
Sorry for asking
On Jul 7 00:16, Pawel Jasinski wrote:
The way I understand it, mintty sets the LANG variable according to
user settings.
Would it make sense for mintty to invoke cmd /c chcp selected
(SetConsoleOutputCP)?
mintty does not use the console at all. A chcp call doesn't make
any sense.
Corinna
The way I understand it, mintty sets the LANG variable according to
user settings.
Would it make sense for mintty to invoke cmd /c chcp selected
(SetConsoleOutputCP)?
In case of no. Would it make sense to place a hint in a .bashrc about it?
--pawel
--
Problem reports: http://cygwin.com
Nice detective work, really. The goldstar is well deservered :)
On May 15 04:00, Shaddy Baddah wrote:
I quickly worked out that the code has a bug for %i. At some point
the code was changed to push and pop the parameters being passed (0 and
39 in my eg.). However, the %i select/case block
Hi,
On 2014-05-15 04:15+1000, Andrew Schulman wrote:
snip
snip
I can't understand why the ./conftest.exe differ. Trying to emulate by
hand, I cannot reproduce it. But it is now very late here, and I can't
debug anymore.
I'm hoping that I've provided enough of a lead for someone of authority
Hi Corinna,
On 2014-05-15 17:17+1000, Corinna Vinschen wrote:
Nice detective work, really. The goldstar is well deservered :)
On May 15 04:00, Shaddy Baddah wrote:
I quickly worked out that the code has a bug for %i. At some point
the code was changed to push and pop the parameters being
On May 15 22:54, Shaddy Baddah wrote:
Hi Corinna,
On 2014-05-15 17:17+1000, Corinna Vinschen wrote:
Nice detective work, really. The goldstar is well deservered :)
On May 15 04:00, Shaddy Baddah wrote:
I quickly worked out that the code has a bug for %i. At some point
the code was
In any case, I've tested the patch below, and it solves the immediate
problem with screen. It probably needs to go upstream too... I'd put
my hand up, but I'm unsure where upstream is exactly.
I've uploaded a new test release of screen that incorporates this patch. So
we'll see if it fixes the
H,
On 2014-05-15 02:46+0100, Andrew Schulman wrote:
snip/
The problem only occurs with screen on 64-bit Cygwin. The 32-bit appears
to work correctly. The problem is that when screen is run in mintty, it
seems to exclude the bottom line, reducing the actual size of the
buffer. Further
snip
The 32-bit defines TERMINFO:
config.h:
/*
* Define TERMINFO if your machine emulates the termcap routines
* with the terminfo database.
* Thus the .screenrc file is parsed for
* the command 'terminfo' and not 'termcap'.
*/
#define TERMINFO 1
configure.log:
On Wed, May 14, 2014 at 02:15:38PM -0400, Andrew Schulman wrote:
snip
The 32-bit defines TERMINFO:
config.h:
/*
* Define TERMINFO if your machine emulates the termcap routines
* with the terminfo database.
* Thus the .screenrc file is parsed for
* the command 'terminfo' and not
I'm hoping that I've provided enough of a lead for someone of authority
to decide where things are right, and where things are wrong.
Yes, I think so!
Thanks a lot, Shaddy. That takes us a long way to a solution. I'll look
at it from there as soon as I can.
Andrew suggested that
is that when screen is run in mintty, it
seems to exclude the bottom line, reducing the actual size of the
buffer. Further, something goes awry at the top. So that if you run
emacs -nw or less from within, scrolling via the keys acts very
strangely.
If you detach or simply exit the screen session
appears
to work correctly. The problem is that when screen is run in mintty, it
seems to exclude the bottom line, reducing the actual size of the
buffer. Further, something goes awry at the top. So that if you run
emacs -nw or less from within, scrolling via the keys acts very
strangely.
If you
. The problem is that when screen is run in mintty, it
seems to exclude the bottom line, reducing the actual size of the
buffer. Further, something goes awry at the top. So that if you run
emacs -nw or less from within, scrolling via the keys acts very
strangely.
If you detach or simply exit
it:
echo -ne \e[0;This is a test\a; sleep 5
That way, the title, if it's getting set at all, will remain set for a
few seconds before it gets reset, so you can see it. That will allow
you to tell the difference between a problem where the escape sequence
is never reaching mintty because something
[0;This is a test\a; sleep 5
That way, the title, if it's getting set at all, will remain set for a
few seconds before it gets reset, so you can see it. That will allow
you to tell the difference between a problem where the escape sequence
is never reaching mintty because something is eating
to support manually setting the
title; this was rejected on the grounds that echoing an appropriate
sequence would do the same thing
(http://code.google.com/p/mintty/issues/detail?id=241). Unfortunately,
that does not seem to be true after connecting to a remote system, or at
least it is not true
prompt is ineffective.
If I start a new shell from within screen (Ctl-a c), the echo
command works from there.
Fundamentally, this is nothing to do with Cygwin. MinTTY will change
the terminal title if it receives the escape sequence to do so. The
title will stay the same if something intercepts
not connecting via cygwin.
Ross Boylan
Someone put in a request for a feature to support manually setting the
title; this was rejected on the grounds that echoing an appropriate sequence
would do the same thing
(http://code.google.com/p/mintty/issues/detail?id=241). Unfortunately, that
does not seem
Well, that problem happened all day yesterday.
Today there is no such problem.
I have not done anything on the system since then, but that is the situation
today.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
On 1/25/2014 3:04 PM, Steven Bardwell wrote:
I would like to understand why Cygwin style paths do not work in a CMD
(DOS)
window on my 32-bit Cygwin system, but work fine on my 64-bit Cygwin
install.
Here is a simple example of the issue:
#include stdio.h
#include stdlib.h
#include
On 1/24/2014 9:40 PM, KARR, DAVID wrote:
-Original Message-
Larry Hall (Cygwin)
Sent: Friday, January 24, 2014 12:14 PM
Subject: Re: mintty shell gets frequent 8~ strings inserted into input
On 1/24/2014 2:57 PM, KARR, DAVID wrote:
-Original Message-
Larry Hall (Cygwin)
Sent
On 1/25/2014 5:27 PM, Larry Hall (Cygwin) wrote:
On 1/24/2014 9:40 PM, KARR, DAVID wrote:
-Original Message-
Larry Hall (Cygwin)
Sent: Friday, January 24, 2014 12:14 PM
Subject: Re: mintty shell gets frequent 8~ strings inserted into input
On 1/24/2014 2:57 PM, KARR, DAVID wrote
On 1/25/2014 3:04 PM, Steven Bardwell wrote:
I would like to understand why Cygwin style paths do not work in a CMD (DOS)
window on my 32-bit Cygwin system, but work fine on my 64-bit Cygwin
install.
Here is a simple example of the issue:
#include stdio.h
#include stdlib.h
#include string.h
Greetings, Larry Hall (Cygwin)!
I would like to understand why Cygwin style paths do not work in a CMD (DOS)
window on my 32-bit Cygwin system, but work fine on my 64-bit Cygwin
install.
Here is a simple example of the issue:
#include stdio.h
#include stdlib.h
#include string.h
#include
I'm on Cygwin 1.7.26 on Win7.
I run mintty with C:\Cygwin\bin\mintty.exe -e /bin/bash --login.
Every minute or so, or randomly, my mintty shell prompt gets the string 8~
inserted. If I leave the shell there, it will end up with a string of them.
What might be causing this?
--
Problem
On 1/24/2014 2:00 PM, KARR, DAVID wrote:
I'm on Cygwin 1.7.26 on Win7.
I run mintty with C:\Cygwin\bin\mintty.exe -e /bin/bash --login.
Every minute or so, or randomly, my mintty shell prompt gets the string
8~ inserted. If I leave the shell there, it will end up with a string of
them. What
-Original Message-
Larry Hall (Cygwin)
Sent: Friday, January 24, 2014 11:35 AM
Subject: Re: mintty shell gets frequent 8~ strings inserted into input
On 1/24/2014 2:00 PM, KARR, DAVID wrote:
I'm on Cygwin 1.7.26 on Win7.
I run mintty with C:\Cygwin\bin\mintty.exe -e /bin/bash
On 1/24/2014 2:57 PM, KARR, DAVID wrote:
-Original Message-
Larry Hall (Cygwin)
Sent: Friday, January 24, 2014 11:35 AM
Subject: Re: mintty shell gets frequent 8~ strings inserted into input
On 1/24/2014 2:00 PM, KARR, DAVID wrote:
I'm on Cygwin 1.7.26 on Win7.
I run mintty with C
On Fri, Jan 24, 2014 at 07:57:46PM +, KARR, DAVID wrote:
On Friday, January 24, 2014 11:35 AM, Larry Hall wrote:
On 1/24/2014 2:00 PM, KARR, DAVID wrote:
I'm on Cygwin 1.7.26 on Win7.
I run mintty with C:\Cygwin\bin\mintty.exe -e /bin/bash --login.
Every minute or so, or randomly, my mintty
On Fri, Jan 24, 2014 at 03:19:58PM -0500, Christopher Faylor wrote:
On Fri, Jan 24, 2014 at 07:57:46PM +, KARR, DAVID wrote:
On Friday, January 24, 2014 11:35 AM, Larry Hall wrote:
On 1/24/2014 2:00 PM, KARR, DAVID wrote:
I'm on Cygwin 1.7.26 on Win7.
I run mintty with C:\Cygwin\bin
-Original Message-
Larry Hall (Cygwin)
Sent: Friday, January 24, 2014 12:14 PM
Subject: Re: mintty shell gets frequent 8~ strings inserted into input
On 1/24/2014 2:57 PM, KARR, DAVID wrote:
-Original Message-
Larry Hall (Cygwin)
Sent: Friday, January 24, 2014 11:35 AM
On Dec 2 23:58, Charles Butterfield wrote:
-Original Message-
From: Dave Kilroy [mailto:BZ]
http://cygwin.com/acronyms/#PCYMTNQREAIYR
On 01/12/2013 21:09, Corinna Vinschen wrote:
Are you starting mintty with run as administrator by any chance?
Corrina's right - check
On 03/12/2013 10:21, Corinna Vinschen wrote:
On Dec 2 23:58, Charles Butterfield wrote:
Any suggestions on how to have a shortcut (or something similar) that
runs mintty as admin, but has no global effect on other mintty launches?
You seem to have gotten something else wrong here
On Dec 3 13:13, Dave Kilroy wrote:
On 03/12/2013 10:21, Corinna Vinschen wrote:
On Dec 2 23:58, Charles Butterfield wrote:
Any suggestions on how to have a shortcut (or something similar) that
runs mintty as admin, but has no global effect on other mintty launches?
You seem to have gotten
On Dec 3 14:32, Corinna Vinschen wrote:
On Dec 3 13:13, Dave Kilroy wrote:
On 03/12/2013 10:21, Corinna Vinschen wrote:
On Dec 2 23:58, Charles Butterfield wrote:
Any suggestions on how to have a shortcut (or something similar) that
runs mintty as admin, but has no global effect
that to execute mintty correctly it needs admin privileges, so it
always runs mintty this way. The latter is the one that just affects the
shortcut.
Dave.
Thanks! I had NO idea there were TWO admin checkboxes.
Now I have a solution to both of my problems, and I'm feeling happy again :-)
OOPS, I suspect
On 01/12/2013 21:09, Corinna Vinschen wrote:
On Dec 1 15:48, Charles Butterfield wrote:
-Original Message-
From: David Kilroy [mailto:kilr...@googlemail.com]
Can you run the following commands from mintty running bash vs cmd
running bash:
cygpath -u y:\apps
test -d /cygdrive/y/apps
-Original Message-
From: Dave Kilroy [mailto:kilr...@googlemail.com]
On 01/12/2013 21:09, Corinna Vinschen wrote:
Are you starting mintty with run as administrator by any chance?
Corrina's right - check that the same user is being used in both cases.
I don't think this would explain
)
but neither variable worked.
I then noticed that if I start bash from a cmd.exe emulator (and adjust the
path to
Include /bin), that I can see (and cd to) a mapped drive. But I cannot see
(via ls)
the mapped drive when using mintty.
From cmd.exe+bash: (Y: is the mapped drive
-Original Message-
From: David Kilroy [mailto:kilr...@googlemail.com]
Can you run the following commands from mintty running bash vs cmd
running bash:
cygpath -u y:\apps
test -d /cygdrive/y/apps
echo $?
Result of the first command should be /cygdrive/y/apps 2nd command
On Dec 1 15:48, Charles Butterfield wrote:
-Original Message-
From: David Kilroy [mailto:kilr...@googlemail.com]
Can you run the following commands from mintty running bash vs cmd
running bash:
cygpath -u y:\apps
test -d /cygdrive/y/apps
echo $?
Result of the first
On 29/11/2013 22:11, Charles Butterfield wrote:
Dave wrote:
Can you clarify which isn't working:
a) a network share mapped to a drive letter, e.g N:\my\network\location
This is my situation. I have my Y: drive mapped to a Linux Samba server. See
more details below
b) network share
that if I start bash from a cmd.exe emulator (and adjust the
path to
Include /bin), that I can see (and cd to) a mapped drive. But I cannot see
(via ls)
the mapped drive when using mintty.
From cmd.exe+bash: (Y: is the mapped drive)
$ ls -l
On Sat, Nov 30, 2013 at 08:41:35AM +, Dave Kilroy wrote:
On 29/11/2013 22:11, Charles Butterfield wrote:
In any event, I have cobbled together something that resembles a reply
to an email that I have really scraped off the web archive. That seems
awfully complicated. Surely I'm missing
mintty -s bash
chere -i -2 -t mintty -s bash
A related clue is that when using a mintty terminal I cannot see network shares
in /cygdrive, but when using the default chere shell I can see the network
shares mapped to drives (e.g. /cygdrive/y/...).
Any suggestions?
Can you clarify which isn't
Dave wrote:
Can you clarify which isn't working:
a) a network share mapped to a drive letter, e.g N:\my\network\location
This is my situation. I have my Y: drive mapped to a Linux Samba server. See
more details below
b) network share accessed via \\ e.g. \\server\path\my\network\location
downloaded a version of mintty 1.0.3 from a download site and unzipped all
the content but no mintty executable can be found there either.
Any suggestions on how to repair the Cygwin setup-x86_64 installation to have
mintty ?
Sincerely,
Matthias Hettwer
, it can't be found anywhere on the hard drive.
I downloaded a version of mintty 1.0.3 from a download site and unzipped
all the content but no mintty executable can be found there either.
Right. This is not a supported way of obtaining and installing a package.
It won't work. While it's
cygwin on Windows 8 64 bit. Packages installation
worked fine but it seems Mintty is missing. I reinstalled cygwin
setup-x86_64 [version 2.819-64 bit] by adding mintty (both bin and
src) under shell tab (1.2-beta-1.1 version), but it seems that error
still persists.
Target path is - C
On 6 September 2013 16:49, Manoj Navandar wrote:
I recently installed cygwin on Windows 8 64 bit. Packages installation
worked fine but it seems Mintty is missing. I reinstalled cygwin
setup-x86_64 [version 2.819-64 bit] by adding mintty (both bin and
src) under shell tab (1.2-beta-1.1 version
Hello Team,
I recently installed cygwin on Windows 8 64 bit. Packages installation
worked fine but it seems Mintty is missing. I reinstalled cygwin
setup-x86_64 [version 2.819-64 bit] by adding mintty (both bin and
src) under shell tab (1.2-beta-1.1 version), but it seems that error
still
Hi,
I've just installed the 64-bit Cygwin port but encountered a few problems.
First of all, there seems to be a problem with the mintty package. While it's
marked as installed in the setup, /bin/mintty does not exist so I cannot fire
up the terminal. I suspect the package has not been
On Tue, Sep 03, 2013 at 11:07:07PM -0700, Bogdan wrote:
Hi,
I've just installed the 64-bit Cygwin port but encountered a few
problems.
First of all, there seems to be a problem with the mintty package.
While it's marked as installed in the setup, /bin/mintty does not exist
so I cannot fire up
Il 9/4/2013 8:07 AM, Bogdan ha scritto:
Hi,
I've just installed the 64-bit Cygwin port but encountered a few problems.
wrong mailing list for problems use cygwin (at) cygwin.com
First of all, there seems to be a problem with the mintty package. While it's
marked as installed in the setup
26.08.2013 22:54, schrieb John Koelndorfer:
I seem to have run into some trouble with focus reporting in mintty
1.1.2 and tmux 1.8 running on a remote Arch Linux host. tmux does not
seem to catch the focus reporting control characters properly and will
allow the ^[[O and ^[[I to bleed through
, schrieb John Koelndorfer:
I seem to have run into some trouble with focus reporting in mintty
1.1.2 and tmux 1.8 running on a remote Arch Linux host. tmux does not
seem to catch the focus reporting control characters properly and will
allow the ^[[O and ^[[I to bleed through to applications. Here
26.08.2013 22:54, schrieb John Koelndorfer:
I seem to have run into some trouble with focus reporting in mintty
1.1.2 and tmux 1.8 running on a remote Arch Linux host. tmux does not
seem to catch the focus reporting control characters properly and will
allow the ^[[O and ^[[I to bleed through
I seem to have run into some trouble with focus reporting in mintty
1.1.2 and tmux 1.8 running on a remote Arch Linux host. tmux does not
seem to catch the focus reporting control characters properly and will
allow the ^[[O and ^[[I to bleed through to applications. Here is
how I have tested
Am 26.08.2013 22:54, schrieb John Koelndorfer:
I seem to have run into some trouble with focus reporting in mintty
1.1.2 and tmux 1.8 running on a remote Arch Linux host. tmux does not
seem to catch the focus reporting control characters properly and will
allow the ^[[O and ^[[I to bleed
David,
thanks for your advice. It didn't run right off the bat, but with some
proper single and double quoting. The fact that env takes a command as an
argument is what enabled it to work.
Cheers.
The normal way works and even
$ PATH=${PATH}: mintty cmd
The command line
I am attempting to create a desktop icon for cygwin based applicatin.
I am using
mkshortcut and mintty with the program to be invoked's name as am argument
to mintty.
The problem I'm encountering is that the applicatin that mintty is to run
requires
/usr/lib/lapack which
1001 - 1100 of 2219 matches
Mail list logo
