Re: Escape colour codes
* Matthew Woehlke (Tue, 03 Apr 2007 16:55:45 -0500) > Thorsten Kampe wrote: > > lftp and yafc show a wrong prompt in the following terminals: cmd, 4nt, > >> console and far manager. Basically each coloured part of the prompt is > >> surrounded by two "funny faces" - the first is white and the second has > >> the desired colour. > > I don't know what these are. Are they non-Cygwin applications that are > looking at the environment variable 'PS1'? No, these are Cygwin applications using Cygwin readline and allowing you to define your own application specific prompt (similar to the PS1 prompt syntax used in bash and zsh). > Cygwin apps (e.g. 'printf') should cope with escapes correctly even > in Windows consoles That's exactly the point. They actually do cope with the escapes - just not with the \001 and \002 used by readline to calculate the length of the line. > (otherwise even bash would not work). Yes, bash is the exception. Maybe bash doesn't use \001/\002? > > Obvioulsy all Windows terminals can't interpret those "non-visible > > characters" (or they don't ignore them like they should or readline > > doesn't "eat" them like it should). > > > > Where is the culprit here? Cygwin readline not correctly interacting > > with non Cygwin terminals? Windows terminals not understanding common > > readline(?) escape characters? > > Windows consoles don't understand escapes, period. Also AFAIK nothing > except readline understands \[ and \]. But Cygwin understands escapes so > Cygwin applications should work even in a Windows console. Okay, so it's obviously a readline (or Cygwin) bug. I think it's a readline thing (as rxvt doesn't have the problem) - the question is just where to submit a bug report? To the Cygwin readline maintainer or upstream? Thorsten -- 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.24 remote launch of java gui
On Apr 3 15:41, Elliston, Jack W CTR USA TRADOC NSC wrote: > It works via an interactive ssh connection but does not work when using > "ssh -f machine2 app" > > Am I doing something wrong? ssh -f -t machine2 app Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Problems between rsync and current sbnapshot ?
On Apr 4 00:11, Angelo Graziosi wrote: > Iwant to flag that 'rsync' seems to hang with current > (20070330) snapshot: > -- > $ rsync -av --delete ftp.dante.de::CTAN/systems/win32/miktex /tmp > > receiving file list ... done > -- > > > > now it hangs, it takes 100% of CPU. I must use CTRL-C: Works for me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Upgrade from cygwin-1.5.23-2 to 1.5.24-2 creates CMD windows when running fetchmail for each fetched mail
On Apr 3 08:58, Dr. Volker Zell wrote: > Hi > > Sorry for being late. > For each mail fetched with fetchmail-6.3.1-1 or 6.3.6-1 from an IMAP server a > new CMD window is > created and then closed. I'm running fetchmail under X. The problem > disappears when downgrading > to 1.5.23-2. I don't see any change between 1.5.23 and 1.5.24 which would explain a difference like this. The ChangeLog is rather short. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
vlc configure conftest.exe error cygwin1.dll
Hi! I use the latest cygwin program I'm trying to compile VLC. After message : checking whether a program can dlopen itself I got windows error message: conftest.exe has encountered a problem Error signature conftest.exe Appver: 0.0.0.0 ModName: cygwin1.dll ModVer: 1005.24.0.0 Offset 00092d77 I confirm message and configure continues. Next line after error is: checking whether to build shared libraries ... no When I do make it shows error lack of libvlc.so. How I can repair that error? Should I update some modules of Cygwin or it is VLC software fault? Thanks, Krystian -- 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.24 remote launch of java gui
Thanks for the suggestions. New info: 1) The "ssh -f -t machine2 app" does not work and leaves my terminal on machine1 unusable. 2) If I start sshd on machine2 in a cygwin window as a user then my "ssh -f machine2 app" works like a champ, however, if I start sshd as a windows service then the "ssh -f machine2 app" does not work but if I am actually logged in to machine2 via ssh then running the app works fine. Jack > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Corinna Vinschen > Sent: Wednesday, April 04, 2007 2:41 AM > To: cygwin@cygwin.com > Subject: Re: 1.5.24 remote launch of java gui > > On Apr 3 15:41, Elliston, Jack W CTR USA TRADOC NSC wrote: > > It works via an interactive ssh connection but does not work when > > using "ssh -f machine2 app" > > > > Am I doing something wrong? > > ssh -f -t machine2 app > > > Corinna > > -- > Corinna Vinschen Please, send mails > regarding Cygwin to > Cygwin Project Co-Leader cygwin AT cygwin DOT com > Red Hat > > -- > 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: Escape colour codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Thorsten Kampe on 4/4/2007 1:38 AM: > That's exactly the point. They actually do cope with the escapes - > just not with the \001 and \002 used by readline to calculate the > length of the line. > >> (otherwise even bash would not work). > > Yes, bash is the exception. Maybe bash doesn't use \001/\002? I need a simple test case. Readline indeed uses \001 and \002 for internal purposes, but I'm not sure whether bash does as well, or whether it is confined to readline. Generally, readline is supposed to remove its internal markers before displaying to the screen. There may be some interaction where bash uses these markers correctly but your other app is using them in such a way that readline leaks them to the terminal. > > Okay, so it's obviously a readline (or Cygwin) bug. > > I think it's a readline thing (as rxvt doesn't have the problem) - the > question is just where to submit a bug report? To the Cygwin readline > maintainer or upstream? You've already reported it to the cygwin readline/bash maintainer. You are also welcome to ask upstream, since the upstream maintainer knows more about what readline actually expects with \1 and \2, but you need to be sure your test case is simple enough that Chet can reproduce your situation, or you won't get much of his time. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] volunteer cygwin readline maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGE6Vh84KuGfSFAYARAjoQAKC+7kty1U9d7hGu3tFCTw6ysmVIaQCeNNSy 1Ade2Wuf4fSU8iolpwu2/6Q= =nAUW -END PGP SIGNATURE- -- 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: httpd
ssh-host-config was a great help Here is what I entered. cygrunsrv -I httpd -d "CYGWIN httpd" -p /usr/sbin/httpd -a -D -y tcpip I then typed net start httpd The following messages then came up The CYGWIN httpd service is starting The CYGWIN httpd service could not be started The service did not report an error It is the case that the command "cygrunsrv -L" does list httpd as an installed service I did notice that when a remote reboot is done on Windows 2003, everything comes (e.g, sshd) but it takes an hour for the GUI to come up so that I can use Remote Desktop. I wonder if that could be the problem? At 11:21 PM 4/3/2007, you wrote: On Tue, 3 Apr 2007, Terry Bailey wrote: > I am running Cygwin on Windows 2003. What is the best way to > automatically start /usr/sbin/httpd automatically when I boot Windows? Install it as a service. To see how to do this on Win2k3, examine the ssh-host-config script from the openssh package. You might also want to read the ntsec section of the User's Guide. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Freedom is just another word for "nothing left to lose"... -- Janis Joplin -- 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: [Packaging error] Re: [ANNOUNCEMENT] Updated: mingw-runtime-3.12-1
>I thought it was decided to keep the MinGW Runtime man pages separate >from the Cygwin man pages? Yes, it was, but I don't remember concluding that putting them in /usr/man was the solution. Please either don't install them at all or put them in a mingw-specific location. Sorry, I must have come to the wrong conclusion. I had thought that since Cygwin by default installs man pages to /usr/share/man installing the MinGW specific man pages in /usr/man as long as they were prefixed with 'mingw-' was OK. This allows users to do a 'man mingw-dirname' without having to modify their MANPATH. If it's desired that they not be included, I'll produce an updated release with them removed. Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org -- 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: bash improperly sets PATH containing period
Pavel Kudrna wrote: > Hi, > when dos(win32) path contains period, e.g. "c:." bash instead of > converting to "/cygdrive/c" incorrectly copies > this string into PATH variable including colon! > (Such dos path containing period is legal and is used in Novell Client > as search drives.) > Pavel Kudrna > > C:\temp> path c:\temp;c:.;s:\public > > C:\temp> path > PATH=c:\temp;c:.;s:\public > > C:\temp> "C:\Program Files\cygwin\bin\bash.exe" --login -i > > [EMAIL PROTECTED] ~ > $ echo $PATH > /usr/X11R6/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/temp:c:.:/cygdri ve/s/public:/usr/local/cint I, too, ran into this problem, and it was also due to Novell, although I believed at the time that our IT department had done it. In my book, this is a bug on Novell's part, because the 'c:.' notation in Windows-land means 'current directory on the C: drive.' This is process-specific, for one thing; for another, as soon as a subprocess happens to go to that drive and change the current directory, the path is changed! This may not matter for the initial process upon login, which won't do be changing its CWD on any drives, but it can mess up other processes started later. I ended up writing a BASH script which invoked a GAWK script (probably could have combined the two) to fix the PATH variable. The latter script invoked a quickie BAT script to get the CWD on the Netware drive: REM This command is a NO-OP so that ERRORLEVEL is reset to ZERO. c:/WINNT/system32/attrib.exe . > nul if . == .%1 goto end cd %1 > nul if NOT errorlevel 1 %1 if NOT errorlevel 1 %cygwindir%/bin/pwd if . == .%2 goto end %SystemDrive% :end The element of the PATH was passed as %1; I believe I used %2 during testing so that I didn't change _my_ PATH. There was more involved than this (I can post the scripts if anybody is interested), but the idea is what's important: Use 'pwd' in a subprocess to print the actual directory on the Netware drive and resplace the bogus PATH element with the _real_ directory. Goss ... Innovation for Business NOTICE: This e-mail and any attachment(s) may contain confidential and proprietary information of Goss International Corporation and/or its subsidiaries and may be legally privileged. This e-mail is intended solely for the addressee. If you are not the addressee, dissemination, copying or other use of this e-mail or any of its content is strictly prohibited and may be unlawful. If you are not the intended recipient please inform the sender immediately and destroy the e-mail and any copies. All liability for viruses is excluded to the fullest extent permitted by law. Any views expressed in this message are those of the individual sender. No contract may be construed by this e-mail. -- 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: [Packaging error] Re: [ANNOUNCEMENT] Updated: mingw-runtime-3.12-1
On Wed, 4 Apr 2007, Chris Sutcliffe wrote: > > >I thought it was decided to keep the MinGW Runtime man pages separate > > >from the Cygwin man pages? > > > > Yes, it was, but I don't remember concluding that putting them in > > /usr/man was the solution. Please either don't install them at all or > > put them in a mingw-specific location. > > Sorry, I must have come to the wrong conclusion. I had thought that > since Cygwin by default installs man pages to /usr/share/man > installing the MinGW specific man pages in /usr/man as long as they > were prefixed with 'mingw-' was OK. This allows users to do a 'man > mingw-dirname' without having to modify their MANPATH. > > If it's desired that they not be included, I'll produce an updated > release with them removed. IMO, if they are already prefixed by "mingw-", they can go into /usr/share/man -- there's no chance they'll be confused with Cygwin's manpages. But perhaps we should move this discussion to -apps, and inform this list of the final decision. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Freedom is just another word for "nothing left to lose"... -- Janis Joplin -- 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: [Packaging error] Re: [ANNOUNCEMENT] Updated: mingw-runtime-3.12-1
Igor Peshansky wrote: On Wed, 4 Apr 2007, Chris Sutcliffe wrote: I thought it was decided to keep the MinGW Runtime man pages separate >from the Cygwin man pages? Yes, it was, but I don't remember concluding that putting them in /usr/man was the solution. Please either don't install them at all or put them in a mingw-specific location. Sorry, I must have come to the wrong conclusion. I had thought that since Cygwin by default installs man pages to /usr/share/man installing the MinGW specific man pages in /usr/man as long as they were prefixed with 'mingw-' was OK. This allows users to do a 'man mingw-dirname' without having to modify their MANPATH. If it's desired that they not be included, I'll produce an updated release with them removed. IMO, if they are already prefixed by "mingw-", they can go into /usr/share/man -- there's no chance they'll be confused with Cygwin's manpages. But perhaps we should move this discussion to -apps, and inform this list of the final decision. Disclaimer: I don't really pay attention to the mingw man pages (but I agree they should not be "found" by default). Anyway, here's a thought that might be useful (unfortunately it seems to need a change to man to work nicely*); rather than prefixing pages, add them to a 'mingw' section. This way you can find them with 'man -S mingw ', and users that felt so inclined could add 'mingw' to their MANSECT. Naturally, you could use symlinks to do this *and* prefix them. (* 'man mingw ' does not work, it seems -S must be used :-(.) -- Matthew "Will somebody get this walking carpet out of my way?!" -- Princess Leia Organa -- 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: Escape colour codes
* Eric Blake (Wed, 04 Apr 2007 07:17:22 -0600)
> According to Thorsten Kampe on 4/4/2007 1:38 AM:
> > That's exactly the point. They actually do cope with the escapes -
> > just not with the \001 and \002 used by readline to calculate the
> > length of the line.
> >
> >> (otherwise even bash would not work).
> >
> > Yes, bash is the exception. Maybe bash doesn't use \001/\002?
>
> I need a simple test case.
It's easy to show that one Cygwin application (lftp) has a problem
with its prompt but it's rather lenghty to show that not lftp is the
culprit but readline making output to Windows Terminals (Cmd, 4NT,
Console, FAR manager, Poderosa)
1. Install lftp, start cygwin.bat
2. Start lftp. Type
set cmd:prompt "\[\e[1;36m\]>\[\e[m\] "
...you will see that the instead of a light cyan "> " prompt you will
get "> " surrounded by white/cyan-cyan/white "Funny Faces" (control
characters).
Conclusion: there is something wrong with lftp or readline or the
Terminal.
3. Run lftp from rxvt: you see that the prompt displays fine
Conclusion: there is nothing wrong with lftp.
4. Read Matthew Woehlke's statement "Windows consoles don't understand
escapes, period."
Conclusion: there is nothing wrong with the Windows Terminal, readline
might have a bug.
--
5. install yafc (http://yafc.sourceforge.net/) - another popular Linux
FTP client (from source because there is no package yet)
6. Insert
prompt1 "%{\e[1;36m%}>%{\e[m%} "
into your yafcrc and start yafc
7. You will see exactly the same as in 2. with lftp
Conclusion: there is nothing wrong with yafc, but with readline or Cmd
8. Repeat 3. with yafc and see the same result
Conclusion: there is nothing wrong but readline might have a bug.
--
9. Install Python and IPython (http://ipython.scipy.org/moin/)
set
prompt_in1 '\C_White[\#\C_White]\C_LightCyan>>> '
prompt_out '\C_White[\N\C_White]'
in your ipythonrc and start IPython. Type 1 [Enter]
you will see exactly the same as in 2. And 7. for the out prompt
10. Repeat step 3. with IPython: you will see exactly the same as in
3. and 8.
11. Install Windows Python and pyreadline (Python readline for
Windows) and use the same IPython from the Cygwin installation. Repeat
step 3.: the prompt displays fine
Conclusion: pyreadline doesn't make the Windows Terminal show Control
characters
12. Remove the \001/\002 constructs in line 88 and 89 from
ColorANSI.py in Cygwin IPython
from
Normal = '\001\033[0m\002' # Reset normal coloring
_base = '\001\033[%sm\002' # Template for all other colors
to
Normal = '\033[0m' # Reset normal coloring
_base = '\033[%sm' # Template for all other colors
See that Cygwin IPython with Windows terminal now displays correctly
--
13. Recompile yafc, comment out lines 167 and 172 in prompt.c
case '{': /* begin non-printable character string */
#ifdef HAVE_LIBREADLINE
// ins = "\001\001"; /* \001 +
RL_PROMPT_START_IGNORE */
#endif
break;
case '}': /* end non-printable character string */
#ifdef HAVE_LIBREADLINE
// ins = "\001\002"; /* \001 + RL_PROMPT_END_IGNORE */
#endif
Now see that yafc does not show the Control characters as "Funny
Faces" anymore.
--
I tried to modify the lftp source, too, but my C knowledge was not
sufficient
char StartIgn[3], EndIgn[3];
/* bash adds the extra \001 too, don't know why */
StartIgn[0] = '\001';
StartIgn[1] = RL_PROMPT_START_IGNORE;
StartIgn[2] = 0;
EndIgn[0] = '\001';
EndIgn[1] = RL_PROMPT_END_IGNORE;
EndIgn[2] = 0;
Thorsten
--
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: [Packaging error] Re: [ANNOUNCEMENT] Updated: mingw-runtime-3.12-1
On Wed, Apr 04, 2007 at 09:57:17AM -0400, Chris Sutcliffe wrote: >>>I thought it was decided to keep the MinGW Runtime man pages separate >>>from the Cygwin man pages? >> >>Yes, it was, but I don't remember concluding that putting them in >>/usr/man was the solution. Please either don't install them at all or >>put them in a mingw-specific location. > >Sorry, I must have come to the wrong conclusion. I had thought that >since Cygwin by default installs man pages to /usr/share/man >installing the MinGW specific man pages in /usr/man as long as they >were prefixed with 'mingw-' was OK. This allows users to do a 'man >mingw-dirname' without having to modify their MANPATH. > >If it's desired that they not be included, I'll produce an updated >release with them removed. I'd rather have them available but I don't want you to invent a new top-level directory to put them in: % tar vtjf mingw-runtime-3.12-1.tar.bz2 | grep /man/ tar: Record size = 8 blocks drwxr-xr-x ironhead/Administrators 0 2007-03-26 03:01:02 usr/man/ drwxr-xr-x ironhead/Administrators 0 2007-03-26 03:04:38 usr/man/man3/ -rw-r--r-- ironhead/Administrators 8956 2007-03-26 03:04:38 usr/man/man3/basename.3 -rw-r--r-- ironhead/Administrators 8956 2007-03-26 03:04:37 usr/man/man3/dirname.3 These should be installed in usr/share/man and basename.3 should become mingw-basename.3. Ditto for dirname. 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: [Packaging error] Re: [ANNOUNCEMENT] Updated: mingw-runtime-3.12-1
On Apr 4 10:12, Matthew Woehlke wrote: > Anyway, here's a thought that might be useful (unfortunately it seems to > need a change to man to work nicely*); rather than prefixing pages, add > them to a 'mingw' section. This way you can find them with 'man -S mingw > ', and users that felt so inclined could add 'mingw' to their MANSECT. This sounds like a good idea to me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: [Packaging error] Re: [ANNOUNCEMENT] Updated: mingw-runtime-3.12-1
% tar vtjf mingw-runtime-3.12-1.tar.bz2 | grep /man/ tar: Record size = 8 blocks drwxr-xr-x ironhead/Administrators 0 2007-03-26 03:01:02 usr/man/ drwxr-xr-x ironhead/Administrators 0 2007-03-26 03:04:38 usr/man/man3/ -rw-r--r-- ironhead/Administrators 8956 2007-03-26 03:04:38 usr/man/man3/basename.3 -rw-r--r-- ironhead/Administrators 8956 2007-03-26 03:04:37 usr/man/man3/dirname.3 Whoops, forgot the configure option to prefix the man pages when compiling. Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org -- 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: Login shell ZSH spins when executed from SSH session
Err, I am sorry, I did not mean to send the email here... -- VH signature.asc Description: OpenPGP digital signature
Re: Login shell ZSH spins when executed from SSH session
Václav Haisman wrote, On 4.4.2007 20:54: > Err, I am sorry, I did not mean to send the email here... > > -- > VH Err, total confusion...disregard only _this_ email, not the original. signature.asc Description: OpenPGP digital signature
Re: Escape colour codes
Thorsten Kampe thorstenkampe.de> writes:
> > I need a simple test case.
>
> It's easy to show that one Cygwin application (lftp) has a problem
> with its prompt but it's rather lenghty to show that not lftp is the
> culprit but readline making output to Windows Terminals (Cmd, 4NT,
> Console, FAR manager, Poderosa)
>
> 1. Install lftp, start cygwin.bat
>
> 2. Start lftp. Type
> set cmd:prompt "\[\e[1;36m\]>\[\e[m\] "
Yep, I reproduced that. Thanks for the better details.
> Conclusion: there is something wrong with lftp or readline or the
> Terminal.
The bug is in lftp. Read on.
> 6. Insert
> prompt1 "%{\e[1;36m%}>%{\e[m%} "
> into your yafcrc and start yafc
The bug is in yafc.
> 9. Install Python and IPython (http://ipython.scipy.org/moin/)
> set
> prompt_in1 '\C_White[\#\C_White]\C_LightCyan>>> '
> prompt_out '\C_White[\N\C_White]'
> in your ipythonrc and start IPython. Type 1 [Enter]
The bug is in IPython.
>
> 12. Remove the \001/\002 constructs in line 88 and 89 from
> ColorANSI.py in Cygwin IPython
>
> from
> Normal = '\001\033[0m\002' # Reset normal coloring
> _base = '\001\033[%sm\002' # Template for all other colors
>
> to
>
> Normal = '\033[0m' # Reset normal coloring
> _base = '\033[%sm' # Template for all other colors
I'm not sure if this is correct. If you pass invisible characters to readline
without marking them as such, using \1 and \2, then readline messes up the
display width. In other words, I wonder if IPython is adding extra \1
somewhere else in the sequence of things, which is then resulting in the
spurious \1 to the cmd terminal.
> 13. Recompile yafc, comment out lines 167 and 172 in prompt.c
>
> case '{': /* begin non-printable character string */
> #ifdef HAVE_LIBREADLINE
> //ins = "\001\001"; /* \001 +
Actually, that should be:
ins = "\001"; /* RL_PROMPT_START_IGNORE */
> RL_PROMPT_START_IGNORE */
> #endif
> break;
> case '}': /* end non-printable character string */
> #ifdef HAVE_LIBREADLINE
> //ins = "\001\002"; /* \001 + RL_PROMPT_END_IGNORE */
And that should be:
ins = "\002"; /* RL_PROMPT_END_IGNORE */
In other words, the extra \001 is what is resulting in the smiley faces.
> I tried to modify the lftp source, too, but my C knowledge was not
> sufficient
>
>char StartIgn[3], EndIgn[3];
>/* bash adds the extra \001 too, don't know why */
>StartIgn[0] = '\001';
>StartIgn[1] = RL_PROMPT_START_IGNORE;
>StartIgn[2] = 0;
>EndIgn[0] = '\001';
>EndIgn[1] = RL_PROMPT_END_IGNORE;
>EndIgn[2] = 0;
Rewrite that as:
char StartIgn[2], EndIgn[2];
StartIgn[0] = RL_PROMPT_START_IGNORE;
StartIgn[1] = '\0';
EndIgn[0] = RL_PROMPT_END_IGNORE;
EndIgn[1] = '\0';
The bug in all three of these programs is that they are adding spurious \1 into
the string passed to readline. When you call readline("\001\001invisible\001
\002plain"), then readline assumes that anything between the FIRST \001 and the
\002 is invisible (ie. special to the terminal instead of literal output). So
readline thinks that it should PRINT the invisible string "\001invisible\001"
special to the terminal, followed by the visible string "plain". However, as
you noticed, \001 is NOT special to the cmd.com terminal, and results in a
smiley face, and readline is now thoroughly confused (it thinks it is waiting
for input on position 6, but in reality it is waiting for input on position 8,
because you printed literal characters while claiming they were invisible).
Bash, on the other hand, DOES map \[ to the sequence '\001\001' inside of
parse.y's decode_prompt_string(), BECAUSE it later calls expand_prompt_string()
to get rid of the extra \001. It needs to do this so that it can support
PS1='$(foo)' (the prompt is the expansion of command foo), and needed a way to
tell \[ and \] in PS1 apart from literal \001 and \002 resulting from the
expansion of other elements in the prompt string. When the prompt is finally
expanded and ready to hand to readline, the extra \001 _used by bash_ is gone,
leaving only the SINGLE \001 _used by readline_. In other words, the common
bug in all three programs you mentioned is that they copied bash's escape
sequences, but NOT bash's round of internal expansion, prior to calling
readline. The comment in the lftp sources was rather revealing - if the coder
didn't know why bash used an extra \001, they shouldn't have copied that.
Meanwhile, I'm asking the upstream readline maintainer if there is any way to
output a literal printing \001 (cmd.com hollow smiley) without having it be
claimed as invisible (in case you really _wanted_ a smiley in your prompt), and
the converse question of if there is any way to output a literal \002 (cmd.com
solid smiley) as part of an invisible sequence (in case it is possible that
your terminal can change its t
Re: Escape colour codes
Eric Blake wrote:
The bug in all three of these programs is that they are adding spurious \1 into
the string passed to readline. When you call readline("\001\001invisible\001
\002plain"), then readline assumes that anything between the FIRST \001 and the
\002 is invisible (ie. special to the terminal instead of literal output). So
readline thinks that it should PRINT the invisible string "\001invisible\001"
special to the terminal, followed by the visible string "plain". However, as
you noticed, \001 is NOT special to the cmd.com terminal, and results in a
smiley face, and readline is now thoroughly confused (it thinks it is waiting
for input on position 6, but in reality it is waiting for input on position 8,
because you printed literal characters while claiming they were invisible).
Bash, on the other hand, DOES map \[ to the sequence '\001\001' inside of
parse.y's decode_prompt_string(), BECAUSE it later calls expand_prompt_string()
to get rid of the extra \001. It needs to do this so that it can support
PS1='$(foo)' (the prompt is the expansion of command foo), and needed a way to
tell \[ and \] in PS1 apart from literal \001 and \002 resulting from the
expansion of other elements in the prompt string. When the prompt is finally
expanded and ready to hand to readline, the extra \001 _used by bash_ is gone,
leaving only the SINGLE \001 _used by readline_. In other words, the common
bug in all three programs you mentioned is that they copied bash's escape
sequences, but NOT bash's round of internal expansion, prior to calling
readline. The comment in the lftp sources was rather revealing - if the coder
didn't know why bash used an extra \001, they shouldn't have copied that.
Given that three separate programs had *the same bug*, and given that
bash is perhaps the most visible readline user, maybe it would be
worthwhile to mention (briefly) in readline's doc to *not* copy bash's
extra \001 in your own implementation? :-)
Anyway, I'm glad this was resolved without my (mis)help interfering too
much. :-)
--
Matthew
"Will somebody get this walking carpet out of my way?!" -- Princess Leia
Organa
--
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: Escape colour codes
"and this children is why we stick to rxvt and puttyCyg!"
On 4/4/07, Matthew Woehlke <[EMAIL PROTECTED]> wrote:
Eric Blake wrote:
> The bug in all three of these programs is that they are adding spurious \1
into
> the string passed to readline. When you call readline("\001\001invisible\001
> \002plain"), then readline assumes that anything between the FIRST \001 and
the
> \002 is invisible (ie. special to the terminal instead of literal output). So
> readline thinks that it should PRINT the invisible string "\001invisible\001"
> special to the terminal, followed by the visible string "plain". However, as
> you noticed, \001 is NOT special to the cmd.com terminal, and results in a
> smiley face, and readline is now thoroughly confused (it thinks it is waiting
> for input on position 6, but in reality it is waiting for input on position 8,
> because you printed literal characters while claiming they were invisible).
>
> Bash, on the other hand, DOES map \[ to the sequence '\001\001' inside of
> parse.y's decode_prompt_string(), BECAUSE it later calls
expand_prompt_string()
> to get rid of the extra \001. It needs to do this so that it can support
> PS1='$(foo)' (the prompt is the expansion of command foo), and needed a way to
> tell \[ and \] in PS1 apart from literal \001 and \002 resulting from the
> expansion of other elements in the prompt string. When the prompt is finally
> expanded and ready to hand to readline, the extra \001 _used by bash_ is gone,
> leaving only the SINGLE \001 _used by readline_. In other words, the common
> bug in all three programs you mentioned is that they copied bash's escape
> sequences, but NOT bash's round of internal expansion, prior to calling
> readline. The comment in the lftp sources was rather revealing - if the coder
> didn't know why bash used an extra \001, they shouldn't have copied that.
Given that three separate programs had *the same bug*, and given that
bash is perhaps the most visible readline user, maybe it would be
worthwhile to mention (briefly) in readline's doc to *not* copy bash's
extra \001 in your own implementation? :-)
Anyway, I'm glad this was resolved without my (mis)help interfering too
much. :-)
--
Matthew
"Will somebody get this walking carpet out of my way?!" -- Princess Leia
Organa
--
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/
--
Morgan gangwere
"Space does not reflect society, it expresses it." -- Castells, M.,
Space of Flows, Space of Places: Materials for a Theory of Urbanism in
the Information Age, in The Cybercities Reader, S. Graham, Editor.
2004, Routledge: London. p. 82-93.
--
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: [Packaging error] gnome-icon-theme-2.14.2-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dr. Volker Zell wrote: > /usr/share/pkgconfig/gnome-icon-theme.pc from gnome-icon-theme-2.14.2-1 > should be in /usr/lib/pkgconfig/gnome-icon-theme.pc The package is correct. gnome-icon-theme contains solely system-independent data, and hence this belongs in /usr/share. Recent versions of pkg-config include /usr/share/pkgconfig in the standard search path; if `pkg-config --modversion gnome-icon-theme` isn't working for you, then be sure that you have the current pkg-config-0.21-1. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFG/qpiWmPGlmQSMRCI5ZAJ4lpJMEMVK0Nt4OQHLvKsP238X/awCgtH74 6QO4VMw/6cb4b9QBFD1sk9M= =uwAG -END PGP SIGNATURE- -- 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: vlc configure conftest.exe error cygwin1.dll
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 krystian wrote: > After message : checking whether a program can dlopen itself The answer will be no regardless of whatever other problems you are having. On Win32, symbols in executables are not exported, unless you add - -Wl,--export-all-symbols to LDFLAGS. On Linux, -Wl,--export-dynamic is enough to assure this. (I would really like to see binutils fixed wrt this, as it would remove the necessity for hacking around this difference, but I don't know all the history or reasoning behind it.) > I got windows error message: conftest.exe has encountered a problem > Error signature > conftest.exe Appver: 0.0.0.0 ModName: cygwin1.dll ModVer: 1005.24.0.0 > Offset 00092d77 > > I confirm message and configure continues. Not sure about this one. > Next line after error is: > checking whether to build shared libraries ... no > > When I do make it shows error lack of libvlc.so. > > How I can repair that error? > Should I update some modules of Cygwin or it is VLC software fault? Haven't built VLC (yet). If it uses libtool, make sure to autoreconf to pull in Cygwin's current libtool. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFHGupiWmPGlmQSMRCPabAJ4gricl6R7D4ZasGD/DCL9mDrQQFwCgvH8b K4CBmJaMyeQiEghf1tH3D6c= =gOJp -END PGP SIGNATURE- -- 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/
