Re: TERM=dummy
Greetings, Fedin Pavel! > Today i've noticed, that in MSYS console Do note that this is Cygwin mailing list, not msys. > TERM=dummy. Why ? > Previously it was set to "cygwin", and it worked fine. I guess this was > caused by some upgrade. -- WBR, Andrey Repin (anrdae...@freemail.ru) 19.06.2012, <10:50> Sorry for my terrible english... -- 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
Re: Trusted Software Vendor
On Jun 19 04:25, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > >> Out of curiosity would downloading setup.exe using wget also work > >> around the problem? > >> >>> > >> >>>Most likely. I don't think wget cares about protecting Windows users > >> >>>from their own stupidity. If you use wget, you should know what you're > >> >>>doing. > >> >>> > >> >>>How about you just give it a try? > >> >> > >> >> Er, I don't have this problem. I wasn't the one reporting it. > >> > Downloading setup.exe with wget has another problem. The downloaded > >> > file is missing the +x bit, IIRC. > >> > >> It's irrelevant for setup.exe. > > > It's not. Try to start any executable on a NTFS filesystem. Remove > > the executable bits from all entries in the ACL. Try again. > > Sure that will cause issues, but read quote from the start. > If you download setup.exe using wget, it's unlikely you'll be unable to run > it. > You need to do some real tinkering first to prevent that. I was solely referring to the common misconception that the execute bit has no meaning for Windows excecutables. Some people even think the execute bit is just faked by Cygwin(*). I can't let this go without commenting on it. Corinna (*) which it is, but only on filesystems which don't support permissions at all, like FAT/FAT32. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
RE: cygwin 1.7.15: svn disk I/O error
Rolf Campbell wrote: > Recently, I've noticed cygwin svn getting a LOT of errors during > operations. I think this started when upgrading from 1.7.14 to 1.7.15, > but I can't say for sure. The nature of these errors are as follows: > > $ svn up > Updating '.': > svn: E200030: disk I/O error, executing statement 'RELEASE s6' > svn: E200030: sqlite: unable to open database file > svn: E200030: sqlite: unable to open database file > > > $ svn cleanup > svn: E200030: disk I/O error, executing statement 'RELEASE s79' > > > I've had the same problem, and have found a solution: this appears for me to be an interaction with TortoiseSVN, which I have on my machine and which is entirely unaware of Cygwin. Disabling TortoiseSVN's icon cache has completely resolved the issue for me. You can do this by running TortoiseSVN's Settings program, going to "Icon Overlays", and selecting "None" under "Status cache", then hitting Apply. That may explain why Rolf's been hitting this despite apparently having no AV installed. Adam -- 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
Re: Cygwin unstable as hell on Windows7 64bit
On 19.06.2012 14:50, Gerard H. Pille wrote: Since my system was replaced by one running Windows 7 on an Intel Core I5, I may call myself lucky if I can work for an hour. Works fine here. May be your hardware is flaky ? RAM for example... Cygwin loads up the system quite well, especially upon fork(). -- Kind regards Pavel Fedin Expert engineer, Samsung Moscow research center -- 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
Re: Cygwin unstable as hell on Windows7 64bit
On 6/19/2012 6:55 AM, Fedin Pavel wrote:> On 19.06.2012 14:50, Gerard H. Pille wrote: >> Since my system was replaced by one running Windows 7 on an Intel Core I5, I may call myself lucky >> if I can work for an hour. > Works fine here. May be your hardware is flaky ? RAM for example... Cygwin loads up the system quite > well, especially upon fork(). I would also look for a) BLODA, and b) need to rebase (though recent cygwins do that automatically) I've been running on Windows 7 for years without difficulty, but in the transition had difficulty from some BLODA that I could have found if I had looked carefully to begin with ... Regards -- Eliot Moss -- 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
Re: Cygwin unstable as hell on Windows7 64bit
On 19/06/2012 6:55 AM, Fedin Pavel wrote: On 19.06.2012 14:50, Gerard H. Pille wrote: Since my system was replaced by one running Windows 7 on an Intel Core I5, I may call myself lucky if I can work for an hour. Works fine here. May be your hardware is flaky ? RAM for example... Cygwin loads up the system quite well, especially upon fork(). That or a particularly virulent BLODA... The fact that shells crash while idle hints strongly that the blame lies outside Cygwin; if other random apps (particularly the memory hogs like web browsers and email clients) aren't crashing, that points to BLODA rather than bad RAM. I'd also do a virus scan: some malware monitors the process list and kills anything it thinks might be used to detect or attack it; command prompts usually rank high on the hit list. (I'm running 64-bit win7 on a core I5 without troubles for the last 18 months or so) Ryan -- 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
RE: UNIX groups in CYGWIN
> Why not allow (and generate with mkgroup) URL encoding e.g. > "Domain%20Users"? Good idea that'd hopefully work, too! Anton Lavrentiev Contractor NIH/NLM/NCBI -- 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
Re: /bin and /lib mount points occasionally lost
richw wrote:
>
> I occasionally find that cygwin is broken, and I find that /usr/bin and
> /usr/lib no longer are useful. The mount command (for which I need to type
> /bin/mount) shows nothing mounted there. I type the following two
> commands:
> mount c:/cygwin/bin /usr/bin
> mount c:/cygwin/lib /usr/lib
> and things work (through reboots) for a while, and then break again.
> Any hints how I can keep this from happening, or what might cause it?
>
>
I believe I have figured out how to reproduce this problem. It seems to be
caused by accessing an nfs server before running cygwin.bat to run bash. But
in case that's not enough information, I'll give a complete sequence. Here's
a cygcheck -s -v -r > cygcheck.out:
http://old.nabble.com/file/p34037768/cygcheck.out cygcheck.out
First, install the cygwin nfs server. Here's my /etc/exports:
> / (ro,no_root_squash)
>
[Yeah, security!]
Reboot.
Run putty and use a serial port to talk to my TS-7250 embedded computer
(embeddedarm.com).
> 50:/root # uname -a
> Linux ts7200 2.4.26-ts9 #151 Mon Feb 13 16:01:46 MST 2006 armv4l unknown
> 50:/root # cat /etc/profile
> [snip]
> m()
> {
> mount | grep nfs >/dev/null
> if [ $? -ne 0 ]; then
> mount 192.168.1.40:/ /mnt
> fi
> cd /mnt/home/rw
> }
> 50:/root # m
> 50:/mnt/home/rw #
>
[I probably did an 'ls' too, but didn't get that copied]
Now, click my cygwin.bat icon:
> bash: id: command not found
> bash: /usr/bin/hostname: No such file or directory
> bash: sed: command not found
> bash: ls: command not found
> bash: /usr/bin/locale: No such file or directory
> bash: /usr/bin/tzset: No such file or directory
> bash: id: command not found
>
> rw@seven ~
> $ mount
> bash: mount: command not found
>
> rw@seven ~
> $ /bin/mount
> C:/cygwin on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
>
> rw@seven ~
>
A reboot fixes the problem, as long as I run cygwin.bat before I access nfs.
--
View this message in context:
http://old.nabble.com/-bin-and--lib-mount-points-occasionally-lost-tp34007108p34037768.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
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
Re: /bin and /lib mount points occasionally lost
richw writes: [...] > A reboot fixes the problem, as long as I run cygwin.bat before I access nfs. The problem quite likely lies with your 11 different copies of cygwin1.dll. You start the NFS server and it picks up one of those, just not the one for your actual Cygwin installation. Now Cygwin is hosed until no process uses cygwin1.dll anymore or you reboot. What is the output from '/bin/uname -a' when your Cygwin has stopped working? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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
Re: /bin and /lib mount points occasionally lost
ASSI wrote: > > richw writes: > [...] >> A reboot fixes the problem, as long as I run cygwin.bat before I access >> nfs. > > The problem quite likely lies with your 11 different copies of > cygwin1.dll. You start the NFS server and it picks up one of those, > just not the one for your actual Cygwin installation. Now Cygwin is > hosed until no process uses cygwin1.dll anymore or you reboot. > > What is the output from '/bin/uname -a' when your Cygwin has stopped > working? > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > Wavetables for the Waldorf Blofeld: > http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables > > > -- > 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 > > > All the superfluous copies of cygwin1.dll are long gone or renamed. After reboot & nfs access: bash: id: command not found > bash: /usr/bin/hostname: No such file or directory > bash: sed: command not found > bash: ls: command not found > bash: /usr/bin/locale: No such file or directory > bash: /usr/bin/tzset: No such file or directory > bash: id: command not found > > rw@seven ~ > $ /bin/uname -a > CYGWIN_NT-6.1-WOW64 seven 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin > > rw@seven ~ > $ -- View this message in context: http://old.nabble.com/-bin-and--lib-mount-points-occasionally-lost-tp34007108p34038496.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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
Re: cygwin 1.7.15: svn disk I/O error
On 2012-06-19 05:29, Adam Dinwoodie wrote: Rolf Campbell wrote: $ svn up Updating '.': svn: E200030: disk I/O error, executing statement 'RELEASE s6' svn: E200030: sqlite: unable to open database file svn: E200030: sqlite: unable to open database file $ svn cleanup svn: E200030: disk I/O error, executing statement 'RELEASE s79' I've had the same problem, and have found a solution: this appears for me to be an interaction with TortoiseSVN, which I have on my machine and which is entirely unaware of Cygwin. Disabling TortoiseSVN's icon cache has completely resolved the issue for me. You can do this by running TortoiseSVN's Settings program, going to "Icon Overlays", and selecting "None" under "Status cache", then hitting Apply. That may explain why Rolf's been hitting this despite apparently having no AV installed. Adam That's a very interesting discovery. I certainly am using TortoiseSVN. There must be some interaction between the most recent version of sqlite and TortoiseSVN's status scanner. I've been playing around with sqlite versions and I've confirmed what others have stated that it's only a problem with v3.7.12.1 and NOT a problem with v3.7.3. I've upgraded back to v3.7.12.1 and disabled TortoiseSVN's icon scanner. It appears to resolve the problem for me as well. I would hate to add TortoiseSVN to the BLODA. -- 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
Re: /bin and /lib mount points occasionally lost
richw writes: >> rw@seven ~ >> $ /bin/uname -a >> CYGWIN_NT-6.1-WOW64 seven 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin Your cygcheck.out said I should be expecting a 1.7.11 version here. So maybe you didn't nuke all extra versions or your cygcheck output wasn't for your actual installation... Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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
Re: cygwin 1.7.15: svn disk I/O error
Rolf Campbell writes: > I would hate to add TortoiseSVN to the BLODA. The icon cache _is_ dodgy — at least the one for TortoiseGit, which needs to be restarted regularly. But getting back to SQLite, backing out the changes in the build would get us back a different bug. So it would be very interesting if you could debug where it hits that roadblock in svn. I suspect that svn does not deal with the file being locked exclusively (when TortoiseSVN accesses the database) and some call through the windows interface blocked. Note that SQLite isn't really designed for concurrent access to the database file from a different process. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- 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
Re: cygwin 1.7.15: svn disk I/O error
On 6/19/2012 3:18 PM, Achim Gratz wrote: I suspect that svn does not deal with the file being locked exclusively (when TortoiseSVN accesses the database) and some call through the windows interface blocked. It's possible svn has a timer on the call that results in a SQL call through SQLite, and when this doesn't return as fast as svn thinks it ought to, it bombs out, complaining that there "must" be a disk I/O problem. What may actually be happening is that Windows' aggressive locking strategy has set up a deadlock between two processes. As for why .3 and .12 behave differently, it's probably because one or more locks that used to be owned by the SQLite DLL that are now owned by the Cygwin DLL. That is, files are being accessed on the DLL's behalf by Cygwin now, rather than directly through the Windows API. Since Cygwin doubtless does file I/O differently than SQLite did, for the same basic reason that any two programmers tend to write code differently, there's a new conflict. If this is the case, the best solution may be for TortoiseSVN to stop grabbing files for long-term exclusive use. It should only be locking the svn DB files as long as is necessary to make some change. Note that SQLite isn't really designed for concurrent access to the database file from a different process. There is a paucity of truth in that statement. See the SQLite FAQ: https://sqlite.org/faq.html#q5 But, there's only so much SQLite can do to cooperate with the OS's locking strategy. On POSIX systems where SQLite was born, locking is mostly advisory and cooperative, whereas Windows gives you mandatory locks by default in a lot of cases. Mandatory locks allow one process (e.g. TortoiseSVN) to deny another (e.g. Cygwin svn) the ability to change a file, indefinitely. -- 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
Re: /bin and /lib mount points occasionally lost
ASSI wrote: > > richw writes: >>> rw@seven ~ >>> $ /bin/uname -a >>> CYGWIN_NT-6.1-WOW64 seven 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin > > Your cygcheck.out said I should be expecting a 1.7.11 version here. So > maybe you didn't nuke all extra versions or your cygcheck output wasn't > for your actual installation... > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > Waldorf MIDI Implementation & additional documentation: > http://Synth.Stromeko.net/Downloads.html#WaldorfDocs > > > -- > 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 > > > You are looking at the wrong version of cygcheck.out somehow. After my initial series of communications, in addition to removing all the surplus cygwin1.dll files, I updated everything, and included an updated cygcheck.out. Look for it in a message dated June 19, since that's the date on the file. An excerpt from that file: 2235k 2012/05/09 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 "cygwin1.dll" v0.0 ts=2012/5/9 9:25 Cygwin DLL version info: DLL version: 1.7.15 -- View this message in context: http://old.nabble.com/-bin-and--lib-mount-points-occasionally-lost-tp34007108p34039888.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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
Re: Bashrc distinguish between mintty and x-windows xterm
Andy wrote:
| Ken Jackson jackson.io> writes:
|> Fri, May 25, 2012 at 09:32AM -0400 Buchbinder, Barry
|> (NIH/NIAID) [E] wrote:
|>> Andrew Hancock sent the following at Friday, May 25, 2012 12:42 AM
|>>>Barry, it works flawlessly. Thanks immensely!
|>>
|>> But I forgot to export ThisTerm, otherwise it is always unset when
|>> a subshell is launched.
|>
|> Access to the /proc file system is fast, so you could forgo the
|> variable and access it directly:
|>
|> case "$(< /proc/$PPID/exename)" in
|> */xterm) echo "This is an xterm" ;;
|> */mintty) echo "This is a mintty" ;;
|> esac
|
|Barry, Ken,
|
|Thanks for your valuable scripting examples. It sent me scurrying back to the
|man page to figure out case/esac and command substitution. It's also a good
|reminder of the wealth of detail available in /proc.
For the record, this in .bashrc seems to work well in xterm's white background
and mintty's black background.
case "$(< /proc/$PPID/exename)" in
*/xterm) function setPS1() {
PS1="\[\033]0;\w\007\033[32m\]\u@\h \[\033[35m\w\033[0m\]\n$" ;
echo xterm
} ;;
*/mintty) function setPS1() {
PS1="\[\e]0;\w\a\]\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$" ;
echo mintty
} ;;
esac
--
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
Re: /bin and /lib mount points occasionally lost
On 6/20/2012 3:07 AM, richw wrote: ASSI wrote: richw writes: rw@seven ~ $ /bin/uname -a CYGWIN_NT-6.1-WOW64 seven 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin Your cygcheck.out said I should be expecting a 1.7.11 version here. So maybe you didn't nuke all extra versions or your cygcheck output wasn't for your actual installation... Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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 You are looking at the wrong version of cygcheck.out somehow. After my initial series of communications, in addition to removing all the surplus cygwin1.dll files, I updated everything, and included an updated cygcheck.out. Look for it in a message dated June 19, since that's the date on the file. An excerpt from that file: 2235k 2012/05/09 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 "cygwin1.dll" v0.0 ts=2012/5/9 9:25 Cygwin DLL version info: DLL version: 1.7.15 cool down your message of 19 Jun http://cygwin.com/ml/cygwin/2012-06/msg00336.html has still an old one cygcheck.out as link. "Cygwin Configuration Diagnostics Current System Time: Wed Jun 13 12:37:37 2012 2748k 2012/02/24 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 "cygwin1.dll" v0.0 ts=2012/2/24 5:05 Cygwin DLL version info: DLL version: 1.7.11 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 260 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 so please so kind to provide us the right and updated info Regards Marco -- 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
Re: cygwin 1.7.15: svn disk I/O error
Warren Young writes: >> Note that SQLite isn't really designed for concurrent access >> to the database file from a different process. > > There is a paucity of truth in that statement. So let me re-formulate that sentence: concurrent access ultimately relies on the file locking provided by the OS. The concurrency support in SQLite is simply to not keep state outside a critical section and lock the database file exclusively when entering one. > But, there's only so much SQLite can do to cooperate with the OS's > locking strategy. On POSIX systems where SQLite was born, locking is > mostly advisory and cooperative, whereas Windows gives you mandatory > locks by default in a lot of cases. Mandatory locks allow one process > (e.g. TortoiseSVN) to deny another (e.g. Cygwin svn) the ability to > change a file, indefinitely. Cygwin should (and apparently does) abstract away that difference. But it seems that the locking strategy might be slightly different between Win32 and POSIX, triggering a foray into that "disk I/O error" branch. There may still be a bug some place else, i.e. it may get a timeout rather than a "file locked" state. I'll have a look when I find some time. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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
Re: /bin and /lib mount points occasionally lost
marco atzeri-4 wrote: > > > cool down > your message of 19 Jun > http://cygwin.com/ml/cygwin/2012-06/msg00336.html > ... > has still an old one cygcheck.out as link. > so please so kind to provide us the right and updated info > > Regards > Marco > > > > -- > 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 > > > I apologize. I have apparently been bitten by uploading two different files with the same name. When I clicked on the link in the message of the 19th, I got the correct file. So, after a name change, we have: http://old.nabble.com/file/p34040469/cygcheck2.out cygcheck2.out -- View this message in context: http://old.nabble.com/-bin-and--lib-mount-points-occasionally-lost-tp34007108p34040469.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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
cygwin terminal acting strange, backspace not working
Hey, I've just freshly installed and reinstalled and reinstalled cygwin, currently I got the "full installation". On another maschine, everything works fine. The strange things here are: 1) no color! Well, I don't care, but I think I should see my user-name in front of each line and it should be green, but it's just white on black.. like the windows command-window. 2) backspace is working, but the graphics is not acting correctly. So when I type "helllo", then remove the "lo" because there is an L to much, then type "o" again, it will work but it looks like this: helllo o If I execute the command, then use the up-arrow, it will show correctly. 3) ssh is not working, it's telling me "bad address", but it works perfectly on the other maschine with the same command in the same network.. So what did I do wrong? Thanks a bunch! hutauf -- View this message in context: http://old.nabble.com/cygwin-terminal-acting-strange%2C-backspace-not-working-tp34040724p34040724.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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
