Re: rxvt in native mode, widely spaced characters

[Lemke, Michael SZ/HZA-ZIOM1]

Daniel Barclay wrote:

 Well, I didn't specify anything.  I haven't touched any of
 /etc/X11/app-defaults/Rxvt, ~/.Xdefaults or ~/.Xresources, or given
any
 options on the command line Iused to invoke rxvt.
 
...
 Just now, I tried installing the ruby package, and as soon as I
started 
 rxvt,
 it started in messed-up form--widely spaced characters, in yellow, on
a 
 dark
 blue background--rather than the way it started immediately 
 before--normally
 spaced characters, in black, on a white background.

I just did something much simpler - update cygwin with setup.exe.
After that I see the same crap fonts.


Either install the bitstream vera fonts in your Windows sytem, (e.g. go

to Control Panel/Fonts...
http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/

Or change the specified font.  You can do the latter by editing the 
/etc/X11/app-defaults/Rxvt file itself, 

This I did (following your helpful instructions) and just commented out
the two lines referring to fonts.  And voila, nice readable fonts.
There is nothing font-related in my ~/.Xdefaults.

or overriding it for your 
particular account by
  (1) creating a ~/.Xdefaults file that specifies a different font
  (2) explicitly starting rxvt with the '-fn some font' option


So my question is why does the default .../app-defaults/Rxvt specify
these useless fonts?  It didn't before, it seems to work nicely
without them, and breaks in the default settings with them.  So why
not toss them altogether?

Michael

--
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: bug with touch t/

[Lemke, Michael SZ/HZA-ZIOM1]

On Thu, 6 Mar 2008 16:32:52 +0100, Corinna Vinschen wrote:
 On Mar  6 16:27, Corinna Vinschen wrote:
  On Mar  6 14:56, Eric Blake wrote:
   Corinna Vinschen corinna-cygwin at cygwin.com writes:
   

But the flags are not O_RDONLY|O_CREAT.  They are
O_WRONLY|O_CREAT.
   
   I still think Linux is wrong - t/ is not an existing directory, so
you can't 
   claim that an attempt was made to open an existing directory with
O_WRONLY.  
   But I guess it is a bit ambiguous, since if t/ did exist, then
opening t/. 
   should indeed fail with EISDIR; at any rate, it is certainly more
efficient to 
   blindly reject O_WRONLY due to the trailing slash without even
checking for the 
   existence of t.
  
  In our case I added a special case to emit EISDIR, otherwise we
would
  get ENOENT automatically (that's what STATUS_OBJECT_NAME_INVALID
gets
  converted to).  However, I'm somewhat puzzled that you used that
bash
  example:
  
$ :  t/
bash: t/: Is a directory.
  
  If what you said is right, and if I revert the change to
fhandler.cc,
  we would get a ENOENT in that case, too.  And given your arguments,
  that should be correct.
  
  Do you agree?
 
 I should add that I'm still rather leaning towards the Linux
behaviour.
 I tested this on Solaris 10, and it behaves again different.  In both
 examples open(2) returns with ENOTDIR.


And for what it's worth, on AIX 5.3 they succeed:

open(t/, O_WRONLY|O_CREAT|O_LARGEFILE)= 3
open(t/, O_RDONLY|O_CREAT|O_LARGEFILE)= 3

But:
open(t/., O_WRONLY|O_CREAT|O_LARGEFILE)   Err#2  ENOENT
open(t/., O_RDONLY|O_CREAT|O_LARGEFILE)   Err#2  ENOENT


And so they do on Solaris 8:

open64(t/, O_WRONLY|O_CREAT|O_LARGEFILE, 0666) = 3
open64(t/, O_RDONLY|O_CREAT|O_LARGEFILE, 0666) = 3

open64(t/., O_WRONLY|O_CREAT|O_LARGEFILE, 0666) Err#2 ENOENT
open64(t/., O_RDONLY|O_CREAT|O_LARGEFILE, 0666) Err#2 ENOENT


So it's the same on both OS and Linux is different.

Michael

--
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/