cgf wrote:
I thought that maybe something like:
cat FIFO 42FIFO
might work since that would cause cat to keep FIFO open for input and
output but that just hangs on both cygwin and linux.
Probably the right thing to do is:
in one shell:
$ cat fifo
in the other shell:
$ exec 6fff
$ echo
Process substitution in bash is not working for me currently. I'm pretty
certain it worked at some point in the past (maybe about 6 months ago).
For example:
$ cat ( echo hello)
hangs, ignoring ^C, kill -9, and requiring kill -f on the cat
process.
Reading the bash manual, it seems bash can
I looked and this doesn't seem to have been mentioned in the archives.
You can cd to any random subdirectory of a directory in the /proc
filesystem, irrespective of whether it exists. Examples:
$ cd /proc/banana
$ ls
ls: .: Not a directory
$ cd /proc/self/banana
$ ls
ls: .: Not a directory
$ cd
There's an interesting interaction with the recent changes to coreutils
here, too:
$ ln -s /proc/banana ooo
$ rm ooo
rm: cannot lstat `ooo.exe': No such file or directory
Who said anything about ooo.exe, just delete ooo :-)
Lev
--
Unsubscribe info:
I tried building bash from the source package, and then it uses either
/dev/fd (if I have that as a symlink) or /proc/self/fd (if I don't),
rather than the fifo that the binary package uses. So perhaps whoever
built the binary package didn't have /proc/self/fd for whatever reason?
With my built
Brian Dessent wrote:
If I'm not mistaken /proc/pid/fd capabilty was added 2005-02-01. The
current bash package (2.05b-16) was released 2003-10-23. (the test
version -17 was released 2004-11-22.) So it was quite impossible for
the person who built bash to have that feature.
Thanks for this
Corina wrote:
In the Linux kernel there's some magic
going on which we can't reproduce in Cygwin so far. Trying to open
an existing pipe for writing or reading opens apparently exactly the
right end of the pipe under Linux. On Windows, you only get the exact
end of the pipe which is already
On Thu, 14 Apr 2005, Lev S Bishop wrote:
Corina wrote:
^^
Sorry, Corinna.
--
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
This is not a new issue, but at some point in the past year or so, my
xterm startup time got much much longer. I never really thought about it
until now because I thought I just needed to defrag my hard drive or
something, but I've just done a whole bunch of spring cleaning and it's
still
Solved my own problem. I ran fc-cache and now xterm kicks off in under a
second... I have:
dir/cygdrive/c/windows/fonts//dir
In my /etc/fonts/local.conf so there's quite a few fonts to scan, which I
guess explains the delay. Question: the man page for fontconfig (man
fonts-conf) states
The recent changes from LoadIcon to LoadImage, while technically The Right
Thing, have made the default X icon less pretty in the small size (ie in
window titles, on the taskbar). I can explain in detail the cause of this
if anyone cares. Last night I was toying in my head with a few ideas for
Earle wrote:
Sure, I'd like to hear the cause!
When you use LoadIcon(), windows keeps track of the original source of the
icon, so that if a different sized icon is required, it can go back to
that resource/file and load up the appropriate sized icon from there. If
you use loadimage, then it
Earle wrote:
Anyone who knows any apps that compile under cygwin that use the render
cursors, I'd be interested in hearing about them so I can do some coding
and testing...
Well, emacs compiles under cygwin, but the version distributed with cygwin
doesn't use render. But I know for a fact
Harold wrote:
Now you are getting somewhere... the implication of BuildFreeType NO
is that you are going to use the installed version since we set
HasFreeType YES, but this does not appear to be the case. We'll either
have to fix the build rules or just set BuildFreeType to YES but not
Harold wrote:
Lev S Bishop wrote:
- the resulting module gets statically linked into libXfont.a (rather
than being a loadable module, as it would be in many other X servers,
since we don't do loadable modules on cygwin/x), and from there gets
linked into XWin.exe and xfs.exe (I understand
Harold wrote:
What more do you want? You must not have read the end of my last
message very clearly.
I just didn't want you to do a complete rebuild with the wrong flags and
break something that worked before or waste your time any more than
needed. Just trying to spell everything out as
16 matches
Mail list logo